SSO auto-hébergé avec Authentik et Samba 4 AD

Le single sign-on ressemble à un luxe d'entreprise jusqu'au moment où vous gérez un homelab avec quinze services et un mot de passe différent pour chacun. À ce stade, ce n'est plus un confort — c'est un vrai problème de sécurité. Une seule credential compromise peut donner à un attaquant accès à tout ; une révocation oubliée laisse un ancien collaborateur avec des accès bien après qu'il aurait dû les perdre.

La solution que j'utilise combine Samba 4 Active Directory sur Linux comme store d'identités central, et Authentik comme fournisseur OIDC/OAuth2 qui relie l'annuaire AD à chaque application nécessitant une authentification.

Pourquoi Samba 4 AD ?

Samba 4 sur Linux offre un contrôleur de domaine Active Directory entièrement fonctionnel — realm Kerberos, annuaire LDAP, DNS et Group Policy — sans licence Windows Server. Tout service sachant parler LDAP (c'est-à-dire la plupart) peut l'interroger directement. Toute application moderne supportant OIDC peut passer par Authentik, qui interroge à son tour le même annuaire Samba via son outpost LDAP.

Le résultat : un compte utilisateur, un mot de passe, un seul endroit pour désactiver les accès.

Architecture

flowchart TD
    classDef user fill:#f9f9f9,stroke:#333,stroke-width:2px;
    classDef auth fill:#fff3e0,stroke:#ef6c00,stroke-width:2px;
    classDef app fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
    classDef dir fill:#e1f5fe,stroke:#01579b,stroke-width:2px;

    User([Navigateur])

    subgraph Identity [Couche d'Identité]
        Samba["Samba 4 AD\nKerberos · LDAP · DNS"]
        Authentik["Authentik\nOIDC · OAuth2 · SAML · Forward Auth"]
    end

    subgraph Apps [Applications]
        Forgejo["Forgejo"]
        Grafana["Grafana"]
        Proxmox["Proxmox VE"]
        Other["N'importe quelle app\nvia Forward Auth"]
    end

    NGINX["NGINX\nProxy Forward Auth"]

    User -->|login| Authentik
    Authentik -->|LDAP bind| Samba
    Authentik -->|token OIDC| Forgejo
    Authentik -->|token OIDC| Grafana
    Authentik -->|token OIDC| Proxmox
    User --> NGINX
    NGINX -->|auth_request| Authentik
    NGINX -->|authentifié| Other

    class User user;
    class Samba,Authentik auth;
    class Forgejo,Grafana,Proxmox,Other app;
    class NGINX dir;

Configurer Samba 4 AD

Samba 4 tourne comme conteneur LXC sur Proxmox. Le provisionnement se fait avec une seule commande samba-tool domain provision :

samba-tool domain provision \
  --domain=HOME \
  --realm=HOME.INTERNAL \
  --server-role=dc \
  --dns-backend=SAMBA_INTERNAL \
  --adminpass='VotreMotDePasseSolide'

Après le provisionnement, le conteneur fournit un KDC Kerberos, un serveur LDAP sur le port 389 et le DNS pour la zone home.internal. L'hôte Proxmox et tous les nœuds LXC/VM pointent leur DNS vers ce conteneur.

Étapes clés après le provisionnement :

• Créer des OUs pour les utilisateurs, comptes de service et groupes
• Créer un compte de service en lecture seule pour le bind LDAP d'Authentik
• Définir une politique de mots de passe (complexité, âge minimum, seuil de blocage)

Connecter Authentik

Authentik tourne comme conteneur séparé. Après la configuration initiale, configurez une source LDAP pointant vers le conteneur Samba :

• URI du serveur : ldap://samba.home.internal
• DN de bind : CN=authentik-svc,OU=ComptesService,DC=home,DC=internal
• DN de base : DC=home,DC=internal
• Filtre d'objets utilisateur : (objectClass=person)
• Synchronisation des groupes : activée

Authentik synchronise les utilisateurs et groupes depuis AD selon un calendrier. Lorsqu'un utilisateur se connecte via Authentik, le mot de passe est validé contre Kerberos via le bind LDAP — Authentik ne stocke jamais le mot de passe.

OIDC pour les intégrations natives

Pour les applications avec support OIDC natif, créez un Fournisseur OAuth2/OIDC dans Authentik et une Application correspondante :

• Forgejo : configurez FORGEJO__server__OAUTH2_JWT_SECRET et ajoutez une source OAuth2 pointant vers l'endpoint de découverte d'Authentik
• Grafana : configurez les variables d'environnement GF_AUTH_GENERIC_OAUTH_*
• Proxmox : ajoutez un realm OpenID dans Datacenter → Realms

Chaque application obtient son propre client ID et secret. L'accès est contrôlé par les politiques Authentik — vous pouvez exiger le MFA pour Proxmox tout en autorisant le mot de passe seul pour Grafana.

Forward Auth pour tout le reste

Pour les applications sans support OIDC, NGINX Forward Auth est la réponse. Chaque requête passe par NGINX, qui appelle l'endpoint /outpost.goauthentik.io/auth/nginx d'Authentik avant de transmettre à l'upstream :

location / {
    auth_request /outpost.goauthentik.io/auth/nginx;
    auth_request_set $authentik_username $upstream_http_x_authentik_username;
    error_page 401 = @authentik_redirect;
    proxy_pass http://upstream;
}

L'outpost Authentik gère le flux de connexion et définit les headers d'identité. L'application upstream reçoit X-Authentik-Username et X-Authentik-Groups sans avoir besoin de connaître OIDC.

Révocation

Quand quelqu'un part, désactivez son compte AD. Cette seule action :

• Invalide ses tickets Kerberos (dans la durée de vie du ticket, typiquement 10 minutes)
• Empêche Authentik d'émettre de nouveaux tokens OIDC
• Bloque immédiatement toutes les vérifications Forward Auth

Pas besoin de chercher dans les panneaux d'administration de chaque application. Un changement, révocation complète.

Stack

Samba 4 · Authentik · NGINX Forward Auth · Proxmox LXC · Kerberos · LDAP