[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: OpenLDAP, PADL and querying multiple ADs

To: openldap-technical@openldap.org
Subject: Re: OpenLDAP, PADL and querying multiple ADs
From: "Markus" <universe@truemetal.org>
Date: Wed, 7 Jul 2010 10:26:18 +0200 (CEST)
Importance: Normal
In-reply-to: <d9546af6714a683bbdf2a69abadcde87.squirrel@squirrel.lightup.net>
References: <6a1a5fafcebf9f06e4db485ed4888412.squirrel@squirrel.lightup.net> <4C189FF0.30203@phillipoux.net> <edd0399db7c58136d8ef4dca4d939c0c.squirrel@squirrel.lightup.net> <d9546af6714a683bbdf2a69abadcde87.squirrel@squirrel.lightup.net>
User-agent: SquirrelMail/1.4.15
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
>>> --------------------------------------------------------------
>>>
>>
>>
>>
>
>
>
Prev by Date: Re: How to batch modify large amount of entries without increasing replication latency
Next by Date: TLS problem
Index(es):
- Chronological
- Thread