Benutzerzertifikate im AD

Mit der Installation einer "Active Directory"-Integrierten Zertifizierungsstelle werden nicht nur in der Configuration-Partition einige Einträge angelegt, sondern Benutzer und Computer können sich mit entsprechenden Berechtigungen Zertifikate anfordern und erhalten diese zur Ablage im eigenen Zertifikatsspeicher. Zudem wird die Zertifizierungsstelle zumindest auf allen Domänen Mitgliedern automatisch als "Vertrauenswürdig" addiert. Aber das ist nur ein Teil der Integration. Sehr viel interessanter wird es, wenn die Zertifikate auch an die Benutzer und Computerobjekte angehängt werden und per LDAP von anderen Anwendern erfragt werden können.

Bitte erstellen Sie ein Konzept, wie sie mit Zertifikaten im AD umgehen. Die Veröffentlichung kann dazu führen, dass andere Personen Informationen verschlüsselt versenden und die Firma, Virenscanner etc. diese nicht mehr einsehen können. Geht er dazu gehörige private Schlüssel verloren sind die Informationen nicht mehr zugreifbar ! -> Stichwort Key Recovery

Outlook nutzt das globale Adressbuch und dieses basiert auf dem Active Directory. Wer nun mit SMIME und einer Zertifizierungsstelle arbeitet, kennt die Funktion, die Benutzerzertifikate im Active Directory zu hinterlegen. Diese Seite möchte diese Besonderheit beschreiben, da es aus meiner Erfahrung hier oft zu Problemen kommen kann, z.B.:

  • Verschlüsselte Mails können nicht gelesen werden
    Wenn der Benutzer z.B. seinen "privaten Schlüssel" für ein Zertifikat verliert (z.B.: neuer PC ohne Datenübernahme), dann wissen das die anderen Anwender ja nicht und können immer noch Mails mit dem dazu gehörigen PublicKey senden
  • Warnungen im Eventlog
    Der OAB-Prozess (Exchange Offline Adressbuch) erstellt jede Nacht das Adressbuch und dabei werden natürlich auch die Zertifikate addiert. Ich habe es schon mehrfach gesehen, dass abgelaufene Zertifikate hier zu Warnungen führen.

Das sind nur zwei Beispiele. Vielleicht haben Sie ja noch mehr.

Sicherheit der Daten hier ?
Im Active Directory sind immer nur die Zertifikate (PublicKey und Bestätigung der ausstellenden CA) hinterlegt. Der privaten Schlüssel ist nicht Bestandteil dieser Information. Insofern ist es aus Sicherheitsaspekten unkritisch, wen ich hier einfach mal produktive Daten meines Accounts bei Net at Work verwende. Allerdings kann ich nicht garantieren, dass ich dazu auch noch die privaten Schlüssel habe. Wenn sie "verschlüsseln" wollen, dann sende ich ihnen gerne einen offiziellen Public Key.

Zertifikate beim Benutzer

Starten Sie einfach einmal die "MMC für Benutzer und Computer" und aktivieren Sie die erweiterte Ansicht. Und schon finden Sie beim Benutzer eine weitere Karteikarte "Veröffentlichte Zertifikate"

Ich habe also schon mindestens drei Zertifikate im AD hinterlegt, die für EFS genutzt werden können. Die ist z.B. erforderlich, wenn ich eine Datei auf dem Dateiserver "verschlüsselt "ablegen will und mehrere Personen darauf Zugriff haben. Dann muss EFS den Key, mit dem die Datei per symmetrisch verschlüsselt ist, ja mit dem öffentlichen Schlüssel aller berechtigten Benutzer verschlüsselt mit anhängen.

Der Platz im AD

Die Zertifikate werden beim Benutzer im Active Directory gespeichert. Insofern ist ADSIEDIT ein einfacher Weg, diese Informationen zumindest einmal zu betrachten. Im Feld "UserCertificate" (multivalued Octed String) finden Sie die Zertifikate in binärer Schreibweise:

ADSIEdit Ansicht

Zertifikate "lesen" mit LDIFDE

In der Form können Sie als Administrator natürlich nicht überprüfen, welche Zertifikate da nun wirklich enthalten sind. Aber mit ein paar Schritten, können Sie die Daten "lesbar" machen.

Zuerst exportieren wir das Feld des entsprechenden Benutzers mittels LDIFDE

ldifde -f fccert.ldf -d "CN=Carius\, Frank,OU=Technik,OU=Abteilung,DC=netatwork,DC=de" -l Usercertificate

Die resultierende Datei hat dann folgenden Aufbau. (Gekürzt)

dn: CN=Carius\, Frank,OU=Technik,OU=Abteilung,DC=netatwork,DC=de UserCertificate:: 
 MIIFoTCCBImgAwIBAgIKFR08TgAAAAAA5zANBgkqhkiG9w0BAQUFADA/MRIwEAYKCZImiZPyLGQBGR
 YCZGUxGTAXBgoJkiaJk/IsZAEZFgluZXRhdHdvcmsxDjAMBgNVBAMTBW5hd2NhMB4XDTA5MDMxMzE3
 MDkyN1oXDTEwMDMxMzE3MDkyN1owbTESMBAGCgmSJomT8ixkARkWAmRlMRkwFwYKCZImiZPyLGQBGR
 YJbmV0YXR3b3JrMRIwEAYDVQQLEwlBYnRlaWx1bmcxEDAOBgNVBAsTB1RlY2huaWsxFjAUBgNVBAMT
 DUNhcml1cywgRnJhbmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALffjBiG2J9JaAoHeCmCZA
 5brXpa2IeykfdWryQH6g52Q9tw8UnEY79vV+5J3Z1rNDUAU1o+GxkTS5GFyu5iW/HQu/NB5gPsxfSA
 dl3enXfjMoU0YijLzpDNdeQiHggolBIKXVJ3DoFiIA9x+66+hhrmI8CiYa9M7mKehwz6SbX9AgMBAA
 GjggLzMIIC7zALBgNVHQ8EBAMCBSAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYI
 KoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBT8lw2By7bRuTZtg8bmbE
 AiVnaF7DAVBgkrBgEEAYI3FAIECB4GAEUARgBTMB8GA1UdIwQYMBaAFLkRKrfd7Ov2omJCSgHn3HdY ucpZMIHuBgNVHR8EgeYwgeMwgeCggd2ggdqGga5sZGFwOi8vL0NOPW5hd2NhLENOPW5hd3N2MDEwLE
 NOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0
 aW9uLERDPW5ldGF0d29yayxEQz1kZT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZW
 N0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9UUG9pbnSGJ2h0dHA6Ly9uYXdjYS5uZXRhdHdvcmsuZGUvcGtp
 L25hd2NhLmNybDCCAQMGCCsGAQUFBwEBBIH2MIHzMIGlBggrBgEFBQcwAoaBmGxkYXA6Ly8vQ049bm
 F3Y2EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZp
 Z3VyYXRpb24sREM9bmV0YXR3b3JrLERDPWRlP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz
 1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MEkGCCsGAQUFBzAChj1odHRwOi8vbmF3Y2EubmV0YXR3b3Jr
 LmRlL3BraS9uYXdzdjAxMC5uZXRhdHdvcmsuZGVfbmF3Y2EuY3J0MBUGA1UdJQQOMAwGCisGAQQBgj
 cKAwQwNAYDVR0RBC0wK6ApBgorBgEEAYI3FAIDoBsMGWZyYW5rLmNhcml1c0BuZXRhdHdvcmsuZGUw
 DQYJKoZIhvcNAQEFBQADggEBAAS3zS8jfQ59g9pbbFAgtsFeuoql6Brj9/VB9C7H/LDcAmcMRvUdH6
 JyE7nY4q1BUaCEpommrWG1Gc8XaLgTykjyMipaCf2M+kFBNnFio0DzHIDeo8vGps3KKmdGxmL2P725
 pHMl48JoGiZvxUXP5PTJoVxnVFHNP6EQg1+v87E4JLVIBdRNbCC8+cT23RKRTgUyw0mzOkqOXX/5qY
 nPhQaZ9G1Q2YRM4G6wGXtdq4s3Vn9pUMHRIjsH7fsla1/CyYJvBnbjby5tsN8Dwh9YIKd+ioG26IXE
 yDzTJ45vYb4oqnSVnXywfYQyO2WBC45r1YBn8Sus2/26q4Z66feLTY8= UserCertificate:: 
 MIIFjjCCBHagAwIBAgIKPKWE7gAAAAAAwzANBgkqhkiG9w0BAQUFADA/MRIwEAYKCZImiZPyLGQBGR
 YCZGUxGTAXBgoJkiaJk/IsZAEZFgluZXRhdHdvcmsxDjAMBgNVBAMTBW5hd2NhMB4XDTA4MDkxMjA3
 MjQxNVoXDTA5MDkxMjA3MjQxNVowbTESMBAGCgmSJomT8ixkARkWAmRlMRkwFwYKCZImiZPyLGQBGR
 YJbmV0YXR3b3JrMRIwEAYDVQQLEwlBYnRlaWx1bmcxEDAOBgNVBAsTB1RlY2huaWsxFjAUBgNVBAMT
 DUNhcml1cywgRnJhbmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL4/T8JCjSKwZc4IiplxWS
 5s725QbueJXu4lKCGCX20iwd26/drnv2d4DwggAl90g9p/flbPnV7PTf/mIQKgIyoAW3Z+9uq8jjHX
 4iFX4Ci4RQWmECaxtlBK5soJp1UN0xMGq0WJ2c5kAfx2aXuOZHKtVpmlEEFE+CJps2rHArirAgMBAA
 GjggLgMIIC3DALBgNVHQ8EBAMCBSAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODANBggq
 hkiG9w0DBAIBODAHBgUrDgMCBzAVBgkrBgEEAYI3FAIECB4GAEUARgBTMBUGA1UdJQQOMAwGCisGAQ
 QBgjcKAwQwLwYDVR0RBCgwJqAkBgorBgEEAYI3FAIDoBYMFGZjYXJpdXNAbmV0YXR3b3JrLmRlMB0G
 A1UdDgQWBBR3q6QHlR3ycnKWGNpdqlPTdZtLdTAfBgNVHSMEGDAWgBS5ESq33ezr9qJiQkoB59x3WF
 HKWTCB7gYDVR0fBIHmMIHjMIHgoIHdoIHahoGubGRhcDovLy9DTj1uYXdjYSxDTj1uYXdzdjAxMCxD
 Tj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdG
 lvbixEQz1uZXRhdHdvcmssREM9ZGU/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj
 dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hidodHRwOi8vbmF3Y2EubmV0YXR3b3JrLmRlL3BraS
 9uYXdjYS5jcmwwggEDBggrBgEFBQcBAQSB9jCB8zCBpQYIKwYBBQUHMAKGgZhsZGFwOi8vL0NOPW5h
 d2NhLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maW
 d1cmF0aW9uLERDPW5ldGF0d29yayxEQz1kZT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9
 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBJBggrBgEFBQcwAoY9aHR0cDovL25hd2NhLm5ldGF0d29yay
 5kZS9wa2kvbmF3c3YwMTAubmV0YXR3b3JrLmRlX25hd2NhLmNydDANBgkqhkiG9w0BAQUFAAOCAQEA
 XJJodFiPNpDqsE0uEBXGynv9XmywsKQite7rizTlx9g7SacWVAX+51yLB0qSNk3w9l+21EDVVsOBps
 tIhYa8x13rSv0hOdsV2Ye+cT2od0NSJ+r7xhhsypF1fiDSb4OcLJX53WcnN4ffVNSrcC0ETzyyg7X+ utPRLuaWbfZnbGS+5rE46FOGFHsEnSAr6CgifP8hSnbY5gSCwMCE4TAqVa49sgeJNw3atZN8Fj3iuB
 yJ3m1mRBODvGgDptmg+3heAGELNdMRJXl1tDNyzgBt/gpRDsdI77w9M0UMjwuybaki6PeEFzmX0CIk
 IQYra1YQcJFQYv41bEHxMVoocIGFGA== UserCertificate:: 
 MIIGBjCCBO6gAwIBAgIKGIMoUQAAAAAAvTANBgkqhkiG9w0BAQUFADA/MRIwEAYKCZImiZPyLGQBGR
 YCZGUxGTAXBgoJkiaJk/IsZAEZFgluZXRhdHdvcmsxDjAMBgNVBAMTBW5hd2NhMB4XDTA4MDcyNjIz
 NDAzOVoXDTA5MDcyNjIzNDAzOVowgZcxEjAQBgoJkiaJk/IsZAEZFgJkZTEZMBcGCgmSJomT8ixkAR
 kWCW5ldGF0d29yazESMBAGA1UECxMJQWJ0ZWlsdW5nMRAwDgYDVQQLEwdUZWNobmlrMRYwFAYDVQQD
 Ew1DYXJpdXMsIEZyYW5rMSgwJgYJKoZIhvcNAQkBFhlmcmFuay5jYXJpdXNAbmV0YXR3b3JrLmRlMI
 GfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzzf3ROwrSv9P+GRyxj2e1BtzK/kiFk5bu9TnT4I+f
 cKQ61urTo1KhqJLoCmntnxQLLn9uKtfpr6Iro/NsAM04NDV0o1SOhC899FxjFgZE78/YEysYBg1f4D
 Cydc5SQHTPyPflHzk5+dBH++4AYkkAggUvVNQQJ3P+Dew2QpCIIwIDAQABo4IDLTCCAykwHQYDVR0O
 BBYEFJEUtPLA+m6XABc9qk3YSMlhmEVhMB8GA1UdIwQYMBaAFLkRKrfd7Ov2omJCSgHn3HdYUcpZMI
 HuBgNVHR8EgeYwgeMwgeCggd2ggdqGga5sZGFwOi8vL0NOPW5hd2NhLENOPW5hd3N2MDEwLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLE
 RDPW5ldGF0d29yayxEQz1kZT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh
 c3M9Y1JMRGlzdHJpYnV0aW9UUG9pbnSGJ2h0dHA6Ly9uYXdjYS5uZXRhdHdvcmsuZGUvcGtpL25hd2
 NhLmNybDCCAQMGCCsGAQUFBwEBBIH2MIHzMIGlBggrBgEFBQcwAoaBmGxkYXA6Ly8vQ049bmF3Y2Es
 Q049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYX
 Rpb24sREM9bmV0YXR3b3JrLERDPWRlP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0
 aWZpY2F0aW9uQXV0aG9yaXR5MEkGCCsGAQUFBzAChj1odHRwOi8vbmF3Y2EubmV0YXR3b3JrLmRlL3
 BraS9uYXdzdjAxMC5uZXRhdHdvcmsuZGVfbmF3Y2EuY3J0MBcGCSsGAQQBgjcUAgQKHggAVQBzAGUA
 cjAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIFoDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQ
 cDBAYIKwYBBQUHAwIwSgYDVR0RBEMwQaAkBgorBgEEAYI3FAIDoBYMFGZjYXJpdXNAbmV0YXR3b3Jr
 LmRlgRlmcmFuay5jYXJpdXNAbmV0YXR3b3JrLmRlMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAw
 ICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQUFAAOC
 AQEAKk+8I4yoKJQSZS7OiFQZRA4D+maOVEJEQf8DmE+ZXeY76ouPd+20m5A9JVqrXtj0bpy+mdOvUB
 9hxTsbJBVjcQJxZOSq3dJFY8pgLSpoobm0lAM1I2SYWy9yIK7gOzbcO+1K0yANQiKOsiYhHfiCi1JP
 AoL3ceoT4ex8co6Xar97tPBkqkOVNwQXRpT4brwo26chSd2CUF6oAmj5LoY4M/cLtWYtiAaA/tWlhF
 wYr77qWm3njdKnMFC0nb6GSXHeYd9f7bd+W70I0U2598TyOfzCKWW5icUCNjCJOKHTSgUyL8QME2Dy
 ybhqi/k/Y3PS4vVEriEIujP7dDcIR0yCqQ==

Mit etwas Phantasie erkennen Sie, dass jeder dieser drei Blöcke mit einem "MII" anfängt und einem "==" endet. Da sollte bei ihnen automatisch die "BASE64"-Lampe angehen. Die Daten sind BASE64 (MIME) codiert, wie jedes normale Zertifikat auch. Also extrahieren wir einfach einen der Bausteine per NOTEPAD und speichern ihn als "CER-Datei ab." für Windows ist es nicht erforderlich, am Ende und am Anfang noch die Begrenzungsmarkierungen einzufügen:

-----BEGIN CERTIFICATE-----
 MIIGBjCCBO6gAwIBAgIKGIMoUQAAAAAAvTANBgkqhkiG9w0BAQUFADA/MRIwEAYKCZImiZPyLGQBGR
...
 ybhqi/k/Y3PS4vVEriEIujP7dDcIR0yCqQ==
-----END CERTIFICATE-----

Sie können dies aber dennoch tun um die Datei z.B. mit OpenSSL weiter zu bearbeiten. Die CER-Datei selbst können Sie nun einfach wieder im Explorer doppelt anklicken und schon sehen Sie das Zertifikate mit allen Details:

Alles gar nicht so schwer, wenn man die Schritte in der richtigen Reihenfolge durchführt.

Zertifikate "lesen" mit PowerShell

Vielleicht habe ich zukünftig die Gelegenheit, den Prozess des Exports und Imports per Skript zu automatisieren. Bis dahin soll ein kleiner PowerShell-Schnipsel reichen, um Sie neugierig auf PowerShell zu machen. So einfach kommt man hier an solche Daten heran

# Binden des Users per LDAP
$User = [adsi]"LDAP://CN=Administrator,CN=Users,DC=msxfaq,DC=net"

# Anzeige der Anzahl der Zertifikate
$User.UserCertificate.count
2

# Export des ersten Zertifikats als Datei
[system.io.file]::WriteAllbytes("c:\temp\cert.der",$User.UserCertificate[0])

Zertifikate schreiben mit PowerShell

Im Rahmen der Entwicklung für CSV2EX habe ich auch User-Zertifikate im DirSync mit übertragen wollen. Ich habe einige Zeit gekämpft, um die Zertifikate über eine CSV-Datei auch in das Ziel zu bekommen.

Zuerst muss man wissen, dass Zertifikate im Active Directory-Feld "UserCertificate" binär gespeichert werden und dass ein Objekt durchaus mehrere Zertifikate haben kann. Entsprechend ist das Feld auch noch ein "MultiValue"-Feld.

Mittels CSVDE kann ein Admin solche Zertifikate auch in einer CSV-Datei exportieren. Im Textfeld starten diese binären Felder dann mit "X'xxxx' und wenn es sogar ein Array ist, dann sind die Felder durch ein ";" getrennt. Hier mal eine gekürzte Version:

DN,displayName,UserCertificate,mail
"CN=User1,ou=csv2ex,dc=msxfaq,dc=de",User1,X'30820...33f4';X'3082...e41e',User1@msxfaq.net

Ein Skript muss also zuerst die Felder nach dem Start "X'" durchsuchen, um dann noch nach ";" zu schauen, ob es noch ein Array ist. Ich bin dann den Weg gegangen, solche besonderen Felder über eine Parametrisierung zu kennzeichnen anstatt zu "erraten", was drin sein soll. Aufgefallen ist mir dabei aber wieder mal, dass PowerShell und "Type Cast" einige böse Fallen stellen können. Wenn eine Funktion ein "[byte[]]" zurück übergibt, kommt bei der aufrufenden Funktion aber ein generisches custom object an, wenn die Rückgabe nicht ebenfalls mit einem "[byte[]]" als Präfix versehen wird. Auch muss man den Wert mit PutEx schreiben, da es ein Array ist.

Zertifikate in das Active Directory importieren

Nun muss man ja nicht immer eine Windows CA einsetzen, die die Benutzerzertifikate selbst direkt in das Active Directory schreibt. Sie wissen ja nun, in welchem Format ein Zertifikat im Active Directory hinterlegt ist. Damit können Sie dann natürlich jedes beliebige Zertifikat im Active Directory veröffentlichen. Sie benötigen einfach die CER-Datei für den Import. Sie können Zertifikate an Benutzer, Computer und einige andere Objekte anfügen. Allerdings macht es nicht mit jedem Objekt Sinn.

Ehe Sie nun aber per LDIFDE oder ADSI anfangen, Zertifikate als Base64 oder HEX-codierte Werte anzufügen, sollten Sie einen Blick auf das Programm CertUtil werfen, welches sowohl bei der Installation einer WindowsCA mit installiert wird aber auch als losgelöstes Programm in dem Adminpack enthalten ist. neben vielen anderen Funktionen kann man damit sehr einfach eine CER-Datei an ein LDAP-Objekt anfügen.

certutil -dspublish "<pfad und name der cer-datei>" "LDAP:///<dn des LDAP-Objects>"

Beachten Sie die "drei" "///" hinter dem LDAP !

Zertifikate von Benutzern oder Kontakte, die in Exchange aktiviert sind, werden übrigens auch in das Outlook Offline Adressbuch übertragen und sind auch per OWA erreichbar. Zudem können Sie Zertifikate auch an Kontakte anfügen. Damit ist es sogar möglich, die Kontakte und Zertifikate von anderen Exchange Organisationen z.B. im Rahmen eines Abgleich der Verzeichnisinformationen auszutauschen.

Über den Weg war es mir bislang nicht möglich, ein Zertifikat an ein Computerobjekt zu addieren. Aber dafür gibt es dann den "-addstore" Befehl.

certutil -addstore "LDAP:///CN=ipad,OU=8021xdevice,DC=msxfaq,DC=de?Usercertificate" .\ipad.cer

Hinweis:
Für die Anmeldung per 802.1x ist es nicht erforderlich, dass Zertifikat bei dem Computer oder Benutzerobjekt im AD zu hinterlegen. Der Radius-Server muss aber anhand des SAN:DNS-Eintrags ein passendes Objekt im AD über den SPN finden um dann die Gruppenmitgliedschaften und sonstigen RADIUS-Berechtigungen zuordnen zu können. Siehe auch 802.1x

Das ist für 802.1x z.B.: interessant, wenn Geräte ein Zertifikat über einen anderen Weg bekommen.

Darf der Benutzer selbst ein Zertifikat in das Active Directory importieren ?

Natürlich kann nicht jeder bei einem Konto Zertifikate hinterlegen. Eine kurze Kontrolle zeigt, dass der Benutzer selbst seine Zertifikate nur lesen kann. Es ist also die Definition im Template, welches eine AD-integrierte Zertifizierungsstelle anweist, das Zertifikat (natürlich ohne privaten Schlüssel) an das Objekt zu schreiben, damit z.B. Outlook eine E-Mail per SMIME verschlüsseln kann.

Administratoren dürfen natürlich die Zertifikate auch schreiben. Sie können über eine entsprechende Delegierung natürlich diese Arbeit auch an ein Dienstkonto oder ein Programm abgeben. Vermeiden Sie aber, diese Daten per ADSIEDIT o.ä. zu schreiben. CERTUTIL ist hierzu viel besser geeignet. (Siehe weiter oben im Dokument)

Zertifikate mit Outlook verwalten

Am Beispiel von Outlook 2003 können Sie aber auch sehen, dass Benutzer selbst Zertifikate im Active Directory veröffentlichen können. In den Outlook Optionen finden Sie den Punkt, um vorhandenen lokale Zertifikate in der GAL zu veröffentlichen. Genaugenommen werden die Zertifikate natürlich im Active Directory veröffentlicht, von dem sich dann die GAL ableitet.

In Outlook 2016 sind die Einstellungen im Trust Center zu finden:

Hier können Sie auch direkt Zertifikate aus einer PFX-Datei importieren und exportieren. Bei früheren Versionen mussten Sie das Zertifikat mit dem privaten Schlüssel erst in ihrem persönlichen Zertifikatsspeicher importieren. Outlook hat dann von dort das Zertifikat, d.h. den signierten PublicKey, an ihre Benutzerobjekte im Active Directory importiert.

Sollte, warum auch immer, auf einem PC der private Key nicht vorliegen, dann können Sie das veröffentlichte Zertifikat auch wieder löschen. Wenn Outlook das bemerkt, könnten Sie bei Outlook 2003 z.B. folgende Meldung sehen:

Und mit dem Schritt wird das Zertifikat dann wirklich auch entfernt:

Dies aber ist eine wichtige Funktion, da sie beim Verlust des privaten Schlüssels (z.B. Verlust des Profiles oder PCs) natürlich dafür sorgen müssen, dass niemand ihnen noch verschlüsselte Mails mit diesem Public Key sendet. Der korrekte Weg dies zu verhindern ist ein "Revoke" des Zertifikats. So bekommen auch ihre externen Kommunikationspartner mit, dass das Zertifikat nicht mehr genutzt werden soll.

Weitere Links