Re: Authenticate as user/instance

[John Devitofranceschi]

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

On Mar 12, 2012, at 12:24, Tiago Elvas <tiago...@gmail.com> wrote:

> Dear all,
>
>
> 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?
>
> Thanks in advance.
> Best regards,
> Tiago
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

[Carson Gaspar]

[ Trimmed and de-top-posted ]

On 3/12/12 6:58 PM, John Devitofranceschi wrote:
> On Mar 12, 2012, at 12:24, Tiago Elvas<tiago...@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@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

[Tiago Elvas]

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

> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

On Tue, Mar 13, 2012 at 2:58 AM, John Devitofranceschi <jd...@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

[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

[Greg Hudson]

On 03/13/2012 01:45 PM, John Devitofranceschi wrote:
> How is 'operator' going to authenticate?

The most workable interpretation of the request is that operator's
password will be the Kerberos password of operator/fqdn, which will be
different for each host.

It looks like this may be possible with Russ's pam_krb5 using the
alt_auth_map or search_k5login directives.

[Nico Williams]

On Tue, Mar 13, 2012 at 4:50 AM, Tiago Elvas <tiago...@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
--

[Tiago Elvas]

On Tue, Mar 13, 2012 at 6:45 PM, John Devitofranceschi <jd...@optonline.net>

wrote:

> 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

The operator will login to the machine using the "normal" Linux
authentication screen.

I managed to successfully have tickets as user/fqdn by creating keytabs for
that user and including "kinit -k -t <persistent keytab path>" in its
profile.
However, this solution makes me have to manually create a keytab file for
each user in each machine, which I believe must not be a "good practice".
Or should it be?

With some modified pam module it can probably be done I guess.
I must confess I am no expert at all handling pam configuration...

[Nico Williams]

FYI, if these are accounts that you'd provide with keytabs, such that
no passwords need be entered interactively in order for the systems to
run, then you may be interested in Roland Dowdeswell's krb5_admin and
krb5_keytab software, which you can find here:

https://github.com/elric1/krb5_admin
https://github.com/elric1/krb5_keytab

Nico
--

[Tiago Elvas]

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

As an example:
Having:
- applications: Application1, Application2
- hostname: Machine1, Machine2
- users: Operator1, Operator2
- app profiles: admin, user

i.e: if *Operator1* logs into *Machine1*, he'd have access to app profile *
admin* on *Application1*
i.e: if *Operator2* logs into *Machine2*, he'd have access to app profile *
admin* on *Application2**
*
The app profiles are configured in LDAP DB.

I'll need to unserstand what "username mapping functionality of MIT krb5"
is...

thanks for your answer Nico!

[Nico Williams]

On Tue, Mar 13, 2012 at 1:59 PM, Tiago Elvas <tiago...@gmail.com> 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
--

[Tiago Elvas]

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