As LDAP profile I actually meant its entry in there, openDS: appUser=admin,app=appName,uid=operator1/fqdn,ou=People,dc=deimos-space,dc=com
So as Unix account, the user would login as operator1 (and not as operator1/fqdn) He would have a ticket as operator1/fqdn which would allow him to read from openDS its profile info as admin. On the other hand, I am also strugling with openDS aci to control this... On Tue, Mar 13, 2012 at 8:57 PM, Nico Williams <[email protected]>wrote: > On Tue, Mar 13, 2012 at 1:59 PM, Tiago Elvas <[email protected]> wrote: > > The domain will be made of several machines, which will be running > dedicated > > applications. > > > > These applications will be operated by persons. So, for several of these > > apps, we'll have profiles such as admin or user. So, in LDAP we'd have > > different profiles for the admin user for each application. The same > > "Operator" can have admin profile on one app and user profile on another > > one. That's why the need of identify principals like this, I guess... > > I'm still confused by what you mean by LDAP profile. Can you post > some example LDAP entries, and some reference for the schema that > you're using? > > If by LDAP profile you mean user account in the POSIX/RFC2307bis > sense, then I think I understand exactly what you want to do, else I > don't yet understand :) > > In any case, from the sounds of it it seems that you want to treat > foo/clientA.fqdn as distinct from foo/clientB.fqdn for the purposes of > _authorization_. I.e., you want foo/clientA to have access to some > resources that foo/clientB doesn't have access to and vice-versa. > > Nico > -- > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
