Multiple Admins

[Theo Willemse]

First off... gShell still rocks!

I love it to see that this once few commands PowerShell module has grown out to one with almost 400 commands.

I do have a question that takes up a lot of time for me and my colleagues.

Is there a possibility that the installer would be extended with the option to install the module for multiple users.

Now... when i install it... it will be available, but other colleagues (if they don't run the "Invoke-GShellScopeManager") will then be running commands on my personal gSuite Admin Account.

It would be nice to see an option that would ask if the user will be using a single Service Account or that there will be multiple Admins.

Hope to hear from you!

[Spencer Varney]

Thanks! I'm really glad you're happy with it!

Damnit, I know I'm long-winded (sorry), but the installer has come up a few times so here's my summary:

Summary

Currently gShell only is set up to install for the user installing it. Adding an option to install for all users and tweaking how it searches for auth files could open functionality up a bit more, but would lessen the security of the authenticated user. This change is possible but would require research and an update to the installer (and I really really hate that installer).

Details

Right now gShell installs into the user directory for the user installing it. If you install it and someone else tries using gShell, it should only work if you never logged out, or if you're all using some shared account.

Currently, if other colleagues want to use gShell (on the same machine) they would need a copy of the files in their own modules directory. If they tried installing it again... I imagine it'd probably work, but would overwrite the uninstallation info in the registry.

(Obviously it's possible to manually load modules from other locations, to set that up to be automatic in a profile script or even to point gShell to look for the auth file in a different spot, but I'm assuming default installations).

Options

That said, an option to install for all users would make sense, though what to do after that is the question. Option 1 would still be an option, but I'd have to figure out what to do for the other:

1) Install at the user level, auth file is at the user level

2a) Install at the system level for all users, user auth files are at the user level.

2b) Install at the system level for all users, auth file is at the system level and is shared with everyone.

2c) Install at the system level for all users, by default gShell will point to the user auth files, but if it sees an auth file in system directory it will use that instead.

For the flexibility, I'm leaning towards 2c. By default it still lets each individual user have their own auth files (which if you're using the .bin format would be very secure and would prevent others from using your auth files, in case that's an issue), but it also allows you to set up essentially a global auth file that everyone would use on that machine.

I don't think going beyond that would be necessary, to be honest, since now you'd be introducing new cmdlets to switch users, or new parameters on every cmdlet to specify which user to use. This would also require another overhaul of the underlying auth files, which is no fun.

Disclaimer

Again, it's worth mentioning that this would lessen the security of the authenticated Google user. If you've got an admin account set up to work with gShell, and you're allowing multiple users to have access to that gShell installation, all users will be able to use that one account for admin work. This reduces accountability and auditing options since you'll never be sure exactly who ran what under that user name (without coorelating other non-google data). 

But, if that works for your environment who am I to say no? :D

Other options

People have asked in the past if the installer could install to a custom directory. Again this is in theory possible but would require research for Wix, and I've not done that for aforementioned reasons. Howver, if we jump in to this I suppose I could look in to this as well.

About the installer

First and foremost, I haven't barely touched that installer since I put it in years ago. Wix (at least at the time) had terrible documentation and it was one of the most annoying things I've ever had to do, but it was free. Since getting it working, I've not touched it for that simple reason. I dread spending more time with it.

Option 2c would (appear to) only require the addition of the 'install for all users' option, and I imagine that is a fairly common and hopefully documented thing, which is a plus for option 2c.

I'm open to other installer alternatives, but this one also has the plus of being plaintext, so people can see in the repository what the installer is doing (if they can decipher the ugly XML). Either way, I'm open to options.

I'm also open to pull requests if anyone wants to take a stab at it - I'm about to have no time at all for the next number of months, so updates may slow to a halt for a while (hint hint).

Let me know what you think!

Cheers,

Spencer

--
You received this message because you are subscribed to the Google Groups "gshell-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gshell-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Theo Willemse]

Hi Spencer,

Thanks for that awesome reply!
Option 2C sounds great, although I think it would be more usefull if it's the other way around. (Check if there is an private auth file, if not use the shared one.

I did some experimenting on my own.

i changed the content of "gShellSettings.config" to:

{

  "SerializeType": "Bin",

  "AuthInfoPath": "gShell"

}

And told my colleagues to run the lines below.

cd $env:USERPROFILE

Set-gShellClientSecrets -ClientId [ClientID].apps.googleusercontent.com -ClientSecret [Client Secret]

Set-GShellDomain -Domain "[private domain"

Get-GAUser $env:USERNAME (if you use the same account name as u use locally.

It's to bad i can't put these variables in the config file tho, should make it a lot more flexible if i could say:

"AuthInfoPath": "$([Environment]::GetFolderPath('MyDocuments'))\gShell"

But maybe that's a nice addition for a future release.

I am afraid i cant help you with your installer tho... not that much knowledge about it.

Cheers.

Theo

[RHMa...@bulldogs.aamu.edu]

In Powershell, there are 2 locations for modules. It would be nice to have gshell install in the "C:\Windows\System32\WindowsPowerShell\v1.0\Modules" directory, and have Google Auth store the Auth File under the user profile AFTER authenticating via invoke-GShellScopeManager.