Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am very new to LDAP & just trying to learn. I am using openldap on debian.

Can someone clarify this - or alternately point me to some link which will clarify these basic concepts?

Let's say I have the following situation I want represent in ldap

I am running a company. The company sells servers which are installed at customer sites. The company sells some servers directly and some through resellers. Company has a central administration tool which can manage all customer servers. I want to have different access permissions when someone logs into the server.

There are 3 levels of permissions P1, P2 & P3.

there are logins for company employees, reseller employees & also for customer employees.

Each employee's access will be decided by whose employee he is - My employees will have access to all servers - Reseller's employees will have access to only servers which have been sold by the reseller. - Customer's employees will have access only to servers which belong to the customer.

Even amongst all these employees what level of access they have will depend on whether they have P1, P2, or P3 permissions.

i.e. My employee with P3 access can do all operations for all servers. My employee with P1 access can do limited operations on all servers Reseller's employee with P1 access can do limited operations on all servers on all servers which have been sold through that reseller & so on and so forth.

This is what I am starting with dn: dc=mycompany,dc=com objectclass: organization objectclass: dcObject o: dc: mycompany

# Perms #
dn: ou=perms, dc=mycompany,dc=com
objectclass: organizationalUnit

dn: cn=p1, ou=perms, dc=mycompany,dc=com
objectclass: organizationalRole
cn: p1

dn: cn=p2, ou=perms,dc=mycompany,dc=com
objectclass: organizationalRole
cn: p2

# Reseller #
dn: ou=resellers, dc=mycompany,dc=com
objectclass: organizationalUnit

dn: cn=r1, ou=resellers, dc=mycompany,dc=com
objectclass: organizationalUnit
member: uid=xyz, ou=unames, dc=mycompany,dc=com

dn: cn=r2, ou=resellers, dc=mycompany,dc=com
objectclass: organizationalUnit
member: uid=abc, ou=unames, dc=mycompany,dc=com

# Customers #

dn: ou=customers, dc=mycompany,dc=com
objectclass: organizationalUnit

dn: cn=c1, ou=customers, dc=mycompany,dc=com
objectclass: organizationalUnit
member: uid=mno, ou=logins, dc=mycompany,dc=com
member: uid=pqr, ou=logins, dc=mycompany,dc=com

dn: cn=c2, ou=customers, dc=mycompany,dc=com
objectclass: organizationalUnit
member: uid=mno2, ou=logins, dc=mycompany,dc=com

// unames
dn: ou=unames, dc=mycompany,dc=com
objectclass: organizationalUnit
ou: logins

dn: uid=abc, ou=unames, dc=mycompany,dc=com
objectclass: inetOrgPerson
cn: a
sn: bc
employeeType: cn=p2, ou=roles,dc=mycompany,dc=com

dn: uid=pqr, ou=logins, dc=mycompany,dc=com
objectclass: inetOrgPerson
cn: p
sn: qr
employeeType: cn=p1, ou=roles, dc=mycompany,dc=com

Not sure if this is correct. But even if this is correct, I am getting confused beyond this

How do I have servers? Let's say I create an ou=servers,dc=mycompany,dc=com Then I have one entry for each server cn=srv1, ou=servers,dc=mycompany,dc=com etc.

How do see which server belongs to which customer. Do I add a member: inside the customer? In that case, the customer will have some members who are employees & some members which are servers. Is that OK?

Or is there a better way to do it?

How do I represent direct customers?

Should I create a reseller called direct & put direct customers in those & then use code logic to treat it as a special customer?

share|improve this question
Do you have to use (only) LDAP? It seems you need a relational database, whereas LDAP is a tree. There is no easy why to connect entries, there is no concept like foreign key in LDAP. – Jasper Mar 11 '11 at 12:06
No - need to use a combination of LDAP & SQL. What do you think should go into SQL & what in LDAP? – Genboy Mar 11 '11 at 19:39
On second thought, everything can go in LDAP, like BillThor proposes. ACLs could be managed by creating posixGroups in ou=perms and define posixGroups P1,P2 and P3. MemberUid can be added to those. – Jasper Mar 11 '11 at 21:52

You may want a tree something like:

- com - mycompany - (stuff)
                  - resellerN - (stuff)
                              - companyR - (stuff 
                  - companyN - (stuff)

Stuff would consist of trees of servers, users, and anything else you track.

You will need to setup ACLs to work based on the logged in user's DC. Give them access to things in their DC and bellow.

This would give you three DC levels arranged as follows:

  • dc=mycomppany,dc=com
  • dc=resellerN,dc=mycomppany,dc=com
  • dc=companyM,dc=resellerN,dc=mycomppany,dc=com
  • dc=companyN,dc=mycomppany,dc=com

You will need to construct and test the appropriate regexp ACLs for the extra levels. (I would get the ACL for your organization working first and work from there. I find the Zytrax documenation helps a lot.

share|improve this answer
What should be the objectclass of CompanyN,CompanyR etc? Also, in this these Companies will be non-leaf nodes. Can I store details about this Customer in this node (i.e. Address, Tel etc?) – Genboy Mar 12 '11 at 1:58
@Genboy: I think I would set them up as DC attributes. I have updated my response accordingly. – BillThor Mar 12 '11 at 2:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.