|
Hi ,
I've got a fairly critical problem to rolling out
openLDAP to control apps in our organisation. We've tested openLDAP and found
it's cross-application support to be superb, especially with v2 support added
in.
Can somebody please, please tell me how to
set up aliases correctly??
We are trying to build as flat a structure as
possible, as people in our organisation move between roles quite frequently, so
in a nutshell what we're planning is something like this:
dc=company,dc=com
|
c=uk
|
o=thisCompany
|
ou=people
cn=John Smith
(inetOrgPerson)
cn=Mary Jane
(inetOrgPerson)
ou=everybody
cn=John Smith (ALIAS pointing to
cn=John Smith,ou=people,o=thisCompany,c=uk,dc=company,dc=com)
ou=managers
cn=Mary Jane (ALIAS pointing to
cn=John Smith,ou=people,o=thisCompany,c=uk,dc=company,dc=com)
We're running openLDAP 2.1.22 and Berkeley DB
4.1.25.
I found some threads in the mailing lists that
state that aliases are not supported running in "bdb" mode, so
i recompiled openldap to get ldbm support into the slapd.conf
(incidentally, i also tried GDBM, but with the same effect).
Currently, the slapd.conf on our test server looks like this:
<snip>
# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v
1.23.2.8 2003/05/24 23:19:14 kurt Exp $
# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/corba.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/openldap.schema pidfile /usr/local/var/slapd.pid argsfile /usr/local/var/slapd.args ####################################################################### # ldbm database definitions ####################################################################### database ldbm suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw password # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq </snip>
Our current ldif looks like this:
<snip>
dn: dc=example,dc=com
objectclass: dcObject
objectclass: organization
o: example
dc: example
dn: cn=Manager,dc=example,dc=com
objectclass: organizationalRole
cn: Manager
dn: o=unipalm,c=uk,dc=example,dc=com
o: unipalm
objectclass: organization
objectclass: top
dn: ou=people,o=unipalm,c=uk,dc=example,dc=com
ou: people
objectclass: organizationalunit
objectclass: top
dn: ou=everyone,o=unipalm,c=uk,dc=example,dc=com
ou: everyone
objectclass: organizationalunit
objectclass: top
dn: ou=managers,o=unipalm,c=uk,dc=example,dc=com
ou: managers
objectclass: organizationalunit
objectclass: top
dn: cn=Patrick Drago,ou=people,o=unipalm,c=uk,dc=example,dc=com
cn: Patrick Drago
sn: Drago
uid: patrickd
userpassword: password
objectclass: inetorgperson
objectclass: top
dn: cn=Emmet Cleere,ou=people,o=unipalm,c=uk,dc=example,dc=com
cn: Emmet Cleere
sn: Cleere
uid: emmetc
userpassword: password
objectclass: inetorgperson
objectclass: top
</snip>
What we'd LIKE to do is create an entry like
the following: (the position of the alias is
in bold)
dn: cn=Emmet
Cleere,ou=manager,o=unipalm,c=uk,dc=example,dc=com
objectclass: alias
aliasedObjectName: cn=Emmet
Cleere,ou=people,o=unipalm,c=uk,dc=example,dc=com
When we try an ldapadd operation, I get this error . . .
# ldapadd -x -v -D "cn=Manager,dc=example,dc=com" -W -f
calias.ldif
ldap_initialize( <DEFAULT> ) Enter LDAP Password: add objectClass: alias add aliasedObjectName: cn=Emmet Cleere,ou=people,o=unipalm,c=uk,dc=example,dc=com adding new entry "cn=Emmet Cleere,ou=managers,o=unipalm,c=uk,dc=example,dc=com" ldapadd: update failed: cn=Emmet Cleere,ou=managers,o=unipalm,c=uk,dc=example,dc=com ldap_add: Naming violation (64) additional info: naming attribute 'cn' is not present in entry I have also tried this variation, based on some info i googled for . . . but it didn't work either . . . dn: cn=Emmet
Cleere,ou=manager,o=unipalm,c=uk,dc=example,dc=com
objectclass: alias
objectclass: inetOrgPerson
cn: Emmet Cleere
aliasedObjectName: cn=Emmet
Cleere,ou=people,o=unipalm,c=uk,dc=example,dc=com on an ldapadd, we get . . .
ldap_initialize( <DEFAULT> )
Enter LDAP Password: add objectClass: alias inetOrgPerson add cn: Emmet Cleere add aliasedObjectName: cn=Emmet Cleere,ou=people,o=unipalm,c=uk,dc=example,dc=com adding new entry "cn=Emmet Cleere,ou=managers,o=unipalm,c=uk,dc=example,dc=com" ldapadd: update failed: cn=Emmet Cleere,ou=managers,o=unipalm,c=uk,dc=example,dc=com ldap_add: Object class violation (65) additional info: invalid structural object class chain (alias/inetOrgPerson) HELP!! I can't seem to find any documentation about this anywhere . . . or i'm looking in all the wrong places. We'd really like to move off out old Netscape Directory as it's application support for anything non Netscape is truly appalling, but this one problem is a massive sticking point. Movement between departments makes segregation of inetorgpersons under OUs a management nightmare. I've also tried implementing a referral instead of an alias, with the referral referencing back to the server, but that doesn't work either!
Thanks & regards,
Patrick Drago
|