> On 8/19/19 10:39 AM, Markus.Storm@t-systems.com wrote:
> > Ultimately I want some UNIX machines using pam-ldap to authenticate
against
> an Active Directory ("AD").
>
> Hint: Don't use the ancient pam_ldap.
>
Of course, my bad. It's sssd already.
> > 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,
> That's exactly the use-case for overlay slapo-translucent used in a
> proxy backend along with back-mdb for storing local data:
>
> https://www.openldap.org/software/man.cgi?query=slapo-translucent
>
> With this you can point your clients to S.
But as mentioned in quote unfortunately S is not an OpenLDAP so this doesn't
work.
I have it working on P (even without slapo-translucent as I can simply store
all attributes in the local DB, there's none that needs to be
retrieved/merged from AD). But I want P to be dataless to not depend on any
synchronization from S to P as that's not issueless with the product we use
to run S.
>
> There are other variants to this use-case, e.g. proxying only the bind
> requests sent to S to AD (pass-through authc) and retrieving all data
> from S.
That's what I'm looking for. Can you elaborate on that please ?
And remember S is not an OpenLDAP. The request either gets from the client
into P (which *is* OpenLDAP) or gets into S first and gets proxied from
there to P.
>
> Ciao, Michael.
Thanks, Markus
Attachment:
smime.p7s
Description: S/MIME cryptographic signature