3

I administer a few servers for a small organization that offers ISP-like services to its members (webhosting, mail adressess on mutiple domains and associated IMAP accounts, Jabber accounts) and I want to centralize all account data in LDAP. I'm new to LDAP and now I need to design and organize the LDAP directory layout.

The biggest issue I'm struggeling with is how to map users to various accounts, e.g. single users currently have multiple IMAP and Jabber accounts which are associated with various addresses on various domains and each account has a different password and I need to retain that.

So how would I organize the LDAP directory layout?
Should users and various accounts be in different trees which are then linked through a common uid, i.e. ou=people,dc=example,dc=net with inetOrgPersons describing the user and then separate trees for the accounts such as ou=imapAccounts,dc=example,dc=net, ou=jabberAccounts,dc=example,dc=net etc. with custom schemas? Or is there a better way since this looks too much like solution using a relational database?

Any recommendations of resources/books/real world examples that are helpful here? Most resources that I've seen seem to assume that one person only has one mail/jabber account etc. and wants to use a single passwords for that. I can't believe it is that uncommon for ISPs to allow their customers to have multiple accounts e.g. in order to allow them to seperate private and work mails or to encourage different passwords for different services so that a saved Jabber password that gets compromised does not result in a compromise of all other services of that customer etc.

I'll try to be more specific about my use case and explain my current data model:

There are unique users which are persons for which I need some contact data and which have a (single) shell account on the webhosting box. Each of these unique users may have multiple IMAP and Jabber accounts.

To answer the design questions:

  • A user could be considered a container for accounts, but it also represents a person which must have contact data associated with them.
  • Users will never share accounts.
  • Accounts will never move between users.
  • The boxes run RHEL6 and I need integration with PAM, Postfix/Dovecot, and ejabberd so integration should be possible with both LDAP and a RDB.
user1226159
  • 31

1 Answers1

6

You are approaching this the wrong way in that you have picked a technology and are now trying to shove your datamodel into it. Design your DATAMODEL first, then find a technology that makes it easy to implement.

Start with a whiteboard and write the things you need to track, then determine how they all relate to each other. If you wind up with a natural hierarchy/tree, LDAP is a good choice. If you wind up with a funky web-like thing a relational system may work better.

Some questions to ask while you do the design:

  • Is a "user" a container (which contains accounts)?
    (If this is the case each account will point to exactly one user. In LDAP parlance a user would be an OU, and accounts would be created within that OU. In relational parlance, Account would have a mandatory (NOT NULL) foreign key pointing at user)

  • Will users ever share accounts?
    (Relational modeling often works better here)

  • Will accounts move between users (or users move between accounts)?

  • What kind of systems will need to integrate with this data store?

voretaq7
  • 80,391
  • 2
    +1 You need to decide what you need to do before you choose what to solve it with. – Jacob Mar 05 '12 at 19:56
  • 1
    In addition to LDAP and relational systems you also might want consider NoSQL systems (like MongoDB). If your data's structure is very uncertain NoSQL will let you adapt quickly, but beware of cruft and database bloat! – voretaq7 Mar 05 '12 at 19:57
  • @voretaq7♦ I've tried to clarify my use case a bit, I think it mostly boils down to having multiple mail and Jabber accounts below a user, I'm not sure whether a user should be considered an OU since it represents a person. NoSQL wouldn't fit my integration requirements. – user1226159 Mar 05 '12 at 21:48
  • @user1226159 You can extend OU to have the attributes of Person (or simply create an object that has both objectClass OU and objectClass person). From what you've described LDAP will work, but you will have to tweak the schema a little – voretaq7 Mar 05 '12 at 22:01
  • @user1226159: Why not have your user objects (probably posixAccount and/or inetOrgPerson) be parents of other objects, such as your mail and jabber accounts? No need to use or extend organizationalUnit for a user object. But you should probably define your own object classes for mail and jabber, which hold the necessary attributes to describe the account (probably something like uid, userPassword, isEnabled, and so on). – daff Mar 06 '12 at 00:12
  • Since I'm not so familiar with LDAP, are there any implications/disadvantages of making accounts as parents of a inetOrgPerson? Are there any advantages of using a combination of OU and person instead? It sounds like both pretty much fit my existing data model, I just didn't come up with it myself since I was thinking too much in terms of RDB patterns. I have already found schemas for Jabber and Mail that seem to fulfill my needs so that shouldn't be a problem. – user1226159 Mar 06 '12 at 12:07
  • I'm sure @voretaq7 means "you are approaching this differently than I would" when he says "You are approaching this the wrong way..."

    I think LDAP is probably the correct tool for the job since most internet service apps speak LDAP natively.

    Whether LDAP should be the only directory, where it should be populated from etc are different questions.

     – Jason Tan Jun 11 '16 at 05:23