Complex setup to do back-ldap AND SASL auth in one go

Dear all,

I am desperately trying to setup an OpenLDAP instance “P” with a proxy or other backend or even chain of proxies to do the following and I just don’t manage to wrap my head around it. I’d be thankful if someone could give me a helping hand and provide me with the missing link. Apologies upfront for the lengthy mail and complicated setup, but for organizational reasons, I have a couple of constraints that I cannot change.

Scenario:

Ultimately I want some UNIX machines using pam-ldap to authenticate against an Active Directory (“AD”).

Logins to those machines require a number of attributes but I don’t have authority/ability to store them in the AD. They are stored in an external (non-OpenLDAP !) server “S” instead.

As the AD passwords cannot be read/replicated, I also cannot simply direct clients to S, so I want to direct them to an OpenLDAP instance “P” to “split” the request, i.e. do authentication against AD using external auth/SASL (that part already works) while retrieving the attributes from S.

I have this working to some extent but needed to create a copy of the user data on S in my openLDAP server/proxy P.
But I’m trying to avoid the need to have those copies in P, I want it to be dataless to avoid all need for synchronization (as S is non-OpenLDAP I cannot simply replicate).

I’m open to suggestions but I think it would need to work like this:

Client “C” connects to P with say binddn cn=user,dc=domain and password pw
P proxies all requests for dc=domain to S using a generic binddn (instead of the user credentials) to have access to the subtree the users are in

As of today I wouldn’t know how to configure that binddn on P.

S has an entry for every user with userpassword={SASL}user@domain and a couple of attributes which all are returned to P
S is the only place where we can store those attributes (and the instruction to use SASL - or is there another place for that ?)

But authentication of C against S fails when I use the user’s credentials (because of the “{SASL}…” contents on S).

Obviously S is unable to interpret/execute SASL auth format (if it was able that would be an obvious solution to my problem).

I also believe I cannot have ANOTHER userPassword attribute on S to have the user’s password pw (S wouldn’t know which of those 2 userPassword attributes to authenticate against).

P does SASL auth as user@domain and initially provided password against an Active Directory (“AD”)

The SASL part already works but only if I setup another DB in P to contain a copy of the user data tree on S and userPassword=“{SASL}user@domain” for all users.

Thanks in advance to anyone willing to wrap his head around my problem.

Best regards

Markus