How SSSD authentication works

Copy link

The PAM issuer container includes sssd-client (including pam_sss.so). After you mount the host’s SSSD pipes into the container, sign-in flows through the host SSSD daemon to your identity provider:

1. A user signs in through the Red Hat Edge Manager web console or flightctl login.
2. The PAM issuer invokes pam_sss.so inside the container.
3. pam_sss.so connects to the host SSSD daemon through Unix sockets under /var/lib/sss/pipes.
4. SSSD validates credentials and resolves group membership from the identity provider.

SSSD version compatibility

Copy link

The PAM issuer container includes sssd-client from CentOS Stream 9, which is SSSD 2.9.x.

Supported: Host SSSD 2.9.x (for example, Red Hat Enterprise Linux 9). The container sssd-client and the host SSSD daemon must be the same major version, and SSSD must run as root by default.

Not supported: Host SSSD 2.10.0 and later. There is no workaround for this incompatibility.

The PAM issuer container runs as root, so the 2.9.xsssd-client connects through the privileged PAM socket at /var/lib/sss/pipes/private/pam. SSSD 2.10.0 removed this socket. On a compatible 2.9.x host, the mounted pipes directory includes:

/var/lib/sss/pipes/
├── nss
├── pam
└── private/
    └── pam

The 2.9.x client also verifies that the socket is owned by root:root and that the SSSD responder process runs as root. SSSD 2.10.0 defaults to running as the unprivileged sssd user, which fails both checks.

NSS lookups (getent passwd) might still work on a 2.10.0 host because the NSS client does not perform these ownership checks. However, PAM authentication through the PAM issuer still fails and sign-in attempts are rejected.

Verify your host SSSD version before you proceed:

rpm -q sssd

Local users and SSSD

Copy link

SSSD integration requires an external identity provider (LDAP, FreeIPA, or Active Directory). Local users defined only in /etc/passwd and /etc/shadow inside the PAM issuer container cannot authenticate through SSSD.

For local users, continue to use the procedures in Configure authentication credentials and Roles and organizations with the PAM issuer in the Additional resources section.

Prerequisites

Copy link

Before you mount SSSD pipes into the PAM issuer container, verify the following on the Red Hat Enterprise Linux host:

• SSSD is installed, configured, and running with an external identity provider.
• /etc/nsswitch.conf includes sss in the passwd and group entries.
• User resolution works on the host (id <user> returns a result).
• Group resolution works on the host (getent group <group> returns a result).

Mounting SSSD pipes

Copy link

1. Edit the PAM issuer container quadlet file:

   sudo vi /etc/containers/systemd/flightctl-pam-issuer.container

2. Add the following line to the [Container] section:

   Volume=/var/lib/sss/pipes:/var/lib/sss/pipes:rw

3. Reload the systemd daemon and restart the service:

   sudo systemctl daemon-reload
   sudo systemctl restart flightctl-pam-issuer.service

If SELinux is enforcing, you might need a targeted policy module to allow the container to access the SSSD pipes. After an access denial, run the following commands:

sudo ausearch -m avc -ts recent | audit2allow -M flightctl-sssd
sudo semodule -i flightctl-sssd.pp

Group mapping for roles and organizations

Copy link

When SSSD resolves user groups from the identity provider, those groups must follow the same naming conventions as local PAM issuer groups. See Roles and organizations with the PAM issuer in the Additional resources section for the full naming scheme. In summary:

• Global roles:flightctl-admin, flightctl-operator, flightctl-viewer, flightctl-installer, flightctl-org-admin
• Organization groups: org-<organization_name>
• Organization-scoped roles: <organization_name>.<role>

Groups in the identity provider must be POSIX groups with gidNumber attributes for SSSD to resolve them.

Verification

Copy link

1. Verify that the SSSD pipes are accessible from the container:

   sudo podman exec flightctl-pam-issuer ls -la /var/lib/sss/pipes/

2. Verify that NSS resolution works from the container:

   sudo podman exec flightctl-pam-issuer getent passwd _<user>_

3. Verify that group resolution works from the container:

   sudo podman exec flightctl-pam-issuer getent group _<group>_

4. Sign in with flightctl login or the web console by using an identity-provider account. See Installing the Flight Control CLI in the Additional resources section for CLI setup.
5. Confirm that the session works:

   flightctl get devices