SSSD (System Security Services Daemon) is a multi-daemon suite that connects Linux systems to remote identity and authentication providers, presenting their data through the standard Linux identity interfaces — NSS (Name Service Switch) for identity lookups (user names, UIDs, GIDs, group membership) and PAM (Pluggable Authentication Modules) 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 LDAP or AD required configuring nss_ldap, pam_ldap, pam_krb5, and pam_winbind 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.
IEEE 802.1X is a standard for Port-Based Network Access Control (PNAC) that prevents any device from sending or receiving traffic on a network port until it has successfully authenticated. Originally designed for wired Ethernet and ratified in 2001, it now equally underpins enterprise Wi-Fi (WPA-Enterprise/WPA3-Enterprise), where access points act as the port gatekeeper. The core premise is that physical access to a port — plugging in a cable or being in range of an access point — does not grant network access. The port is logically divided into two channels: the uncontrolled port, which passes only EAP authentication traffic (EAPOL frames), and the controlled port, which is fully blocked until authentication succeeds. Only after the authentication server approves the device does the switch or access point open the controlled port and allow normal traffic. This port-level gate is what separates 802.1X from higher-layer authentication: a device that fails 802.1X receives no IP address, cannot reach any network resource, and cannot even attempt an attack at layer 3.
OpenID Connect (OIDC) is an authentication protocol built as a thin layer on top of OAuth 2.0, published by the OpenID Foundation in 2014. Where OAuth 2.0 defines how to delegate authorisation (granting access to resources), OIDC adds the missing authentication semantics: a standard ID token that proves who the user is, a UserInfo endpoint that returns standardised identity claims, and a discovery document that allows clients to configure themselves automatically from a single well-known URL. The separation is precise: OAuth 2.0 access tokens prove that a client is authorised to call an API; OIDC ID tokens prove that a specific user authenticated with a specific identity provider at a specific time. OIDC is the protocol behind virtually every “Sign in with Google / GitHub / Microsoft” flow, every SAML-to-modern-stack migration, and every Kubernetes service account token issued today — making it the dominant authentication federation standard in cloud-native infrastructure.
LDAP (Lightweight Directory Access Protocol) is a client-server protocol for accessing and modifying a directory service: a specialised database optimised for read-heavy, hierarchically-organised identity data. It was derived from the X.500 directory standard in the early 1990s, stripping out OSI transport dependencies to run over TCP/IP, and standardised in its current form in RFC 4511 (LDAPv3, 2006). A directory in the LDAP sense is not a general-purpose database — it is a tree of entries (also called objects), each identified by a Distinguished Name (DN) that encodes its position in the hierarchy: cn=alice,ou=users,dc=example,dc=com. Each entry is an instance of one or more object classes (defined in a schema), and each object class defines a set of mandatory and optional attributes — typed, multi-valued fields such as uid, cn (common name), mail, userPassword, memberOf, sshPublicKey, objectClass, and userCertificate. The schema is extensible: LDAP servers ship with standard schema files (RFC 2307 for POSIX users and groups, RFC 4519 for person entries) and organisations add custom schema for application-specific attributes. The tree structure makes hierarchical policy delegation natural — all objects under ou=engineering,dc=example,dc=com can be administered by a different set of ACL rules than objects under ou=ops.
HMAC (Hash-based Message Authentication Code), standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a Message Authentication Code (MAC) by combining a cryptographic hash function with a shared secret key. A plain hash function provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key K can produce a valid HMAC(K, message), and only a party who knows K can verify it. The construction is HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)) — two rounds of hashing with the key XOR’d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive H(K ∥ m) constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.
FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.
Active Directory (AD) is Microsoft’s enterprise directory and identity platform, first released with Windows 2000 and now the dominant identity provider in enterprise environments worldwide. It combines four technologies into a single integrated system: LDAP as the directory access protocol for querying and modifying identity data; Kerberos 5 as the authentication protocol for issuing tickets that prove identity without transmitting passwords; DNS as the service location mechanism that clients use to discover domain controllers, Kerberos KDCs, and LDAP servers; and Group Policy as the configuration management system that pushes security settings, software installation, and policy enforcement to every joined machine. These four components are inseparable in practice: a Linux host joining an AD domain receives a Kerberos principal in AD’s KDC, a machine account object in the AD LDAP directory, a DNS record for its hostname, and (optionally) Group Policy Objects applied to it. The AD forest is the trust boundary: multiple domains can exist within a forest and all share a common schema, configuration, and Global Catalog, with transitive Kerberos trust between them.
