On Tue, Mar 13, 2012 at 4:50 AM, Tiago Elvas <tiagoel...@gmail.com> wrote: > Thanks for your reply. > The idea is to have a domain of several machines where each one has its own > dedicated purpose and not having a requirement to have unique user ids for > the whole system.
There was a long thread on heimdal-discuss a while about about similar concepts. There the user wanted to be able to manage remote filesystem access controls for similar "accounts"on many clients but as different entities. I'm not at all sure what it is that you want to do. Perhaps you want all these principal names for authorization purposes. But perhaps you want them for simplifying key management. Or perhaps you just want better auditing on the theory that the principal name tells you the client hostname, assuming the principal's credentials are not being used on the wrong host. Are these operators humans interacting with computers? Or automated services? > So that if the operator logs in in machine1(being machine1 a fqdn) he has > the authentication as principal "operator/machine1" and then in ldap he has > his own profile. If he logs in in machine2 he'll get a different ldap > profile. "then in ldap he has his own profile". Do you mean own user account? If so it sounds like you want to use this idea for authorization purposes. If so, and if you're intending to use normal Unix/LDAP user accounts for authorization, then you'll probably need to read up on the principal to username mapping functionality of MIT krb5. > Probably as John Devitofranceschi, I could generate keytabs for each user > and force the authentication with that key. But I do not want to perform a > kinit each time I login. Unless I modify the .bashrc file to do that... You can almost certainly coax Russ' pam-krb5 to do what you want, either via existing features or if need be by hacking on it. Nico -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos