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 Samba + EJBCA möglich. Der Einsatz dieser Lösung erfordert jedoch einige Überlegungen, damit das zuverlässig und stabil funktioniert.

Warnung

Sofern nicht ausschließlich aktuelle Windows Versionen in der AD Domäne betrieben werden, kann es zu einer Scheinsicherheit durch Smartcards kommen. Sofern in der Domände noch NTLM 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 NTLM komplett deaktiviert werden, so dass die Authentifizierung mit Kerberos erzwungen wird.

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 z.B. für den Einsatz bei Banken oder Kritis Unternehmen zu empfehlen ist. Aufgrund der EAL4+ Zertifizierung dieser Software wird es bei sachgerechter Konfiguration nur wenig Rückfragen im Falle von Prüfungen geben.

Custom Certificate Extensions

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.

Extended Key Usages

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

In den Extended Key Usages muss die OID 1.3.6.1.4.1.311.20.2.3 (msUPN) ergänzt werden.

Certificate Profile Server

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

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:

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.

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.

Der CN ist der angezeigte Name, z.B. "Erika Mustermann". der MS UPN ist der Benutzername in der AD Domäne, z.B. im-erika@mydom.example.com 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 Gruppenrichtliinien 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. Dort gibt es lediglich einen Kiosk Mode, bei dem sich ein Firefox öffnet und nur die RA der PKI aufrufbar ist. 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.

Grundsätzlich geht das auch mit einem gesonderten Terminal, wobei ein Raspberry PI ausreicht. Mit einer kleinen Java oder Python Software verlangt er Username/Passwort und das Token erhält sein Schlüsselpaar und das Zertifikat.

Mit der SOAP Schnittstelle von EJBCA sind parktisch beliebige Lösungen für alle Sicherheitsanforderungen und Volumina machbar.

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 10
  • Mac OS X
  • 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 Kartebleser 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.

Login

Hier nun ein paar Screenshots von Windows 10 (1903)