3

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.

Community
  • 1
David R.
  • 607
  • 3
  • 6
  • 18

1 Answers1

1

Why not just create an object for each position that includes the officedn and related information in the same object?

So:

dn: cn=DC107,cn=user,ou=staff,dc=college,dc=edu
officedn: cn=DC107,ou=locations,dc=college,dc=edu
phone: 555-555-5555
departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu
title: web systems admin

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

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.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
Generic user
  • 11
  • 1
  • Thanks for your response. I have thought about something like that. I was hoping there was a simpler method that wouldn't require a bunch of extra code and ldap entries. Also, how would you deal with employees who have more than one department and associated job title? Since I have to relate each job title with it's department. – David R. Apr 17 '13 at 20:48
  • Do you mean that a single position might have more than one associated department? If so, why not just make the departmentdn multi-valued? If you just mean that a single person has multiple position, then that's handled by the entry as described above. You'd probably want to use a naming attribute other than the office's CN to identify the object, but you could generate some sort of index for that (e.g., code that combines department and position title--although a better solution would be to find some value, like a position code, that's used in your ERP system). – Generic user Apr 18 '13 at 05:23
  • departmentdn is multi valued. As is title. The issue is that I need to associate the persons job title with the department the job title applies to. I might be wrong, but our system does not keep job titles unique to departments, so I can't just look at the title and know what the department is. In other words, when displaying the information, how do I know what job title goes with what department? Our ERP doesn't even have job titles in it, and the department list is a mess. We're trying to fix it, but it's like herding cats... – David R. Apr 18 '13 at 16:15
  • The objects above already associate the specific job title with the specific department, because each "position" is a separate object. As long as you don't have many-to-one or one-to-many mappings between those two values, the above scheme will do what you described. If you DO have such mappings, you could rename attributes to map them (title1, department1, etc). But it doesn't sound from your description like that's the case. If using separate objects doesn't suit you for some reason, then you could also just add named attrs to the user object (jobtitle1, department1, jobtitle2, etc). – Generic user Apr 18 '13 at 20:53
  • "JobTitleZYX" can be used in "DepartmentA" or "DepartmentB" or any other department. At least as far as I can tell from what I'm getting out of our ERP. I THINK employees who have more than one department, have a job title for each, but I'm not sure. I suppose I could create an bunch of numbered attributes, but something feels off about it. I'll think about it some more. – David R. Apr 19 '13 at 17:00
  • Why does a job title have to be unique? As long as dept attributes are isolated in the same object with the connected job title, what does the value matter? If you're somehow keying off that title as a unique key, then I suspect you might want to re-think that approach. – Generic user Apr 19 '13 at 18:55
  • What? I think we're both miscommunicating somewhere... Each employee can have more than one department. They may, or may not, have a job title specific to each department. Job titles may, or may not, be used in only one department. So if you just list all their departments, and all their job titles, there's no way to know which job title is used for which department. – David R. Apr 19 '13 at 23:49
  • If you have a separate object for each position that a person holds, with the title, department, phone, etc., etc., as values in that object, that automatically separates the positions, doesn't it? Put those objects in the cn=user, ou=staff container, and you automatically have a way to separate objects for each position, and they're automatically grouped by user. That is exactly what's demonstrated in the objects in the LDIF example I posted. (Except, as I said in an earlier comment, you'd want to use something offer than officedn as the naming attribute for the position objects.) – Generic user Apr 20 '13 at 07:16