2

I'm currently making a custom LDAP schema for my organisation but I can't find how to give an objectclass an attribute that allows you to refer to another entry.

For example: I have an enrollment objectclass. It has an attribute that links to the user whose enrollment it is. That user is also an entry (person objectclass) in the LDAP database.

When I look for aliases, references and such but can't find out how to do it.

Can anyone get me going again?

Improve this question

2 Answers 2

Reset to default
2

.schema format 

attributetype ( $OIDNUMBER NAME '$attribute-name'
    DESC '$description-of-attribute'
    SUP distinguishedName )

You'll still need to define an objectclass that may/must use this attributetype.
(In OpenLDAP distinguishedName is built into the system schema.)

This isn't actually aliasing, but rather an attribute type that allows for dn valued entries.
The most common example of this would be groupOfNames and member from core.schema.

attributetype ( 2.5.4.49 NAME 'distinguishedName'
       EQUALITY distinguishedNameMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attributetype ( 2.5.4.31 NAME 'member'
        DESC 'RFC2256: member of a group'
        SUP distinguishedName )

objectclass ( 2.5.6.9 NAME 'groupOfNames'
        DESC 'RFC2256: a group of names (DNs)'
        SUP top STRUCTURAL
        MUST ( member $ cn )
        MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )


dn: cn=postmasters,ou=groups,dc=domain,dc=tld
objectClass: groupOfNames
cn: postmasters
member: uid=user1,ou=users,dc=domain,dc=tld
member: uid=user2,ou=users,dc=domain,dc=tld
Improve this answer
3

LDAP does not specify a means to automatically link to the authoritative data of another object or attribute. When you see aliases and the like in LDAP, they are usually objects that have an attribute specifying which object should actually be read in place of the alias. This is because LDAP is essentially a hierarchical store of objects rather than a relational datastore. Following aliases and like is an implementation detail of what is reading the LDAP data rather than a low-level function of the LDAP store itself (although sometimes highly abstracted environments like eDirectory will do this themselves).

What you probably want to do is something like the above, where you have an attribute that contains the DN of the "linked" object and make sure that anything calling the "link" knows to do a second lookup of the other DN.

Improve this answer
1
  • Thanks, the other comment by @84104 was a good example but your explanation helped me understand it a lot better.
    – HDW
    Aug 15, 2012 at 8:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .