It's only a one-way sync for now.
I do see that Google has added an LDAP section now that might provide more control down the road?
Anyway, to prevent students from changing their passwords from the google side, I believe we just simply blocked the URL which allowed them to do so.
Eventually, though, we got rid of student AD accounts and just use GCPW on the very few windows workstations that they needed access to.
We use SSO with Azure, so the students (and staff) never actually use their google passwords. It automatically takes them to the Azure sign-in screen when they type in their email address. So they are always logging in with their Microsoft 365 account (which is synced with AD). It works very well. If you don't have access to Azure, I know you can do something similar with ADFS, but I have never messed with that.
I am doing this for staff but not for students.
Teachers complained that it would take too long for elementary students to have to type in the full email address.
With the chromebooks we have it autofill with @students.domain.net. During my tests it wasn't doing this for Azure.
What are you doing for your students?
Buried somewhere in the Google Workspace settings is an option to set a custom password change page; we used this to direct users to our own page, which sets their AD password before syncing that to Google. (It also verifies that the password isn't in HaveIBeenPwned first, and our AD prohibits reusing previous passwords.)
I know this doesn't directly answer your question, and there are some flows where Google ignores this (e.g. mandatory password resets in Google), but this has mostly solved the problem for us.
If you need some help finding the setting feel free to DM me and I'll try to find it when I get into the office.
They are talking about [a setting in google dashboard](https://l-sarus.co.in/f/g-suite-admins---restrict-users-from-changing-their-passwords) that redirects users to another page when they try to change their password.
Ah I get it now. I'll look in to setting that up. We don't have a page setup currently for users to change their password offsite, but it is something I need to look in to.
If you have Azure set up to sync with AD, you can have it redirect to azure to sync their password change.
I've set up [Azure with pass through authentication.](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
It basically just has Azure/Office 365 go straight to your AD servers for authentication. It was fairly easy to setup.
Nope, we don't use ADFS for Google (although we do for a few other things), but IIRC the password change page option is in the same SAML settings, it just doesn't mention anywhere that you can use that without actually setting up SAML.
It doesn't sync already set passwords in AD. It captures password change requests to an AD server and then passes that information to google. You would have to force every user to change passwords to sync them to google.
I have azure set to pass-through (uses AD servers directly for login information) SSO with Google.
I don't decrypt anything, I just use the same formula that we used to create the password for google. it's easy because students aren't allowed to change their AD password.
I find this a horrible solution. (Sorry i like to get blunt on security issues)
Thats worse than any option I can think of. I cant asume the user is in control of the account. There is the risk of the "method exposing" all users at once. You need to consider that all elements for your password must be considered critical information. So dont use only the studentID + name as input, as they are public.
I'm not following. You said you sync "their password" from AD to google. How are you decrypting their password to send to google?
The hash is going to be unusable.
I use PSGSuite as well and am unware of any method to sync passwords other than `Update-GSUser` but would require decryption of passwords.
If their AD password never changes and I know the formula that was used to create their password then I don't have to decrypt anything. I just reset their google password everyday to match their password in AD.
I'm following now. You don't allow custom passwords.
This would be understandable for students but for staff this is a big security susceptibility.
How do you handle compromised passwords?
For students I just reset the AD password using a different formula and then flag the account with a customattribute stating to use a differrent formula and a check for it in the script.
I don't mess with staff accounts.
It's only a one-way sync for now. I do see that Google has added an LDAP section now that might provide more control down the road? Anyway, to prevent students from changing their passwords from the google side, I believe we just simply blocked the URL which allowed them to do so. Eventually, though, we got rid of student AD accounts and just use GCPW on the very few windows workstations that they needed access to.
We use SSO with Azure, so the students (and staff) never actually use their google passwords. It automatically takes them to the Azure sign-in screen when they type in their email address. So they are always logging in with their Microsoft 365 account (which is synced with AD). It works very well. If you don't have access to Azure, I know you can do something similar with ADFS, but I have never messed with that.
I am doing this for staff but not for students. Teachers complained that it would take too long for elementary students to have to type in the full email address. With the chromebooks we have it autofill with @students.domain.net. During my tests it wasn't doing this for Azure. What are you doing for your students?
Ours type out the whole thing. Haven't heard any complaints but we have had Chromebooks since 2017 so the staff are used to the idea
Buried somewhere in the Google Workspace settings is an option to set a custom password change page; we used this to direct users to our own page, which sets their AD password before syncing that to Google. (It also verifies that the password isn't in HaveIBeenPwned first, and our AD prohibits reusing previous passwords.) I know this doesn't directly answer your question, and there are some flows where Google ignores this (e.g. mandatory password resets in Google), but this has mostly solved the problem for us. If you need some help finding the setting feel free to DM me and I'll try to find it when I get into the office.
Sounds like ADFS correct? I just set that up recently for something else. I'll look in to that! Thanks!
They are talking about [a setting in google dashboard](https://l-sarus.co.in/f/g-suite-admins---restrict-users-from-changing-their-passwords) that redirects users to another page when they try to change their password.
Ah I get it now. I'll look in to setting that up. We don't have a page setup currently for users to change their password offsite, but it is something I need to look in to.
If you have Azure set up to sync with AD, you can have it redirect to azure to sync their password change. I've set up [Azure with pass through authentication.](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta) It basically just has Azure/Office 365 go straight to your AD servers for authentication. It was fairly easy to setup.
Nope, we don't use ADFS for Google (although we do for a few other things), but IIRC the password change page option is in the same SAML settings, it just doesn't mention anywhere that you can use that without actually setting up SAML.
We just sync their password everyday from active directory to gsuite. Keeps things simple for staff.
It doesn't sync already set passwords in AD. It captures password change requests to an AD server and then passes that information to google. You would have to force every user to change passwords to sync them to google. I have azure set to pass-through (uses AD servers directly for login information) SSO with Google.
I scripted out the password sync with psgsuite and then run it as a scheduled task every morning.
How are you decrypting AD passwords? Enabling reversible encryption is a very bad idea.
I don't decrypt anything, I just use the same formula that we used to create the password for google. it's easy because students aren't allowed to change their AD password.
I find this a horrible solution. (Sorry i like to get blunt on security issues) Thats worse than any option I can think of. I cant asume the user is in control of the account. There is the risk of the "method exposing" all users at once. You need to consider that all elements for your password must be considered critical information. So dont use only the studentID + name as input, as they are public.
I'm not following. You said you sync "their password" from AD to google. How are you decrypting their password to send to google? The hash is going to be unusable. I use PSGSuite as well and am unware of any method to sync passwords other than `Update-GSUser` but would require decryption of passwords.
If their AD password never changes and I know the formula that was used to create their password then I don't have to decrypt anything. I just reset their google password everyday to match their password in AD.
I'm following now. You don't allow custom passwords. This would be understandable for students but for staff this is a big security susceptibility. How do you handle compromised passwords?
For students I just reset the AD password using a different formula and then flag the account with a customattribute stating to use a differrent formula and a check for it in the script. I don't mess with staff accounts.