16
AD CS, Active Directory Certificate Services, SmartCards
Hi zusammen,
was brauche ich, um SmartCards in einer AD Umgebung zu verwenden? Bin ich mit AD CS da auf dem richtigen Weg?
Und ist es besser, einen dedizierten Server dafür zu haben? Gibt es bei AD CS auch die Möglichkeit, einen zweiten bis xten Server zur Ausfallsicherheit zu verwenden?
Oder geht auch: Haupt CS auf AD1, Backup CS auf AD2?
Habe de Ehre,
Badde
was brauche ich, um SmartCards in einer AD Umgebung zu verwenden? Bin ich mit AD CS da auf dem richtigen Weg?
Und ist es besser, einen dedizierten Server dafür zu haben? Gibt es bei AD CS auch die Möglichkeit, einen zweiten bis xten Server zur Ausfallsicherheit zu verwenden?
Oder geht auch: Haupt CS auf AD1, Backup CS auf AD2?
Habe de Ehre,
Badde
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 588208
Url: https://administrator.de/contentid/588208
Printed on: April 19, 2024 at 09:04 o'clock
16 Comments
Latest comment
Hallo,
Du kannst die CA und Zertifikate mit jeder beliebigen Lösung erstellen und verwalten (OpenSSL, xca etc.), aber ADCS ist natürlich der typische Weg in Windows-Umgebungen.
Ein hierarchischer Aufbau mit Offline-Root-CA und Issuing-CAs ist grundsätzlich anzuraten. In manchen Fällen (insbesondere wenn nur SC-Login umgesetzt werden soll) kommt es nicht darauf an, dann reicht auch eine kombinierte Root/Issuing-CA. Wenn Du aber mehrere (Issuing-)CAs betreiben willst, sollte schon deshalb die Root-CA von diesen unabhängig aufgesetzt sein.
Du kannst eine beliebige Zahl von Issuing-CAs aufsetzen. Ihre Verwendung richtet sich nach den auf ihnen freigegebenen Templates. Wenn das Aufkommen an Zertifikatanforderungen nicht zu hoch ist, muss eine CA in der Regel allerdings nicht hochverfügbar sein. Näherliegende Gründe für mehrere Issuing-CAs sind der organisatorische Aufbau und Sicherheitsaspekte, wenn Nutzer selbst Zertifikate anfordern dürfen.
Was hochverfügbar sein sollte, sind CRL-Verteilungspunkte.
Grüße
Richard
Du kannst die CA und Zertifikate mit jeder beliebigen Lösung erstellen und verwalten (OpenSSL, xca etc.), aber ADCS ist natürlich der typische Weg in Windows-Umgebungen.
Ein hierarchischer Aufbau mit Offline-Root-CA und Issuing-CAs ist grundsätzlich anzuraten. In manchen Fällen (insbesondere wenn nur SC-Login umgesetzt werden soll) kommt es nicht darauf an, dann reicht auch eine kombinierte Root/Issuing-CA. Wenn Du aber mehrere (Issuing-)CAs betreiben willst, sollte schon deshalb die Root-CA von diesen unabhängig aufgesetzt sein.
Du kannst eine beliebige Zahl von Issuing-CAs aufsetzen. Ihre Verwendung richtet sich nach den auf ihnen freigegebenen Templates. Wenn das Aufkommen an Zertifikatanforderungen nicht zu hoch ist, muss eine CA in der Regel allerdings nicht hochverfügbar sein. Näherliegende Gründe für mehrere Issuing-CAs sind der organisatorische Aufbau und Sicherheitsaspekte, wenn Nutzer selbst Zertifikate anfordern dürfen.
Was hochverfügbar sein sollte, sind CRL-Verteilungspunkte.
Grüße
Richard
Danke, Richard. Dann werde ich mich hierzu tiefer einarbeiten. Da ich bisher noch keine Berührung mit SmartCards hatte, hätte ich noch ein paar Fragen.
Macht es Sinn, den root CA auf dem ersten AD Server mitzuinstallieren, den issuing CA auf dem zweiten AD Server? Oder sollten die CA Server getrennt sein?
Und ganz doof: Kann ich dann eine 2FA Authentifizierung machen? Also, erst, wenn die SmartCard im Reader ist, die Anmeldung mit AD Passwort ermöglichen?
Es handelt sich um max. 15 Clients, die so angemeldet werden.
Badde
Macht es Sinn, den root CA auf dem ersten AD Server mitzuinstallieren, den issuing CA auf dem zweiten AD Server? Oder sollten die CA Server getrennt sein?
Und ganz doof: Kann ich dann eine 2FA Authentifizierung machen? Also, erst, wenn die SmartCard im Reader ist, die Anmeldung mit AD Passwort ermöglichen?
Es handelt sich um max. 15 Clients, die so angemeldet werden.
Badde
Hallo,
man kann das eigentlich recht einfach umsetzen. Wir nutzen Yubikeys mit unserer AD-CA. Bei Yubico gibt es eine ausführliche Anleitung unter Setting up Windows Server for YubiKey PIV Authentication
Wenn Du bisher keine CA im AD betreibst loht sich ein wenig Vorüberlegung, ggf. auch ein Trockenlauf auf einem Testsystem. Infos dazu findest Du unter z.B. openbook.rheinwerk-verlag.de/windows_server_2012r2/12_001.html#dodtp1554547c-ad02-4636-bbcc-ba16cd9c2b8f
Grüße
lcer
man kann das eigentlich recht einfach umsetzen. Wir nutzen Yubikeys mit unserer AD-CA. Bei Yubico gibt es eine ausführliche Anleitung unter Setting up Windows Server for YubiKey PIV Authentication
Wenn Du bisher keine CA im AD betreibst loht sich ein wenig Vorüberlegung, ggf. auch ein Trockenlauf auf einem Testsystem. Infos dazu findest Du unter z.B. openbook.rheinwerk-verlag.de/windows_server_2012r2/12_001.html#dodtp1554547c-ad02-4636-bbcc-ba16cd9c2b8f
Grüße
lcer
Yubikey hab ich auch schon in den Raum geworfen. Wurde allerdings abgeschmettert, da die vorhandenen SmartCards verwendet werden sollen. Auf dem key ist aber keine Möglichkeit, zusätzlich Datenspeicher zu haben? Denn USB-Sticks sind evil und dürfen nicht verwendet werden. 
Das wäre evtl. dann eine Lösung für den Rechner ohne AD Anbindung und Internetanschluß, wie ich an anderer Stelle gefragt habe.
Das Testsystem installiere ich die nächsten Wochen. Danke für die links.
Das wäre evtl. dann eine Lösung für den Rechner ohne AD Anbindung und Internetanschluß, wie ich an anderer Stelle gefragt habe.
Das Testsystem installiere ich die nächsten Wochen. Danke für die links.
Zitat von @baddeit:
Yubikey hab ich auch schon in den Raum geworfen. Wurde allerdings abgeschmettert, da die vorhandenen SmartCards verwendet werden sollen.
Da muss man dann aber auch Smartcard Reader an jedem PC haben und warten.Yubikey hab ich auch schon in den Raum geworfen. Wurde allerdings abgeschmettert, da die vorhandenen SmartCards verwendet werden sollen.
Auf dem key ist aber keine Möglichkeit, zusätzlich Datenspeicher zu haben? Denn USB-Sticks sind evil und dürfen nicht verwendet werden.
Es gibt kein Benutzervolume.Das wäre evtl. dann eine Lösung für den Rechner ohne AD Anbindung
Na ja, über die Domäne lassen sich die Zertifikate gut verteilen, ohne ist das mühsam.Das Testsystem installiere ich die nächsten Wochen. Danke für die links.
GerneGrüße
lcer
Alle CA-Server sollten getrennt vom DC sein. Eine Offline-Root-CA kann auch ein verlässlicher Desktop oder ein Laptop sein, sie läuft ja normalerweise nicht.
Smartcard-Login ist per se 2FA (Smartcard haben und PIN wissen), das ist ohne weitere Hilfsmittel ein Gegensatz zum AD-Passwort und nicht kombinierbar.
Bei dem Umfang und keiner sonstigen Verwendung der CA ist auch ein Single-Tier-Aufbau vertretbar.
Smartcard-Login ist per se 2FA (Smartcard haben und PIN wissen), das ist ohne weitere Hilfsmittel ein Gegensatz zum AD-Passwort und nicht kombinierbar.
Bei dem Umfang und keiner sonstigen Verwendung der CA ist auch ein Single-Tier-Aufbau vertretbar.
Verstehe ich das richtig? Ich installiere einen CA (wird, denke ich, eine VM) und konfiguriere meine Zertifikate/SmartCards. Diese Daten werden ins AD geschrieben und ich kann den CA anschließend runterfahren und brauch diesen eigentlich nur, wenn ein neuer Nutzer hinzugefügt werden muß bzw. eine neue SmartCard bespielt?
Da komme ich auf folgende Frage:
Wie kommt das Zertifikat/PIN auf die SmartCard? Geht das auch via CS oder AD?
Da komme ich auf folgende Frage:
Wie kommt das Zertifikat/PIN auf die SmartCard? Geht das auch via CS oder AD?
Zitat von @lcer00:
Dann wirds schon wieder interessanter. Ach, ich bestell jetzt einen für mich selber. Zitat von @baddeit:
Auf dem key ist aber keine Möglichkeit, zusätzlich Datenspeicher zu haben? Denn USB-Sticks sind evil und dürfen nicht verwendet werden.
Es gibt kein Benutzervolume.Auf dem key ist aber keine Möglichkeit, zusätzlich Datenspeicher zu haben? Denn USB-Sticks sind evil und dürfen nicht verwendet werden.
Das wäre evtl. dann eine Lösung für den Rechner ohne AD Anbindung
Na ja, über die Domäne lassen sich die Zertifikate gut verteilen, ohne ist das mühsam.
Eine Offline-Root-CA wird heruntergefahren und nur für die CRL-Abfrage (z.B. jährlich) hochgefahren (und für Updates natürlich). Eine Issuing-CA bzw. ein Single-Tier-Setup kannst Du nicht runterfahren, weil die CRL-Lebenszeit kurz ist.
Mit dieser Anleitung bekommst Du einen fehlerfreien Normalfall (Two-Tier) hin: https://www.einfaches-netzwerk.at/pki-hierachy-offline-root-ca-konfiguri ...
Wobei ein Webserver auf der Issuing-CA sicher Geschmackssache ist. Der gängigere "Normalfall" wären schon drei Server für ein Two-Tier: Offline-Root-CA, Issuing-CA und Web-Server (dieser ggf. noch HA).
Bei Single-Tier bzw. Online-Root-CA verbietet sich eigentlich die Kombination mit dem Webserver. Du kannst einen Azure Storage Account o.ä. anstelle des Webservers nehmen, oder bei dem geringen Umfang zur Not auch nur mit dem AD-LDAP als Verteilungspunkt arbeiten.
Das lässt sich stark variieren. Wenn du wirklich Server sparen willst und Gefrickel nicht scheust, kannst Du die CA auch ganz ohne Server in xca oder OpenSSL auf deinem Admin-Rechner aufsetzen. Du musst halt die CA in den Domain-Store importieren (certutil.exe -dspublish), für jeden Nutzer ein passendes Zertifikat (SC-Login Verwendungszweck, im Normalfall mit dem UPN als SAN:OtherName) ausstellen und auf die Karte schreiben und die CRL regelmäßig am konfigurierten Punkt veröffentlichen.
Der Unterschied des Servers ist, dass er die CRL selbst verwaltet und Nutzer ggf. ihre Zertifikate selbst anfordern können bzw. Du Auto-Enrollment nutzen kannst. Außerdem gibt er funktionierende Templates vor.
Grunsätzlich können Nutzer die meisten Smartcards selbst konfigurieren bzw. ein Zertifikat dafür (von ADCS) anfordern. Es ist nur häufig (z.B. bei Yubikeys) mit funktionalen Einschränkungen versehen (Hierarche von Admin-PIN, PUK und PIN, entsprechende Lockout-Regeln), sodass ich bei unter 100 Nutzern Smartcards in der Regel administrativ beschreiben und ausgeben würde.
Mit dieser Anleitung bekommst Du einen fehlerfreien Normalfall (Two-Tier) hin: https://www.einfaches-netzwerk.at/pki-hierachy-offline-root-ca-konfiguri ...
Wobei ein Webserver auf der Issuing-CA sicher Geschmackssache ist. Der gängigere "Normalfall" wären schon drei Server für ein Two-Tier: Offline-Root-CA, Issuing-CA und Web-Server (dieser ggf. noch HA).
Bei Single-Tier bzw. Online-Root-CA verbietet sich eigentlich die Kombination mit dem Webserver. Du kannst einen Azure Storage Account o.ä. anstelle des Webservers nehmen, oder bei dem geringen Umfang zur Not auch nur mit dem AD-LDAP als Verteilungspunkt arbeiten.
Das lässt sich stark variieren. Wenn du wirklich Server sparen willst und Gefrickel nicht scheust, kannst Du die CA auch ganz ohne Server in xca oder OpenSSL auf deinem Admin-Rechner aufsetzen. Du musst halt die CA in den Domain-Store importieren (certutil.exe -dspublish), für jeden Nutzer ein passendes Zertifikat (SC-Login Verwendungszweck, im Normalfall mit dem UPN als SAN:OtherName) ausstellen und auf die Karte schreiben und die CRL regelmäßig am konfigurierten Punkt veröffentlichen.
Der Unterschied des Servers ist, dass er die CRL selbst verwaltet und Nutzer ggf. ihre Zertifikate selbst anfordern können bzw. Du Auto-Enrollment nutzen kannst. Außerdem gibt er funktionierende Templates vor.
Grunsätzlich können Nutzer die meisten Smartcards selbst konfigurieren bzw. ein Zertifikat dafür (von ADCS) anfordern. Es ist nur häufig (z.B. bei Yubikeys) mit funktionalen Einschränkungen versehen (Hierarche von Admin-PIN, PUK und PIN, entsprechende Lockout-Regeln), sodass ich bei unter 100 Nutzern Smartcards in der Regel administrativ beschreiben und ausgeben würde.
1
Moin,
Gerne werden die Sperrlisten und & Co auf der SubCA plaziert. Denn mit der Installation der Webregistierungstelle wird auch ein Webserver (IIS) dort installiert. Somit können dort auch die Zertifikate der CAs und deren Sperrlisten untergebracht werden.
Gruß,
Dani
Eine Offline-Root-CA wird heruntergefahren und nur für die CRL-Abfrage (z.B. jährlich) hochgefahren (und für Updates natürlich).
es geht darum nicht um die Abfrage der CRL sondern die Aktualisierung der Sperrlisten, bevor diese ihr Ablaufdatum erreicht hat. Die Sperrliste muss natürlich zu jederzeit abfragbar sein.Gerne werden die Sperrlisten und & Co auf der SubCA plaziert. Denn mit der Installation der Webregistierungstelle wird auch ein Webserver (IIS) dort installiert. Somit können dort auch die Zertifikate der CAs und deren Sperrlisten untergebracht werden.
Gruß,
Dani
Zitat von @c.r.s.:
Bei dem Umfang und keiner sonstigen Verwendung der CA ist auch ein Single-Tier-Aufbau vertretbar.
Ich denke, auf das wird es rauslaufen (müssen). Das heißt, die von Dir vorgeschlagene Two-Tier Anleitung findet dann auf einem Server statt? Oder gibt es dabei etwas anderes zu beachten?Bei dem Umfang und keiner sonstigen Verwendung der CA ist auch ein Single-Tier-Aufbau vertretbar.
Mit dem Backup im Hinterkopf denke ich, werde ich die Installation auf einem separaten Server vornehmen. Auf dem AD Server wäre mir das dann zu heikel.
Hallo,
Lediglich, wenn Du bei den CA-Rollen einen Webdienst mit installieren willst würde ich das nicht auf dem DC machen, da gehört ein Webserver irgendwie nicht hin.
Grüße
lcer
Zitat von @baddeit:
Du musst Dir überlegen, wie lange das Zertifizierungsstellenzertifikat laufen soll. Bei 2 CAs wäre die Stamm-CA mit einer längeren Laufzeit versehen, die untergeordneten CAs hätte kürzere Laufzeiten. Hier musst Du einen Kompromiss festlegen.Zitat von @c.r.s.:
Bei dem Umfang und keiner sonstigen Verwendung der CA ist auch ein Single-Tier-Aufbau vertretbar.
Ich denke, auf das wird es rauslaufen (müssen). Das heißt, die von Dir vorgeschlagene Two-Tier Anleitung findet dann auf einem Server statt? Oder gibt es dabei etwas anderes zu beachten?Bei dem Umfang und keiner sonstigen Verwendung der CA ist auch ein Single-Tier-Aufbau vertretbar.
Mit dem Backup im Hinterkopf denke ich, werde ich die Installation auf einem separaten Server vornehmen. Auf dem AD Server wäre mir das dann zu heikel.
Heikel ist das eigentlich nicht. Sicherheitstechnisch wäre der CA-Server genau so wichtig wie der DC !! Es nützt nichts, wenn der DC wie Fort Knox abgesichert wird und die CA auf irgendeinem Member-Server rumliegt. Hast Du beide auf dem selben DC, hast Du gleiche Sicherheit für beide. Wenn Du Sorgen um den DC hast, es aber an Windows-Lizenzen und Hardware nicht scheitert, installier lieber einen 2. (oder 3. .... ) DCLediglich, wenn Du bei den CA-Rollen einen Webdienst mit installieren willst würde ich das nicht auf dem DC machen, da gehört ein Webserver irgendwie nicht hin.
Grüße
lcer
1
Ein zweiter DC wird vorhanden sein. Somit könnte ich den root-CA auf DC1 installieren, den issue-CA auf DC2? Macht das Sinn? Ist das dann eine Art Ausfallsicherheit, wenn DC1 (oder DC2) hops geht?
Wenn der Webdienst nicht benötigt wird für die grundsätzliche Ausstellung und Zuweisung von Zertifikaten, würde ich gerne darauf verzichten. Je einfacher, desto besser, da nach dem Ausrollen des Systems ich nicht mehr dafür verantwortlich bin, sondern jemand vor Ort, dessen Wissen ich nicht einschätzen kann.
Wenn der Webdienst nicht benötigt wird für die grundsätzliche Ausstellung und Zuweisung von Zertifikaten, würde ich gerne darauf verzichten. Je einfacher, desto besser, da nach dem Ausrollen des Systems ich nicht mehr dafür verantwortlich bin, sondern jemand vor Ort, dessen Wissen ich nicht einschätzen kann.
Grundsätzlich kannst Du die ADCS auf einem DC installieren (sprich: es funktioniert). Würde ich aber nicht machen, einfach weil das ein Dienst ist, den man auch mal wieder aus dem AD entfernen könnte, und ich sowas (bzw. irgendwas) ungern wieder vom DC deinstalliere.
Im Single-Tier-Szenario hast Du normalerweise keine Issuing-CA als Zwischenzertifizierungsstelle. Du könntest einen Two-Tier-Aufbau mit der Root-CA auf einem und der Issuing-CA auf dem anderen DC wählen. Hat aber keinen Vorteil gegenüber Single-Tier auf einem DC.
Ausfallsicher, wie du dir das vorstellst, geht es nicht. Wenn Du ADCS auf einem Server installierst, hast Du damit eine CA mit einem festen Platz in der Hierarchie. Das kann eine Root- oder Zwischenzertifizierungsstelle sein, beides auf einem Server geht nicht. Für zwei verfügbare Issuing-/Intermediate-CAs brauchst Du also schon drei Server.
Theoretisch könnte man in einem Two-Tier Aufbau, bei dem die Root-CA online gelassen wird, auf der Root-CA dieselben Templates anbieten wie auf der Issuing-CA (gleichbedeutend mit einem Single-Tier-Aufbau, dem eine Issuing-CA der Verfügbarkeit wegen hinzugefügt wird). Dann hätten aber funktional gleiche Zertifikate unterschiedliche Zertifizierungspfade, was sehr untypisch ist. Die gewonnene Ausfallsicherheit für das Ausstellen der Zertifikate fällt bei Smartcard-Nutzern außerdem nicht ins Gewicht.
Im Single-Tier-Szenario hast Du normalerweise keine Issuing-CA als Zwischenzertifizierungsstelle. Du könntest einen Two-Tier-Aufbau mit der Root-CA auf einem und der Issuing-CA auf dem anderen DC wählen. Hat aber keinen Vorteil gegenüber Single-Tier auf einem DC.
Ausfallsicher, wie du dir das vorstellst, geht es nicht. Wenn Du ADCS auf einem Server installierst, hast Du damit eine CA mit einem festen Platz in der Hierarchie. Das kann eine Root- oder Zwischenzertifizierungsstelle sein, beides auf einem Server geht nicht. Für zwei verfügbare Issuing-/Intermediate-CAs brauchst Du also schon drei Server.
Theoretisch könnte man in einem Two-Tier Aufbau, bei dem die Root-CA online gelassen wird, auf der Root-CA dieselben Templates anbieten wie auf der Issuing-CA (gleichbedeutend mit einem Single-Tier-Aufbau, dem eine Issuing-CA der Verfügbarkeit wegen hinzugefügt wird). Dann hätten aber funktional gleiche Zertifikate unterschiedliche Zertifizierungspfade, was sehr untypisch ist. Die gewonnene Ausfallsicherheit für das Ausstellen der Zertifikate fällt bei Smartcard-Nutzern außerdem nicht ins Gewicht.
1
Zum Verständnis: Wenn sich die Nutzer dann mittels SmartCards anmelden: Wo werden diese Daten gespeichert? Im AD? In der CA? Falls im AD: Heißt das, ich habe dann schon eine Art Ausfallsicherheit, wenn die CA nicht mehr erreichbar sein sollte?
Ich gebe Dir recht, mir wäre eine separate Maschine auch lieber. Und dann sollte die Gaudi via Single-Tier stattfinden, einen zusätzlichen Server werde ich wohl nicht verargumentieren können. Oder halt Two-Tier auf den beiden DCs...menno...
Zwischenfrage: Wie kommt eigentlich die Verbindung zwischen User/SmartCard zustande und wie werden die Karten bespielt?
Da ich wahrscheinlich erst nächste Woche mit der Installation beginnen kann, sind jetzt noch viele Fragezeichen hier. Aber wenn die Installation dann endlich beginnt, wirds hoffentlich viele "Aha, so geht das also." geben.
Beste Güße,
Badde
Ich gebe Dir recht, mir wäre eine separate Maschine auch lieber. Und dann sollte die Gaudi via Single-Tier stattfinden, einen zusätzlichen Server werde ich wohl nicht verargumentieren können. Oder halt Two-Tier auf den beiden DCs...menno...
Zwischenfrage: Wie kommt eigentlich die Verbindung zwischen User/SmartCard zustande und wie werden die Karten bespielt?
Da ich wahrscheinlich erst nächste Woche mit der Installation beginnen kann, sind jetzt noch viele Fragezeichen hier. Aber wenn die Installation dann endlich beginnt, wirds hoffentlich viele "Aha, so geht das also." geben.
Beste Güße,
Badde
Zitat von @baddeit:
Zum Verständnis: Wenn sich die Nutzer dann mittels SmartCards anmelden: Wo werden diese Daten gespeichert? Im AD? In der CA? Falls im AD: Heißt das, ich habe dann schon eine Art Ausfallsicherheit, wenn die CA nicht mehr erreichbar sein sollte?
Für die Anmeldung erreichbar muss nur die im Zertifikat konfigurierte Sperrliste sein. Die kann im AD liegen, aber auch per http zur Verfügung gestellt werden. Die CA kann offline sein, die Nutzer können sich totzdem anmelden.Zum Verständnis: Wenn sich die Nutzer dann mittels SmartCards anmelden: Wo werden diese Daten gespeichert? Im AD? In der CA? Falls im AD: Heißt das, ich habe dann schon eine Art Ausfallsicherheit, wenn die CA nicht mehr erreichbar sein sollte?
Der Computer, auf dem sich der Nutzer anmeldet prüft die Identität des Benutzers mittels des Zertifikates, das auf der Smartcard gespeichert ist. Vertraut der Computer dem Zertifikat und ist der im Zertifikat eingetragene Benutzer derjenige, der sich anmelden will, wird angemeldet. Die PIN auf der Smartcard stellt sicher, dass nicht jeder das Zertifikat aus der Smartcard auslesen kann.
Grüße
lcer
