ssh GSSAPI and auth_to_local

[Tom Parker]

On 09/29/2010 10:34 AM, Douglas E. Engert wrote:
>
> On 9/27/2010 8:11 PM, Tom Parker wrote:
>>     I apologize for the long posting.  I am stumped here and my scenario
>> is a bit complex.
>>
>> As I am sure the list has noticed from all my questions, in the past few
>> weeks I have been trying to build a distributed Kerberos/LDAP system
>> with hosts scattered around the Americas.
>>
>> Due to latency and reliability reasons we cannot trust that the networks
>> between our various sites will be up at any given time so we need to
>> maintain remote realms + LDAP for authorization at each site for remote
>> users.
> So you would have multiple realms for authorization, with a single LDAP
> database for authorization?
We have a single LDAP tree made up of subordinate databases.  The remote 
databases glue the central database on top.
>> These remote realms will be administered both centrally by central
>> admins when links are up as well as by remote admins with limited
>> permissions at each remote site.
>>
>> We can't trust our remote admins 100% so at no time will there be a copy
>> of the central realm on a remote kdc (We learned this from the list) and
>> we will use Cross-realm authentication for central users when they need
>> to access remote machines (if the networks are down we can't get in anyway).
>>
>> My problem is the following.  I need to make sure that all of my users
>> in all of my sites are unique so that tparker at CENTRAL does not collide
>> with tparker at REMOTE if such a user is created.  Unfortunately with
>> nss_ldap both of these users would become the same person when the realm
>> is stripped off.
>
> You said you can not trust your admins for the KDCs, can you trust them
> with LDAP? Will all the account additions be done by CENTRAL? If so can
> you verify the uniqness of the accounts/principal names?
We need to allow them to do account modifications for non login based 
access control.  We have local services that we don't want to deal 
with.  Because of the way we are gluing our trees together a local admin 
can see his branch and the top, but not the other branches.  This is ok 
for local but could mean name conflicts at the top between two branches.
>
>   >  What I have attempted to do is replace the uid of each user with the
>> krbPrincipalName and use the full user at REALM to log in to our servers
>> and services.  This can be done by changing a mapping rule in nss_ldap
>> and adding the following auth_to_local rule in /etc/krb5.conf
>>
>> [realms]
>>        CENTRAL = {
>>                    auth_to_local = RULE:[1:$1 at CENTRAL]
>>                    auth_to_local = RULE:[2:$1 at CENTRAL]
>>        }
>>
>> This works great for ssh with passwords but it has totally broken the
>> GSSAPI Single Sign On.
> The problem may be you are leaving the @ in the name, and some applications
> like ssh see this as a principal name, and do their own stripping of the realm.
>
> Have you looked at having two UID attrubutes on an account?
> Like UID=tparker and UID=tparker.central. Then letting nss-ldap durnig login
> lookup the tparker.central. (This may or may not work..)
This does not work.  nss_ldap is not that smart unfortunately.
> Also see Greg's note as you may have the rules in the wrong realm section.
I did.  His suggestion works perfectly and I can now use 
krbPrincipalNames as my userids!

Thanks Greg.

As usual this list is fast to reply and knows what they are talking 
about!  I wish all opensource projects (and closed source vendors who 
are being paid for support) were this good!
>>     From what I can see with strace and a little reading, the krb5_kuserok
>> function that is used to validate a user is ignoring the auth_to_local
>> directives and is stripping off everything but the first component of a
>> principal.
>>
>> This has the effect of comparing tparker to tparker at CENTRAL which fails
>> and then looking for a .k5login file which doesn't exist and so also
>> fails. (and which I don't want to have to create on every server, this
>> defeats one of the purposes of centralized administration)
>>
>> Does anyone know of a way I can get the krb5_kuserok code to use the
>> username built by the auth_to_local rules?
> The .k5login and auth_to_local are designed to allow multiple principals
> access to an account. They don't change the account name, only check if
> the use of the account by the principal is OK, and the test is done late
> in the login process.
>
> ssh with gssapi can use this feature of multiple principals access to an
> account with the "ssh -l user" or "ssh user at host" where the user specifies the
> name of account on the remote host, and the gss has the principal being used
> for authentication.
>
>> If not does anyone have any suggestions on how to make this work some
>> other way?  I am also considering adding a "domain" component to my user
>> names (eg: tparker.central at CENTRAL) but the domain is already there in
>> the principal and it would be nice to use that.
>>
>> Thanks!
>>
>> Tom Parker
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>