Windows Login mit Smartcard

Damit Windows Smartcards akzeptiert, sind in der von Microsoft unterstützten Lösung Active Directory und eine PKI notwendig. Das muss jetzt aber nicht notwendigerweise Windows Server bedeuten, sondern ist auch mit Samba4 und EJBCA möglich. Der Einsatz dieser Lösung erfordert jedoch einige Überlegungen, damit das zuverlässig und stabil funktioniert.

Die Lösung wurde mit Windows 10 und 11 getestet (Patchstand: September 2022)

Übrigens: Mit qemu/libvirt kann man Linux nutzen, um Windows 11 ein TPM2 vorzuspiegel, weil diese Virtualisierungsplattform in Verbindung mit stpm ein virtuelles TPM2 im Gast anbietet. Sofern also zumindest die CPU für Windows 11 geeignet ist, kann Windows 11 uneingeschränkt genutzt werden.

Warnung

Sofern nicht ausschließlich aktuelle Windows Versionen in der AD Domäne betrieben werden, kann es zu einer Scheinsicherheit durch Smartcards kommen. Wenn in der Domände noch NTLMv1 verwendet wird, kann ein Angreifer die Smartcard Authentifizierung umgehen und sich mit den bekannten Angriffsmethoden auch ohne Smartcard Zugang zu der Domäne verschaffen. Das gilt auch für Accounts mit erhöhten Berechtigungen, wie z.B. Domänen Administratoren. Damit die Lösung sicher arbeitet, muss NTLMv1 komplett deaktiviert werden.

Samba Konfiguration

Für einen ersten Einstieg ist der Anleitung im Samba Wiki ein guter Einstieg. Komplizierter wird es, wenn die Windows CA eine SubCA einer zentralen Root-CA ist, was dennoch zu empfehlen ist. Auf diese Weise braucht man in der Windows Domäne nur noch das CA Zertifikat der zentralen Root-CA mit Hilfe der Gruppenrichtlinie zu verteilen.

krb5.conf

Abweichend von der Empfehlung im Samba Wiki muss bei Verwendung einer SubCA die krb5.conf etwas anders konfiguriert werden:

[libdefaults]
    default_realm = CFWIN.FELSING.NET
    dns_lookup_realm = false
    dns_lookup_kdc = true
    pkinit_pool = FILE:/mnt/samba4/private/tls/ca.pem
    pkinit_anchors = FILE:/mnt/samba4/private/tls/root-ca.pem

[appdefaults]
    pkinit_pool = FILE:/mnt/samba4/private/tls/ca.pem
    pkinit_anchors = FILE:/mnt/samba4/private/tls/root-ca.pem

[realms]
    CFWIN.FELSING.NET = {
    pkinit_require_eku = true
}

[kdc]
    enable-pkinit = yes
    pkinit_identity = FILE:/mnt/samba4/private/tls/cert.pem,/mnt/samba4/private/tls/key.pem
    pkinit_pool = FILE:/mnt/samba4/private/tls/ca.pem
    pkinit_anchors = FILE:/mnt/samba4/private/tls/root-ca.pem
    pkinit_principal_in_certificate = yes
    pkinit_win2k = no
    pkinit_win2k_require_binding = yes

Auf diese Weise wird das SubCA Zertifikat eingebunden.

smb.conf

Die folgende smb.conf zeigt die Einbindung der Zertifikate in Samba.

# Global parameters
[global]
    cache directory = /mnt/samba4
    ntlm auth = disabled
    dedicated keytab file = /mnt/samba4/private/krb5.conf
    dns forwarder = 192.168.1.254
    kerberos method = dedicated keytab
    lock directory = /mnt/samba4
    log level = 3 passdb:5 auth:5
    netbios name = AD1
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    private dir = /mnt/samba4/private
    realm = CFWIN.FELSING.NET
    server role = active directory domain controller
    smb passwd file = /mnt/samba4/private/smbpasswd
    state directory = /mnt/samba4
    tls cafile = /mnt/samba4/private/tls/full-chain.pem
    tls certfile = /mnt/samba4/private/tls/cert.pem
    tls crlfile = /mnt/samba4/private/tls/ca.crl
    tls dh params file = /mnt/samba4/private/tls/dh.pem
    tls enabled = Yes
    tls keyfile = /mnt/samba4/private/tls/key.pem
    usershare path = /mnt/samba4/usershares
    workgroup = CFWIN
    idmap_ldb:use rfc2307 = yes

[public]
    comment = Public files
    path = /mnt/samba4/public
    write list = Administrator @Administrators

[netlogon]
    path = /mnt/samba4/sysvol/cfwin.felsing.net/scripts
    read only = No

[sysvol]
    path = /mnt/samba4/sysvol
    read only = No

Wichtig ist, hier, dass das Zertifikat zumindest einen CRL Distribution Point enthält, ansonsten verwift
Windows alle Zertifikate, weil diese nicht validierbar sind.

Der Share Public ist sehr nützlich, wenn man über Gruppenrichtlinien irgendwelche Config Files verwenden will.
Das können z.B. XML Files sein für Standardanwendungen oder Vorgaben für die Startleiste.

EJBCA

Windows erwartet als PKI eine richtige PKI, die zumindest folgende Eigenschaften bietet:

Bereitstellung eines CRL Distributionpoints
Optimal ist auch OCSP

Beides wird von EJBCA unterstützt. Als Zertifizierungsstelle für professionelle Ansprüche sollte diese Lösung auch bei der Verwendung von Windows Server der Vorzug gegeben werden. Es gibt davon auch eine kostenpflichtige Version mit Wartungsvertrag, die für den Einsatz in Unternehmen zu empfehlen ist. Aufgrund der EAL4+ Zertifizierung dieser Software wird es bei sachgerechter Konfiguration und Betrieb nur wenig Rückfragen im Falle von Prüfungen geben.

Custom Certificate Extensions

msADGUID

Für die Verwendung in den Zertifikaten muss die OID 1.3.6.1.4.1.311.25.1 (msADGUID) als DEROCTETSTRING ergänzt werden. Leider scheint EJBCA den Wert nicht aus dem CSR zu übernehmen, daher muss der Wert hardcodiert in diesem Objekt eingetragen werden. Das folgende Skript extrahiert die msADGUID aus der Samba AD-DC Konfiguration.

#/usr/bin/env bash

# Author: Christian Felsing

# Improvement regarding https://wiki.samba.org/index.php/Samba_AD_Smart_Card_Login
# You no longer need Windows for aquiring DCs GUID

convertToHex() {
  # Inspired by https://docs.microsoft.com/en-us/troubleshoot/windows-server/admin-development/convert-string-guid-to-hexadecimal-string
  RAW="$1"
  GUID=$(echo "$RAW" | sed 's/\-//g')

  HEX="${GUID:6:2}"
  HEX="${HEX}${GUID:4:2}"
  HEX="${HEX}${GUID:2:2}"
  HEX="${HEX}${GUID:0:2}"
  HEX="${HEX}${GUID:10:2}"
  HEX="${HEX}${GUID:8:2}"
  HEX="${HEX}${GUID:14:2}"
  HEX="${HEX}${GUID:12:2}"
  len=${#HEX}
  HEX="${HEX}${GUID:16:${len}}"

  echo "$RAW -> $HEX"
}


# apt install ldb-tools
realm=$(grep -i realm /etc/samba/smb.conf | awk '{print $3}' | tr '[:upper:]' '[:lower:]')
dc=$(echo $realm | awk -F '.' '{for(i = 1; i <= NF; i++) {printf ",DC=" $i}}')
base="OU=Domain Controllers${dc}"
cn=$(hostname)

GUID=$(ldbsearch -H /var/lib/samba/private/sam.ldb --basedn="$base" "CN=${cn}" objectGUID \
  | grep '^objectGUID:' \
  | awk '{print $2}' \
)
convertToHex "$GUID"

Der hier ermittelte Hex-Wert muss in der EJBCA Konfiguration eingetragen werden.

ToDo

Unter Custom Certificate Extensions wird beschrieben, wie man ein Custom Klasse zur Behandlung solcher Certificate Extensions erstellen kann. Es muss noch geklärt werden, ob man tatsächlich dafür eine eigene Klasse für die PKI erstellen muss.

Extended Key Usages

Damit Windows den Usernamen aus dem Zertifikat ermitteln kann, muss noch msUPN als Key Usage definiert werden.

msUPN

In den Extended Key Usages muss die OID 1.3.6.1.4.1.311.20.2.3 (msUPN) ergänzt werden. In den aktuellen EJBCA Versionen ist das nicht mehr notwendig.

Certificate Profile Server

Das Zertifikat für den Server (DC) muss wie folgt eingestellt werden:

Server Profile

Die Extended Key Usage erlaubt Windows die Verwendung der damit erstellen Zertifikate für TLS Server und Kerberos KDC.

Certificate Profile Client

Die Client Zertifikate werden mit dem folgenden Profil erstellt:

Client Profile

Neben den typischen Verwendungen von Client Zertifikaten ist hier "MS Smartcard Logon" wichtig.

End Entity Profile Server

Für den DC sind die Attribute "DNS Name" und "MS GUID" von besonderer Bedeutung.

Entity Profile Server

Die zusätzlichen DNS Namen sowie IP-Adressen erlauben eine universelle Verwendung für Server Zertifikate, sind aber in der vorliegenen
Anwendung nicht zwingend notwendig.

End Entity Profile Client

Für Windows sind hier die Zertifikatsattribute CN und "MS UPN" wichtig.

Entity Profile Client

Der CN ist der angezeigte Name, z.B. "Erika Mustermann". der MS UPN ist der Benutzername in der AD Domäne, z.B. [email protected] wie er in den Eigenschaften im AD
zu finden ist.

Verteilung der Zertifikate

Während die CA Zertifikate einfach wie im Samba Wiki beschrieben über Gruppenrichtlinien verteilt werden können, ist das bei den Client Zertifikaten etwas komplizierter, da kommt aber eine gut organisierte RA (Registration Authority) ins Spiel.

Am Einfachsten geht das über ein Selfservice Portal, bei dem sich die User mit Username und Passwort anmelden können. Zweckmäßigerweise verwendet man bei dem Webserver eine Kerberos Authentifizierung, für Apache httpd/EJBCA ist das in dem Admin Manual beschrieben. Man kann nun das Token mit einem neuen Schlüsselpaar versehen.

Es spricht auch nichts gegen ein Powershell Skript, das ggf. über die AD GPOs zentral gesteuert wird. Wichtig ist dabei, dass das private Schlüsselmaterial ausschließlich auf der Smartcard erzeugt wird.

Welche Tokens?

An dieser Stelle ist die Tatsache interessant, dass sich hier die Lösungen für große und kleine Unternehmen oder sogar private Anwendung auf technischer Ebene nur wenig unterscheiden müssen.

Entscheidend: Die Middleware

Gleich vorweg: Finger weg von Closed Source Lösungen. Die Erfahrung hat gezeigt, dass diese Lösungen qualitativ oft hinter den Open Source Lösungen liegen. Es sollten also ausschließlich nur Tokens/Smartcards in Betracht gezogen werden, die von OpenSC unterstützt werden. OpenSC wird sehr aktiv weiterentwickelt und verursacht neben den Tokens keine weiteren Kosten und unterstützt verschiedene Plattformen:

Windows 7 bis 11
Mac OS
Linux
FreeBSD

Bei Linux ist zusätzlich noch das P11-Kit zu empfehlen.

Hardware

Die o.g. Anforderungen führen zusammen mit den vorliegenden Erfahrungen zu einer bisher recht kurzen Liste. Karten oder Tokens mit Kontakten führen gerade in Unternehmen durch die häufige Verwendung zu einem erheblichen Verschleiss der Kontakte, egal ob USB oder IEC7816-1. Optimal sind daher Karten mit einem NFC Interface nach IEC14443, wobei die NFC Übertragung verschlüsselt erfolgen muss. Bisher konnten sich aufgrund der zahlreichen Anforderungen nur folgende Produkte qualifizieren:

Smartcard-HSM (nur die Karte unterstützt NFC)
Nitrokey (baugleich mit Smartcard-HSM)
Yubikey Neo 5

Bei der Verwendung von Smartcards müssen Kartenleser verwendet werden, die "Extended APDUs" unterstützen. Ansonsten können nur max 261 Bytes große Datenpakete übertragen werden, so dass meist schon der Aufbau einer verschlüsselten NFC Verbindung scheitert und damit die Smartcard abgewiesen wird.

TPM

Unter virtual Smartcard wird gezeigt, wie man das Client Zertifikat unter Windows in einem TPM speichert.

Showtime

Unter Showtime sind einige Screenshots zu sehen, wie Windows mit der Smartcard arbeitet.

Falls es nicht klappt

Unter Troubleshooting sind Hinweise zu finden, fall Windows das Client Zertifikat nicht akzeptiert.

Quellen

Samba AD Smart Card Login