3

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.

2
  • So are you looking to store the realm information in the LDAP directory itself for each user? And then extract it when authenticating?
    – Univ426
    Jun 15, 2012 at 13:59
  • 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.
    – tstm
    Jun 18, 2012 at 7:27

4 Answers 4

3

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

1

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
       }  
1
  • Yes, this part is easy. But how do I get services, eg. OpenSSH to decide which realm to use?
    – tstm
    Jun 18, 2012 at 6:51
1

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

0

The windows way to authenticate against different domains is to specify the domain in addition to the login name. So, is it acceptable for you to do something similar and have people login as [email protected] or [email protected]? And if you just use "user3" you could get to login into the default domain.

According to the pam_krb5(5), this is possible:

If the username provided to PAM contains an "@" and Kerberos can, treating the username as a principal, map it to a local account name, pam_authenticate() will change the PAM user to that local account name. This allows users to log in with their Kerberos principal and let Kerberos do the mapping to an account.

Unfortunately, it continues:

Be aware, however, that this facility cannot be used with OpenSSH. OpenSSH will reject usernames that don't match local accounts before this remapping can be done and will pass an invalid password to the PAM module. Also be aware that several other common PAM modules, such as pam_securetty, expect to be able to look up the user with getpwnam() and cannot be called before pam_krb5 if this feature is used.

1
  • 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.
    – tstm
    Jun 18, 2012 at 6:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .