Smartcard-Anmeldung

Früher musste ein Anwender nur seinen NT4-Usernamen und Kennwort eingeben, wenn nicht gleich "Autologin" aktiviert war. Ich hoffe, dass das heute niemand mehr macht und in der Cloud mit der Erreichbarkeit der Dienste von Überall ist eine sichere Anmeldung schon Pflicht. Microsoft fordert sogar zu MFA auf, d.h. dass neben dem Kennwort auch noch eine SMS, ein Einmalkey, die Authenticator App oder biometrische Informationen (Bild, Fingerabdruck) oder ein FIDO2-Key dazu kommen. Das gilt aber erst einmal nur für "Cloud"-Dienst und ausgewählte lokale Dienste, die mit OAUTH umgehen können, wie z.B. Hybrid Modern Authentication (HMA) oder mittlerweile auch PRTG. On-Premises gibt es zwar auch schon länger "Windows Hello for Business" aber in nicht wenigen Firmen ist auch eine klassische Smartcard ein Thema.

Konto per Smartcard absichern

Auf den Prozess des Smartcard-Rollouts gehe ich nicht weiter ein aber damit ein Anwender sich nicht mehr mit Benutzername/Kennwort anmeldet, gibt es eine gesonderte Einstellungen bei Benutzer im Active Directory.

Durch das Setzen des Werts ändern sich bei mir folgende Felder im AD (Erfasst durch GET-ADChanges) 

Action,Identity,Field,Value
Modify,CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE,useraccountcontrol,262656
Modify,CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE,ntpwdhistory,
Modify,CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE,dbcspwd,
Modify,CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE,lmpwdhistory,
Modify,CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE,unicodepwd,
Modify,CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE,supplementalcredentials,

Es wird also nicht nur "useraccountcontol" gesetzt. Durch das Setzen von "SMARTCARD_REQUIRED" wird zeitgleich auch das DONT_EXPIRE_PASSWORD-Flag gesetzt, damit das Kennwort nicht aufläuft. Der Benutzer kennt es ja nicht. Zudem wird das Kennwort auf einen zufälligen Wert gesetzt, damit der Anwender sich nicht mehr anmelden kann.

Auch wenn es hier nicht offen sichtbar wird, sollte ein SmartCard-User auch einen geeigneten UPN haben.

Kennwort absichern

Die Einschränkung bezieht sich aber nur auf "Interaktive Logons". Der Anwender könnte natürlich immer noch eine "Anmeldung als Service" o.ä. mit dem bekannten Kennwort durchführen. Daher kann es eine Option sein, auch das normale Kennwort des Anwenders zu ändern, so dass dieser es gar nicht mehr kennt. Es ist aber ein Kennwort und es könnte durch einen Abgriff der NTDS.DIT im Rahmen eines Angriffs über Hashwerte/Rainbow-Tables auch durch Angreifer ermittelt und der Zugang missbraucht werden.

Daher ist auch hier regelmäßiger Wechsel wünschenswert. Dies gilt umso mehr, da der Anwender mit Smartcard sein eigentliches Kennwort gar nicht mehr ändert und ohne Vorkehrungen es durchaus angreifbar wäre. Bei einer Anmeldung per NTLM wird vom Kennwort ein Hashwert gebildet, der nur mit einer Kennwortänderung ungültig wird. Nur weil sich der Anwender nicht mehr "interaktiv" ohne Kennwort anmelden kann, so können

Über die Kennwortrichtlinien kann ich schon für die interaktive Anmeldung entsprechende Anforderungen an Komplexität, Dauer, Länge, etc. stellen. Wenn der Benutzer aber sich eh nur per Smartcard anmeldet, bekommt er den Dialog nicht. Seit Windows 2016 kann aber Windows selbst das Kennwort anhand der Kennwortrichtlinie ändern. Hierfür gibt es mit dem Property "msDS-ExpirePasswordsOnSmartCardOnlyAccounts" auf jeder AD-Domain eine elegante Funktion, diesen Kennwortwechsel zu automatisieren ohne eigene Skripte einsetzen zu müssen:

Der Standardwert ist "False" aber kann einfach auf "True" gesetzt werden. Auch per AD-PowerShell kann der Wert einfach gesetzt und gelesen werden.

Set-ADDomain `
   -Identity uclabor.de `
   -PublicKeyRequiredPasswordRolling $true

PS C:\> Get-ADDomain | ft name,PublicKeyRequiredPasswordRolling

name    PublicKeyRequiredPasswordRolling
----    --------------------------------
UCLABOR                             True

Damit übernimmt dann der Domain Controller die Aufgabe die Kennworte der Benutzer gemäß der Kennwortrichtlinie zu ändern. Die Einstellung gibt es auch als Dialog im "Active Directory Administrative Center":

 Für Smartcard-Benutzer kann ich daher eine eigene Richtlinie anlegen, welche dann die Kennworte nicht erst alle Monate ändert.

Kennwort Richtlinien

Seit Windows 2016 muss ich die Kennwort-Richtlinie nicht mehr pro Domain steuern, sondern kann dies feiner abstimmen. Über die neuen "Password Settings" kann ich für die Benutzer oder OUs dann eine Richtlinie anlegen, die z.B. einen täglichen Kennwortwechsel anfordert.

Wenn Sie wirklich jeden Tag ein neues Kennwort erfordern, dann sollten Sie diese Richtlinien nur auf die Personen anwenden, die sich per Smartcard anmelden müssen und nicht auf Dienstkonten o.ä. Damit ist aber sichergestellt, dass die Anwenderkennworte selbst beim Abgriff der Hashwerte meist schon geändert sind, ehe ein Angreifer ein zum Hashwert passendes Kennwort gefunden hat. Per PowerShell kann ich auch Werte <1 Tag angeben:

# Neue Policy anlegen
New-ADFineGrainedPasswordPolicy `
   -Name:"SmartcardUser-Policy” `
   -Precedence:1 `
   -MaxPasswordAge:"00.00:05:00" `
   -MinPasswordAge:"00.00:00:00" `
   -ComplexityEnabled:$true `
   -LockoutDuration:”00:30:00" `
   -LockoutObservationWindow:"00:30:00" `
   -LockoutThreshold:0 `
   -MinPasswordLength:120 `
   -PasswordHistoryCount:24 `
   -ReversibleEncryptionEnabled:$false

# An Benutzer zuweisen
Add-ADFineGrainedPasswordPolicySubject `
   -Identity " CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE" `
   -Subjects "CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE"

Technisch werden dabei folgende Einträge im AD gemacht:

Action,Identity,Field,Value
NewOrMove,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,parentguid,9f e7 fb c9 33 5f 71 46 b2 ca 9c 9d 56 b8 9b 2e
NewOrMove,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,parentdn,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-minimumpasswordlength,120
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-passwordreversibleencryptionenabled,False
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-minimumpasswordage,0
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,ntsecuritydescriptor,System.Byte[]
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-lockoutobservationwindow,-18000000000
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,objectcategory,CN=ms-DS-Password-Settings,CN=Schema,CN=Configuration,DC=UCLABOR,DC=DE
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-passwordcomplexityenabled,True
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-passwordsettingsprecedence,1
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-maximumpasswordage,-3000000000
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,whencreated,04/14/2022 16:46:10
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-lockoutduration,-18000000000
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-lockoutthreshold,0
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,objectclass,top msDS-PasswordSettings
Modify,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-passwordhistorylength,24
Add,CN=SmartcardUser-Policy,CN=Password Settings Container,CN=System,DC=UCLABOR,DC=DE,msds-psoappliesto,CN=Smardcardonly-User,OU=FCTest,OU=Accounts,DC=UCLABOR,DC=DE

Die letzte Zeile ist die Zuweisung an den Benutzer:

Password-Änderung

Ich habe dann einige Zeit gewartet, bis und in welchem Intervallen der DC das Kennwort ändert. Leider habe ich aber keine einzige Änderung gesehen. Erst wenn ich mich per Smartcard anmelde und das Kennwort zu alt ist, dann scheint das auf dem DC die entsprechende Aktion zu triggern. Das Kennwort wird nur aktualisiert, wenn ich mich anmelden. So steht es auch in der GUI des "Active Directory Administration Center"

Umgekehrt bedeutet das, dass das Kennwort eines inaktiven Benutzers auch nicht geändert wird, selbst wenn die Kennwortrichtlinie eine sehr häufige Änderung vorschreibt.

Vielleicht ist es dann doch wieder besser, per geplantem Task alle Benutzer zu ermitteln, bei denen "

ADSync

Die Aktivierung eines Benutzers zur Smartcard-Anmeldung ändert zwar lokal das Feld UserAccountContol und einige andere Einträge, die aber hinsichtlich ADSync keine weitere Auswirkungen haben. Ich habe beim "Delta Import" zwar gesehen, dass ADSync eine Änderung gelesen aber beim nachfolgenden Export nichts in die Cloud übertragen hat.

Eine Suche in den ADSync Rules oder auch im Metaverse hat aber keinen Treffer auf "UserAccountContol" oder ein ähnliches Feld ergeben. Der Cloud ist diese Einstellungen hier erst einmal egal.

Wenn Sie aber schon Smartcard-Anmeldungen o.ä. aktiviert haben und sich im ADSync Wizard z.B. per Smartcard anmelden müssen, dann hilft ihnen folgende Information

To use authentication support for non-password scenarios such as federated accounts, smartcards and MFA scenarios, you can provide the switch /InteractiveAuth when starting the wizard. Using this switch will bypass the Wizard's authentication user interface and use the MSAL library's UI to handle the authentication.
Quelle Custom installation of Azure Active Directory Connect https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-custom

Virtuelle Smartcard

Siehe dazu die eigene Seite Virtual Smartcard

PFX Import in Smartcard

Mittlerweile ist der Internet Explorer nicht mehr Supported und weder Edge, Chrome noch Firefox unterstützen die "ActiveX"-Technologie der alten Windows PKI zum Rollout eines Zertifikats per Browser. Sie erkennen das immer beim Aufruf von "https://<fqdn der pki>/certsrv/certrqma.asp" und einen "Loading" in der Auswahlliste des CSP:

In dem Fall bleibt dann nur ein manuelles WebEnrollment oder ein Enrollment über die MMC. Das Problem wird hier aber sichtbar, wenn sie einen PC haben, der gar nicht mehr Mitglied des Active Directory ist. Ein Enrollment per MMC funktioniert "integriert" nur, wenn der Benutzer sich auch an der PKI anmelden kann.

Theoretisch können Sie natürlich ein Zertifikat anfordern und auf einen Smartcard importieren. Das geht aber auf Windows nicht von hause aus, wenn eigentlich sollte die Smartcard ja den "PrivateKey" errechnen und nur den passenden PublicKey zur Signierung bereitstellen. Mit ein paar Änderungen können sie aber einen Import von privaten Schlüsseln aktivieren, wenn die Smartcard dies erlaubt:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Smart Card Crypto Provider]
"AllowPrivateSignatureKeyImport"=dword:00000001
"AllowPrivateExchangeKeyImport"=dword:00000001

Der Import muss dann natürlich per Certutil erfolgen. Es gibt keine GUI oder MMC.

certutil -user -csp "Microsoft Base Smart Card Crypto Provider" -importpfx <pfxdatei> -p <PFX-password> -v

Das Kennwort kann auch entfallen. Dann werden Sie danach interaktiv gefragt.

Cloud-Anmeldung

Wenn der Benutzer aber sein Kennwort nicht mehr kennt, weil es ein Skript regelmäßig oder der Domain Controller bei der Anmeldung ändert, dann kann ADSync mit Password Hash Sync (PHS) zwar ein Kennwort synchronisieren, aber der Anwender kann damit nichts anfangen. Er kann sich ja nicht anmelden. Auch Pass Through Authentifizierung (PTA) hilft nicht weiter, da auch hier die Cloud die Credentials erwartet und durch den lokalen DC verifizieren lässt.

Nach meinem Kenntnisstand kann Microsoft 365 und Office 365 nicht direkt eine Anmeldung per Smartcard unterstützen. Aber das ist auch nicht erforderlich, denn mit "Modern Auth/Oauth/SAML" kann die Cloud einen entsprechend kompatiblen Client ja zu einem OAUHT/SAML-Server schicken, der dann die Anmeldung per Smartcard ausführt und dann ein Ticket ausstellt, welches von der Cloud akzeptiert wird. Genau genommen muss der Client auch "nur" ein Primary Refresh Token" oder TGT bekommen, um sich in der Folge weitere Zugriffstokens zu besorgen.

Nach meinem Kenntnisstand kann ein Client sich per Smartcard nur mit einem selbst betriebenen ADFS-Service authentifizieren.

Aktuell habe ich noch keine Information vorliegen, wie sich ein Client an der Cloud allein über den EVOSTS-Service (login.microsoftonline.com) per Smartcard anmelden kann.

Weitere Links