Jump to content

Zertifikatserver physisch dauerhaft ausgefallen


Empfohlene Beiträge

Geschrieben

Die alte Maschine mit einem nicht genutzten, aber mal installiertem CertServer Server2019 ist irreparabel defekt.

Ich möchte gerne eine VM 2022 aufsetzen und dort einen neuen CertServer einrichten, der dann aber auch bald für ein neu zu installierendes Programm in der Domäne genutzt werden soll. 

 

Meine Frage an die Experten:

 

- Laufe ich in irgendwelche Probleme, wenn ich in der Domäne einen neuen CertServer installiere?

 

- MUSS ich in den beiden DCs, die laufen, irgendwelche Einträge VOR der neuen 2022 CertServer-Installation suchen und entfernen?

 

Ich betone lieber noch mal: der physisch defekte Server mit der Cert... ist nur einmal vor Jahren standardmäßig installiert worden, aber es sind nie Zertifikate darauf eingerichtet worden.

 

Bedanke mich für ein paar Hinweise !

Muriel

Geschrieben

Na dann sauber bereinigen und den neuen nicht mit Setup enter enter installieren. ;)

vor 11 Minuten schrieb Täglichlerner:

aber es sind nie Zertifikate darauf eingerichtet worden.

Glaub ich nicht. Zumindest deine dcs haben sich dort ein Zertifikat gezogen. Ansonsten war’s kein Standard.

 

vor 12 Minuten schrieb Täglichlerner:

ist nur einmal vor Jahren standardmäßig installiert worden


;)

 

bye

norbert

Geschrieben
vor 10 Stunden schrieb Täglichlerner:
 

- Laufe ich in irgendwelche Probleme, wenn ich in der Domäne einen neuen CertServer installiere?

Nur, dass Du, wenn Du es nicht bewusst und geregelt betreibst, die Angriffsfläche Deiner Umgebung noch einmal erweiterst. Denk daran, eine mit Weiter-Weiter-Finish installierte Enterprise CA ist sofort a. zur Ausstellung von Kerberos- (Smartcard-)Zertifikaten befähigt und b. so konfiguriert, dass der Beantragende die Namen selber festlegen kann.
 

Wenn Du nicht vorhast, Smartcard-Authentifizierung auch wirklich zu nutzen, trage die CA daher am besten gleich nach der Installation aus dem NTAuth-Container aus.

Ansonsten google mal nach capolicy.inf und installiere die CA erst mal "blank" und veröffentliche nur die Vorlagen, die Du wirklich brauchst, berechtigt nur für die User/Computer, die sie jeweils wirklich benötigen.

 

vor 10 Stunden schrieb Täglichlerner:
 

, aber es sind nie Zertifikate darauf eingerichtet worden.

Wie bereits gesagt wurde, die DCs haben sich vermutlich welche gezogen. Schmeiß sie einfach runter. Wenn eine Einrichtung LDAPS nutzen wollte, wüßtest Du es. Alles, was Domain Member ist, braucht kein LDAPS (siehe auch https://it-pro-berlin.de/2024/06/ldap-deaktivieren-ein-reality-check/).

Geschrieben

Moin, 

 

Und wenn wir schon dabei sind, könntest du auch prüfen, ob du überhaupt eine PKI brauchst. Eine schlecht eingerichtete PKI (wie etwa die, die du gerade verloren hast), ist ein großes Sicherheitsrisiko. 

 

Gruß, Nils

PS. PKI ist böse. 

  • Like 1
  • Haha 1
Geschrieben (bearbeitet)

Vielen Dank für die drei Beiträge vom Wochenende !

....
ja, ich habe ein Backup der CA..stelle vom Januar 2025. Aber ich möchte keine neue CA aufsetzen mit einem Import des Backups, sondern mich von den Altlasten einer nie benutzten CA seit Einrichtung 2020 befreien. (macht das Sinn?)

 

Ich überlege gerade, ob ich die phys. Maschine für CA wieder zum Laufen kriege, um dann eine geordnete Dekommissionierung der CA nach Vorlage etwa von


https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/decommission-enterprise-certification-authority-and-remove-objects

 

hinbekomme - trainingsmäßig :)

Aber meint ihr nicht auch, dass das zu viel Aktion ist - nur Training StepbyStep lt URL?

 

Danke auch für den Hinweis zum Thema "Smartcard" (NTAuth-Container).

Und ja, die DCs werde ich vom alten CA-Müll säubern.

 

Die neue CA-Stelle will ich auf einer separaten VM aufsetzen und sie ist in meiner Umgebung nur dazu da für eine neue ArchivSoft D.velop, die in ihrer neuen Version eine CA-Stelle braucht (sie wird von d.velop bei mir eingerichtet).
Ich selber setze also nur die CA "blank" auf.

 

Und, Nils, ob ich eine PKI brauche, muss mit dem d.velop-Supporter geklärt werden.
In meiner kleinen Umgebung brauchte ich eigentlich keine CA - jetzt eben nur für die Authentifikation der paar Clients mit dem neuen d.velop-Archivserver d3.

 

"PKI sind böse" ... ich dachte eher Putin oder Trump sind es.

 

Viele Grüße

bearbeitet von Täglichlerner
Geschrieben

ich bezog mich auf cj_berlin: "Ansonsten google mal nach capolicy.inf und installiere die CA erst mal "blank" und veröffentliche nur die Vorlagen, die Du wirklich brauchst, berechtigt nur für die User/Computer, die sie jeweils wirklich benötigen."

 

... und beobachte die Veränderungswünsche vom Archiv-Software-Support (kritisch), weil es ja "nur" darum gehen sollt, dass sich die 5 Clients bei Verbindungen zum Archiv beim Server authentifizieren sollen - mehr nicht. 

 

Dazu müsste ich allerdings in der Lage sein, das zu beurteilen ... ich schau mal und frage euch ggf. ;)

Geschrieben

Moin,

 

eine CA zu entfernen, die man nicht braucht, ist in jedem Fall sinnvoll. Wenn es dann Bedarf für eine neue PKI gibt, ist das ja anscheinend ein valider Use Case. Dann muss die PKI aber auch "gut" aufgesetzt und betrieben werden, und da hapert es meist. Leider sind PKIs allgemein und die Windows-PKI im Speziellen sehr unübersichtlich und fehlerträchtig in Einrichtung und Betrieb, daher mein Diktum "PKI ist böse". Das gilt prinzipiell und mit Produktbezug.

 

Ich kenne den Use Case von d.velop nicht, aber falls die User-Anmeldung dort auch ohne eigene PKI möglich ist und sonst nichts anderes eine eigene PKI erfordert, würde ich ein PKI-freies Setup ernsthaft in Erwägung ziehen.

 

Falls es eine eigene Windows-PKI sein soll, empfehle ich das Rheinwerk-Buch zum Thema und ggf. einen Dienstleister, der sich wirklich damit auskennt.

 

Gruß, Nils

 

Geschrieben
vor einer Stunde schrieb NilsK:

eine CA zu entfernen, die man nicht braucht, ist in jedem Fall sinnvoll. Wenn es dann Bedarf für eine neue PKI gibt, ist das ja anscheinend ein valider Use Case. Dann muss die PKI aber auch "gut" aufgesetzt und betrieben werden, und da hapert es meist. Leider sind PKIs allgemein und die Windows-PKI im Speziellen sehr unübersichtlich und fehlerträchtig in Einrichtung und Betrieb, daher mein Diktum "PKI ist böse". Das gilt prinzipiell und mit Produktbezug.

Kehrtwende ist Kehrtwende.

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...