ssh GSSAPI and auth_to_local
Tom Parker
tparker at cbnco.com
Mon Sep 27 21:11:42 EDT 2010
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.
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.
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.
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?
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
More information about the Kerberos
mailing list