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: 1. Client "C" connects to P with say binddn cn=user,dc=domain and password pw 2. 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. 1. 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). 1. 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