Jump to content

mchluba

Members
  • Gesamte Inhalte

    5
  • Registriert seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von mchluba

Rookie

Rookie (2/14)

  • Erste Antwort
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei
  • 1 Jahre dabei

Neueste Abzeichen

0

Reputation in der Community

  1. 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
  2. Bisher war nicht ein Versuch erfolgreich, egal welche Herangehensweise, die AD Anmeldung findet immer statt obwohl sie blockiert werden sollte.
  3. 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.
  4. Danke für die schnelle Antwort. Muss das ganze zwingend per HTTP passieren oder geht das auch über ein SMB-Freigabe im Netzwerk?
  5. 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!
×
×
  • Neu erstellen...