Self-hosting SSO with Authentik and Samba 4 AD

Single sign-on is one of those things that sounds like an enterprise luxury until you're managing a homelab with fifteen services and a different password for each one. At that point it stops being a nice-to-have and starts being a genuine security problem. A single compromised credential can give an attacker access to everything; a single forgotten revocation leaves a former team member with access long after they should have had it.

The solution I use is a combination of Samba 4 Active Directory running on Linux as the central identity store, and Authentik as the OIDC/OAuth2 provider that bridges the AD directory to every application that needs authentication.

Why Samba 4 AD?

Samba 4 on Linux gives you a fully functional Active Directory domain controller — Kerberos realm, LDAP directory, DNS, and Group Policy — without a Windows Server license. Every service that knows how to talk LDAP (which is most of them) can query it directly. Every modern application that supports OIDC can go through Authentik, which in turn queries the same Samba directory via its LDAP outpost.

The result: one user account, one password, one place to disable access.

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([Browser])

    subgraph Identity [Identity Layer]
        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["Any app\nvia Forward Auth"]
    end

    NGINX["NGINX\nForward Auth proxy"]

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

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

Setting up Samba 4 AD

Samba 4 runs as an LXC container on Proxmox. The provisioning command is a single samba-tool domain provision:

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

After provisioning, the container provides a Kerberos KDC, an LDAP server on port 389, and DNS for the home.internal zone. The Proxmox host and all LXC/VM nodes point their DNS at this container.

Key post-provisioning steps:

• Create OUs for users, service accounts, and groups
• Create a read-only service account for Authentik's LDAP bind
• Set a password policy (complexity, minimum age, lockout threshold)

Connecting Authentik

Authentik runs as a separate container. After the initial setup, configure an LDAP source pointing at the Samba container:

• Server URI: ldap://samba.home.internal
• Bind DN: CN=authentik-svc,OU=ServiceAccounts,DC=home,DC=internal
• Base DN: DC=home,DC=internal
• User object filter: (objectClass=person)
• Group sync: enabled, group object filter (objectClass=group)

Authentik syncs users and groups from AD on a schedule. When a user logs in through Authentik, the password is validated against Kerberos via the LDAP bind — Authentik never stores the password itself.

OIDC for native integrations

For applications with native OIDC support, create an OAuth2/OIDC Provider in Authentik and a corresponding Application:

• Forgejo: set FORGEJO__server__OAUTH2_JWT_SECRET and add an OAuth2 source pointing at Authentik's discovery endpoint
• Grafana: configure GF_AUTH_GENERIC_OAUTH_* environment variables
• Proxmox: add an OpenID realm under Datacenter → Realms

Each application gets its own client ID and secret. Access is gated by Authentik policies — you can require MFA for Proxmox while allowing password-only for Grafana.

Forward Auth for everything else

For applications with no OIDC support, NGINX Forward Auth is the answer. Every request passes through NGINX, which calls Authentik's /outpost.goauthentik.io/auth/nginx endpoint before forwarding to the 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;
}

The Authentik outpost handles the login flow and sets identity headers. The upstream application sees X-Authentik-Username and X-Authentik-Groups without needing to know anything about OIDC.

Revocation

When someone leaves, disable their AD account. That single action:

• Invalidates their Kerberos tickets (within the ticket lifetime, typically 10 minutes)
• Prevents new OIDC tokens from being issued by Authentik
• Blocks all Forward Auth checks immediately

No hunting through individual application admin panels. One change, full revocation.

Stack

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