Passwords normally. While it would be nice to say "you get a single account", I have yet to see that Go Big in *most* production environments. God, it would be nice. :-)
But, basically, we have some reqs for accounts having different passwords. --- 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 Tuesday, April 11, 2006, 4:59:35 PM, you wrote: > --On Tuesday, April 11, 2006 4:57 PM -0500 Dustin Puryear > <[EMAIL PROTECTED]> wrote: >> I'm curious how others handle this particular issue. >> >> Let's say we have several accounts per user. In general, a user has >> their primary account, and then several application-specific accounts. >> We have a base account objectClass and each app has their own extended >> objectClass, like so: >> >> compAccount >> compApp1Account extends compAccount >> compApp2Account extends compAccount >> compApp3Account extends compAccount >> >> When an App wants to find the account for a given user, we define >> filters such as: >> >> * App1 uses the filter (&(objectClass=compApp1Account)(uid=...)) >> * App2 uses the filter (&(objectClass=compApp2Account)(uid=...)) >> * General apps that don't need an App-specific account entry use the >> filter (&(objectClass=compAccount)(uid=...)) >> >> Looks good. However, some areas of our large LDAP tree may be >> maintained by different packages. Some of these packages tend to >> declare more than the necessary objectClass, so you may see: >> >> objectClass: top >> objectClass: compAccount >> objectClass: compApp2Account >> >> In this case, our filter breaks for a general-case app since it will >> potentially find an App2-specific account. >> >> We can handle this in one of several ways: >> >> 1. Just make sure any app adding an account never does this. >> 2. Each app that we support gets basically an empty objectClass called >> compAppX. So a primary account entry that is used by one of these apps >> that doesn't require an App-specific account would then use the >> primary account that also has the app objectClass: >> >> dn: uid=abc,ou=primary,... >> objectClass: inetOrgPerson >> objectClass: compAccount >> objectClass: compAppXAccount >> objectClass: compAppYAccount >> >> dn: uid=abc,ou=App1,... >> objectClass: inetOrgPerson >> objectClass: compApp1Account >> >> Thoughts? >> >> Alas, this method adds some admin overhead each time we add a >> supported app. > Why not just have a single account, with AUX objectClasses that add the > information for a given user to use that application? > Then they only have a single account entry and your objectClass filters > work... > @ Stanford, we'd basically consider that a "service". Our account tree has > several AUX ObjectClasses, one per service. > --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.
