[Date Prev][Date Next] [Chronological] [Thread] [Top]

New to openLDAP: CRY FOR HELP! What on earth do i need to do to create ALIASES????



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
 


-------------------------------------------------------------------
CONFIDENTIALITY AND DISCLAIMER NOTICE

This e-mail is intended only for the addressee named above and the
contents should not be disclosed to any other person nor copies
taken. Any views or opinions presented are solely those of the
sender and do not necessarily represent those of ComputerLinks (UK) Ltd.
(trading as Unipalm) unless otherwise specifically stated. As
internet communications are not secure we do not accept legal
responsibility for the contents of this message nor responsibility
for any change made to this message after it was sent by the
original sender. We advise you to carry out your own virus check
before opening any attachment as we cannot accept liability for any
damage sustained as a result of any software viruses.
-------------------------------------------------------------------