How is 'operator' going to authenticate? Will it have its own password and principal? Or will users be mapped to it via operator's .k5login or by using auth_to_local statements in krb5.conf?
jd On Mar 13, 2012, at 3:50, Tiago Elvas <[email protected]> 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. > > 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. > > 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... > > Thanks, > Tiago > > On Tue, Mar 13, 2012 at 7:34 AM, Carson Gaspar <[email protected]> wrote: > >> [ Trimmed and de-top-posted ] >> >> On 3/12/12 6:58 PM, John Devitofranceschi wrote: >>> On Mar 12, 2012, at 12:24, Tiago Elvas<[email protected]> wrote: >>> >>>> I would like to configure my machine so that when I login as user >>>> "operator" I get a credential as operator/instance, where instance >>>> should be the hostname. >>>> >>>> The idea is that if I login as "operator" in both machines I get >>>> different tickets. I thought that the instance should be the >>>> hostname but I haven't yet found information on how to configure >>>> this: >>>> >>>> - machine1.mydomain.com: ticket as operator/machine1.mydomain.com - >>>> machine2.mydomain.com: ticket as operator/machine2.mydomain.com >>>> >>>> Any thoughts? >>> >>> I think you're not going to be able to do this without a local >>> keytab. >>> >>> Keep your local keytabs in a consistent place, like >>> /var/spool/keytabs/LOGINNAME and then, when you log in as LOGINNAME >>> make certain that KRB5_KTNAME is set to the right keytab in the >>> user's .profile or the system .profile and, if it exists, run "kinit >>> -k". >> >> It can be done, but it requires: >> - all of the account/FQDN@REALM principals exist, and all have the same >> passphrase (unless you have different passwords for "operator" on >> different machines) >> - Something in the PAM stack does the principal transmogrification - a >> patched pam_krb5 would be fairly easy to produce >> >> Of course if they all have the same passphrase, anyone with the operator >> password could kinit as any of them. What are you trying to accomplish >> with this scheme? >> >> -- >> Carson >> ________________________________________________ >> Kerberos mailing list [email protected] >> https://mailman.mit.edu/mailman/listinfo/kerberos >> > > On Tue, Mar 13, 2012 at 2:58 AM, John Devitofranceschi <[email protected]> > wrote: > >> I think you're not going to be able to do this without a local keytab. >> >> Keep your local keytabs in a consistent place, like >> /var/spool/keytabs/LOGINNAME and then, when you log in as LOGINNAME make >> certain that KRB5_KTNAME is set to the right keytab in the user's .profile >> or the system .profile and, if it exists, run "kinit -k". >> >> jd > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
