Smartcardzertifikat sperren?

[mchluba 0]

Hallo und danke für die Aufnahme in eurem Forum,

ich sitze hier seit 2 Tagen vor einem Problem und finde keine passende Lösung, weder per SuFu noch mit Onkel Google.

 

Wir möchten bei uns YubiKeys zur Authentifizierung der User einsetzen. Per PIV und Zertifikatserstellung funktioniert das zertifizieren einwandfrei, ebenso ist die Anmeldung - auch über mehrere RDP-Sessions - ohne Probleme möglich.

Was ist allerdings, wenn ein User mal das Unternehmen verlassen sollte, bzw. jemand seinen Key verliert?

Ich habe hier einen YubiKey mit unserem Testaccount liegen und dieses Zertifikat gesperrt und die Sperrliste veröffentlicht, auch nach mehreren Neustarts kann sich der User ganz normal am System anmelden.

 

Was ich ebenfalls probiert habe:

certutil -urlcache * delete

 

Wenn ich das Zertifikat per certutil verify checke sagt mir auch, dass jenes Zertifikat gesperrt wurde. Über die MMC-Konsole wird es allerdings weiterhin ganz normal als "gültig" deklariert.

 

Kennt jemand die Problematik oder hat evtl. sogar einen Workaround für das schnelle sperren von Zertifikaten bzw. SmartCards?

 

Liebe Grüße aus dem Rhein-Main Gebiet!

[zahni 550]

Um ein Zertifikat zurückziehen zu können, muss der Server prüfen können, ob ein Zertifikat zurückgezogen wurde. Dazu eine per HTTP muss vom Server und Client erreichbare CRL existieren und in den Zertifikaten konfiguriert sein.

Noch effizienter und sicherer ist die Nutzung eines Online Responders, der auch von beiden Systemen erreichbar sein muss und die Lösung muss damit umgehen können. Sprich: Den Revocation-Check muss der RDP-Server machen.

 

 

 

 

[mchluba 0]

vor 1 Minute schrieb zahni:

Um ein Zertifikat zurückziehen zu können, muss der Server prüfen können, ob ein Zertifikat zurückgezogen wurde. Dazu eine per HTTP muss vom Server und Client erreichbare CRL existieren und in den Zertifikaten konfiguriert sein.

Noch effizienter und sicherer ist die Nutzung eines Online Responders, der auch von beiden Systemen erreichbar sein muss und die Lösung muss damit umgehen können. Sprich: Den Revocation-Check muss der RDP-Server machen.

 

 

 

 

Danke für die schnelle Antwort. Muss das ganze zwingend per HTTP passieren oder geht das auch über ein SMB-Freigabe im Netzwerk?

[NorbertFe 2.027]

vor 6 Minuten schrieb mchluba:

Danke für die schnelle Antwort. Muss das ganze zwingend per HTTP passieren oder geht das auch über ein SMB-Freigabe im Netzwerk?

Nö es geht auch per LDAP. Und wenn du jetzt erst überlegen musst, wie eine CRL funktioniert, könnte es schon zu spät sein.

[cj_berlin 1.306]

Moin,

das sind *zwei* Anwendungsfälle:

1. wenn der User das Unternehmen verlässt, sperre sein Account im AD. Das wirkt sich auch auf die Smartcard-Authentifizierung aus.
2. wenn er seinen Key verliert und Du wirklich nur das Zertifikat zurückziehen möchtest, muss der Domain Controller davon erfahren. Es geht also nicht um den CRL Cache auf den Clients, sondern auf den Domain Controllern.

[Dukel 451]

Wenn ein User das Unternehmen verlässt möchte man den User sperren UND das Zertifikat revoken.

 

[NorbertFe 2.027]

Sperren ist sowieso notwendig, da ein revocation check nicht zwingenderweise sofort durchgeführt wird.

[NilsK 2.930]

Moin,

 

Das Sperren eines Zertifikats ist keine sofort wirksame Sache. Der Client wird erst dann eine neue CRL anfordern, wenn die alte abgelaufen ist. Solange nutzt er die letzte, die er im Cache hat, sie ist ja noch gültig.

 

Daran ändert auch ein Online Responder nichts, weil auch der nur die CRL nutzt. Für zeitkritische Fälle braucht man also immer noch zusätzliche Mechanismen, muss also etwa den User sperren.

 

Gruß, Nils

[cj_berlin 1.306]

vor 28 Minuten schrieb NilsK:

Daran ändert auch ein Online Responder nichts, weil auch der nur die CRL nutzt. 

 

Schon, aber man kann ihn anweisen, die CRL häufiger zu ziehen als sie abläuft:

Neu ausstellen muss man sie nach Sperrung eines Zertifikats natürlich manuell

[mchluba 0]

Servus und danke für eure Antworten.

 

Die Kontosperrung ist natürlich selbstverständlich, sobald ein User das Unternehmen verlässt. 

Im Falle eines Verlustes der SmartCard möchte der Benutzer natürlich trotzdem weiterarbeiten, deswegen ist eine Kontosperrung - aufgrund einer verlorenen Smartcard - für uns aktuell keine Option.

 

Ich habe über den Befehl:

certutil -verify -urlfetch "..."

jeweils eine Prüfung auf dem Client und allen DC's durchgeführt. Trotzdessen, dass mir angezeigt wird, das Zertifikat wäre gesperrt ist eine Anmeldung jederzeit möglich. 

 

Für den Test habe ich folgendes durchgeführt:

1. Zertifikat erstellt und auf Yubikey gespeichert 

2. Testanmeldung durchgeführt (hat einwandfrei funktioniert)

3. Zertifikat gesperrt und Sperrliste veröffentlicht

4. Zertifikat gecheckt - Zertifikat war noch gültig (wie erwartet)

5. Cache gelöscht 

6. Zertifikat gecheckt - war nun gesperrt (wie erwartet)

 

Nichtsdestotrotz ist die Anmeldung ohne Probleme möglich. In unserer Testumgebung (deutlich kleineres Netzwerk) hat die Sperrung auch ohne Cache-Löschen keine 5 Minuten gedauert und die Anmeldung war nicht mehr möglich. 

 

[NorbertFe 2.027]

vor 1 Minute schrieb mchluba:

In unserer Testumgebung (deutlich kleineres Netzwerk) hat die Sperrung auch ohne Cache-Löschen keine 5 Minuten gedauert und die Anmeldung war nicht mehr möglich. 

Und wie lange dauert es in der Produktivumgebung?

[mchluba 0]

vor 14 Minuten schrieb NorbertFe:

Und wie lange dauert es in der Produktivumgebung?

Bisher war nicht ein Versuch erfolgreich, egal welche Herangehensweise, die AD Anmeldung findet immer statt obwohl sie blockiert werden sollte.

[NorbertFe 2.027]

Dann mußt du ja nur noch den Unterschied zwischen Test- und Produktivumgebung finden. ;)

 

Bye

Norbert

 

PS: In der Theorie besteht zwischen Theorie und Praxis kein Unterschied. ;) 

[NilsK 2.930]

Moin,

 

ja, so eine Problemlage tritt immer wieder auf. Man wird sich in solchen Fällen dann auch ansehen müssen, was denn wirklich passiert. Oft stellt man dabei fest, dass man sich in falscher Sicherheit wiegt, nur weil Zertifikate im Spiel sind.

 

So ist es bei vielen Anwendungen so, dass zwar die "Erstanmeldung" ein Client-Zertifikat erfordert, der eigentliche Zugriff aber auf Basis eines Tokens geschieht, dass nach der Anmeldung ausgestellt wird. Solange dieses Token gültig ist, prüft niemand mehr das Zertifikat. Da kann man es dann sperren, so viel man will. So ist das z.B. bei den allermeisten Cloud-Services, die eine Zertifikatsanmeldung erlauben. Die Anbieter (z.B. Microsoft) dokumentieren das auch, man muss aber danach suchen.

 

Auch die Möglichkeit, mit OCSP schneller auf Sperrungen zu reagieren (danke @cj_berlin für die Ergänzung), ändert daran nichts. Zudem ist bei OCSP immer zu berücksichtigen, dass der Client auf die Idee kommen muss, überhaupt nachzufragen, was dann in seinem Ermessen liegt. Und noch dazu wird für OCSP oft eine herkömmliche CRL als Fallback angeboten - ist OCSP also nicht erreichbar, nützt dessen Geschwindigkeitsvorteil auch wieder nix.

 

Es bleibt also dabei: Wenn ein Zugriff schnell entzogen werden muss, muss man eine zertifikatsbasierte Zugriffssteuerung auf jeden Fall durch weitere Mechanismen ergänzen.

 

Edit: Da in deinem Anwendungsfall auch noch eine andere Ebene durchscheint, auch dazu noch eine Anmerkung. Du sagst, dass ihr reagieren wollt, wenn jemand seine Smartcard verliert, aber nicht das Unternehmen verlässt. Hier wollt ihr euch absichern, dass nicht jemand anderes mit der gefundenen/gestohlenen Smartcard sich anmeldet. Hier wäre der korrekte Weg (neben dem Erfordernis, dass zu einer Smartcard auch ein zweiter Faktor wie eine PIN gehören sollte), das vorhandene, ggf. gesperrte Zertifikat von dem Useraccount zu trennen. Der legitime Benutzer braucht dann ja ohnehin eine neue Smartcard, also ein neues Zertifikat mit neuem Private Key. Auch hier würde dir eine schnellere Durchsetzung der Zertifikatssperrung nichts nutzen - diese kann ja erst erfolgen, wenn der Verlust bekannt ist, und sie muss manuell erfolgen. Da gehört es dann zum Prozess, das nicht mehr vertrauenswürdige Zertifikat vom Useraccount zu trennen.

 

Auch dies hilft allerdings nur für Neuanmeldungen, nicht für bestehende Sitzungen. Letztere allerdings gehören auch nicht zu dem Szenario "Smartcard verloren". Wie sich hieraus ergibt, können Smartcards immer nur ein Baustein sein, aber keine ausreichende Lösung für ... irgendwas.

 

Gruß, Nils

PS: dies sind Details, die mich dazu bringen, PKI insgesamt als "krank" zu betrachten.

bearbeitet 17. Dezember 2020 von NilsK

[mchluba 0]

Hallo Leute,

 

danke erstmal für eure Hilfe. Kleines Feedback meinerseits: Der entscheidende Tipp kam von @cj_berlin, danke schonmal hierfür!

 

Tatsächlich waren die Zertifikatsvorlagen jeweils in Produktiv- und Testumgebung gleich. Der Unterschied war nur, dass die Zertifizierungsstelle in der Produktivumgebung nicht auf dem DC eingerichtet war.

 

Nachdem das Zertifikat gesperrt wird muss auf dem DC der Befehl 

certutil -setreg chain\ChainCacheResyncFiletime @now

ausgeführt werden. Mit diesem Befehl wird eine Neusynchronisation und Überprüfung der Zertifikate und deren Eigenschaften neu angestoßen.

Im Anschluss daran habe ich ein kleines Script für den Server - welcher die Zertifikate verwaltet - gebaut.

certutil -setreg chain\ChainCacheResyncFiletime @now
net stop CertSvc
timeout 3
net start CertSvc
@Echo Skript beendet
pause

Dasselbe wird dann nochmal auf dem Server der Zertifikatverwaltung ausgeführt und der Dienst "CertSvc" neu gestartet. So konnte ich die Zertifikate binnen 1 Minute sperren.

 

Das ganze war bei einem Test 5x hintereinander zuverlässig.

 

Danke für eure Hilfe!

 

LG Marco