> 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, a
Fortunately we are one of them. :) > 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. Many applications do a search to locate the user DN and then bind. Also if the bind is SASL where/how to locate the account object is entirely internal to the DSA. Most of the web applications I've seen work this way, especially those of the PHP and Tomcat variety. > 3. One person entry, multiple accounts under separate container > 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. If I didn't live in a rigidly 1:1 environment I'd suggest option #3 as the cleanest solution. #2 is really a hacked version of #3 (IMHO) and doesn't facilitate the optimization of search bases. --- 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.
