G Suite SSO with Chrome on Windows

[Primus]

Previously we deliberately didn't look into SSO on Windows (basically we wanted students to learn their email addresses so they could use them reliably at home). Things have now changed and I want to make things a bit smoother but my Google-Fu is letting my down.

 

Does anyone have a link to instructions on how to make SSO work for G Suite using Chrome on Windows please?

 

Thanks!

[rogerdnixon]

We just use the relatively new GCPW tool from Windows - my brief writeup here if you are in an AD environment: https://wpsit.blogspot.com/2021/03/google-login-and-single-sign-on-to.html - this is free.

 

What to ditch AD (as we have done in all primaries), you can manage your Windows devices in the Google Admin console now - you do need Google "Plus" licences - my look at this: https://wpsit.blogspot.com/2020/02/google-mdm-for-windows-10-devices-more.html - things have moved on a bit since I wrote this - lots more features (inc software deployment) - but it gives you and idea.

[Primus]

As always Roger you are a fount of knowledge.

 

I will have to see if Salamander can automate the process of the custom attribute and then we'll need to reverse how we do password changes - at present we change on prem only and sync to G Suite - from your post it sounds like it'll be change on G Suite and have it sync down to AD?

Edited April 1, 2021 by Primus

[Ditto]

With Roger and Salamander, I think you'll be on to a winner!

[rogerdnixon]

You are correct - change passwords on the Google side and the tool syncs them to AD. Don't change them on AD as that causes problems.

[eddyc]

You are correct - change passwords on the Google side and the tool syncs them to AD. Don't change them on AD as that causes problems.

 

I’m curious, if you run GADS, would that not also let the password change from AD also go back up to Google? So if you used both products side by side the accounts would always be in sync as far as passwords go?

[rogerdnixon]

Maybe - not tried as we just change PWs on the Google side.

[TwistedHelixis]

We just use the relatively new GCPW tool from Windows - my brief writeup here if you are in an AD environment: https://wpsit.blogspot.com/2021/03/google-login-and-single-sign-on-to.html - this is free.

 

What to ditch AD (as we have done in all primaries), you can manage your Windows devices in the Google Admin console now - you do need Google "Plus" licences - my look at this: https://wpsit.blogspot.com/2020/02/google-mdm-for-windows-10-devices-more.html - things have moved on a bit since I wrote this - lots more features (inc software deployment) - but it gives you and idea.

This is exactly what I have been wanting to do but wasn't sure where to start :-)

[highsky]

Hybrid with AAD?

 

Azure Active Directory single sign-on (SSO) integration with Google Cloud (G Suite) Connector

This works also with a secondary trusted domain

[SpaceInvader83]

I've been looking at this for a while, trialled and works pretty well, GCPW and management through Google, what's kind of scuppered it for me is the plus licence according to my reseller can only be purchased whole domain and not part domain. It's made me rethink my plans and halted me moving everyone on to a single G-Suite tenancy.

[gh5000]

We just use the relatively new GCPW tool from Windows - my brief writeup here if you are in an AD environment: https://wpsit.blogspot.com/2021/03/google-login-and-single-sign-on-to.html - this is free.

 

What to ditch AD (as we have done in all primaries), you can manage your Windows devices in the Google Admin console now - you do need Google "Plus" licences - my look at this: https://wpsit.blogspot.com/2020/02/google-mdm-for-windows-10-devices-more.html - things have moved on a bit since I wrote this - lots more features (inc software deployment) - but it gives you and idea.

Can't find this online, but I presume you install the MSI on all your client devices, not servers.

 

If so, when and how does the password sync to AD happen. If a user changes the Google password online. If they go to their windows computer and choose Google login does the AD password update then to match. But if they logged into the computer with the normal windows domain method they would have to use the old AD details.

 

Is there a way to stop logging into the desktop using their traditional method with AD, but still have the computer on the domain for management. ie only allow Google logins? Do you just do a deny login right to staff and students on GPO?

[rogerdnixon]

Password sync happens when a user logs in.

 

AD passwords and the AD login bit are not a thing that regular users see or even know exist. They always login with their Google account.

 

You can still login with a local AD account without the Google Login - if you know the account name, password and how to get to the regular login screen - which people don't generally.

 

The vast majority of our devices are ChromeOS - we use this approach to make "legacy" windows device behave login wise to like ChromeOS devices. Works well in the instances where we still have Windows - but the default position is ChromeOS unless there is a very clear need for Windows - so much now.

[gh5000]

Password sync happens when a user logs in.

 

AD passwords and the AD login bit are not a thing that regular users see or even know exist. They always login with their Google account.

 

You can still login with a local AD account without the Google Login - if you know the account name, password and how to get to the regular login screen - which people don't generally.

 

The vast majority of our devices are ChromeOS - we use this approach to make "legacy" windows device behave login wise to like ChromeOS devices. Works well in the instances where we still have Windows - but the default position is ChromeOS unless there is a very clear need for Windows - so much now.

Ok thanks. Currently we do gcds and password sync from AD to GC. I setup a VM with GCPW and was able to login fine with it linking to my AD profile.

 

I then changed my Google password and logged in with that password on the VM. Again fine, but when paper cut client tried to load from the server I got a Windows AD credential prompt. This was because my AD password hadn't been updated to match my new Google one. Should it be that quick?

 

I know I need to check that password complexity is allowing the Google password to pass the AD complexity. Anything else to check if passwords aren't syncing back to AD?

[rogerdnixon]

Have you added the custom attribute on the google side? If not, you can login - but the account is not linked to AD and things like Papercut won't work. The AD password is changed when you login with the Google account immediately - no delay. So if the attribute is set correctly on the Google side it should just work.

[gh5000]

Have you added the custom attribute on the google side? If not, you can login - but the account is not linked to AD and things like Papercut won't work. The AD password is changed when you login with the Google account immediately - no delay. So if the attribute is set correctly on the Google side it should just work.

I did mean to ask about that too. I set it up with custom schemas in GCDS and found a guide that says adding userprincipalname is ok eg [email protected] rather than domain.local\user which your guide does. Any idea if there is a difference?

[rogerdnixon]

Does it look like this is the Google Admin console? Should show addomain\username under the custom attribute (which you must add on the Google side)

[gh5000]

Does it look like this is the Google Admin console? Should show addomain\username under the custom attribute (which you must add on the Google side)

[ATTACH=CONFIG]61441[/ATTACH]

 

Does it look like this is the Google Admin console? Should show addomain\username under the custom attribute (which you must add on the Google side)

[ATTACH=CONFIG]61441[/ATTACH]

 

No, as my previous it would look like [email protected] as I read that you could use that but I do see that the official docs say wps\roger

 

The official docs do say that you can sync this field with GCDS and I managed that using the ad field userprincipalname. However, domain\user isn't held in active directory. So unless someone knows how to get that as an LDAP field I'll need to go back to one of the other API solutions.

 

Suppose best of both will be having gcds sync samaccountname to a field then have a bit of AppsScript running on a trigger to prepend the domain\

[rogerdnixon]

Yep needs to be domain\username in the custom field. I have one school who users GADS to populate the field - but you do need a custom field on AD - another just a powershell script to dump users to a csv and then sync to Drive, import to a Google Sheet and a bit of sheet scripting to populate the field from the Google Sheet.

[gh5000]

Yep needs to be domain\username in the custom field. I have one school who users GADS to populate the field - but you do need a custom field on AD - another just a powershell script to dump users to a csv and then sync to Drive, import to a Google Sheet and a bit of sheet scripting to populate the field from the Google Sheet.

 

Thanks, I've got something setup for getting the custom field populated ok now.

 

Can I check I've got the part about linking AD accounts correct...if a user has previously logged into a computer with AD account, then logs in with GCPW the two will link. If this is the first time a user logs on and logs in only with GCPW then only a local computer profile will be created and there is no link to their AD account/profile and the group policies that go along with that - e.g. mapped drives?

[rogerdnixon]

Assuming the user has their AD account details in the custom field in the Google admin console the following happens:

 

Existing Windows profile: login with Google account and password - use gets prompted for old Windows password - they put in the old Windows password and the AD password is changed to match the Google one and the user logs in and accesses stuff as normal.

 

No existing Windows profile: user logs in with Google login details. AD password is updated to match Google one and user logs in and can access stuff as normal.

 

In both cases normal local group policies apply - network shares etc.

 

If you have not linked AD to Google with the custom attribute, then as far as Windows is concerned you are logging in as a local user not an AD one.

[gh5000]

Assuming the user has their AD account details in the custom field in the Google admin console the following happens:

 

Existing Windows profile: login with Google account and password - use gets prompted for old Windows password - they put in the old Windows password and the AD password is changed to match the Google one and the user logs in and accesses stuff as normal.

 

No existing Windows profile: user logs in with Google login details. AD password is updated to match Google one and user logs in and can access stuff as normal.

 

In both cases normal local group policies apply - network shares etc.

 

If you have not linked AD to Google with the custom attribute, then as far as Windows is concerned you are logging in as a local user not an AD one.

 

Ok, that's what I hoped because the alternative is ridiculous. But that's the situation I'm currently in.

 

If I login to the AD computer first with an AD account. Logout, then login with the associated Google account, then I follow what you have said for "Existing Windows profile" - prompt for old Windows password, Group policies apply, etc So I know that my Enhanced Desktop Security custom schema is in place. I can recreate this with multiple accounts.

 

However, if I delete that user profile from the computer or use another computer where the AD account hasn't previously been logged in, and try first to login with GCPW then I only get a local Windows profile created. No links to active directory.

 

I enabled verbose logging on GCPW and the most useful error is "MakeUsernameForAccount: No valid sid mapping found.Fallback to create a new local user account". If I add a key for the users AD SID with their email address value then the link occurs e.g. HKLM\SOFTWARE\Google\GCPW\Users\S-1-5-21-2785799904-2391824654-440469764-13604\email = [email protected]

[rogerdnixon]

Hmm - not sure. Not seen that behaviour. I'd suggest raising a support ticket as see what Google says.

[mproffitt1983]

Yep needs to be domain\username in the custom field. I have one school who users GADS to populate the field - but you do need a custom field on AD - another just a powershell script to dump users to a csv and then sync to Drive, import to a Google Sheet and a bit of sheet scripting to populate the field from the Google Sheet.

We use salamander to populate the 'o' attribute in AD then use GADS custom schema to populate the AD attribute on the Google side.

 

If you are having trouble with new user profiles it may be worth trying FQDN\username for your attribute rather than DOMAIN\username of not already.

[RLR]

Can someone post their Custom Schema setup from GCDS? I'm not sure I'm getting the correct field names. The sync seems to be adding the LDAP field as a seperate custom attribute based on the ldap attribute name. How do I point it to the "Enhanced desktop security > AD accounts" google attribute?

[mproffitt1983]

We point ours to the 'o' attribute in AD which is populated with our domain\username

 

GCDS - Custom Schema

 

Schema Name = Enhanced_desktop_security

Field Names / Google field = [AD_accounts]

LDAP field = o

 

 

Hope this helps.

 

Matt