<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pam on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/pam/</link><description>Recent content in Pam on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/pam/index.xml" rel="self" type="application/rss+xml"/><item><title>Break-Glass User (Emergency Access Account)</title><link>https://lesitedefrancois.be/en/security/break-glass/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/break-glass/</guid><description>&lt;p&gt;A &lt;strong&gt;break-glass user&lt;/strong&gt; (or break-glass account, emergency access account) is a privileged account that exists outside the normal access control workflow — bypassing &lt;strong&gt;PAM&lt;/strong&gt; approval gates, MFA requirements, or SSO dependencies — and is reserved for situations where those normal mechanisms are themselves unavailable or would prevent responding to a critical incident in time. The name is a physical analogy: like the fire alarm panel behind a pane of glass that reads &lt;em&gt;break glass in emergency&lt;/em&gt;, the account is designed so that accessing it requires a deliberate, detectable act. It is not a convenience mechanism; it is an organisational safety net for scenarios such as an identity provider outage locking all administrators out of their own infrastructure, a PAM platform failing during an active incident, or a ransomware attack disabling the tooling needed to contain it.&lt;/p&gt;</description></item><item><title>SSSD (System Security Services Daemon)</title><link>https://lesitedefrancois.be/en/security/sssd/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/sssd/</guid><description>&lt;p&gt;&lt;strong&gt;SSSD (System Security Services Daemon)&lt;/strong&gt; is a multi-daemon suite that connects Linux systems to remote identity and authentication providers, presenting their data through the standard Linux identity interfaces — &lt;strong&gt;NSS (Name Service Switch)&lt;/strong&gt; for identity lookups (user names, UIDs, GIDs, group membership) and &lt;strong&gt;PAM (Pluggable Authentication Modules)&lt;/strong&gt; for authentication and session management — without creating local user accounts. It was originally developed as a component of the FreeIPA project at Red Hat, introduced in Fedora 11 (2009), and quickly became the standard identity integration layer across RHEL, Fedora, Ubuntu, Debian, and most enterprise Linux distributions. Before SSSD, integrating a Linux host with &lt;strong&gt;LDAP&lt;/strong&gt; or &lt;strong&gt;AD&lt;/strong&gt; required configuring &lt;code&gt;nss_ldap&lt;/code&gt;, &lt;code&gt;pam_ldap&lt;/code&gt;, &lt;code&gt;pam_krb5&lt;/code&gt;, and &lt;code&gt;pam_winbind&lt;/code&gt; independently — each with its own caching (or lack thereof), its own reconnection logic, and its own configuration syntax. SSSD replaced this collection with a single, unified daemon providing caching, offline authentication, multi-domain support, and access control in one place.&lt;/p&gt;</description></item></channel></rss>