Handling LDAP Referrals

[arjan-saly-tfs]

Hi,
First of all thanks for this great tool and superb documentation. As a database specialist I have no knowledge of Active Directory/LDAP, YAML or Python, but thanks to your documentation I was able to setup a successful synchronization from AD to PostgreSQL.

However, now I run into an issue I can't find a solution for:
We have multiple synchronized active directories, at least one in EMEA and one in the US. Perhaps more, but I'm only aware of those two. We also have multiple sub domains for (at least) emea and US.

Hence, we have these two:

• DC=amer,DC=OurCompany,DC=com
• DC=emea,DC=OurCompany,DC=com

When I configure ldap2pg to login to the EMEA AD server and configure a PostgreSQL synchronization for a group in the AMER domain, I get this error in the verbose=debug ouput:
[ldap2pg.script CRITI] Failed to query LDAP: {'info': u'Referral:\nldap://amer.OurCompany.com/OU=AWS,OU=Global,DC=amer,DC=OurCompany,DC=com', 'msgid': 4, 'msgtype': 101, 'result': 10, 'desc': u'Referral', 'ctrls': []}.

So, I digged a bit deeper using ldapsearch:
When I use ldapsearch to login to the emea AD/LDAP server and search for a group in an amer domain, I get only this result:
# search result search: 2 result: 10 Referral
Plus a link to the other AD server. But no group member details.
Doing it the other way around, I get the same results. Hence I can only get group members for groups of the domain that matches the AD-servers domain. I searched around a bit on the net and this seems like a pretty normal situation in the AD world, not duplicating the whole tree, but referring to the other server for details.

I need to be able to sync from both of these domains, how can I configure ldap2pg to search in both?

Thanks!

Arjan

[bersace]

Hi @arjan-saly-tfs,

Since ldap2pg 4.13, ldap2pg has the same behaviour as ldapsearch, referrals are disabled by default. https://ldap2pg.readthedocs.io/en/latest/changelog/?h=referrals#ldap2pg-413

I agree that partiionned directory is a standard feature and ldap2pg should handle this. I need to spike this issue and design a way to handle this. ldap2pg design is based on the hypothesis of a single directory with a single connection. Which cover a large set of use cases. This need to be reviewed.

[bersace]

@arjan-saly-tfs except from URI, can you reuse user, password and all connexions parameters accross directory servers ?

[arjan-saly-tfs]

@arjan-saly-tfs except from URI, can you reuse user, password and all connexions parameters accross directory servers ?

When using binddn I can. When using SASL I cannot, then I need a different user/password for connection to the other "servers".

By the way, after starting this ticket, I learnt that these different domain servers, actually are are different "forests".
Hence, this issue is closely related to #409 .

[bersace]

Handling referrals requires multiple binds to each server. I could design a first implementation that only accepts multiple LDAP connexions sharing same binddn/password or SASL user/password. I need to check how ldapsearch follows referrals to match the same behaviour.

For the record, the first issue about referrals was #228 .

[bersace]

Referrals is mentionned in python-ldap FAQ. https://www.python-ldap.org/en/python-ldap-3.4.0/faq.html?highlight=referrals#usage

With REFERRALS=yes, libldap chase referrals using anonymous binding. This not what you want. Which SASL method do you use ? GSSAPI should best match this use case.

[arjan-saly-tfs]

Which SASL method do you use ?

I don't use a specific SASL method by choice (keep in mind I'm a database expert, not an LDAP expert)

But does this line from the verbose output give the answer?

[ldap2pg.ldap         DEBUG] Doing: ldapsearch -Y DIGEST-MD5

[bersace]

Which SASL method do you use ?

I don't use a specific SASL method by choice (keep in mind I'm a database expert, not an LDAP expert)

I try to make ldap2pg logs explicit enought for DBA, if something is not clear, please tell.

But does this line from the verbose output give the answer?

[ldap2pg.ldap         DEBUG] Doing: ldapsearch -Y DIGEST-MD5

Yes, that's the anwser. Thanks.