Thanks for the hint, Jonathan.

Is there anyone on this list who would call himself an (Open)LDAP expert and would be available for paid consulting regarding this matter? Please get in touch with me then!

Thanks Markus

On 15/06/2010 16:39, Markus wrote:

...

Hello list,

I'm on SLES 11 and the mission is to allow Active Directory (AD) users to log in to Linux. The difficulty is that those users are stored in two separate ADs which have no connection to each other. Both ADs are running on Windows 2003 R2 (or later) and I'm using the LDAP PADL NSS (/etc/ldap.conf) implementation to map the UNIX attributes that are stored in the AD to local values (homedir, shell, UID/GID etc.). So far so good, everything works fine (getent passwd, PAM logins).

Now, when searching for a solution on how to query two ADs via LDAP at the same time it seems like OpenLDAP supports multiple LDAP search bases, and there was also a mentioning of the translucent overlay feature, so I suppose using OpenLDAP I could fetch the UNIX attributes from both ADs simultaneously.

Yes, you can use OpenLDAP as a proxy to the two ADs via LDAP. Checkout the slapd-meta man page (meta is a backend that can take several remote LDAP proxy databases).

The translucent overlay would allow you to store extra information on your OpenLDAP server that's not in the AD directories. It doesn't sound like this is necessary for you, but I may be wrong.

Hope this helps, Jonathan

...

What completely puzzles me is the NSS/PAM configuration and how PADL NSS and OpenLDAP interact respectively not interact:

• If I configure OpenLDAP (/etc/openldap/ldap.conf) instead of PADL NSS

(/etc/ldap.conf) how do I configure NSS/PAM for OpenLDAP? I need "getent passwd" and "getent group" and of course PAM logins to work. E.g. getent passwd has to give me back all users from BOTH ADs that have UNIX attributes stored. But since there seems to be only the PADL NSS module in existance (/lib/libnss_ldap.so.2), I am clueless on how to integrate the OpenLDAP variant. Shouldn't there be something like /lib/libnss_openldap.so and shouldn't I be able to add something like "passwd: compat openldap" to /etc/nsswitch.conf? I guess not, but I don't understand why.

• So that leaves me with the idea of *somehow* fetching the UNIX

attributes from both ADs via OpenLDAP, set up a local OpenLDAP server to store this information in, and then using the PADL NSS module to query it. I'm not sure if this is the right approach or if this is even technically feasible. Is there maybe a easier way with less overhead (e.g. no OpenLDAP server required).

Thank you very much for any hints or pointers that you might share with me! I'm really lost...

Best regards Markus

--

Jonathan Clarke - jonathan@phillipoux.net

Ldap Synchronization Connector (LSC) - http://lsc-project.org

I have found a solution to the problem with the help of the following Blog entry that I found via Googling:

http://blog.sejo.be/2010/01/8/openldap-en-3-ad-servers/

This guy is my hero. :-)

Since this example only fetches user information from the ADs, but I also need to get group information, I have set up another "database meta" stanza for each ou= in AD where group information lies that I need to fetch, e.g.:

database meta suffix "dc=ad4,dc=grouped,dc=all" subordinate uri "ldap://x.x.x.x/dc=ad4,dc=grouped,dc=all" suffixmassage "dc=ad4,dc=grouped,dc=all" "OU=UNIXgroups,DC=company,DC=com" rewriteEngine on RewriteRule "group=(.*)dc=ad4,dc=grouped,dc=all$" "%1OU=UNIXgroups,DC=company,DC=com" ":"

I cannot figure out how to get to the groups otherwise. Maybe it would be possible to add another line of "uri", "suffixmassage" and "RewriteRule" to the e.g. dc=ad3 stanza (see Blog entry), but I haven't tested yet because my variant already works. The question is what will happen with the performance if I will have to add so many ou='s in the future and add another "database meta" stanza for each of them (maybe dozens or hundreds).

Anyway... lets go on:

What is not mentioned in the blog example is that we have to add the following to get users/groups mapped (and this means getting the whole setup to work at all). For database meta stanzas where you fetch users:

overlay rwm rwm-map objectclass posixAccount user rwm-map attribute homeDirectory unixHomeDirectory

And instead for those database meta stanzas where you fetch groups:

overlay rwm rwm-map objectclass posixGroup group

OpenLDAP will complain with the following at startup, though:

line 108: warning, destination objectClass 'group' is not defined in schema line 134: warning, destination objectClass 'user' is not defined in schema line 135: warning, destination attributeType 'unixHomeDirectory' is not defined in schema

But we don't care. :-) Without that it just doesn't work. It should be noted that the ADs are running on Windows Server 2003 R2 who have the rfc2307bis stuff integreated, no SFU (Services for Unix) required anymore.

Then, in /etc/ldap.conf I have the following:

host 127.0.0.1 base dc=grouped,dc=all binddn cn=user,dc=grouped,dc=all bindpw cn=userpw bind_policy soft nss_base_passwd DC=grouped,DC=all?sub nss_base_passwd DC=ad2,DC=grouped,DC=all?sub nss_base_group DC=ad3,DC=grouped,DC=all?sub nss_base_group DC=ad4,DC=grouped,DC=all?sub

Without the ?sub stuff I'm not getting any results (even though, at least for groups, I am specifying the exact ou= location of the groups in slapd.conf. Weird.).

Then getent passwd and getent group works and I can log in (e.g. via FTP) just fine to my local machine using an AD user that has proper UNIX attributes stored in any of the two ADs.

That's it. And what I just realized that I'm not using the "subordinate" feature how its supposed to work (according to the Blog entry) cause for me it doesn't work as described. So that means since I'm specifying the _passwd and _group stuff directly in /etc/ldap.conf I could probably also use multiple "database ldap" entries instead of "database meta". But then the question is how can I log in with a single root DN to my local OpenLDAP server, since /etc/ldap.conf allows only to set one, and only one search base (which is so 90s in some way).

Regards Markus

Thanks for the hint, Jonathan.

Is there anyone on this list who would call himself an (Open)LDAP expert and would be available for paid consulting regarding this matter? Please get in touch with me then!

Thanks Markus

...

On 15/06/2010 16:39, Markus wrote:

...

Hello list,

I'm on SLES 11 and the mission is to allow Active Directory (AD) users to log in to Linux. The difficulty is that those users are stored in two separate ADs which have no connection to each other. Both ADs are running on Windows 2003 R2 (or later) and I'm using the LDAP PADL NSS (/etc/ldap.conf) implementation to map the UNIX attributes that are stored in the AD to local values (homedir, shell, UID/GID etc.). So far so good, everything works fine (getent passwd, PAM logins).

Now, when searching for a solution on how to query two ADs via LDAP at the same time it seems like OpenLDAP supports multiple LDAP search bases, and there was also a mentioning of the translucent overlay feature, so I suppose using OpenLDAP I could fetch the UNIX attributes from both ADs simultaneously.

Yes, you can use OpenLDAP as a proxy to the two ADs via LDAP. Checkout the slapd-meta man page (meta is a backend that can take several remote LDAP proxy databases).

The translucent overlay would allow you to store extra information on your OpenLDAP server that's not in the AD directories. It doesn't sound like this is necessary for you, but I may be wrong.

Hope this helps, Jonathan

...

What completely puzzles me is the NSS/PAM configuration and how PADL NSS and OpenLDAP interact respectively not interact:

• If I configure OpenLDAP (/etc/openldap/ldap.conf) instead of PADL NSS

(/etc/ldap.conf) how do I configure NSS/PAM for OpenLDAP? I need "getent passwd" and "getent group" and of course PAM logins to work. E.g. getent passwd has to give me back all users from BOTH ADs that have UNIX attributes stored. But since there seems to be only the PADL NSS module in existance (/lib/libnss_ldap.so.2), I am clueless on how to integrate the OpenLDAP variant. Shouldn't there be something like /lib/libnss_openldap.so and shouldn't I be able to add something like "passwd: compat openldap" to /etc/nsswitch.conf? I guess not, but I don't understand why.

• So that leaves me with the idea of *somehow* fetching the UNIX

attributes from both ADs via OpenLDAP, set up a local OpenLDAP server to store this information in, and then using the PADL NSS module to query it. I'm not sure if this is the right approach or if this is even technically feasible. Is there maybe a easier way with less overhead (e.g. no OpenLDAP server required).

Thank you very much for any hints or pointers that you might share with me! I'm really lost...

Best regards Markus

--

Jonathan Clarke - jonathan@phillipoux.net

Ldap Synchronization Connector (LSC) - http://lsc-project.org

Replying to myself... some more infos regarding this setup:

1. If you are trying to specify the "root level" of your Active Directory forest as the search base in slapd.conf, then you may see that "id" and "getent passwd" will hang forever. If, while you are performing an LDAP search ("id username", for example), you will run tcpdump and/or strace you may see that your slapd is trying to contact a specific number of DCs in your forest (depending on how many are joined to your AD) one by one, and this might basically never time out... I've had to hit CTRL+C after 30 minutes of waiting for output from "getent passwd", as it was still (re)trying to contact all sorts of DCs (to which my box has no direct connection and thus failed to connect). To disable that behavior, the magic switch was "norefs yes" in your "database meta" stanza.

2. "RewriteRule ..." is not necessary. suffixmassage will do just fine.

So, in order to integrate two ADs at the same time and fetching the UNIX attributes stored in the AD for each user, the following config works. Note that "getent passwd" and "getent group" will not yield any output (at least here, probably too many users.), but you may work around that if you specify all the OU's with UNIX users/groups (= UNIX attributes) manually in /etc/ldap.conf, e.g.

nss_base_passwd ou=UNIXusers,dc=grouped,dc=all?sub nss_base_group ou=UNIXgroups,dc=grouped,dc=all?sub nss_base_passwd ou=MoreUsers,dc=ad2,dc=grouped,dc=all?sub nss_base_group ou=MoreGroups,dc=ad2,dc=grouped,dc=all?sub ...etc...

But even if it doesn't work its not that bad as its just cosmetic. "id username" or "getent passwd username" will always work.

So, anyways, the working config is:

/etc/openldap/slapd.conf:

moduleload back_meta.so

include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema

database meta norefs yes suffix "dc=ad2,dc=grouped,dc=all" subordinate uri "ldap://ADhost1/dc=ad2,dc=grouped,dc=all ldap://ADhostbackup/" suffixmassage "dc=ad2,dc=grouped,dc=all" "dc=bla,dc=blubb" idassert-bind bindmethod=simple binddn="CN="abc, def",OU=Accounts,OU=Somewhere,DC=bla,DC=blubb" credentials="xxxxxxx" overlay rwm rwm-map objectclass posixGroup group rwm-map objectclass posixAccount organizationalPerson rwm-map attribute homeDirectory unixHomeDirectory

database meta norefs yes suffix "dc=grouped,dc=all" rootdn "cn=adminuser,dc=grouped,dc=all" rootpw "somepassword" uri "ldaps://anotherADhost1/dc=grouped,dc=all ldaps://anotherADhostbackup1/ ldaps://anotherADhostbackup2/" suffixmassage "dc=grouped,dc=all" "DC=oink,DC=boink" idassert-bind bindmethod=simple binddn="CN=bla.XXX.svc,OU=SpecialAccounts,OU=Huhu,DC=oink,DC=boink" credentials="yyyyyyyy" overlay rwm rwm-map objectclass posixGroup group rwm-map objectclass posixAccount organizationalPerson rwm-map attribute homeDirectory unixHomeDirectory

And then finally your /etc/ldap.conf:

host 127.0.0.1 base dc=grouped,dc=all binddn cn=adminuser,dc=grouped,dc=all bindpw somepassword

(Yes, those 4 lines are sufficient. No mapping of the UNIX attributes necessary, you are already doing that in the rwm overlay of slapd.)

Regards Markus

I have found a solution to the problem with the help of the following Blog entry that I found via Googling:

http://blog.sejo.be/2010/01/8/openldap-en-3-ad-servers/

This guy is my hero. :-)

Since this example only fetches user information from the ADs, but I also need to get group information, I have set up another "database meta" stanza for each ou= in AD where group information lies that I need to fetch, e.g.:

database meta suffix "dc=ad4,dc=grouped,dc=all" subordinate uri "ldap://x.x.x.x/dc=ad4,dc=grouped,dc=all" suffixmassage "dc=ad4,dc=grouped,dc=all" "OU=UNIXgroups,DC=company,DC=com" rewriteEngine on RewriteRule "group=(.*)dc=ad4,dc=grouped,dc=all$" "%1OU=UNIXgroups,DC=company,DC=com" ":"

I cannot figure out how to get to the groups otherwise. Maybe it would be possible to add another line of "uri", "suffixmassage" and "RewriteRule" to the e.g. dc=ad3 stanza (see Blog entry), but I haven't tested yet because my variant already works. The question is what will happen with the performance if I will have to add so many ou='s in the future and add another "database meta" stanza for each of them (maybe dozens or hundreds).

Anyway... lets go on:

What is not mentioned in the blog example is that we have to add the following to get users/groups mapped (and this means getting the whole setup to work at all). For database meta stanzas where you fetch users:

overlay rwm rwm-map objectclass posixAccount user rwm-map attribute homeDirectory unixHomeDirectory

And instead for those database meta stanzas where you fetch groups:

overlay rwm rwm-map objectclass posixGroup group

OpenLDAP will complain with the following at startup, though:

line 108: warning, destination objectClass 'group' is not defined in schema line 134: warning, destination objectClass 'user' is not defined in schema line 135: warning, destination attributeType 'unixHomeDirectory' is not defined in schema

But we don't care. :-) Without that it just doesn't work. It should be noted that the ADs are running on Windows Server 2003 R2 who have the rfc2307bis stuff integreated, no SFU (Services for Unix) required anymore.

Then, in /etc/ldap.conf I have the following:

host 127.0.0.1 base dc=grouped,dc=all binddn cn=user,dc=grouped,dc=all bindpw cn=userpw bind_policy soft nss_base_passwd DC=grouped,DC=all?sub nss_base_passwd DC=ad2,DC=grouped,DC=all?sub nss_base_group DC=ad3,DC=grouped,DC=all?sub nss_base_group DC=ad4,DC=grouped,DC=all?sub

Without the ?sub stuff I'm not getting any results (even though, at least for groups, I am specifying the exact ou= location of the groups in slapd.conf. Weird.).

Then getent passwd and getent group works and I can log in (e.g. via FTP) just fine to my local machine using an AD user that has proper UNIX attributes stored in any of the two ADs.

That's it. And what I just realized that I'm not using the "subordinate" feature how its supposed to work (according to the Blog entry) cause for me it doesn't work as described. So that means since I'm specifying the _passwd and _group stuff directly in /etc/ldap.conf I could probably also use multiple "database ldap" entries instead of "database meta". But then the question is how can I log in with a single root DN to my local OpenLDAP server, since /etc/ldap.conf allows only to set one, and only one search base (which is so 90s in some way).

Regards Markus

...

Thanks for the hint, Jonathan.

Is there anyone on this list who would call himself an (Open)LDAP expert and would be available for paid consulting regarding this matter? Please get in touch with me then!

Thanks Markus

...

On 15/06/2010 16:39, Markus wrote:

...

Hello list,

I'm on SLES 11 and the mission is to allow Active Directory (AD) users to log in to Linux. The difficulty is that those users are stored in two separate ADs which have no connection to each other. Both ADs are running on Windows 2003 R2 (or later) and I'm using the LDAP PADL NSS (/etc/ldap.conf) implementation to map the UNIX attributes that are stored in the AD to local values (homedir, shell, UID/GID etc.). So far so good, everything works fine (getent passwd, PAM logins).

Now, when searching for a solution on how to query two ADs via LDAP at the same time it seems like OpenLDAP supports multiple LDAP search bases, and there was also a mentioning of the translucent overlay feature, so I suppose using OpenLDAP I could fetch the UNIX attributes from both ADs simultaneously.

Yes, you can use OpenLDAP as a proxy to the two ADs via LDAP. Checkout the slapd-meta man page (meta is a backend that can take several remote LDAP proxy databases).

The translucent overlay would allow you to store extra information on your OpenLDAP server that's not in the AD directories. It doesn't sound like this is necessary for you, but I may be wrong.

Hope this helps, Jonathan

...

What completely puzzles me is the NSS/PAM configuration and how PADL NSS and OpenLDAP interact respectively not interact:

• If I configure OpenLDAP (/etc/openldap/ldap.conf) instead of PADL

NSS (/etc/ldap.conf) how do I configure NSS/PAM for OpenLDAP? I need "getent passwd" and "getent group" and of course PAM logins to work. E.g. getent passwd has to give me back all users from BOTH ADs that have UNIX attributes stored. But since there seems to be only the PADL NSS module in existance (/lib/libnss_ldap.so.2), I am clueless on how to integrate the OpenLDAP variant. Shouldn't there be something like /lib/libnss_openldap.so and shouldn't I be able to add something like "passwd: compat openldap" to /etc/nsswitch.conf? I guess not, but I don't understand why.

• So that leaves me with the idea of *somehow* fetching the UNIX

attributes from both ADs via OpenLDAP, set up a local OpenLDAP server to store this information in, and then using the PADL NSS module to query it. I'm not sure if this is the right approach or if this is even technically feasible. Is there maybe a easier way with less overhead (e.g. no OpenLDAP server required).

Thank you very much for any hints or pointers that you might share with me! I'm really lost...

Best regards Markus

--

Jonathan Clarke - jonathan@phillipoux.net

Ldap Synchronization Connector (LSC) - http://lsc-project.org