A couple of Google Credential Provider questions

[TwistedHelixis]

I have been playing around with GCPW for a few weeks now.

 

Am I right in thinking GCPW can only deploy custom (OMA-URI) policies at the computer level, not user level?

 

Am I right in thinking its best to have a single GCPW setup user in Google Workspace, that is used just for deploying GCPW to all Windows devices. I read the first user to login to a Windows device running GCPW becomes the 'settings' user. All device / user settings are effectively deployed from the first account logged on. I guess if this is the case, I definitely wouldn't want to delete this account, of have random staff / pupils logging in first.

 

Thanks

[dhicks]

I read the first user to login to a Windows device running GCPW becomes the 'settings' user.

 

I don't know the answer, but that's useful to know to check when next setting up new machines.

[paulkerton]

Am I right in thinking GCPW can only deploy custom (OMA-URI) policies at the computer level, not user level?

Correct, but this is also the case with inTune without AD in place. It's a Microsoft limitation.

 

Am I right in thinking its best to have a single GCPW setup user in Google Workspace, that is used just for deploying GCPW to all Windows devices. I read the first user to login to a Windows device running GCPW becomes the 'settings' user. All device / user settings are effectively deployed from the first account logged on. I guess if this is the case, I definitely wouldn't want to delete this account, of have random staff / pupils logging in first.

Yes, absolutely. you set the OMA-URIs on an OU, and then put this setup user in that OU.

[TheHyperTechie]

Hopefully I can help answer these below, please correct me if I am wrong though!

 

1. The OMA-URI policies are set at the user level according to the OU you assign them to. The only policies that apply at the device level are the top-level ones, including updates, BitLocker, and GCPW settings. So, whichever user signs in first to a device, the device will use the settings applied to that user. It's fixed (if that makes sense). This is the official explanation from Google:

 

"When many users sign in through GCPW on the same device, the first user is enrolled in Windows device management. Their device-level settings (such as Windows updates, admin privileges, and BitLocker encryption) apply to all users of the device."

 

2. I believe the logic behind this is correct; however, I think it would only work properly with fleets of student devices or IT suites. What about SSO for Chrome? It would prompt all of these devices to log into the same Chrome account. For that reason, I allow all of our teachers to use their own Google accounts. I then applied all of the custom OMA-URI policies to our "teachers" OU. I also made sure to adjust the top-level policies, such as account settings and updates, to ensure they receive the correct level of access on the device (Standard User). I can see the benefit of following this method for student devices though, but our students use chromebooks so we didn't need to implement it.

Edited March 5, 2025 by HyperTech

[TwistedHelixis]

It would prompt all of these devices to log into the same Chrome account.

 

This is not the case in my testing. I log in with my first user, log out then the teacher logs in, they are then able to sign in to Chrome browser and Google Drive for desktop with their own account.

 

That being said, SSO to Chrome browser is not working for me in my testing so far and was mentioned as not working for others in another post. Perhaps when it gets fixed, ill then have an issue.

Edited March 5, 2025 by TwistedHelixis

[TheHyperTechie]

This is not the case in my testing. I log in with my first user, log out then the teacher logs in, they are then able to sign in to Chrome browser and Google Drive for desktop with their own account.

 

That being said, SSO to Chrome browser is not working for me in my testing so far and was mentioned as not working for others in another post. Perhaps when it gets fixed, ill then have an issue.

 

Just re-read my message. My logic of thinking is actually incorrect (long day!) it wouldn’t matter about the account you used to enroll it, as this would just be signed out of and then you would sign in with your Google account. This would then SSO into chrome and connect the correct profile.

[TwistedHelixis]

@HyperTech

EDIT - Just read your post above....

So the way I currently have this setup......

 

GCPW Windows device OU - With main setup user in this OU - Also has the custom (OMA-URI) policies applied (changing these settings also changes them for users that have logged in from the Staff OU)

 

Staff OU - with 3 test teachers - Also has the main Windows settings applied (admin or standard user, Windows update, Bitlocker etc)

 

During my testing the main user can log onto any number of clean Windows devices and set them up, then teachers 1, 2 and 3 can also log into that device and they will get the main Windows settings applied (admin or standard user, Windows update, Bitlocker etc), along with the custom (OMA-URI) policies.

 

HyperTech, what happens when one of your teachers leaves and you delete them from the Workspace Admin, if they are the main settings user on a device, doesn't that device become unusable?

Edited March 5, 2025 by TwistedHelixis

[TwistedHelixis]

it wouldn’t matter about the account you used to enroll it

 

But.... What happens when one of your teachers leaves and you delete them from the Workspace Admin, if they are the main settings user on a device, doesn't that device become unusable?

 

EDIT - Changed usable to unusable

Edited March 5, 2025 by TwistedHelixis

[TheHyperTechie]

@HyperTech

EDIT - Just read your post above....

So the way I currently have this setup......

 

GCPW Windows device OU - With main setup user in this OU - Also has the custom (OMA-URI) policies applied (changing these settings also changes them for users that have logged in from the Staff OU)

 

Staff OU - with 3 test teachers - Also has the main Windows settings applied (admin or standard user, Windows update, Bitlocker etc)

 

During my testing the main user can log onto any number of clean Windows devices and set them up, then teachers 1, 2 and 3 can also log into that device and they will get the main Windows settings applied (admin or standard user, Windows update, Bitlocker etc), along with the custom (OMA-URI) policies.

 

HyperTech, what happens when one of your teachers leaves and you delete them from the Workspace Admin, if they are the main settings user on a device, doesn't that device become unusable?

 

This setup sounds exactly like mine, the only difference is that I allow the staff members to enroll the device using their Google account rather than a generic one.

 

I have my teachers OU, with all of the relative custom policies added. I apply the main GCPW policies at the root (Trust level) though, as these are settings I would want enabled regardless of the user e.g. update settings, user permissions, and bit locker. For the user permission sections, I do have an override in place to allow the “Administrators” OU admin privileges. This OU contains myself and my assistants account.

 

In regard to a teaching leaving - standard practice for me is/has always been to wipe the device anyway. So I just initiate a reset from the Google admin console, and then redeploy GCPW to it. Luckily I have Action1 to help me with this.

[TwistedHelixis]

I apply the main GCPW policies at the root (Trust level)

Thanks, that is good to know.

 

Another questions, if that is OK....

 

“Administrators” OU admin privileges. This OU contains myself and my assistants account.

Do you leave a default Windows local admin user account on the machine, or remove that and rely only on your “Administrators” OU

[TwistedHelixis]

Also, do you have device approval Turned on (requires admin approval), or tuned off, so the devices auto approves?

 

The reason I am asking, in my testing each separate teacher needed approving for each separate laptop. So if teacher A logs onto 2 laptops '1 & 2', they would need approving, even if a completely different teacher had already been approved on laptops 1 & 2.

If it asked for approval just once per device that would be OK, but I can see things getting a bit OTT.

[TwistedHelixis]

Sorry, another question....

 

Do you have Windows device management applied to the root OU, or specific OUs?

[TheHyperTechie]

Thanks, that is good to know.

 

Another questions, if that is OK....

 

 

Do you leave a default Windows local admin user account on the machine, or remove that and rely only on your “Administrators” OU

 

I don’t leave any local admins on the devices. I just rely on the administrators OU and the account settings option in GCPW. So when I need admin access to a machine, I just log in so the computer recognises my account then sign out/in again (this is standard GCPW behaviour) and my account is elevated to administrator.

 

Honestly I am happy to answer any questions you have. GCPW does have its quirks and isn’t highly documented. I feel that unless you have used it, it’s a minefield to try and find something out. It definitely gave me the occasional headache!

[TwistedHelixis]

Honestly I am happy to answer any questions you have.

Thanks for your help with this. I am so close, just want to make sure I have everything lined up

 

Just a few more questions and I think I might be there.

 

do you have device approval Turned on (requires admin approval), or tuned off, so the devices auto approves?

If so, is that at root OU or spacific OUs

 

Do you have Windows device management enabled on the root OU, or specific OUs?

Edited March 5, 2025 by TwistedHelixis

[TheHyperTechie]

Thanks for your help with this. I am so close, just want to make sure I have everything lined up

 

Just a few more questions and I think I might be there.

 

do you have device approval Turned on (requires admin approval), or tuned off, so the devices auto approves?

If so, is that at root OU or spacific OUs

 

Do you have Windows device management enabled on the root OU, or specific OUs?

 

1. I have this turned off, I believe (correct me if I am wrong) it requires the devices to be setup using advanced mobile management. We just use basic level - as this is how I inherited the console/setup. I may turn this on at some point though, as for laptops and desktops it only requires Endpoint Verification.

 

2. I have Windows Device Management enabled at the top (Trust) level OU. You could have it set at a particular OU though. However, the device would only enroll if the user is a member of the OU you have applied it to.

[TwistedHelixis]

The only reason I am not sure about the Windows Device Management policy is that Google mention the following....

 

As an administrator, you can control Windows 10 or 11 device security and features by applying policy settings. Some of these settings apply only to Windows devices with Google Credential Provider for Windows installed on them, and some apply only to devices under Windows device management.

If this only effected devices with GCPW installed, I wouldn't worry about putting it in the root OU, but 'some apply only to devices under Windows device management.' is not very helpful.I would prefer it to go in the root OU if possible, but I am a little concerned that if I do, its going to have some bizarre knock-on issues for our current Windows devices.

 

Am I reading more into this than I should / worrying over nothing?

Edited March 6, 2025 by TwistedHelixis

[TheHyperTechie]

The only reason I am not sure about the Windows Device Management policy is that Google mention the following....

 

 

If this only effected devices with GCPW installed, I wouldn't worry about putting it in the root OU, but 'some apply only to devices under Windows device management.' is not very helpful.I would prefer it to go in the root OU if possible, but I am a little concerned that if I do, its going to have some bizarre knock-on issues for our current Windows devices.

 

Am I reading more into this than I should / worrying over nothing?

 

It's just the way that Google displays their documentation, it can be confusing. If you click on the link at the end of the sentence you quoted. It breaks down what GCPW can provide on its own, followed by Windows Device Management.

GCPW (on its own):

 

 

• Additional Security
  
• SSO experience
  
• Password Sync
  
• Automatic enrollment into Windows Device Management
  

 

Windows Device Management:

 

• Settings management (custom settings, updates, bitlocker, admin permissions)
  
• Device Management (Wipe device, sign users out, audit device activity, unenroll a device)
  

Hope this helps.

 

EDIT - Sure he won't mind, just going to tag @rogerdnixon who is a GCPW/Windows Device Management guru. Roger initially helped me setup my console. I am sure he can provide more info or correct me on any information I have provided.

Edited March 6, 2025 by HyperTech

[TwistedHelixis]

So, I think one of the issues for me is, all these different settings have been listed in Google Workspace since it got created, some enabled some disabled. Its only after adding our new upgrade license that all these other settings might now have an effect.

 

Windows Device Management:

Settings management (custom settings, updates, bitlocker, admin permissions)

Device Management (Wipe device, sign users out, audit device activity, unenroll a device)

 

So, this throws up more questions for me then.

If I look in Devices > Mobile and endpoints > Devices, I currently have a load of users and devices listed. For example teacher1 is on OS Windows 10.

Are you saying I can also manage these devices for things like admin permissions etc even though they do not have GCPW installed?

 

Edit - If this is the case, what happens if a teacher logs into their email from their home laptop and I have (Devices > Mobile and endpoints > Windows settings> Account settings) set to delete the local admin account, will this delete the local admin acc on their personal device?

Edited March 6, 2025 by TwistedHelixis

[TwistedHelixis]

I might have stumbled on the answer.

 

At he bottom of one of Googles support pages is the following....

 

Verify enrollment of a Windows device

 

 

1. Sign in with an administrator account to the Google Admin console.
   
2. Go to Menu Devices > Overview.
   
3. Click Endpoints.
   
4. Click Add a filterManagement TypeEnhanced desktop securityApply to show only devices enrolled in Windows device management.
   

 

 

And it only lists Windows devices I have ben testing GCPW on.

So what I now need to workout is, does making a Windows setting change in Google Workspace, only apply to devices that either have GCPW installed or Enhanced desktop security setup?

 

I really hope this is the case

Edited March 6, 2025 by TwistedHelixis

[TwistedHelixis]

Found more info on the same page....

Enroll a Windows device

 

 

1. Sign in to the Windows 10 device.
   
2. Open https://deviceenrollmentforwindows.googleapis.com/v1/deeplink in a Chrome or Edge browser.
   
3. Confirm that you want to switch apps.
   
4. Enter the Google email address you want to enroll the device with.
   
5. Click Next to start device enrollment.
   
6. Sign in to your managed Google Account.
   

If you get an error during enrollment, review the requirements.

 

So I believe, even though my users along with their Windows devices, (some home personal devices) are listed in endpoints > devices and have approved for the status, they are not actually enrolled, which would then mean any Windows settings I deploy from the root OU should not apply to any of their personal devices as I wouldn't have carried out the steps above to enroll them.

 

Does anyone else agree?

 

Would be great if someone is already managing windows devices without GCPW installed could answer.

[TheHyperTechie]

So, I think one of the issues for me is, all these different settings have been listed in Google Workspace since it got created, some enabled some disabled. Its only after adding our new upgrade license that all these other settings might now have an effect.

 

 

 

So, this throws up more questions for me then.

If I look in Devices > Mobile and endpoints > Devices, I currently have a load of users and devices listed. For example teacher1 is on OS Windows 10.

Are you saying I can also manage these devices for things like admin permissions etc even though they do not have GCPW installed?

 

Edit - If this is the case, what happens if a teacher logs into their email from their home laptop and I have (Devices > Mobile and endpoints > Windows settings> Account settings) set to delete the local admin account, will this delete the local admin acc on their personal device?

 

I can't really comment on using each of the services separately, as we rolled both out together which is recommended from Google. Those devices that you see under Devices > Mobile and Endpoints > Devices, are devices that users from your console have signed into with their work account. The devices you see, will differ according to the level of mobile management you have enabled. If unmanaged, it will just list devices you own that your users have signed into. If set to basic, it will list these along with personal devices e.g if Joe Bloggs has used their iPhone to check their email. This is the same for advanced (I believe)

 

As for the teacher logging in from home on their own PC - It wouldn't be affected, as the device wouldn't have GCPW installed and wouldn't be enrolled into the tenant (Windows Device Management). If you are not using GCPW you enroll the device manually using a link. The only situation I could see this happening in, is if the user downloaded GCPW onto their personal device, and you had the setting applied to the OU they were a member of, to automatically enroll the device into Windows Device Management.

 

Does this help?

[TwistedHelixis]

Does this help?

 

Yes, I think it does.

 

Thanks for all your help :-)

Edited March 6, 2025 by TwistedHelixis

[TwistedHelixis]

For everyone reading this post, something else I have worked out is, you can un-enroll the device and then delete the device in Workspace and the next user signing will then become the Master user for that device.

 

I do need to do some more testing, but it does seem like a nice quick way of switch the master user over to a different account and saves wiping the device completely if needed.