Dear OpenLDAP Tech list:
I can't tell if the problem below is with OpenLDAP, or nss_ldap. Since I can reproduce the problem with the ldapsearch command, I'm inclined to think it's with OpenLDAP. Any assistance will be greatly appreciated.
At the academic institution where are work, there are several different departments that maintain their own LDAP directory:
dc=sns,dc=example,dc=edu dc=math,dc=example,dc=edu dc=itg,dc=example,dc=edu dc=net,dc=example,dc=edu
and a top-level LDAP server that just contains referrals to the individual dept servers:
dc=example,dc=edu
We are now looking to share access to systems without duplicating account information in all the LDAP servers. So if someone from math would like to log into an SNS system, they can authenticate against their credentials in the math LDAP directory, and get their account information from there, too.
We are using an RHEL 5.4-based Linux distro.
To facilitate this, I added this to my /etc/openldap/slapd.conf:
database ldap suffix "dc=example,dc=edu" uri ldaps://ldap.example.edu/
And in /etc/ldap.conf, I changed the base to dc=example, dc=edu. The clients are still searching my local OpenLDAP server first.
After making these changes, 'getent passwd no longer works correctly, and these ldapsearch no longer returns results
ldapsearch -x objectClass=posixAccount ldapsearch -x -b dc=example,dc=edu objectClass=posixAccount ldapsearch -x -b dc=sns,dc=example,dc=edu objectClass=posixAccount ldapsearch -x -b dc=math,dc=example,dc=edu objectClass=posixAccount
However, these ldapsearches work as expected
ldapsearch -x objectClass=account ldapsearch -x ldapsearch -x objectClass=inetorgperson ldapsearch -x objectClass=inetlocalmailrecipient ldapsearch -x objectClass=top ldapsearch -x -b dc=math,dc=example,dc=edu
Any ideas why the behavior is different for the posixAccount object class vs. the other object classes? Is there any other configurations for OpenLDAP that would achieve the same goal?
Prentice Bisbal wrote:
Dear OpenLDAP Tech list:
I can't tell if the problem below is with OpenLDAP, or nss_ldap. Since I can reproduce the problem with the ldapsearch command, I'm inclined to think it's with OpenLDAP. Any assistance will be greatly appreciated.
At the academic institution where are work, there are several different departments that maintain their own LDAP directory:
dc=sns,dc=example,dc=edu dc=math,dc=example,dc=edu dc=itg,dc=example,dc=edu dc=net,dc=example,dc=edu
and a top-level LDAP server that just contains referrals to the individual dept servers:
dc=example,dc=edu
We are now looking to share access to systems without duplicating account information in all the LDAP servers. So if someone from math would like to log into an SNS system, they can authenticate against their credentials in the math LDAP directory, and get their account information from there, too.
We are using an RHEL 5.4-based Linux distro.
To facilitate this, I added this to my /etc/openldap/slapd.conf:
database ldap suffix "dc=example,dc=edu" uri ldaps://ldap.example.edu/
And in /etc/ldap.conf, I changed the base to dc=example, dc=edu. The clients are still searching my local OpenLDAP server first.
After making these changes, 'getent passwd no longer works correctly, and these ldapsearch no longer returns results
ldapsearch -x objectClass=posixAccount ldapsearch -x -b dc=example,dc=edu objectClass=posixAccount ldapsearch -x -b dc=sns,dc=example,dc=edu objectClass=posixAccount ldapsearch -x -b dc=math,dc=example,dc=edu objectClass=posixAccount
However, these ldapsearches work as expected
ldapsearch -x objectClass=account ldapsearch -x ldapsearch -x objectClass=inetorgperson ldapsearch -x objectClass=inetlocalmailrecipient ldapsearch -x objectClass=top ldapsearch -x -b dc=math,dc=example,dc=edu
Any ideas why the behavior is different for the posixAccount object class vs. the other object classes? Is there any other configurations for OpenLDAP that would achieve the same goal?
Hi,
please, provide us with: *OpenLDAP version - and since you say RHEL, I'd bet you're using 2.3.x. In such case, please update to the latest version which is 2.4.20. 2.3.x is deprecated and unmaintained *slapd.conf and probably even structure of the tree would be useful too (?)
The last thing. Do you have % nscd; running? I'm using nss-ldap too and it -didn't- doesn't work without % nscd;. Or let's just say, it is not reliable without it.
Regards, Zdenek
openldap-technical@openldap.org