↓ Skip to main content
Le Site de François
  1. Index/

AD (Active Directory)

Identity Authentication Microsoft Kerberos Ldap Pki Enterprise

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.

AD’s directory schema is LDAPv3-compatible but Microsoft-extended beyond standard RFC 2307. Every security principal (user, computer, group, service account) has a Security Identifier (SID) — a globally unique, immutable identifier that is the actual identity token in Windows access control, independent of name or DN. The SID is carried in the PAC (Privilege Attribute Certificate) embedded in every Kerberos ticket, containing the user’s SID, all group SIDs, and privilege flags — allowing Windows services and AD-aware Linux services to make authorisation decisions from the ticket alone without querying LDAP. User account attributes of security relevance include: userAccountControl (a bitmask encoding account enabled/disabled, password never expires, smart card required, trusted for delegation, and dozens more), pwdLastSet and lockoutTime for password policy enforcement, msDS-SupportedEncryptionTypes declaring which Kerberos encryption types the account supports, and altSecurityIdentities for storing certificate subject names and SSH public keys for certificate- and key-based authentication. Group Policy Objects (GPOs) are LDAP objects in the cn=Policies,cn=System container linked to sites, domains, or OUs; Windows clients process them at boot and login via the Group Policy Client service; Linux clients joined via SSSD and realmd do not process GPOs natively but can apply a subset of security policy through SSSD’s AD provider features.

For Linux infrastructure, AD integration is the dominant enterprise identity use case and SSSD with realmd is the standard integration path. realm join example.com performs the full join in one command: it discovers the nearest domain controller via DNS SRV records (_ldap._tcp.example.com, _kerberos._tcp.example.com), creates a machine account in AD, writes the Kerberos keytab to /etc/krb5.keytab, and configures SSSD with the ad provider. Once joined, Linux users authenticate with their AD username and password (or Kerberos ticket), group membership is resolved from AD, sudo rules can be stored in AD using the RFC 2307 schema extension or in FreeIPA trust mode, and HBAC (Host-Based Access Control) restricts which AD users may log in to which Linux hosts. AD Certificate Services (AD CS) provides the enterprise CA for issuing user and machine certificates, integrated with the AD identity store — user certificates issued by AD CS carry the user’s UPN in the SAN, enabling certificate-based authentication to Linux hosts via SSSD’s pam_cert_auth feature and FIDO2/smartcard login. Kerberos constrained delegation and resource-based constrained delegation (RBCD) allow AD-enrolled Linux services to impersonate users when accessing other Kerberos-protected services — the mechanism underlying gss-proxy and kerberised NFS, CIFS, and PostgreSQL authentication. The Azure AD / Microsoft Entra ID cloud identity service is a separate product that does not implement the same AD protocols (no LDAP, no Kerberos, no Group Policy) and integrates with Linux via OIDC/OAuth 2.0 through SSSD’s IdP provider or via the Microsoft Entra Linux agent rather than through the traditional AD domain join path.

Related

SSSD (System Security Services Daemon)

Identity Authentication Linux Ldap Kerberos Ad Pam Rhel
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.

LDAP (Lightweight Directory Access Protocol)

Identity Networking Directory Authentication Standards Pki
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.

FIDO (Fast IDentity Online) / FIDO2

Security Authentication Cryptography Pki Webauthn Mfa Zero-Trust
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.