AutoEnroll

Windows Zertifizierungsstellen erlauben ein automatisches Enrollment von Zertifikaten. Diese an sich ganz nette Funktion erlaubt es z.B., dass Domänenbenutzer oder Computer automatisch ein Zertifikat bekommen um sich per 802.1x am Switch oder oder WIFI-AccessPoint anzumelden. Allerdings kann dies auch "nach hinten" los gehen, wenn die Clients dann damit unkontrolliert Dateien per EFS oder Mails per SMIME verschlüsseln und Sie als Administrator sich nicht über ein "Key Recovery" Gedanken gemacht haben.

Das Problem mit OAB

Ein Problem wird den meisten Administratoren erst dann offenbar, wenn bei der Generierung des Exchange Offline Adressbuchs plötzlich Fehler erscheinen:

Oder als Text-Auszug, damit die Suchmaschinen das auch finden können.

Ereignistyp: Fehler
Ereignisquelle: MSExchangeSA
Ereigniskategorie: OAL-Generator
Ereigniskennung: 9321
Beschreibung:
OALGen konnte für den Eintrag 'Administrator' keine vollständigen Detailinformationen erstellen, weil die Gesamtgröße der Detailinformationen größer als 64 KB ist.

Bei der Suche nach diesem Fehler ist dann aufgefallen, dass dieser Benutzer "sehr viele" Zertifikate hatte

Per ADSIEDIT kann ich das Feld ebenfalls anzeigen lassen:

Ein Zertifikat ist je nach Schlüssellänge in der Regel 1-4kByte lang, so dass bei vielen "Versuchen" mit Zertifikaten schnell die 64kbit Grenze für das Offline Adressbuch erreicht ist.

Beschränken Sie AutoEnrollment
Sie sollten ein "wildes" AutoEnrollment rechtzeitig in die Grenzen weisen. Zertifikate für die Authentifizierung von Computern sind für alle sinnvoll, Webserver Zertifikate für die Benutzer, die auch Webserver verwalten aber SMIME-Zertifikate sollten vielleicht nicht per AutoEnroll verteilt werden.

Das viel kritischere Problem

Nun könnten Sie sagen, dass die internen Zertifikate ja nichts kosten aber das ist etwas kurz gedacht. Stellen Sie sich mal vor, sie sind ein Anwender, der sich an mehreren PCs anmeldet und jeder PC fordert nun für den Anwender ein eigenes Zertifikat an. Am Ende sind ihnen als Benutzer im Active Directory mehrere Zertifikate zugeordnet, die für SMIME und andere Zwecke genutzt werden können. Viel unangenehmer ist aber, dass zu jedem Zertifikat Auch ein "Private Key" gehört und auf jedem PC ist ein eigener Key. Das kann dazu führen, dass ihnen jemand eine Mail verschlüsselt sendet und Sie diese nur auf genau dem einem PC lesen können, auf dem auch der passende private Schlüssel dazu vorliegt.

Sie müssen also zum einen dafür sorgen, dass jeder Benutzer am besten immer nur ein Zertifikat hat, welches nach Ablauf auch einfach verlängert wird und dass diese Zertifikat mit dem Benutzer "mitzieht". Dazu gibt es gleich mehrere Optionen:

  • Roaming Profiles
    Wenn Sie das Benutzerprofil als "Roaming Profiles" auf dem Server ablegen, dann wird auch der "Protected Store" als Bestandteil des Zertifikats auf den Server übertragen und bei der nächten Anmeldung auf einem anderen System wieder herunter geladen. Achten Sie hierbei aber auf die unterschiedlichen Profile beim Einsatz von Desktops und Terminal Server
  • Smartcard oder anderer Zertifikatspeicher
    Alternativ können Sie die Zertifikate natürlich gleich aus dem Profil in einen anderen "geschützten Speicher" anlegen lassen. Dazu eignen sich sich natürlich Smartcards und andere Hilfsmittel
  • PFX Export/Import
    Zuletzt kann der Anwender natürlich selbst "seine" Zertifikate mit den Windows Bordmitteln exportieren und manuell wieder importieren.

In allen Fällen müssen sie aber sicherstellen, dass die "AutoEnroll"-Funktion nicht schon Zertifikate anfordert, wenn sich der Mitarbeiter das erste Mal an einem Client anmeldet und seine eigenen Zertifikate noch nicht importiert sind.

AutoEnrollment steuern

Damit AutoEnrollment funktioniert, müssen mehrere Dinge zusammenpassen.

  • Einstellung des Templates

    Wenn Sie eigene Templates anlegen oder bestehende ändern wollen, dann benötigen Sie eine CA auf Windows Enterprise Server.
  • Berechtigungen
  • Dubletten vermeiden
    Wie sie im vorigen Kapitel schon gesehen haben, sollte ein Anwender nur genau ein Zertifikat haben und ein Auto-Enrollment nicht dazu führen, dass ein Konto sehr viele Zertifikate anfordern kann. Eine entsprechende Einstellung in den Templates erlaubt auch dies:

    Mit dieser Einstellung sollte es möglich sein, dass die CA das Ausstellen eines Zertifikats verhindert, wenn im Active Directory schon ein gleichartiges Zertifikat hinterlegt ist.
    Etwas irritiert bin ich, dass ich per manueller Anforderung per WebGUI immer noch mehrfache Zertifikate erhalten kann. Es scheint sich also nur auf "AutoEnroll" auszuwirken.

Das sind dann natürlich auch die Hebel, über die ein Administrator diese Funktion steuern kann und z.B. nur bestimmte Vorlagen für "AutoEnrollment" zulässt und selbst hier noch über Sicherheitsgruppen geht.

Enrollment Prozesse ohne Automatik

Wenn ihnen diese Automatik nun suspekt ist und sie doch lieber als CA-Administrator anstehende Zertifikatanforderungen für wichtige Zertifikate (z.B. SMIME) erst von Hand freigeben wollen, dann ist dies natürlich möglich. Eine passende Änderung der Berechtigung an den Vorlagen erlaubt, dass die Anwender ein Zertifikat zwar anfordern aber ein CA-Admin dieses erst nach einer Prüfung ausstellen muss.

Kleiner Tipp: Sie können ihre CA so einstellen, dass ausstehende Anforderungen ihnen per Mail zugesendet werden.

certutil -setreg exit\smtp\smtpserverServerName
certutil -setreg exit\smtp\CRLIssued\To caadmin@firma.tld
certutil -setreg exit\smtp\CertPending\To caadmin@firma.tld
certutil -setreg exit\smtp\Startup\To caadmin@firma.tld
certutil -setreg exit\smtp\Shutdown\To caadmin@firma.tld

Alternativ könnte mal geprüft werden, ob die Ausstellung nach Ablauf einer Wartezeit auch automatisch z.B. per Skript erfolgen könnte. Hierzu konnte ich aber noch keine weiteren Experimente durchführen.

AutoEnroll und Dienste

Wenn auf dem Computer schon ein Zertifikat landet, dann ist es natürlich interessant zu wissen, wie die Clients ihre Bindung aktualisieren.

Habe habe noch nicht geprüft ,wie sie die Produkte bei einem Renew statt einer Neuausstellung verhalten. Wer sich an den Thumbprint hängt, kann ein verlängertes Zertifikat nicht automatisch nutzen. Wer sich nur am private Key oder am CN orientiert, kann einen

Dienst Hinweise

Netzwerk 802.1x

Der Windows Client nutzt alleine ein passendes Zertifikat. Die Gegenseite liefert ja die Liste der RootCAs, von der das Zertifikat ausgestellt sein muss.

IIS

Die Bindung des IIS/HTTP.SYS ist meines Wissens statisch, d.h. sie müssen ein getauschtes Zertifkat manuell binden

Exchange

Nutzt das "beste passende" Zertifikat für seine Connectoren aber nicht die Webseiten

RDPHost

Nutzt er alleine, wenn Sie das Template per GPO festlegen

 

 

 

Weitere Link

  • Private Key
  • Private und öffentliche Schlüssel
  • 322607 PRB: CAPICOM 1.0 kann nicht mit CAPICOM 2.0 verschlüsselte Daten entschlüsseln.
  • 318215 How To Create a Multipart SMIME Signature by using CAPICOM and CDO
    Mit SampleCode
  • 555894 How to remove a trusted Certificate Authority from computers in the domain
    Samplecode von MVP mit VBScript ud CAPICOM
  • 935432 A Windows XP-based portable computer cannot use the Wireless Zero Configuration service to connect to a wireless network
    SampleCode mit CAPICOM
  • 947237 The autoenrollment functionality fails when a Windows Vista-based computer uses version 2 (V2) certificates
  • Example C Program: Setting and Getting Certificate Store Properties
    http://msdn.microsoft.com/en-us/library/aa382369(VS.85).aspx
  • Importing and Exporting Protected Configuration RSA Key Containers
    http://msdn.microsoft.com/en-us/library/yxw286t2(VS.80).aspx