For a variety of reasons, I've become the defacto LDAP admin at my workplace. I've been learning it on the job for about a year now. So, as I describe things, feel free to suggest better ways of doing things.
I have a Novell eDirectory that I'm storing employee information in. It's main use is to authenticate various web services like Moodle or Drupal. But I'm also using it as a backend for a new Employee Directory. I didn't see any point in duplicating the data anymore than it was already being duplicated. Plus, an employee directory sounds like exactly the kind of thing LDAP was made for.
I created entries for each office, then set up an attribute on each user that references the dn of the office entry for their office. The problem I have now is that each office likely has it's own phone number. Thus, employees who have more than one office (if they work at more than one campus, for example) have more than one phone number. Since phone numbers follow the employee, I can't just assign the number to the office entry. So, I need some way to say, "this phone number is for this office."
If this was a MySQL database, I'd just create a table that maps things however I want.
Is there a similar structure I could use in LDAP? Or method that's equivalent?
To give a detailed example of what I'm talking about here's a pseudo ldif of an employee entry:
dn: cn=user,ou=staff,dc=college,dc=edu
officedn: cn=DC107,ou=locations,dc=college,dc=edu
officedn: cn=MAIN222,ou=locations,dc=college,dc=edu
phone: 555-555-5555
phone: 111-111-1111
departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu
departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
title: web systems admin
title: professor of discrete math
So, how would I relate:
officedn: cn=DC107,ou=locations,dc=college,dc=edu
to phone: 555-555-5555
?
Or officedn: cn=MAIN222,ou=locations,dc=college,dc=edu
to phone: 111-111-1111
?
Or departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
to title: professor of discrete math
?
And so on...
Some notes, just in case they are relevant:
I created custom attributes for the office and department dn's using the DN syntax 1.3.6.1.4.1.1466.115.121.1.12.
Department entries have the objectClasses groupOfNames, nestedGroupAux, and Top.
Offices have the objectClasses: A custom objectClass containing the custom dn reference to their parent campus entry, ndsLoginProperties, organizationalPerson, Person, and Top.
User entries are the same as offices, plus posixAccount.
Is there any other information I should provide?
Edit to address issues the comments are too short for:
If I create another entry containing the meta information, as described in https://serverfault.com/a/500129/99647 I'd need to create a meta entry per phone number, and per job title.
dn: cn=MAIN222,cn=user,ou=staff,dc=college,dc=edu
officedn: cn=MAIN222,ou=locations,dc=college,dc=edu
phone: 111-111-1111
departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
title: professor of discrete math
departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu
title: web systems admin
Would not work because there's no way for a computer to figure out that web systems admin doesn't go with math, but does go with it.
Before I posted the question, the method I thought out was something like creating an ou for all the metadata: ou=metadata,dc=college,dc=edu
Then an ou for each user: ou=userid,ou=metadata,dc=college,dc=edu
Then an entry per job title and phone number that linked them to their departments and offices:
``` dn: cn=jobtitle,ou=userid,ou=metadata,dc=college,dc=edu officedn: cn=DC107,ou=locations,dc=college,dc=edu phone: 555-555-5555
dn: cn=phonenumber,ou=userid,ou=metadata,dc=college,dc=edu officedn: cn=MAIN222,ou=locations,dc=college,dc=edu phone: 111-111-1111 ```
I was hoping that there was a cleaner way than that to accomplish what I want.
Why not just create an object for each position that includes the officedn and related information in the same object?
So:
That way, you keep all the fields relevant to a single position in one object, and the user's object is the container. That'll make searching and processing an arbitrary number of positions extremely straightforward.