Rechercher

12.3. Data flow when authenticating as a user with SSSD in IdM

download PDF

Authenticating as a user on an IdM server or client involves the following components:

  • The service that initiates the authentication request, such as the sshd service.
  • The Pluggable Authentication Module (PAM) library and its modules.
  • The SSSD service, its responders, and back-ends.
  • A smart card reader, if smart card authentication is configured.
  • The authentication server:

    • IdM users are authenticated against an IdM Kerberos Key Distribution Center (KDC).
    • Active Directory (AD) users are authenticated against an AD Domain Controller (DC).

The following diagram is a simplification of the information flow when a user needs to authenticate during an attempt to log in locally to a host via the SSH service on the command line.

A diagram with numbered arrows representing the flow of information between an IdM client and an IdM server or AD Domain Controller during an authentication attempt. The following numbered list describes each step in the process.

  1. The authentication attempt with the ssh command triggers the libpam library.
  2. The libpam library references the PAM file in the /etc/pam.d/ directory that corresponds to the service requesting the authentication attempt. In this example involving authenticating via the SSH service on the local host, the libpam library checks the /etc/pam.d/system-auth configuration file and discovers the pam_sss.so entry for the SSSD PAM:

    auth    sufficient    pam_sss.so
  3. To determine which authentication methods are available, the libpam library opens the pam_sss module and sends an SSS_PAM_PREAUTH request to the sssd_pam PAM responder of the SSSD service.
  4. If smart card authentication is configured, the SSSD service spawns a temporary p11_child process to check for a smart card and retrieve certificates from it.
  5. If smart card authentication is configured for the user, the sssd_pam responder attempts to match the certificate from the smart card with the user. The sssd_pam responder also performs a search for the groups that the user belongs to, since group membership might affect access control.
  6. The sssd_pam responder sends an SSS_PAM_PREAUTH request to the sssd_be back-end responder to see which authentication methods the server supports, such as passwords or 2-factor authentication. In an IdM environment, where the SSSD service uses the IPA responder, the default authentication method is Kerberos. For this example, the user authenticates with a simple Kerberos password.
  7. The sssd_be responder spawns a temporary krb5_child process.
  8. The krb5_child process contacts the KDC on the IdM server and checks for available authentication methods.
  9. The KDC responds to the request:

    1. The krb5_child process evaluates the reply and sends the results back to the sssd_be backend process.
    2. The sssd_be backend process receives the result.
    3. The sssd_pam responder receives the result.
    4. The pam_sss module receives the result.
  10. If password authentication is configured for the user, the pam_sss module prompts the user for their password. If smart card authentication is configured, the pam_sss module prompts the user for their smart card PIN.
  11. The module sends an SSS_PAM_AUTHENTICATE request with the user name and password, which travels to:

    1. The sssd_pam responder.
    2. The sssd_be back-end process.
  12. The sssd_be process spawns a temporary krb5_child process to contact the KDC.
  13. The krb5_child process attempts to retrieve a Kerberos Ticket Granting Ticket (TGT) from the KDC with the user name and password the user provided.
  14. The krb5_child process receives the result of the authentication attempt.
  15. The krb5_child process:

    1. Stores the TGT in a credential cache.
    2. Returns the authentication result to the sssd_be back-end process.
  16. The authentication result travels from the sssd_be process to:

    1. The sssd_pam responder.
    2. The pam_sss module.
  17. The pam_sss module sets an environment variable with the location of the user’s TGT so other applications can reference it.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.