Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am pretty new to LDAP & trying to design a schema for a particular need.

I have a Support Organization.

There are three levels P1 - lowest permissions P2 - middle P3 - highest permissions.

I have split the support team into subteams.

TeamA manages customers A1, A2, A3 etc TeamB manages customers B1, B2, B3 etc.

Customer A1 has his internal users. Internal Users of each customer have 2 levels of permissions either P1 or P2. Their P1 or P2 permissions are only for stuff relevant to themselves. i.e a P2 from Customer A1 will not have any permissions for Customer A2.

TeamA people (who manage customers A1, A2 etc) have either P1 or P2 permissions. A person from TeamA who has P2 permissions will have P2 permissions for each customer who is managed by TeamA. i.e. A TeamA P2 will have P2 for A1, A2, A3 (all of them).

Then there is a super support team. Here people are not specific to groups of customers. A P2 from the SuperSupport team will have P2 permissions for Customer A1, Customer B1 - for everything. A P3 will be similiar.

I have designing a schema

# Root node
dn: dc=myorg,dc=com
objectclass: organization
objectclass: dcObject
o: myorg.com
dc: myorg

# Groups
dn: ou=Groups, dc=myorg,dc=com
objectclass: organizationalUnit
ou: Groups

dn: cn=P1, ou=Groups, dc=myorg,dc=com
objectclass: organizationalRole
cn: P1
description: Lowest level

dn: cn=P2, ou=Groups,dc=myorg,dc=com
objectclass: organizationalRole
cn: P2
description: Higher level

dn: cn=P3, ou=Groups,dc=myorg,dc=com
objectclass: organizationalRole
cn: P3
description: Highest level of Support

# Teams
dn: ou=Team, dc=myorg,dc=com
objectclass: organizationalUnit
ou: partner
description: Teams

# Team A
dn: ou=teamB, ou=Team, dc=myorg,dc=com
objectclass: organizationalUnit
ou: teamA
description: Team A

# Team B
dn: ou=teamb, ou=Team, dc=myorg,dc=com
objectclass: organizationalUnit
ou: teamB
description: Team B

# Customers

# Customer A1 of Team A
dn: ou=custa1, ou=teama, ou=Team dc=myorg,dc=com
objectclass: organizationalUnit
ou: custa1
description: Some Org

# Customer B2 of Team B
dn: ou=custb2, ou=teamb, ou=Team, dc=myorg,dc=com
objectclass: organizationalUnit
ou: custb2
description: Some other Org

Is it correct up to this?

I am getting a little stuck beyond this - how do I put in people from different teams, different customers, super support etc, so that it would be easy to easily figure out after binding to the ldap server with a uname/passwd - what permissions that particular user has.

Can someone help or point me to a sample schema for similar requirements?

share|improve this question

1 Answer 1

The pedant in me is forced to point out that what you're creating here is not a schema, but a layout. A schema defines objects-types and attributes on the objects, a layout defines where the objects are and what values are assigned to the attributes.

That out of the way...

When you add people you'll be associating them with the OrganizationalRoles you're defining, and people can belong to many of them. In fact, where their object actually resides doesn't confer any rights; it's the act of associating an OR with them. When they bind, they'll gain the rights of the ORs they're a member of, regardless of where their object is.

To answer your question of figuring out what rights they get, they should be listed in two places:

  • On their user-object
  • On the organizationalRole object

You'd form the LDAP query to pull either the orMember attribute from the user object, or query all organizationalRole objects with a member of the user. The exact name of the attribute on the user depends on your actual LDAP schema in use.

share|improve this answer

Your Answer

 
discard

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.