--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.
