---
name: "pam_sss_gss"
section: "8"
platform: "linux"
package: "sssd"
version: "2.13.1-1"
release: "Arch Linux 2026-11-01"
platforms: ["linux"]
url: "https://new.carta.tech/pam_sss_gss"
---

# pam\_sss\_gss(8)

PAM module for SSSD GSSAPI authentication

## NAME

pam\_sss\_gss - PAM module for SSSD GSSAPI authentication

## SYNOPSIS

**pam\_sss\_gss.so** \[*debug*\]

## DESCRIPTION

**pam\_sss\_gss.so** authenticates user over GSSAPI in cooperation with SSSD.

This module will try to authenticate the user using the GSSAPI hostbased service name host@hostname which translates to host/hostname@REALM Kerberos principal. The *REALM* part of the Kerberos principal name is derived by Kerberos internal mechanisms and it can be set explicitly in configuration of \[domain\_realm\] section in /etc/krb5.conf.

SSSD is used to provide desired service name and to validate the user's credentials using GSSAPI calls. If the service ticket is already present in the Kerberos credentials cache or if user's ticket granting ticket can be used to get the correct service ticket then the user will be authenticated.

If **pam\_gssapi\_check\_upn** is True (default) then SSSD requires that the credentials used to obtain the service tickets can be associated with the user. This means that the principal that owns the Kerberos credentials must match with the user principal name as defined in LDAP.

To enable GSSAPI authentication in SSSD, set **pam\_gssapi\_services** option in \[pam\] or domain section of sssd.conf. The service credentials need to be stored in SSSD's keytab (it is already present if you use ipa or ad provider). The keytab location can be set with **krb5\_keytab** option. See [**sssd.conf**(5)](/sssd.conf/5.md) and [**sssd-krb5**(5)](/sssd-krb5/5.md) for more details on these options.

Some Kerberos deployments allow to associate authentication indicators with a particular pre-authentication method used to obtain the ticket granting ticket by the user. **pam\_sss\_gss.so** allows to enforce presence of authentication indicators in the service tickets before a particular PAM service can be accessed.

If **pam\_gssapi\_indicators\_map** is set in the \[pam\] or domain section of sssd.conf, then SSSD will perform a check of the presence of any configured indicators in the service ticket.

## OPTIONS

**debug**

Print debugging information.

## MODULE TYPES PROVIDED

Only the **auth** module type is provided.

## RETURN VALUES

PAM\_SUCCESS

The PAM operation finished successfully.

PAM\_USER\_UNKNOWN

The user is not known to the authentication service or the GSSAPI authentication is not supported.

PAM\_AUTH\_ERR

Authentication failure.

PAM\_AUTHINFO\_UNAVAIL

Unable to access the authentication information. This might be due to a network or hardware failure.

PAM\_SYSTEM\_ERR

A system error occurred. The SSSD log files may contain additional information about the error.

## EXAMPLES

The main use case is to provide password-less authentication in sudo but without the need to disable authentication completely. To achieve this, first enable GSSAPI authentication for sudo in sssd.conf:

```
[domain/MYDOMAIN]
pam_gssapi_services = sudo, sudo-i
```

And then enable the module in desired PAM stack (e.g. /etc/pam.d/sudo and /etc/pam.d/sudo-i).

```
...
auth sufficient pam_sss_gss.so
...
```

## TROUBLESHOOTING

SSSD logs, pam\_sss\_gss debug output and syslog may contain helpful information about the error. Here are some common issues:

1\. I have KRB5CCNAME environment variable set and the authentication does not work: Depending on your sudo version, it is possible that sudo does not pass this variable to the PAM environment. Try adding KRB5CCNAME to **env\_keep** in /etc/sudoers or in your LDAP sudo rules default options.

2\. Authentication does not work and syslog contains "Server not found in Kerberos database": Kerberos is probably not able to resolve correct realm for the service ticket based on the hostname. Try adding the hostname directly to **\[domain\_realm\]** in /etc/krb5.conf like so:

3\. Authentication does not work and syslog contains "No Kerberos credentials available": You don't have any credentials that can be used to obtain the required service ticket. Use kinit or authenticate over SSSD to acquire those credentials.

4\. Authentication does not work and SSSD sssd-pam log contains "User with UPN \[$UPN\] was not found." or "UPN \[$UPN\] does not match target user \[$username\].": You are using credentials that can not be mapped to the user that is being authenticated. Try to use kswitch to select different principal, make sure you authenticated with SSSD or consider disabling **pam\_gssapi\_check\_upn**.

```
[domain_realm]
.myhostname = MYREALM
```

## SEE ALSO

[**sssd**(8)](/sssd/8.md), [**sssd.conf**(5)](/sssd.conf/5.md), [**sssd-ldap**(5)](/sssd-ldap/5.md), [**sssd-ldap-attributes**(5)](/sssd-ldap-attributes/5.md), [**sssd-krb5**(5)](/sssd-krb5/5.md), [**sssd-simple**(5)](/sssd-simple/5.md), [**sssd-ipa**(5)](/sssd-ipa/5.md), [**sssd-ad**(5)](/sssd-ad/5.md), [**sssd-idp**(5)](/sssd-idp/5.md), [**sssd-sudo**(5)](/sssd-sudo/5.md), [**sssd-session-recording**(5)](/sssd-session-recording/5.md), [**sss\_cache**(8)](/sss_cache/8.md), [**sss\_debuglevel**(8)](/sss_debuglevel/8.md), [**sss\_obfuscate**(8)](/sss_obfuscate/8.md), [**sss\_seed**(8)](/sss_seed/8.md), [**sssd\_krb5\_locator\_plugin**(8)](/sssd_krb5_locator_plugin/8.md), [**sss\_ssh\_authorizedkeys**(1)](/sss_ssh_authorizedkeys/1.md), [**sss\_ssh\_knownhosts**(1)](/sss_ssh_knownhosts/1.md), [**sssd-ifp**(5)](/sssd-ifp/5.md), [**pam\_sss**(8)](/pam_sss/8.md). [**sss\_rpcidmapd**(5)](/sss_rpcidmapd/5.md)

## AUTHORS

**The SSSD upstream - https://github.com/SSSD/sssd/**