Authenticate as user/instance

[John Devitofranceschi]

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 <tiagoelvas at 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.
> 
> 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 <carson at taltos.org> 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<tiagoelvas at gmail.com>  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 at 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           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>> 
> 
> On Tue, Mar 13, 2012 at 2:58 AM, John Devitofranceschi <jdvf at optonline.net>
> 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           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos