I'm particularly interested in this discussion as it pertains to 1-person
N-accounts. That's what is truly tricky to me in a directory with a
significant number of entries supporting several applications. The simple
fact is that most locations are not on the 1-person 1-account rule, and they
may never do this. So we have to figure out how to support 1-person
N-accounts.
Methods:
1. One entry, unique rdn, multi-value UID, one password.
In this scheme a person has a single entry with multiple uid's assigned to
that entry. Nice idea. You get one entry to maintain and one password.
Problem: A lot of LDAP apps want to test bind a user against their entry
using a rule like:
uid=%s,ou=...,dc=com
So how does the app translate what the user considers the uid against the
actual rdn? Most apps aren't this smart. They could of course do this:
step 1: bind as master user
step 2: ldapsearch uid=%s, get dn
step 3: bind user against returned dn
step 4: success or fail
A lot of apps just don't do this, and if you don't have access to the source
code..
2. One person entry, hang accounts off person entry
Here, you have:
personEntry --> account1
|-> account2
|-> account3
Again, we have an app logic problem here. A lot of apps want to use the
uid=%,ou=...,dc=com for a bind. How is the app going to know that it should
look under personEntry first to find the account? Does it do an ldapsearch
for uid=% first and then bind? Sure, let's just send the app vendor our
request for that change..
3. One person entry, multiple accounts under separate container
What I typically do is create a 1-N relationship in the tree like so:
You have a person entry that represents a physical person (e.g., via an HR
number) under ou=People. There are no dups here. One person, one entry. That
person probably owns several accounts. We then put a single, default account
under ou=Accounts for that Person. So we have:
uid=bob,ou=People
ownsAccount: uid=bob,ou=Account
uid=bob,ou=Account
ownedBy: uid=bob,ou=People
Each new account gets tied to the Person entry:
uid=bob,ou=People
ownsAccount: uid=bob,ou=Account
ownsAccount: uid=bobmail,ou=Account
ownsAccount: uid=bob,ou=SpecApp1,ou=Account
uid=bob,ou=Account
ownedBy: uid=bob,ou=People
uid=bobmail,ou=Account
ownedBy: uid=bob,ou=People
uid=bob,ou=SpecApp1,ou=Account
ownedBy: uid=bob,ou=People
And so on. (Why the need for N accounts? Legacy systems, custom-designed
apps, the list goes on..)
This works well. It pushes all of your problems into two areas: user
provisioning and password management. For user provisioning, you need to
create something moderately intelligent that can handle all of these
accounts and maintain knowledge of who owns what (e.g., the CA eTrust Admin
product that I use to build provisioning systems for clients--there are
other products out there). As far as password management, you need something
that can maintain passwords for each account, and/or an SSO product that
handles all of this account info for the end-user.
You are going to have complexity SOMEWHERE. That's a promise. I like to push
the complexity away from the end-user and applications and to the management
systems that IT handles, like user provisioning and password management.
That way all the complexity is in a few apps that IT manages, and not in
convoluted customizations in several dozen apps. That's my take. :-)
With all this said, I would LOVE to have a debate on the pros and cons of
these and other approaches. There is very little really being said in the
LDAP community about a best practice approach to this.
---
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com
Author of "Best Practices for Managing Linux and UNIX Servers"
Download your free copy:
http://www.puryear-it.com/bestpractices.htm
----- Original Message -----
From: "Quanah Gibson-Mount" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, March 13, 2006 12:59 PM
Subject: [ldap] Re: Advice Designing a LDAP Tree
--On Saturday, March 11, 2006 10:08 PM -0500 "Michael J. Smith"
<[EMAIL PROTECTED]> wrote:
On Saturday 11 March 2006 21:32, Quanah Gibson-Mount wrote:
--On Saturday, March 11, 2006 7:34 PM -0500 "Michael J. Smith"
<[EMAIL PROTECTED]> wrote:
> Campus A may want to give wireless access to students and faculty of
> campus B, but only to faculty of campus C.
[....]
Ah, well, for policy based stuff, we have "workgroups". They are stored
in the directory as the attribute "suprivilegegroup". We have a
frontend application (workgroup.stanford.edu) that allows people to
assign privileges to various users, and then the directory is queried
to see if a given individual has access to resources, areas, etc, based
on the values of "suprivilegegroup".
So -- following up my contrived scenario -- if we used this model, then
anybody who was entitled to wireless access on Campus A would have to
have CampusAWireless vel sim as one of the attributes of
suprivilegegroup?
Well, not how Stanford does it. The accounts with wireless available on
Campus A would have something like an "objectClass:
CampusAWirelessService" that is AUX added, with and attribute named
"suCampusAWirelessStatus" set to "enabled".
However, for things like wireless, we put those into the account entry
rather than the person entry (accounts are not people, and people can
have multiple accounts, etc, and there can be non-person accounts,
etc). We have a sponsorship application that allows people to sponsor
other people for particular services, and when they do that, an AUX
objectClass is added to their entry allowing them access to that
account related resource.
This is interesting. How does the linkage between "people" entries and
"account" entries work? If people can have multiple accounts, can
multiple people share a single account? Do accounts have authentication
info (passwords, public keys, etc.)? If I want wireless access, do I
bind to my account or to my "people" entry, and if the latter, how does
the account info get pulled into the picture?
The account entry contains references back to the owner, via the following
attributes:
owner
seeAlso
suIdentifies
"suIdentifies" is used when the account is linked to a person (rather than
a department or other organization).
Multiple people cannot share accounts (nor do we intend to ever support
that, AFAIK).
As an example of multiple accounts, I have at least 3:
My primary ID, an ID I use for testing, and a "root" instance ID (related
to Kerberos V).
Our account tree does not have passwords in it, since all of our passwords
are stored in Kerberos which is where all authentication occurs. The LDAP
servers are used for authorizations.
Generally, people do not bind to their entries in the LDAP server at all.
In our case, applications bind to the LDAP servers, and then verify if a
given account has access to a particular resource (i.e., someone goes to
log into wireless. The wireless software does an LDAP lookup to see if
that ID has "wireless" service).
Do you folks have any design documents or white papers or such
that explain the thinking behind your design? You've obviously put a lot
of thought into it, and I imagine a good many other institutions could
benefit from a better understanding of it.
Some of this is present at:
<http://www.stanford.edu/dept/as/mais/>
specifically:
<https://www.stanford.edu/dept/as/mais/integration/index.html>
However, this site is currently blocked off to Stanford only people for
reasons I don't understand. I've queried the group responsible (we've
undergone many reorgs in the last couple years, and that group is now in
an entirely different organization). I'll keep you posted on if/when it
gets opened up.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word
UNSUBSCRIBE as the SUBJECT of the message.
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
