2

I have successfully set up Google Apps Directory Sync (GADS) for one of the Active Directory forests I manage. This forest was created with a functional level of 2012R2. Now I am setting up GADS for a second forest. This forest used to be at the 2003 functional level but was later raised to a 2008 functional level.

In GADS I'm using a pair of User Account search rules that suspend Google Apps users who are Disabled in AD and un-suspend users who are Enabled in AD. This arrangement works flawlessly in the first forest I set up. But in my new forest it returns incomplete data.

Here are the queries I'm using:

Do Not Suspend (&(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Suspend (&(objectCategory=person)(userAccountControl:1.2.840.113556.1.4.803:=2))

Here's the problem: If I run "Test LDAP Query" in the GADS interface on that Suspend query, it returns me only two users. But there are 36 users total who should be returned. Because the query is not finding the complete list of Disabled users, when I disable someone in AD and run a sync, GADS does not disable the user in Google Apps.

When I run the same query in a non-GADS LDAP query tool (VTLDAPQuery), it returns me the complete list.

The two users that GADS returns when I test the query were created back during the 2003 days. The other 34 were, I believe, created after the functional level was raised.

  • Follow-up: I have done some further testing by moving an older user into the scope of the query. This user was created at functional level 2003 but still does not get returned by the query in GADS. – Ryan Elainska Sep 12 '16 at 18:20
  • I have determined that some of my pre-2008-level users have the adminCount attribute set in AD, but others do not. (For the ones who have it, it is set to 1.) So far all the users I have tested who have this attribute set will be retrieved by my query. I have not identified any users who do not have this attribute set but who do get retrieved by the query. Could this have something to do with ACLs or Security Group membership? – Ryan Elainska Sep 12 '16 at 19:27
  • Unsurprisingly, my domain had some screwed-up nested groups and users in protected groups. I've scrubbed as much as I could find. Then I cleaned the permissions of one of the older users who showed up in the query. I reset her adminCount value to 0 and her permissions to default. After that, the query no longer retrieved her. – Ryan Elainska Sep 12 '16 at 20:30
  • I added a new users to a protected group. After a few minutes her adminCount was set to 1, and she was no longer retrieved by the query. So the problem seems to be that the GADS LDAP query method will not retrieve users with inheritable permissions. – Ryan Elainska Sep 12 '16 at 20:38
  • Okay I figured it out, and now I'm so angry with myself. The problem was insufficient permissions for the service account being used to run the LDAP query. In a forest that had not gotten as screwed up as our is, special permissions would probably not be required, but in my particular domain, adding the LDAP query account to "Domain Admins" immediately resolved the problem. I will have to continue experimenting to find the minimum level of permissions required, but it is clearly the permissions that were at fault. – Ryan Elainska Jan 27 '17 at 14:29
1

Okay I figured it out, and now I'm so angry with myself. The problem was insufficient permissions for the service account being used to run the LDAP query. In a forest that had not gotten as screwed up as ours is, special permissions would probably not be required, but in my particular domain, adding the LDAP query account to "Domain Admins" immediately resolved the problem. I will have to continue experimenting to find the minimum level of permissions required, but it is clearly the permissions that were at fault.

0

I just encountered a similar issue, where an LDAP query in Google Cloud Directory Sync would return 109 users but the same query in Microsoft's LDP tool returned 118 users. The BaseDN was the same in both cases, logged in with the same BindDN user account. The query is as simple as it gets: (objectclass=user)

This turned out to be the easiest solution imaginable - GCDS automatically filters results to only select those that have a properly filled out "mail" attribute. If your user does not have an e-mail address in their AD properties, or the e-mail address is not a valid format, then GCDS will drop the user from the search results.

This may not be the problem with incomplete results in every case, but it was the problem in my case, so I hope this answer is helpful to someone.

  • I have also discovered the same thing. (It actually is very useful for proactively selecting accounts that you don't want to sync.) This turned out not to be the source of the issue for me, though. I thought I had posted the answer already, but I hadn't. – Ryan Elainska Jan 27 '17 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.