How to determine the Kerberos realm from an LDAP directory?

Question

I have two Kerberos realms I can authenticate against. One of them I can control, and the other one is external from my point of view. I also have an internal user database in LDAP. Let's say the realms are INTERNAL.COM and EXTERNAL.COM. In ldap I have user entries like this:

1054 uid=testuser,ou=People,dc=tml,dc=hut,dc=fi
shadowFlag: 0
shadowMin: -1
loginShell: /bin/bash
shadowInactive: -1
displayName: User Test
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uidNumber: 1059
shadowWarning: 14
uid: testuser
shadowMax: 99999
gidNumber: 1024
gecos: User Test
sn: Test
homeDirectory: /home/testuser
mail: [email protected]
givenName: User
shadowLastChange: 15504
shadowExpire: 15522
cn: User.Test
userPassword: {SASL}[email protected]

What I would like to do, somehow, is to specify per-user basis to which authentication server / realm the user is authenticated against. Configuring kerberos to handle multiple realms is easy.

But how to I configure other instances, like PAM, to handle the fact that some users are from INTERNAL.COM and some from EXTERNAL.COM? There needs to be an LDAP lookup of some kind where the realm and the authentication name is fetched from, and then the actual authentication itself.

Is there a standardized way to add this information to LDAP, or look it up? Are there some other workarounds for a multi-realm user base? I might be ok with a single realm solution, too, as long as I can specify the user name - realm -combination for the user separately.

Solution 1

I think the best approach would be to use sssd. This gives you the most flexiblity as sssd supports what it calls domains. Note that newer Distros already use sssd. It's a dream come true and there's no excuse to use libpam_krb5.so and libpam_ldap.so or any of those.

The simplest aproach would be to use an ldap filter for selecting into which realm you need to go to for tgts like this:

First create two security groups that contain the members for external and internal realms in order to be able to get to the proper kdc.

Setup sssd and check it's documentation, this snippet is a sketch how you need to setup the two domains.

[domain/internal.com]
access_provider = ldap
id_provider = ldap
ldap_access_filter = memberOf=cn=allowedusersinternal,ou=Groups,dc=internal,dc=com
auth_provider = krb5 

[domain/external.com]
access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusersexternal,ou=Groups,dc=internal,dc=com
id_provider = ldap
auth_provider = krb5

Then configure your kerberos for the two realms according to need (but you got that already).

Solution 2

pam_ldap
For ssh password/challenge-response LDAP example entry already sufficient.
Modify appropriate file(s) in /etc/pam.d to use the pam_ldap library.
Setup SASL passthough authentication on your OpenLDAP server(s).
RHEL (CentOS): nss_ldap
Debian: libpam-ldap
Ubuntu: ldap-auth-client

krb5.conf
auth_to_local should work for GSSAPI based auth.

[realms]
$LOCALREALM = {
auth_to_local = RULE:[1:$1]
auth_to_local = DEFAULT
}
This might be too permissive.

!pam_krb5 alt_auth_map shouldn't work as quoted from the man page before OpenSSH will reject usernames that don't match local accounts

Solution 3

The settings you are looking for are in /etc/krb5.conf here you can store multiple realms under the [realms] tag, each pointing to their own LDAP server.

[realms]
       INTERNAL.COM = {
               kdc = some.server.internal.com:88
               admin_server = some.server.internal.com:749
               default_domain = internal.com
       }
       EXTERNAL.COM = {
               kdc = some.server.external.com:88
               admin_server = some.server.external.com:749
               default_domain = external.com
       }  

Comments

[Ehud Shahak]

Yes. The principal for authentication, say [email protected] should come from somewhere. The default behavior in Linux seems to be that the principal is generated from the user name and the default realm.

[Ehud Shahak]

Yes, this part is easy. But how do I get services, eg. OpenSSH to decide which realm to use?

[Ehud Shahak]

And OpenSSH is one of the important features I like to use. Many other services can do direct to LDAP authentication, and LDAP knows how to authenticate against kerberos with a pre-specified realm for the user.