Hi,
I'm migrating from a Sun One DS service to Openldap 2.4. In our current setup, the ldap.conf on each client the nss_base_passwd line is configured as
nss_base_passwd ou=people,dc=ldn,dc=sw,dc=com?sub?ismemberof=cn=access,ou=auth,dc=ldn,dc=sw,dc=com
This ensures that only users within the CN 'access' can login to the servers.
Have exported and imported the data and carried out necessary cleaning up work, the ldapsearch brings back identical output when examining 'cn=access,ou=auth,dc=ldn,dc=sw,dc=com' but on my client which talks to the Openldap server, I cannot login with any accounts is the above setting is in place.
I'm presuming that the issue is about the config of the above line but try as I might I can't get it to work correctly.
Any help would be appreciated.
Thanks,
Stuart Cherrington. _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now
On Fri, 4 Jun 2010, Stuart Cherrington wrote:
nss_base_passwd ou=people,dc=ldn,dc=sw,dc=com?sub?ismemberof=cn=access,ou=auth,dc=ldn,dc=sw,dc=com
This ensures that only users within the CN 'access' can login to the servers.
For a group, perhaps you should be using "pam_groupdn" directive instead of that filter? (Test your setup with OpenLDAP's ldapcompare(1).)
On 04/06/2010 11:49, Stuart Cherrington wrote:
Hi,
I'm migrating from a Sun One DS service to Openldap 2.4. In our current setup, the ldap.conf on each client the nss_base_passwd line is configured as
nss_base_passwd ou=people,dc=ldn,dc=sw,dc=com?sub?ismemberof=cn=access,ou=auth,dc=ldn,dc=sw,dc=com
This ensures that only users within the CN 'access' can login to the servers.
Have exported and imported the data and carried out necessary cleaning up work, the ldapsearch brings back identical output when examining 'cn=access,ou=auth,dc=ldn,dc=sw,dc=com' but on my client which talks to the Openldap server, I cannot login with any accounts is the above setting is in place.
I'm presuming that the issue is about the config of the above line but try as I might I can't get it to work correctly.
Any help would be appreciated.
Hi,
As far as I know, "nss_base_passwd" is not a valid keyword in ldap.conf for OpenLDAP clients.
If you're configuring this on a Linux server, I think you'll find the equivalent configuration in /etc/libnss_ldap.conf or similar.
Hope this helps, Jonathan
On Friday, 4 June 2010 13:47:42 Jonathan Clarke wrote:
On 04/06/2010 11:49, Stuart Cherrington wrote:
As far as I know, "nss_base_passwd" is not a valid keyword in ldap.conf for OpenLDAP clients.
If you're configuring this on a Linux server, I think you'll find the equivalent configuration in /etc/libnss_ldap.conf or similar.
Upstream default is /etc/ldap.conf, libnss-ldap.conf is an unnecessary Debian- ism.
Regards, Buchan
Buchan Milne wrote:
On Friday, 4 June 2010 13:47:42 Jonathan Clarke wrote:
On 04/06/2010 11:49, Stuart Cherrington wrote:
As far as I know, "nss_base_passwd" is not a valid keyword in ldap.conf for OpenLDAP clients.
If you're configuring this on a Linux server, I think you'll find the equivalent configuration in /etc/libnss_ldap.conf or similar.
Upstream default is /etc/ldap.conf, libnss-ldap.conf is an unnecessary Debian- ism.
The upstream default has been an endless source of confusion for the better part of a decade. Renaming ala Debian is the right answer.
Date: Sat, 5 Jun 2010 11:39:22 -0700 From: hyc@symas.com To: bgmilne@staff.telkomsa.net CC: openldap-technical@openldap.org; jonathan@phillipoux.net; stuart_cherrington@hotmail.co.uk Subject: Re: User restriction
Buchan Milne wrote:
On Friday, 4 June 2010 13:47:42 Jonathan Clarke wrote:
On 04/06/2010 11:49, Stuart Cherrington wrote:
As far as I know, "nss_base_passwd" is not a valid keyword in ldap.conf for OpenLDAP clients.
If you're configuring this on a Linux server, I think you'll find the equivalent configuration in /etc/libnss_ldap.conf or similar.
Upstream default is /etc/ldap.conf, libnss-ldap.conf is an unnecessary Debian- ism.
The upstream default has been an endless source of confusion for the better part of a decade. Renaming ala Debian is the right answer.
OK - Thanks for all your comments so far, the whole LDAP structure is starting to become clearer but not as simple as I'd like. As Aron suggested, I used the ldapcompare command to see if I could pull the 'member' information from the schema but it fails.
An ldapsearch shows the following:
ldapsearch -x -b 'ou=auth,dc=ldn,dc=sw,dc=com' -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxxx # extended LDIF # # LDAPv3 # base <ou=auth,dc=ldn,dc=sw,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# auth, ldn.sw.com dn: ou=auth,dc=ldn,dc=sw,dc=com ou: auth objectClass: organizationalUnit objectClass: top
# access, auth, ldn.sw.com dn: cn=access,ou=auth,dc=ldn,dc=sw,dc=com objectClass: groupOfNames objectClass: top cn: access member: uid=stuart,ou=people,dc=ldn,dc=sw,dc=com member: cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com member: uid=rpratt,ou=people,dc=ldn,dc=sw,dc=com member: uid=jason,ou=people,dc=ldn,dc=sw,dc=com member: uid=pstuart,ou=people,dc=ldn,dc=sw,dc=com member: uid=pfield,ou=people,dc=ldn,dc=sw,dc=com member: uid=nereelot,ou=people,dc=ldn,dc=sw,dc=com member: uid=scolebro,ou=people,dc=ldn,dc=sw,dc=com member: uid=bpower,ou=people,dc=ldn,dc=sw,dc=com member: uid=ihunt,ou=people,dc=ldn,dc=sw,dc=com member: uid=emoreton,ou=people,dc=ldn,dc=sw,dc=com member: uid=lcable,ou=people,dc=ldn,dc=sw,dc=com member: uid=pmurray,ou=people,dc=ldn,dc=sw,dc=com
# search result search: 2 result: 0 Success
You can clearly see the first Member line is myself. If I now try:
ldapcompare2.4 -v -x -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxxxxx "ou=auth,dc=ldn,dc=sw,dc=com" member:uid=stuart,ou=people,dc=ldn,dc=sw,dc=com
ldap_initialize( ldap://10.2.250.15 ) DN:ou=auth,dc=ldn,dc=sw,dc=com, attr:member, value:uid=stuart,ou=people,dc=ldn,dc=sw,dc=com Compare Result: No such attribute (16) UNDEFINED
Any pointers here would be useful.
Thanks,
Stuart.
_________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now
On Mon, Jun 7, 2010 at 4:44 AM, Stuart Cherrington < stuart_cherrington@hotmail.co.uk> wrote:
Date: Sat, 5 Jun 2010 11:39:22 -0700 From: hyc@symas.com To: bgmilne@staff.telkomsa.net CC: openldap-technical@openldap.org; jonathan@phillipoux.net;
stuart_cherrington@hotmail.co.uk
Subject: Re: User restriction
Buchan Milne wrote:
On Friday, 4 June 2010 13:47:42 Jonathan Clarke wrote:
On 04/06/2010 11:49, Stuart Cherrington wrote:
As far as I know, "nss_base_passwd" is not a valid keyword in
ldap.conf
for OpenLDAP clients.
If you're configuring this on a Linux server, I think you'll find the equivalent configuration in /etc/libnss_ldap.conf or similar.
Upstream default is /etc/ldap.conf, libnss-ldap.conf is an unnecessary
Debian-
ism.
The upstream default has been an endless source of confusion for the
better
part of a decade. Renaming ala Debian is the right answer.
OK - Thanks for all your comments so far, the whole LDAP structure is starting to become clearer but not as simple as I'd like. As Aron suggested, I used the ldapcompare command to see if I could pull the 'member' information from the schema but it fails.
An ldapsearch shows the following:
ldapsearch -x -b 'ou=auth,dc=ldn,dc=sw,dc=com' -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxxx # extended LDIF # # LDAPv3 # base <ou=auth,dc=ldn,dc=sw,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# auth, ldn.sw.com dn: ou=auth,dc=ldn,dc=sw,dc=com ou: auth objectClass: organizationalUnit objectClass: top
# access, auth, ldn.sw.com dn: cn=access,ou=auth,dc=ldn,dc=sw,dc=com objectClass: groupOfNames objectClass: top cn: access member: uid=stuart,ou=people,dc=ldn,dc=sw,dc=com member: cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com member: uid=rpratt,ou=people,dc=ldn,dc=sw,dc=com member: uid=jason,ou=people,dc=ldn,dc=sw,dc=com member: uid=pstuart,ou=people,dc=ldn,dc=sw,dc=com member: uid=pfield,ou=people,dc=ldn,dc=sw,dc=com member: uid=nereelot,ou=people,dc=ldn,dc=sw,dc=com member: uid=scolebro,ou=people,dc=ldn,dc=sw,dc=com member: uid=bpower,ou=people,dc=ldn,dc=sw,dc=com member: uid=ihunt,ou=people,dc=ldn,dc=sw,dc=com member: uid=emoreton,ou=people,dc=ldn,dc=sw,dc=com member: uid=lcable,ou=people,dc=ldn,dc=sw,dc=com member: uid=pmurray,ou=people,dc=ldn,dc=sw,dc=com
# search result search: 2 result: 0 Success
You can clearly see the first Member line is myself. If I now try:
ldapcompare2.4 -v -x -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxxxxx "ou=auth,dc=ldn,dc=sw,dc=com" member:uid=stuart,ou=people,dc=ldn,dc=sw,dc=com
ldap_initialize( ldap://10.2.250.15 ) DN:ou=auth,dc=ldn,dc=sw,dc=com, attr:member, value:uid=stuart,ou=people,dc=ldn,dc=sw,dc=com Compare Result: No such attribute (16) UNDEFINED
Any pointers here would be useful.
Thanks,
Stuart.
Get a new e-mail account with Hotmail - Free. Sign-up now.http://clk.atdmt.com/UKM/go/197222280/direct/01/
I suggest reading these two threads and it might answer your question.
First Thread: http://www.openldap.org/lists/openldap-technical/200912/msg00022.html
Continuation of First Thread: http://www.openldap.org/lists/openldap-technical/201006/msg00018.html
Sorry for not re-typing all of that but i have other things to be doing this morning.
- Adam
On Mon, 7 Jun 2010, Stuart Cherrington wrote:
[given]
dn: cn=access,ou=auth,dc=ldn,dc=sw,dc=com objectClass: groupOfNames objectClass: top cn: access member: uid=stuart,ou=people,dc=ldn,dc=sw,dc=com member: cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com member: uid=rpratt,ou=people,dc=ldn,dc=sw,dc=com member: uid=jason,ou=people,dc=ldn,dc=sw,dc=com member: uid=pstuart,ou=people,dc=ldn,dc=sw,dc=com member: uid=pfield,ou=people,dc=ldn,dc=sw,dc=com member: uid=nereelot,ou=people,dc=ldn,dc=sw,dc=com member: uid=scolebro,ou=people,dc=ldn,dc=sw,dc=com member: uid=bpower,ou=people,dc=ldn,dc=sw,dc=com member: uid=ihunt,ou=people,dc=ldn,dc=sw,dc=com member: uid=emoreton,ou=people,dc=ldn,dc=sw,dc=com member: uid=lcable,ou=people,dc=ldn,dc=sw,dc=com member: uid=pmurray,ou=people,dc=ldn,dc=sw,dc=com
[running]
ldapcompare2.4 -v -x -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxxxxx "ou=auth,dc=ldn,dc=sw,dc=com" member:uid=stuart,ou=people,dc=ldn,dc=sw,dc=com
[outputs]
Compare Result: No such attribute (16)
Yes. Don't compare against "ou=auth,dc=ldn,dc=sw,dc=com", compare against "cn=access,ou=auth,dc=ldn,dc=sw,dc=com" in your ldapcompare2.4 command.
Adam Hough adam@gradientzero.com writes:
On Mon, Jun 7, 2010 at 4:44 AM, Stuart Cherrington < stuart_cherrington@hotmail.co.uk> wrote:
[...]
ldapsearch -x -b 'ou=auth,dc=ldn,dc=sw,dc=com' -h 10.2.250.15 -D cn= proxyagent,ou=profile,dc=ldn,dc=sw,dc=com -w xxxxxx
[...]
This search is done with default scope, which is subtree.
dn: cn=access,ou=auth,dc=ldn,dc=sw,dc=com objectClass: groupOfNames objectClass: top cn: access member: uid=stuart,ou=people,dc=ldn,dc=sw,dc=com
[...]
You can clearly see the first Member line is myself. If I now try: ldapcompare2.4 -v -x -h 10.2.250.15 -D cn=proxyagent,ou=profile,dc=ldn,dc= sw,dc=com -w xxxxxxxx "ou=auth,dc=ldn,dc=sw,dc=com" member:uid=stuart,ou= people,dc=ldn,dc=sw,dc=com
[...]
A ldapcompare is done one the base DN. please compare those two DN's: ou=auth,dc=ldn,dc=sw;dc=com cn=access,ou=auth,dc=ldn,dc=sw,dc=com
-Dieter
-
openldap-technical@openldap.org
-
Aaron Richton -
Adam Hough -
Buchan Milne -
Dieter Kluenter -
Howard Chu -
Jonathan Clarke -
Stuart Cherrington