We currently run a ldap server to authenticate our systems. It uses openldap 2.0.27-23 on redhat 3 or earlier. We recently tried to to upgrade the servers to Redhat 4 which uses openldap 2.2.13-7. We were unable to get it to function with the exact setup, configs and database we used in the earlier versions. As I understand it, strict checking was enforced in the later version of openldap and was not in the previous versions. The entries in the ldap directory have the following object classes: top, person, organizationalperson, inetorgperson, posixaccount, shadowaccount, account. Person and Account are both structural classes. I could be off base, but I thought that only one structural class is allowed and since this wasn't enforced in earlier versions it worked. Now since it is enforced it may be at least one of the issues. The main reason the account object class is used is for the host attribute which we use with the ldap.conf "pam_check_host_attr" directive to limit who can log into certain machines. If my assumptions above are correct, are there any suggestions on how to upgrade to the newer version of openldap and get around the above issues?
Thanks
--On Thursday, October 18, 2007 10:00 AM -0600 ldap ldap@buglecreek.com wrote:
We currently run a ldap server to authenticate our systems. It uses openldap 2.0.27-23 on redhat 3 or earlier. We recently tried to to upgrade the servers to Redhat 4 which uses openldap 2.2.13-7. We were unable to get it to function with the exact setup, configs and database we used in the earlier versions. As I understand it, strict checking was enforced in the later version of openldap and was not in the previous versions. The entries in the ldap directory have the following object classes: top, person, organizationalperson, inetorgperson, posixaccount, shadowaccount, account. Person and Account are both structural classes. I could be off base, but I thought that only one structural class is allowed and since this wasn't enforced in earlier versions it worked. Now since it is enforced it may be at least one of the issues. The main reason the account object class is used is for the host attribute which we use with the ldap.conf "pam_check_host_attr" directive to limit who can log into certain machines. If my assumptions above are correct, are there any suggestions on how to upgrade to the newer version of openldap and get around the above issues?
Redesign your data and do a mass migration.
Use a modern, supported version of OpenLDAP. Avoid what RedHat ships like the plague.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
ldap skrev, on 18-10-2007 18:00:
We currently run a ldap server to authenticate our systems. It uses openldap 2.0.27-23 on redhat 3 or earlier. We recently tried to to upgrade the servers to Redhat 4 which uses openldap 2.2.13-7. We were unable to get it to function with the exact setup, configs and database we used in the earlier versions. As I understand it, strict checking was enforced in the later version of openldap and was not in the previous versions. The entries in the ldap directory have the following object classes: top, person, organizationalperson, inetorgperson, posixaccount, shadowaccount, account. Person and Account are both structural classes. I could be off base, but I thought that only one structural class is allowed and since this wasn't enforced in earlier versions it worked. Now since it is enforced it may be at least one of the issues. The main reason the account object class is used is for the host attribute which we use with the ldap.conf "pam_check_host_attr" directive to limit who can log into certain machines. If my assumptions above are correct, are there any suggestions on how to upgrade to the newer version of openldap and get around the above issues?
In addition to what Quanah says about using an up to date release and avoiding Red Hat offerings like the plague, you can use the ldapns.schema for providing the host attribute; the objectClass hostObject that provides the host attribute is auxiliary. This schema is provided in Buchan Milnes' rpm set which you should use instead of Red Hat's.
--Tonni
openldap-software@openldap.org
-
ldap -
Quanah Gibson-Mount -
Tony Earnshaw