Hi @MoritzMuehlenhoff,

Is it possible for us to modify the replication? We have an ou for ex-employees.

Thanks,
Byron

What's running on ldap1.corp.wikimedia.org? (the host against which our openldap servers are synching). Some Linux server synching with the G Suite LDAP interface?
From that server, can you run ldapsearch queries aginst the LDAP interface of G Suite? If you run an LDAP search against a standard user and an offboarded user, is the difference visible in the DN of the search results?

Hi @MoritzMuehlenhoff ,

ldap1 is running Ubuntu 14.04.5 LTS. Google Cloud Directory Sync [1], to sync users from LDAP with G-Suite, is hosted on another server. We can not run ldap queries against G-suite, we have to use their Admin API [2]. A standard search, on ldap1, that determines if a employee is with us or not could be run as follows:

Search base:

dc=corp,dc=wikimedia,dc=org

Filter:

(cn=bbogaert)

Result DN:

cn=bbogaert,ou=people,dc=corp,dc=wikimedia,dc=org

We can see I am in the ou=people, if I were in ou=ex-employees, I would be a off-boarded user. People in ou=ex-employees are suspended in G-Suite.

Would this work?

Thanks,
Byron

[1] https://support.google.com/a/answer/106368?hl=en
[2] https://developers.google.com/admin-sdk/directory/

Ok, thanks for the explanation! The problem is somewhere in "Google Cloud Directory Sync", then. It appears as if moving a user to a different OU isn't reflected in the LDAP data generated by GCDS. If I run an LDAP search against a user which I know is offboarded, then the DN shown is still the DN with which the user was originally created (CN=REDACTED,ou=people,dc=corp,dc=wikimedia,dc=org), That isn't uncommon in several LDAP connectors (since changing the DN will also affect e.g. DNs in group memberships, so many LDAP connectors go the easy route and don't update the DN of a moved user in a replica).

There's one way to reach that, though, which is independant of the DN: We could add a custom attribute in G-Suite (as already done for the Yubikey used in VPN auth), which would then be visible in the corp LDAP replica. This means that when offboarding a user in addition to moving him/her to a different OU you'd also need to tick the custom attribute. Would that work for OIT? Implementation-wise that's straightforward, only needs an LDAP schema extension on both ldap1 and the LDAP mirrors in production. I could prepare that.

The problem is somewhere in "Google Cloud Directory Sync", then. It appears as if moving a user to a different OU isn't reflected in the LDAP data generated by GCDS

I do not think this is the issue because GCDS does not generate LDAP data and it does not change our LDAP data. The GCDS just queries our LDAP server for users.

If I run an LDAP search against a user which I know is offboarded, then the DN shown is still the DN with which the user was originally created (CN=REDACTED,ou=people,dc=corp,dc=wikimedia,dc=org)

This could also be because said employee was not moved into the proper ou.

We could add a custom attribute in G-Suite (as already done for the Yubikey used in VPN auth), which would then be visible in the corp LDAP replica

Before we do this, could we do a walk-through of ldap1 and how the GCDS works? I just want to confirm that this would be the best option for us based on the way the different systems interoperate. I am on PST time but would be willing to meet in your time zone.

I do not think this is the issue because GCDS does not generate LDAP data and it does not change our LDAP data. The GCDS just queries our LDAP server for users.

Ah, so you have an LDAP server running on ldap1, the LDAP port isn't served by GCDS? Could you send me the content of /etc/ldap and the output of "netstat -ntulp" via email/PGP?

This could also be because said employee was not moved into the proper ou.

I checked quite a few, but let's rule that out. For the privacy of the affected users, I'll send you three user names via email, which are showing the unmodified DN.

Before we do this, could we do a walk-through of ldap1 and how the GCDS works? I just want to confirm that this would be the best option for us based on the way the different systems interoperate. I am on PST time but would be willing to meet in your time zone.

Sure, but let me first install GCDS in a VM so that I can have a quick look what it does and how it works.

It seems my test set was a case of really bad luck. The two disabled users accounts I was testing against, in fact still show up under cn=people, but when testing further accounts I in fact found several others which are showing up under ou=ex-employees. So these were probably just forgotten, I'll send you mail for that. Further cases of that kind will then be found when I add a test to our account consistency validation script.