[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP, PADL and querying multiple ADs
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
>> --------------------------------------------------------------
>>
>
>
>