At my organization, we're required to use different kerberos principals when authenticating for sudo than for other types of auth, such as logging in. For instance, my regular (login) principal might be called foobar@DOMAIN, whereas my sudo principal is called foobar/sudo@DOMAIN. In the past, we've met this requirement by building our own sudo with the --with-kerb5 and --enable-kerb5-instance=sudo flags set at build time. This means that our version of sudo hooks directly into kerberos, never using the PAM stack at all.

We're trying to see if we can meet the split-principal requirement without building and distributing our own build of sudo. My question is: Is this possible, and if so, how?

Using the standard RHEL 6/7 sudo package, I can't use the --with-kerb5 build-time option; I have to use PAM as my authentication stack. That means I must use pam_krb5. With pam_krb5, I've noticed that I can map usernames to principal names in /etc/krb5.conf using the appdefaults/pam/mappings configuration option. This gets me partway there, as it enables me to map a username of foobar to a principal name of foobar/sudo. However, from what I can tell, there's no way to set mappings per application (kerberos sees PAM as a single application, no matter which application is invoking the PAM stack), meaning the mapping applies to any applications that use pam_krb5 in their PAM configuration. So I can get the system to use the sudo principals for both sudo and login, or login principals for both, but I can't get the system to use sudo principals for sudo and login principals for login.

Any ideas? Or am I stuck with having to build & distribute a custom sudo?

1 Answer 1


This is not a complete answer, but I wonder if you could accomplish this using SSSD.

The pam_sss module lets you restrict a service to only considering particular domains in /etc/sssd/sssd.conf. From pam_sss(8):


Allows the administrator to restrict the domains a particular PAM service is allowed to authenticate against. The format is a comma-separated list of SSSD domain names, as specified in the sssd.conf file.

In theory, you could have two domains both pointing at the same upstream authentication environment, but with different rules for mapping users to principals.

Unfortunately, it looks like SSSD only supports static mappings of usernames to principal names, which doesn't scale very well.


It also looks like more recent versions of the pam_krb5 module support an alt_auth_map option that does exactly what you want. That is, in /etc/pam.d/sudo, I can do this:

auth    required    pam_krb5.so alt_auth_map=%s/sudo only_alt_auth

...and now sudo will always use the <username>/sudo principal for authentication.

This version of pam-krb5 is distributed with Ubuntu, but presumably one could build an rpm and install it on your systems without too much fuss.

  • I can configure pam_krb5 to restrict a service to a particular domain as well, so I'm not sure I'm buying anything by using pam_sssd. And I'm not sure if I can do custom mappings on a per-domain level (I inferred from my reading of the man page that mappings is a global configuration option). I like this idea, though. I'll look into it and see if it leads anywhere.
    – jayhendren
    Jul 28, 2015 at 6:20
  • So, "SSSD domain" != "Kerberos domain". An SSSD "domain" basically means "a section of the configuration file", and you can have multiple domains pointing at the same Kerberos domain. This is different from what you can do with pam_krb5. User <-> principal mappings are definitely not global options (they are per SSSD domain). I don't know for certain it will work, but I think it might.
    – larsks
    Jul 28, 2015 at 11:09
  • Oh, I see what you're saying now. I read too quickly and I thought you meant using SSSD to restrict a service to a particular Kerb domain. This sounds promising.
    – jayhendren
    Jul 28, 2015 at 15:30
  • Hmmm, looks like I may be able to perform dynamic mapping using the full_name_format option in a domain block of sssd.conf (I'm looking at a man page on RHEL 6.7). Where were you seeing that SSSD only supports static mappings?
    – jayhendren
    Jul 28, 2015 at 16:40
  • 1
    I ended up solving my problem. Basically, the approach that I'm using is to "proxy" kerberos through pam_sss for one service (login) and use pam_krb5 directly for another service (sudo). This way I can use different appdefaults sections for the two services and take advantage of separate mappings attributes for each service. I'll write up my solution and add it to your answer tomorrow.
    – jayhendren
    Jul 28, 2015 at 22:32

You must log in to answer this question.

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