22
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 588208
Url: https://administrator.de/forum/ad-cs-active-directory-certificate-services-smartcards-588208.html
Ausgedruckt am: 27.12.2024 um 15:12 Uhr
22 Kommentare
Neuester Kommentar
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
Hey,
älterer Beitrag aber gleiche Konstellation.
Ich benutze derzeit xca als ROOT CA und habe ein kleines AD plus yubikey.
Ich kann wie ich dich verstanden haben, dort die certificate für den user erstellen und muss diese plus das root ca in den domain controller importieren, damit das ad es als korrekt ansieht. Nur wie meinst du das mit dem crl akutalisieren? Wenn ich dem certificate 2 Jahre laufzeit gebe , muss ich dann zum change die crl verfügbar machen von xca?
Kannst du das kurz etwas erläutern? Danke
Im Prinzip möchte ich nur 3 User per smartcard (yubikey) schützen und dafür nichtd irekt microsoft seine pki installieren, was auch auf dem ad wohl nicht best practise ist.
Danke
älterer Beitrag aber gleiche Konstellation.
Ich benutze derzeit xca als ROOT CA und habe ein kleines AD plus yubikey.
Ich kann wie ich dich verstanden haben, dort die certificate für den user erstellen und muss diese plus das root ca in den domain controller importieren, damit das ad es als korrekt ansieht. Nur wie meinst du das mit dem crl akutalisieren? Wenn ich dem certificate 2 Jahre laufzeit gebe , muss ich dann zum change die crl verfügbar machen von xca?
Kannst du das kurz etwas erläutern? Danke
Im Prinzip möchte ich nur 3 User per smartcard (yubikey) schützen und dafür nichtd irekt microsoft seine pki installieren, was auch auf dem ad wohl nicht best practise ist.
Danke
Hallo,
nur die Root-CA und eventl. Intermediate-CAs müssen ins AD importiert werden. Die Nutzerzertifikate werden bei Verwendung standardmäßig automatisch in den Nutzerspeicher geladen.
Du musst mit der CRL eine Widerrufsmöglichkeit für die Zertifikate vorsehen. Eine PIN kann abgegriffen werden: Wenn der YubiKey verloren wird, sollen aber weder der Nutzer langfristig deaktiviert werden, noch die Infrastruktur bedroht sein, solange das Zertifikat noch gilt. Die CRL wird ad hoc dann erneuert, wenn ein Zertifikat vor Ende seiner Lebensdauer widerrufen werden soll, und regelmäßig wenn die CRL abläuft.
Die Lebensdauer der CRL gibt unter Beachtung kombinierter Angriffe den Zeitraum vor, in dem auf einen Vorfall reagiert werden kann, denn einem validierenden System kann ggf. eine abgelöste CRL untergeschoben werden, solange sie nicht abgelaufen ist. Die CDP-Protokolle LDAP und HTTP sind ja selbst nicht sicher.
Das Aktualisierungsintervall ist folglich eine Abwägung aus dem Risiko, dem die privaten Schlüssel der ausgestellten Zertifikate ausgesetzt sind, dem praktischen Aufwand und der übrigen Schutzniveau der Infrastruktur (CDP, Netzwerk, Host für potenziell automatisierte Ausstellung). Für einen solchen Fall mit Smartcards finde ich das manuelle Vorgehen mit z.B. 2-3 Monaten vertretbar.
Grüße
Richard
nur die Root-CA und eventl. Intermediate-CAs müssen ins AD importiert werden. Die Nutzerzertifikate werden bei Verwendung standardmäßig automatisch in den Nutzerspeicher geladen.
Du musst mit der CRL eine Widerrufsmöglichkeit für die Zertifikate vorsehen. Eine PIN kann abgegriffen werden: Wenn der YubiKey verloren wird, sollen aber weder der Nutzer langfristig deaktiviert werden, noch die Infrastruktur bedroht sein, solange das Zertifikat noch gilt. Die CRL wird ad hoc dann erneuert, wenn ein Zertifikat vor Ende seiner Lebensdauer widerrufen werden soll, und regelmäßig wenn die CRL abläuft.
Die Lebensdauer der CRL gibt unter Beachtung kombinierter Angriffe den Zeitraum vor, in dem auf einen Vorfall reagiert werden kann, denn einem validierenden System kann ggf. eine abgelöste CRL untergeschoben werden, solange sie nicht abgelaufen ist. Die CDP-Protokolle LDAP und HTTP sind ja selbst nicht sicher.
Das Aktualisierungsintervall ist folglich eine Abwägung aus dem Risiko, dem die privaten Schlüssel der ausgestellten Zertifikate ausgesetzt sind, dem praktischen Aufwand und der übrigen Schutzniveau der Infrastruktur (CDP, Netzwerk, Host für potenziell automatisierte Ausstellung). Für einen solchen Fall mit Smartcards finde ich das manuelle Vorgehen mit z.B. 2-3 Monaten vertretbar.
Grüße
Richard
Guten Morgen Richard!
danke für deine ausführliche Erklärung. Da ich ja xca als root ca benutzte, verstehe ich, das dieses Root Ca ins AD muss, damit Domain Controller und alle clients dieses als Sicher / Trust ansehen.
Nur noch mal zur Frage bezüglich der Nutzerzertifikate:
Die Nutzerzertifikate werden bei Verwendung standardmäßig automatisch in den Nutzerspeicher geladen.
Muss ich nicht noch das user certificate, was ich per xca erstelle und in den yubikey dann importiere oder von dieses als request erstellen lasse , noch dem user importieren / hinterlegen im AD?
Liebe Grüße
Felix
danke für deine ausführliche Erklärung. Da ich ja xca als root ca benutzte, verstehe ich, das dieses Root Ca ins AD muss, damit Domain Controller und alle clients dieses als Sicher / Trust ansehen.
Nur noch mal zur Frage bezüglich der Nutzerzertifikate:
Die Nutzerzertifikate werden bei Verwendung standardmäßig automatisch in den Nutzerspeicher geladen.
Muss ich nicht noch das user certificate, was ich per xca erstelle und in den yubikey dann importiere oder von dieses als request erstellen lasse , noch dem user importieren / hinterlegen im AD?
Liebe Grüße
Felix
Zitat von @Felix123:
Muss ich nicht noch das user certificate, was ich per xca erstelle und in den yubikey dann importiere oder von dieses als request erstellen lasse , noch dem user importieren / hinterlegen im AD?
Muss ich nicht noch das user certificate, was ich per xca erstelle und in den yubikey dann importiere oder von dieses als request erstellen lasse , noch dem user importieren / hinterlegen im AD?
Das Betrifft nur Fälle, in denen andere Konten ein Nutzerzertifikat aus dem AD abrufen können sollen. Wenn die Zertifikate auch für E-Mail-Verschlüsselung oder EFS genutzt werden, kann man das machen. Für Smartcard-Login ist es nicht erforderlich.
also wenn ich mich auf der workstation/server per user anmelde , reicht wenn das ad die rootca importiert hat und der yubikey ein certifikat/schlüssel von dieser ca import hat?
dann kann ich es einfach als smartcard login verwenden ohne , den user noch irgendwas zu importieren?
ich ging davon aus, dass es noch in sein useraccount eingefügt werden muss, das er sich mit diesem authentifiziert. Da muss ich etwas nicht verstanden haben und werde das noch einmal nachlesen. Danke
ich werde das jetzt einmal testen.
1.domain
2.xca root ca exportieren und in den domain zertifikats store hinzufügen
3.certificat in den yubikey importieren mit schlüssel und pin
4. smartcard login für den user aktivieren.
Das wären dann die richitgen schritte oder?
dann kann ich es einfach als smartcard login verwenden ohne , den user noch irgendwas zu importieren?
ich ging davon aus, dass es noch in sein useraccount eingefügt werden muss, das er sich mit diesem authentifiziert. Da muss ich etwas nicht verstanden haben und werde das noch einmal nachlesen. Danke
ich werde das jetzt einmal testen.
1.domain
2.xca root ca exportieren und in den domain zertifikats store hinzufügen
3.certificat in den yubikey importieren mit schlüssel und pin
4. smartcard login für den user aktivieren.
Das wären dann die richitgen schritte oder?
Zitat von @Felix123:
1.domain
2.xca root ca exportieren und in den domain zertifikats store hinzufügen
3.certificat in den yubikey importieren mit schlüssel und pin
4. smartcard login für den user aktivieren.
Das wären dann die richitgen schritte oder?
1.domain
2.xca root ca exportieren und in den domain zertifikats store hinzufügen
3.certificat in den yubikey importieren mit schlüssel und pin
4. smartcard login für den user aktivieren.
Das wären dann die richitgen schritte oder?
Die DCs brauchen auch Computer/DC-Zertifikate, hatte ich vergessen. Die CA muss sowohl mit dem o.g. dspublish im AD konfiguriert werden als auch als vertrauenswürdige Root-CA verteilt werden.
Smartcard-Login ist aber standardmäßig (mit RSA-Zertifikaten), man kann es nur erzwingen. Der AD-Nutzer wird dem Anmeldeversuch durch Übereinstimmung von CN und UPN zugeordnet, daher muss nichts im Nutzerobjekt hinterlegt werden (und die Zwecke bzw. die Ausstellung von Zertifikaten, die auf den UPN lauten, gewissenhaft kontrolliert werden).
