Google Cloud Directory Sync help

[MrWu]

Hi

 

Any experts with GCDS ?

 

I'm getting Salamander to sync Google Classroom this year, and one of the requirements is using GCDS to sync accounts between AD to Google Suite.

 

It's very buggy at the moment .. for a start I can't even save or open Config files properly:

 

 

this was ran on Server 2022, Windows 10 and Linux machine as a test.

I'm running the latest version of GCDS. Version 4.7.14

 

Any ideas would be appreciated.

 

Also is it best practice to use LDAP on my internal server (389) or use LDAP SSL (seems more involved)

Whats the best way to filter out legacy stuff on Google Gsuite if previous users/groups were created manually or through Wonde?

 

Cheers

 

Wil

[jthompson]

GCDS encrypts the config file that it stores all your sync config into. It can therefore only be opened or used by whatever user account it was originally created by. We have a dedicated AD account that we use for all things GCDS. I don't know if that explains the error message you've shared (i.e. attempting to open the config from a different user account), but something to bear in mind when putting together your setup.

 

Exclusions take a bit of careful consideration in GCDS, as you need to be sure whether it's AD items being excluded, or Google Workspace items being excluded. If you've got a whole bunch of existing Google accounts that you don't want GCDS to touch, you ought to be able to set exclusions in GCDS to ignore whatever Google OUs and Google Groups that it should just ignore and leave alone. Generally speaking, in GCDS parlance, I think exclusions will be referring to excluding Google items from being affected, and search rules will be referring to which items from AD to work with.

 

RE: LDAPS, AD these days I think is going to require it (or at least, it's highly recommended). GCDS will be able to do cope with that, but there are a few certificate-related hoops to jump through in order to make the Java stuff happy. There will be posts about that on here somewhere, but happy to share my notes on that with you. It's something that you would need to repeat whenever you install a new GCDS version, also.

[MrWu]

Thank you, would appreciate this !

 

I have got a bit further, turns out that newest version of GDCS has this issue, we downloaded an older version and it worked.

 

So ran a simulation (after testing LDAP 389 connects) but gets error on simulation:

 

Caused by: javax.naming.NamingException: Network problem: Unable to connect to the specified LDAP server: myschool.sc:389, reason: UnknownHostException - myschool.sc [Root exception is java.net.UnknownHostException: myschool.sc]

 

Note= my domain ends with .sch not quite sure why GDCS cuts it to .sc ?

 

 

have checked firewall, and filter etc

 

also have the FQDN for the LDAP server (our AD controller)

 

Will give some other settings a try..

Edited March 3, 2022 by MrWu

[mavhc]

If you're not doing TLS, then could just use IP, worth trying to test it.

[MrWu]

Got it.. Was a typo in one of my search rules (entered the wrong base DN...)

[jthompson]

I'd double-check in GCDS that you've not typo'd the FQDN of your domain controller to miss of the h.

 

For the LDAPS certificate gubbins, we've had to do the following because the domain controllers' LDAPS certificates are issued by our own internal CA. The bundled Java runtime needs to have the CA cert added and then ahave a couple of checks disabled. This has also needed to be repeated after updating GCDS.

 

The required certificate will be the public root CA certificate for the certificate authority that issued the domain controllers' certificates.

 

On the server hosting GCDS, copy the certificate to a temporary location and open an administrator prompt. Run the following commands:

 

cd "C:\Program Files\Google Cloud Directory Sync\jre"

bin\keytool.exe -keystore lib\security\cacerts -storepass changeit -import -file C:\your_CA_cert.cer -alias someAlias_CA

 

N.B. the default keystore password is literally "changeit".

 

Then, edit these two files…

 

C:\Program Files\Google Cloud Directory Sync\config-manager.vmoptions

C:\Program Files\Google Cloud Directory Sync\sync-cmd.vmoptions

 

…to add the following lines:

 

-Dcom.sun.net.ssl.checkRevocation=false
-Dcom.sun.security.enableCRLDP=false

[MrWu]

Hi

 

Salamander installed, so found a bit of time to start playing with GCDS.

 

So, its working through LDAP 389 for now, and running sync test seems to work.

 

I have a few newbie questions hope one can help:

 

1) Lots of clean up to do, since Google Domain was a mish mash of CSV loaded users, with Wonde doing updates a few years ago. So OUs were manually created. So do I just try and get GCDS to match up existing users but leave groups and OUs alone, and get the new intake Year 7s to sync into OUs and new processes?

 

2) Do schools bother with synching AD's groups and OUs to mirror this in Google Suite as well (any benefit to this?)

 

3) I used the standard default rules to match users in GCDS, but it creates a lot of duplicate users since we have a mismatch of email address to user names. Salamander has kindly added a field in Attribute 1 in AD so that if that matches, GCDS will not create a duplicate, how do I add 'extensionAttribute1' as a search criteria in GCDS, with correct syntax?

 

Thanks so much for all your help.

[jthompson]

2) Our Google groups are primarily there are email groups. We therefore maintain a dedicated set of groups in AD specifically for syncing to Google. That is, those AD groups serve no other purpose in AD and are purely there for management of Google groups. We have them in a dedicated OU in AD, separate from all our other AD security groups that we use for Windows stuff. GCDS is then configured to just sync the groups that it finds in that OU.

 

3) If your 'extensionAttribute1' is where you have the email address that you want to use as a user's main Google address (i.e. what you're wanting to use to match AD accounts to Google accounts), then you can tell GCDS to use that instead of the 'mail' attribute from AD. In the 'User Accounts' section of your GCDS config, you'd change the 'Email Address Attribute' field from mail to extensionattribute1. GCDS also keeps account of objectGUID from AD as well. That's there so that GCDS can update primary addresses of Google accounts when the email address attribute of an AD object gets changed (e.g. when someone changes their name and needs their email address altering).

[MrWu]

2) Our Google groups are primarily there are email groups. We therefore maintain a dedicated set of groups in AD specifically for syncing to Google. That is, those AD groups serve no other purpose in AD and are purely there for management of Google groups. We have them in a dedicated OU in AD, separate from all our other AD security groups that we use for Windows stuff. GCDS is then configured to just sync the groups that it finds in that OU.

 

3) If your 'extensionAttribute1' is where you have the email address that you want to use as a user's main Google address (i.e. what you're wanting to use to match AD accounts to Google accounts), then you can tell GCDS to use that instead of the 'mail' attribute from AD. In the 'User Accounts' section of your GCDS config, you'd change the 'Email Address Attribute' field from mail to extensionattribute1. GCDS also keeps account of objectGUID from AD as well. That's there so that GCDS can update primary addresses of Google accounts when the email address attribute of an AD object gets changed (e.g. when someone changes their name and needs their email address altering).

 

Brilliant, thanks for the advice.

 

So currently, in Google Suite,

 

I have mailing groups and tutor groups created by Wonde and also manually (im not sure these are being used anyway, bar classroom teachers group created manually for Shared google drive permissions - which I presume needs to be retained) - Would GCDS setup to move new staff to groups created in Google or it doesn't work like that?

 

In AD currently students are created and put in OUS we name intake_20XX, which we create

 

.. so from your advice I should for Sept 2022 create an group in AD called for example google_intake2022 and put the new year 7s AD accounts in that group,

and let GCDS sync with this and create that corresponding group in Google Suite? (hope I got this right!)

Edited March 30, 2022 by MrWu

[Garacesh]

bar classroom teachers group created manually for Shared google drive permissions - which I presume needs to be retained)

classroom_teachers@ is used to define whether a user is a teacher or a pupil in Google Classroom.

You can actually manually add members now, and it supports nested groups, so if you have an all-staff mailing list, you can add that the the group and boom, all your staff are automatically teachers.

If you define groups in AD, then you can sync them up to google via LDAP query the same as you do users, as long as that group has an email address in AD (so you just use (objectCategory=group) as your search query)

 

.. so from your advice I should for Sept 2022 create an group in AD called for example google_intake2022 and put the new year 7s AD accounts in that group,

and let GCDS sync with this and create that corresponding group in Google Suite? (hope I got this right!)

You can name your OU's anything you feel like, the name doesn't matter. For example, we have 20XX Intake for all our our year groups.

 

The way we do it is to have users synchronised (User Accounts tab - (&(sAMAccountType=805306368)(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) query), and then we map where they should go on the Org Units tab. So OU=2016 Intake,OU=Pupils,OU=$School Users,DC=$domain,DC=local maps to Pupils/Intake 2016, OU=Staff,OU=$School Users,DC=$domain,DC=local to Staff, OU=Student Teachers,OU=Staff,OU=$School Users,DC=$domain,DC=local to Staff/Student Teachers, etcetera

 

Just be careful that you don't leave any OU's unaccounted for, or they'll end up getting dumped in the root domain.gtld OU.

Edited March 30, 2022 by Garacesh

[jthompson]

In AD currently students are created and put in OUS we name intake_20XX, which we create

 

.. so from your advice I should for Sept 2022 create an group in AD called for example google_intake2022 and put the new year 7s AD accounts in that group,

and let GCDS sync with this and create that corresponding group in Google Suite? (hope I got this right!)

 

That's what we do, yes. In the GCDS config, the groups search rule is just looking at the AD OU containing the groups we want synced to Google. All our other AD groups are going to be outside of that scope.

If you have existing Google Groups that you don't want GCDS interfering with (i.e. you want to keep them, continue to manually manage them on Google and not sync them from AD at all), then you can specifiy exclusion rules for those in GCDS under 'Google Domain Configuration -> Exclusion Rules'. GCDS will delete any Google groups that aren't matched from AD and aren't covered by such an exclusion rule.

 

The 'Classroom Teachers' Google group is a special case and won't get affected by GCDS in any case. You can just add suitable staff groups as members of that group and leave it be.

[jthompson]

classroom_teachers@ is used to define whether a user is a teacher or a pupil in Google Classroom.

You can actually manually add members now, and it supports nested groups, so if you have an all-staff mailing list, you can add that the the group and boom, all your staff are automatically teachers.

If you define groups in AD, then you can sync them up to google via LDAP query the same as you do users, as long as that group has an email address in AD (so you just use (objectCategory=group) as your search query)

 

 

You can name your OU's anything you feel like, the name doesn't matter. For example, we have 20XX Intake for all our our year groups.

 

The way we do it is to have users synchronised (User Accounts tab - (&(sAMAccountType=805306368)(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) query), and then we map where they should go on the Org Units tab. So OU=2016 Intake,OU=Pupils,OU=$School Users,DC=$domain,DC=local maps to Pupils/Intake 2016, OU=Staff,OU=$School Users,DC=$domain,DC=local to Staff, OU=Student Teachers,OU=Staff,OU=$School Users,DC=$domain,DC=local to Staff/Student Teachers, etcetera

 

Just be careful that you don't leave any OU's unaccounted for, or they'll end up getting dumped in the root domain.gtld OU.

 

That's what we do, too. That would also help to tidy up existing users on Google by sorting them into their respective OUs. Just make sure to remind yourself to add new search rules at the start of each academic year to account for new cohorts.

[MrWu]

Thanks for all the help here guys..

 

I have managed on and off to clear a lot of the clutter and match existing users from AD to GC (we had a lot of discrepancies with maunally created accounts with wrong names and its nice running a sync and Google flagging and suspending users, plus matching users to a primary key..

 

So I just need to get my head around Groups and OUs in GC now, historically GC OUs was added manually as intake_20XX and when we put Wonde in that created them in Year (7-13) + Year Groups as GC Groups and sync that accordingly, again a mish mash of manually added groups and OUS etc

 

In AD, we have staff in security OUs called teachers and associate staff, students are in OUs called intake_20XX etc

 

In GC, classroom teachers groups (built in) and some OUs are assigned to permissions for Google shared drive and apps and shortcuts.

 

So

 

a) Should I keep existing users as is in GC groups and OUs?

 

b) How would I tell Google to put new staff and students when they go from AD > GC ?

 

Apologies I'm going to run through some of the replies again, some of the answers are probably within!

 

thanks!

[mavhc]

If everyone in the same OU in AD will go into the same OU in Google, then just do the OU mapping in GCDS

[MrWu]

Cheers !

 

So for example, staff that are in AD with OU called Teachers, I will need to setup OU sync in GCDS with rule to create an OU called teachers as well, and move and create teaching staff when sync?

 

if I understood this right, same with students - ask GCDS to create relevant intake_20xx into Google and place students in there.

 

I will then need to replicate whatever Google policies that were applied to the manually created legacy OUs in Google and apply to the new ones created?

[mavhc]

You can or you can just say Intake_2022 goes to Students and Intake_2023 goes to Students.

 

If you're starting from scratch you'd just replicate the OUs, but which way is best is the question, either will work.

[MrWu]

Ok, thanks for all the help you guys give,awesome!

 

I think I have made some headway.. my team have added some search rules and filters I'll post here, any feedback welcome or if it helps someone with our setup, even better.

 

Reminder that my existing Google suite is a mish mash of uploaded CSV, and part Wonde sync historically.

 

So first of all, we looked at Organization Unit mapping from AD - to Google, moving staff from OUs in AD to existing OU manually created in Google..then search rules applied where OUs had a certain OU name, where we want the users synced:

 

[MrWu]

Then we used an 'extensionAttribute1' set up by Salamander to map any manually misnamed accounts on Google to the correct user in AD, Search rule was anybody in AD that belongs to group GCDS_Sync will be Synced, and any odd users that I have to explicitly exclude in exclusion section for odd reasons I cant sync.

 

[MrWu]

Next was mapping of Distribution Groups (that exists on AD, that would be recreated on Google

 

[MrWu]

The following changes were proposed:-

*****************************************************************************

 

Proposed Change Report, Generated 14:40:30 06-May-2022

 

Analyzed organizations:

7 local

23 remote

 

Proposed changes:

Extra: 0

New: 15

Modify: 3

 

Create Organization(s) - 15 total

"sch"

"sch/test"

"sch/test/InterJigsaw"

"sch/test/InterJigsaw/test Staff"

"sch/test/InterJigsaw/test Staff/test IT"

"sch/test/InterJigsaw/test Staff/test IT/Users"

"sch/test/InterJigsaw/test Staff/test IT/Users/IT_Admins"

"sch/test/InterJigsaw/test Students"

"sch/test/InterJigsaw/test Students/Users"

"sch/test/InterJigsaw/test Students/Users/Student_Leavers"

"sch/test/InterJigsaw/test Students/Users/Student_Leavers/Intake_2014"

"sch/test/InterJigsaw/test Students/Users/Student_Leavers/Leavers_to_2019"

"sch/test/InterJigsaw/test Students/Users/Student_Leavers/Leavers_to_2019/Student_Leavers"

"sch/test/InterJigsaw/test Students/Users/Student_Leavers/Leavers_to_2019/Student_Leavers/Intake_2012"

"sch/test/InterJigsaw/test Students/Users/Student_Leavers/Leavers_to_2019/Student_Leavers/Intake_2013"

 

Modify (all proposed changes) - 3 total organizations affected

Modify organization 1: "Staff/Teaching Staff"

Set description "Teachers"

 

Modify organization 2: "Students"

Set description "Intake_2021"

 

Modify organization 3: "Staff/Non Teaching Staff"

Set description "Admin_staff"

 

 

Analyzed users:

1,616 local

2,706 remote

 

Proposed changes:

Delete: 0

Modify: 2,348

Create: 6

 

Modify (all proposed changes) - 2,348 total users affected

Modify user 1: "[email protected]"

Change org to "Students"

Change stored non-address primary key to "YhHeSOaCIk6mqd1XSxxxxx"

Remove 1 existing aliases

"[email protected]"

 

 

Modify user 202: "[email protected]"

Suspend user

Reason: This user was not found in any LDAP user search rules.

 

Modify user 185: "[email protected]"

Change org to "Staff/Non Teaching Staff"

Change stored non-address primary key to "aJ_3jb8CH0WXQ8U1XXXXX"

 

Modify user 268: "[email protected]"

Change org to "Staff/Teaching Staff"

Change stored non-address primary key to "1OpwXYa0VUaTUzAXXXX"

Change family name to "Dodd"

 

Create Group(s) - 12 total

"[email protected]"

 

 

Modify (all proposed changes) - 11 total groups affected

Modify group 1: "[email protected]"

Add address "[email protected]"

Edited May 6, 2022 by MrWu

[jthompson]

In your Org Unit search rules, you've got on that searching for name=Intake*. Since "sch/hinchleyw/InterJigsaw/HWS Students/Users/Student_Leavers/Leavers_to_2019/Student_Leavers/Intake_2013" is matching that pattern, GCDS will be creating the OU structure shown there, which is why it's creating student leavers OUs for you.

[Planehazza]

Hi all,

Just bumping an existing thread rather than create a new one. Just looking for some advice.

The gist: AD and Google are already built with OUs created, and we have six sites, each with the following OU structures:

 

Site1 
  >Groups
  >Staff
  >Students
     > Intake 23
     > Intake 24
etc.

 

In my testing OUs, I have defined one to one OU mappings for each OU. This works well and reliably but it's going to be a lot of work for each OU for the six schools.

Is there a way I can sort of semi dynamically 'auto map' AD OUs to Google OUs assuming the names and structure are the same? Failing that, and I need to define each mapping manually (and remember to do it annually during induction) is there a way I can do this via CLI or batch file etc?

 

I'm also getting a little confused as to where I should be defining where user objects go to when synced to Google? Do I map ou=intake xx,ou=students,ou=site x... to ../site x/students/Intake xx in each search rule, or in the org mappings section? Or both?!

Edited April 25, 2023 by Planehazza

[mavhc]

The config file it saves is an xml file, so you can just edit that, either copy and paste or write a script to generate the code you need

[Planehazza]

The config file it saves is an xml file, so you can just edit that, either copy and paste or write a script to generate the code you need

 

Doh, you're right, can't believe I forgot that, thanks!

 

Also, I worked out my issue with knowing where to define the OU mappings. I turned off the option in org mappings "do not create or delete Google Organisations..." which then allowed me to tell the search rules to derive target Google OUs from Org mappings. Result!

 

Current issue is syncing group managers. It doesn't seem to be honouring the managedBy attribute defined in the group search rule...

Edited April 25, 2023 by Planehazza

[Planehazza]

Anyone ever had an issue with GCDS not paying attention to entires in proxyAddresses attribute? I've tried "SMTP:[email protected]", "stmp:[email protected]", "[email protected]", "a.bcd"... no joy!