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
