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:
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])
- File.WriteAllBytes-Methode
(ab NET 2.0)
https://msdn.microsoft.com/de-de/library/system.io.file.writeallbytes(v=vs.110).aspx - Understanding Byte Arrays
in PowerShell
https://seanonit.wordpress.com/2014/11/11/understanding-byte-arrays-in-PowerShell/ - Working with certificates
in PowerShell
https://seanonit.wordpress.com/2014/11/03/working-with-certificates-in-PowerShell/
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.
- 802.1x
- Manually publishing a CA
certificate or CRL into a LDAP
store
http://blogs.technet.com/b/pki/archive/2007/04/13/manually-publishing-a-ca-certificate-or-crl-into-a-ldap-store.aspx - Publish S/MIME certificates für external contacts to Active
Directory für use with Exchange
Server 2007
http://blogs.technet.com/b/exchange/archive/2008/04/23/3405402.aspx - Domain Controller
Certificate Installation
http://technet.microsoft.com/en-us/library/cc785678(WS.10).aspx
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
- Remove-Usercert
- Office 365 SMIME
- CA installieren
- IIS Zertifikat einrichten
- Clientzertifikat anfordern
- SelfSSL
- OpenSSL
- OWA und SMIME
- Sichere Mails mit S/Mime und PGP
- Free SMIME Zertifikat
Warum kostenfreie SMIME-Zertifikate nur vergiftete Angebote sind - Finger weg - Certutil
http://technet.microsoft.com/en-us/library/cc773087.aspx - Publish certificates in a foreign Active Directory forest
http://technet.microsoft.com/en-us/library/cc786746(WS.10).aspx - Configuring certificate publishing in Active Directory
http://technet.microsoft.com/en-us/library/cc736694(WS.10).aspx - 2840546 How to prevent Outlook 2010 from publishing certificates to UserSMIMEcertificate
- 822504 Outlook continues to use old certificates after you migrate from Key Management Server to Public Key Infrastructure
-
Digital Certificates Cleanup Script
https://technet.microsoft.com/en-us/library/aa996392(v=exchg.65).aspx -
Outlook S/MIME certificate selection
http://blogs.technet.com/b/pki/archive/2008/12/17/outlook-s-mime-certificate-selection.aspx -
Sync User certificates to Office 365 für S/MIME
https://technet.microsoft.com/en-us/library/dn626159(v=exchg.150).aspx -
How to access User certificate stored in active directory (AD)?
http://devblog.antongochev.net/2008/09/17/how-to-access-User-certificate-stored-in-active-directory-ad/