ssh GSSAPI and auth_to_local

[Douglas E. Engert]

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?

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


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

Also see Greg's note as you may have the rules in the wrong realm section.

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

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444