20
Zertifikatsvorlagen teilweise nicht sichtbar
Hallöchen zusammen,
ich hab folgendes Problem / Konstellation:
U.a. 2 DCs, ein paar Server, eine Root CA (normalerweise ausgeschaltet, wird nur für Updates und zum Veröffentlichen der Sperrlisten eingeschaltet), eine Issuing CA. Sperrlisten gehen aktuell ausschließlich übers AD / LDAP, OCSP haben wir keinen im Einsatz, in den Zertifikaten wird auch nur der LDAP-Speicherort eingetragen.
Die Issuing CA hat Anfang August ein neues Zertifizierungsstellenzertifikat bekommen, weil das alte Ende August abgelaufen ist (weiß nicht, inwiweit das relevant sein könnte).
Es gibt unter anderem ein Template "Computer-AutoDeploy", damit sich die Computer selbstständig ein Zertifikat ziehen/erneuern können (u.a. für WLAN mit 802.1x oder SSL für den WSUS). Lesen dürfen Authentifizierte Benutzer, Registrieren und automatisch registrieren dürfen Domaincontroller und Domänencomputer.
Einige Server (DCs, Root CA, Issuing CA) können ganz normal Zertifikate abrufen, andere Server (WSUS, Dienstserver mit Fachanwendung, Admin-Jumphost) rufen kein Zertifikat automatisch ab (hat früher funktioniert mittels GPO). GPOs wurden nicht geändert. Wenn ich manuell das Computerzertifikat-MMC öffne und dort versuche, ein Zertifikat über die AD-Templates zu ziehen, findet er kein einziges, auf DCs und CAs geht es.
Ich bin auch schon im ADSI-Editor gewesen, Authentifizierte Benutzer dürfen von Configuration -> Services -> Public Key Services -> alle Container lesen (insbesondere auch die Templates). Eine Auswertung "effektiven Zugriff anzeigen" auf das betreffende Template-Objekt zeigt, dass die betreffenden Server, auf denen keine Zertifikate registriert werden können, lesenden Zugriff haben. Das Template ist auf der Issuing CA auch in den Zertifikatsvorlagen verknüpft (wie gesagt bei manchen Servern gehts ja).
Was mir aufgefallen ist: In der MMC "Computerzertifikate" laden die Vorlagen auf den funktionierenden Servern extrem lange, bis sie mal auftauchen, selbiges in der certsrv-MMC der CAs. Das war früher recht flott (max. 1-2 Sekunden). Ich kann aber nicht genau sagen, wann sich das geändert hat, da wir eigentlich nie Anpassungen an den Vorlagen gemacht haben.
Vor allem für den WSUS ist das problematisch, weil der sein Zertifikat natürlich entsprechend für die WSUS-Dienste nutzt (SSL und so).
Ob es was damit zu tun hat weiß ich nicht, aber es sei noch erwähnt, dass wir folgende GPOs aktiv / konfiguriert haben:
Außerdem wird mir bei einem gpupdate auf dem WSUS folgender Fehler ausgespuckt (hängt evtl. auch mit dem Ganzen zusammen):
Ereignisanzeige spuckt dann bei den Details "Der Benutzername oder das Kennwort ist falsch." aus. Kann aber eigentlich nicht sein, anmelden kann ich mich ja per RDP.
Ich hab dann folgendes versucht, um evtl. beide Fehler zu beheben:
WSUS raus aus der Domäne, Neustart, mit nem lokalen Admin das Domänenprofil gelöscht, Computerkonto gelöscht und neu angelegt in der richtigen OU, Neustart, rein in die Domäne, Neustart. Aber beide Fehler bestehen weiterhin.
Kann mir hier vielleicht einer weiterhelfen, ich komm hier nicht weiter. Falls ihr noch weitere Infos braucht stell ich die natürlich gern zur Verfügung.
Danke schonmal!
Viele Grüße
Ketanest
ich hab folgendes Problem / Konstellation:
U.a. 2 DCs, ein paar Server, eine Root CA (normalerweise ausgeschaltet, wird nur für Updates und zum Veröffentlichen der Sperrlisten eingeschaltet), eine Issuing CA. Sperrlisten gehen aktuell ausschließlich übers AD / LDAP, OCSP haben wir keinen im Einsatz, in den Zertifikaten wird auch nur der LDAP-Speicherort eingetragen.
Die Issuing CA hat Anfang August ein neues Zertifizierungsstellenzertifikat bekommen, weil das alte Ende August abgelaufen ist (weiß nicht, inwiweit das relevant sein könnte).
Es gibt unter anderem ein Template "Computer-AutoDeploy", damit sich die Computer selbstständig ein Zertifikat ziehen/erneuern können (u.a. für WLAN mit 802.1x oder SSL für den WSUS). Lesen dürfen Authentifizierte Benutzer, Registrieren und automatisch registrieren dürfen Domaincontroller und Domänencomputer.
Einige Server (DCs, Root CA, Issuing CA) können ganz normal Zertifikate abrufen, andere Server (WSUS, Dienstserver mit Fachanwendung, Admin-Jumphost) rufen kein Zertifikat automatisch ab (hat früher funktioniert mittels GPO). GPOs wurden nicht geändert. Wenn ich manuell das Computerzertifikat-MMC öffne und dort versuche, ein Zertifikat über die AD-Templates zu ziehen, findet er kein einziges, auf DCs und CAs geht es.
Ich bin auch schon im ADSI-Editor gewesen, Authentifizierte Benutzer dürfen von Configuration -> Services -> Public Key Services -> alle Container lesen (insbesondere auch die Templates). Eine Auswertung "effektiven Zugriff anzeigen" auf das betreffende Template-Objekt zeigt, dass die betreffenden Server, auf denen keine Zertifikate registriert werden können, lesenden Zugriff haben. Das Template ist auf der Issuing CA auch in den Zertifikatsvorlagen verknüpft (wie gesagt bei manchen Servern gehts ja).
Was mir aufgefallen ist: In der MMC "Computerzertifikate" laden die Vorlagen auf den funktionierenden Servern extrem lange, bis sie mal auftauchen, selbiges in der certsrv-MMC der CAs. Das war früher recht flott (max. 1-2 Sekunden). Ich kann aber nicht genau sagen, wann sich das geändert hat, da wir eigentlich nie Anpassungen an den Vorlagen gemacht haben.
Vor allem für den WSUS ist das problematisch, weil der sein Zertifikat natürlich entsprechend für die WSUS-Dienste nutzt (SSL und so).
Ob es was damit zu tun hat weiß ich nicht, aber es sei noch erwähnt, dass wir folgende GPOs aktiv / konfiguriert haben:
Domänencontroller: Signaturanforderungen für LDAP-Server Signatur erforderlich
Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) Aktiviert
Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) Aktiviert
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Aktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Aktiviert
Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern Aktiviert
Netzwerksicherheit: LAN Manager-Authentifizierungsebene Nur NTLMv2-Antworten senden. LM & NTLM verweigern
Netzwerksicherheit: Signaturanforderungen für LDAP-Clients Signatur erforderlich
Domänencontroller: Anforderungen an das LDAP-Serverkanal-Bindungstoken Immer Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, neue Gruppenrichtlinieneinstellungen für diesen Benutzer oder Computer abzurufen. Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". Dieser Vorgang wird automatisch beim nächsten Aktualisierungszyklus wiederholt. Computer, die der Domäne beigetreten sind, müssen über eine geeignete Namensauflösung sowie über eine Netzwerkverbindung zu einem Domänencontroller zum Ermitteln von neuen Gruppenrichtlinienobjekten und -einstellungen verfügen. Wenn die Gruppenrichtlinie erfolgreich ist, wird ein Ereignis protokolliert. Ich hab dann folgendes versucht, um evtl. beide Fehler zu beheben:
WSUS raus aus der Domäne, Neustart, mit nem lokalen Admin das Domänenprofil gelöscht, Computerkonto gelöscht und neu angelegt in der richtigen OU, Neustart, rein in die Domäne, Neustart. Aber beide Fehler bestehen weiterhin.
Kann mir hier vielleicht einer weiterhelfen, ich komm hier nicht weiter. Falls ihr noch weitere Infos braucht stell ich die natürlich gern zur Verfügung.
Danke schonmal!
Viele Grüße
Ketanest
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: 667823
Url: https://administrator.de/contentid/667823
Ausgedruckt am: 21.11.2024 um 11:11 Uhr
20 Kommentare
Neuester Kommentar
Wenn du sagst das die Berechtigungen passen dann wäre ein Blick in den Event Viewer hilfreich.
Die GPUPDATE Fehlermeldung sagt mir das irgendwas mit der Domäne nicht stimmt.
Was sagt denn dcdiag ? Kommen da irgendwelche Meldungen ?
Die GPUPDATE Fehlermeldung sagt mir das irgendwas mit der Domäne nicht stimmt.
Was sagt denn dcdiag ? Kommen da irgendwelche Meldungen ?
Wenn du sagst das die Berechtigungen passen dann wäre ein Blick in den Event Viewer hilfreich.
Achso das hatte ich vergessen, beim Anwenden der entsprechenden GPO für die Zertifikate sagt er, dass der RPC Server nicht erreichbar sei. Was aber eigentlich auch nicht sein kann, denn auf nem anderen Server funktionierts ja, wenn ich es teste.
Hab grad nochmal auf der Firewall nachgeschaut, das Paket ist auf dem falschen Interface gelandet, weil eine Regel nicht gepasst hat (hab den falschen Host eingetragen). Beim gpudate zieht sich der WSUS jetzt auch brav sein Zertifikat. Vorlagen kann ich dennoch nicht abrufen.
Was sagt denn dcdiag ? Kommen da irgendwelche Meldungen ?
Nur ne "alte" DFS-R Meldung von heute morgen, die ich aber schon geprüft hab, die Replikation funktioniert. GPO Verarbeitung an sich geht, ich hab das mal mit ner neuen GPO getestet, die wird auch angewendet.
Laut überlegt: Mit dem eingesetzten Tiering sollte es eigentlich auch nicht zusammenhängen, wenn mich nicht alles täuscht hat es auch bislang funktioniert.
Per GPO ist es verboten, sich aus einem anderen Tier anzumelden, sprich:
Es gibt für jeden Tier eine Gruppe ADM_Tier-X, in welcher die jeweiligen Tier-Admin-Accounts sind, die per GPO dann lokale Admin-Rechte auf den Kisten kriegen (also die Gruppe). Tier 0 zählt nicht, sind keine Windows-Hypervisoren. In Tier 1 darf sich nicht anmelden: Tier 2-4 und Domain Admins, in Tier 2 darf sich nicht anmelden: Tier 1, 3, 4 und Domain Admins, etc.
Sonderstellung: DCs, trotz Tier 1 sind diese noch in der Default DC-OU und an der "Default Domain Controllers Policy" wurde auch nicht rumgefummelt (is aber auch egal, weil Tier 1-4-Admins sich an DCs sowieso nicht anmelden dürfen).
Da in der Default Domain Controllers Policy keine Verweigerung konfiguriert ist sollte das ja eigentlich funktionieren. Den Fehler bei den GPOs bekomme ich, wenn ich mich in Tier 2 und 3 mit dem jeweiligen Admn Account anmelde, in Tier 1 geht es komischerweise.
Tier 0: Hypervisoren
Tier 1: DCs, CAs, DHCP, Admin-Jumphost
Tier 2: Monitoring, WSUS, WLAN-Controller, Client Management
Tier 3: Anwendungen (Fachanwendung)
Tier 4: ClientsAnmelden als Batchauftrag verweigern
Anmelden als Dienst verweigern
Anmelden über Terminaldienste verweigern
Lokal anmelden verweigern
Zugriff vom Netzwerk auf diesen Computer verweigernSonderstellung: DCs, trotz Tier 1 sind diese noch in der Default DC-OU und an der "Default Domain Controllers Policy" wurde auch nicht rumgefummelt (is aber auch egal, weil Tier 1-4-Admins sich an DCs sowieso nicht anmelden dürfen).
Da in der Default Domain Controllers Policy keine Verweigerung konfiguriert ist sollte das ja eigentlich funktionieren. Den Fehler bei den GPOs bekomme ich, wenn ich mich in Tier 2 und 3 mit dem jeweiligen Admn Account anmelde, in Tier 1 geht es komischerweise.
Im Event-Log von den Servern hab ich in der Nähe der Kennwort-Falsch-Meldung noch folgendes Ereignis gefunden:
Der Dienst "Netzwerkkonnektivitäts-Assistent" wurde mit dem folgenden dienstspezifischen Fehler beendet:
Die Anforderung wird nicht unterstützt.Zugriff vom Netzwerk auf diesen Computer verweigern
sorgt eigentlich auch das sich Computersysteme nicht anmelden bzw. Authtifizieren dürfen.
Eventuell mal Testweise eine Ausnahme für das System einstellen und Testen.
sorgt eigentlich auch das sich Computersysteme nicht anmelden bzw. Authtifizieren dürfen.
Das schon aber in den betreffenden Gruppen sind nur User Accounts Mitglieder (Die jeweiligen Admin User).
Eventuell mal Testweise eine Ausnahme für das System einstellen und Testen.
Hab auch schon probiert, die Tier-GPOs komplett zu deaktvieren aber das brachte auch nix.
Fehler bei der Verarbeitung der Gruppenrichtlinie.
Nur ne "alte" DFS-R Meldung von heute morgen, die ich aber schon geprüft hab, die Replikation funktioniert.
Hast du zwei oder mehrere Domain Controller? Evtl ist der SYSVOL Ordner nicht synchron. Dann fehlt auf einem DC eine GPO und dann kommt sowas auch zustande.
Es gibt 3 mögliche Fehlerursachen für sowas:
1) DNS Probleme,
2) DNS Probleme und
3) DNS Probleme
Hast du zwei oder mehrere Domain Controller?
Zwei
Evtl ist der SYSVOL Ordner nicht synchron. Dann fehlt auf einem DC eine GPO und dann kommt sowas auch zustande.
Das hab ich schon geprüft, die sind synchron.
Es gibt 3 mögliche Fehlerursachen für sowas:
1) DNS Probleme,
2) DNS Probleme und
3) DNS Probleme
1) DNS Probleme,
2) DNS Probleme und
3) DNS Probleme
Jo, sehr spezifisch, Danke. Nach was genau soll ich denn da schauen?
Also nur noch mal zu Verständnis:
Es geht hier um ein "Internes SSL Zetifikat" was du für den WSUS nutzen willst
Und nicht um die Computer Zertifikate welche autom. über die GPO kommen ?
Es geht hier um ein "Internes SSL Zetifikat" was du für den WSUS nutzen willst
Und nicht um die Computer Zertifikate welche autom. über die GPO kommen ?
WSUS an sich geht. Der hat ein Computerzertifikat, das durch die Issuing-CA ausgestellt wurde und dasselbe Zertifkat wird für den IIS vom WSUS genutzt. Clients und Server ziehen sich auch brav ihre Updates, weil die da übers AD der Root CA und der Issuing CA vertrauen und damit auch dem von dieser ausgestellten Zertifkat für den WSUS.
Lediglich das mit dem gpupdate verursacht noch Probleme beim Ziehen der Benutzerkonfiguration (was aber in meinen Augen nicht mit dem Zertifikatskram zusammenhängt).
Und zusätzlich kann ich immer noch keine Zertifikatsvorlagen sehen, wenn ich über das entsprechende MMC das versuche (weder auf Benutzer noch auf Computerebene), das Zertifikat per GPO zieht sich der Server aber.
Lediglich das mit dem gpupdate verursacht noch Probleme beim Ziehen der Benutzerkonfiguration (was aber in meinen Augen nicht mit dem Zertifikatskram zusammenhängt).
Und zusätzlich kann ich immer noch keine Zertifikatsvorlagen sehen, wenn ich über das entsprechende MMC das versuche (weder auf Benutzer noch auf Computerebene), das Zertifikat per GPO zieht sich der Server aber.
Und zusätzlich kann ich immer noch keine Zertifikatsvorlagen sehen
Lösche mal den Cache der MMC Konsolen und starte sie neu. Datei => Optionen > Dateien löschen.Gruß
Zitat von @14260433693:
Gruß
Und zusätzlich kann ich immer noch keine Zertifikatsvorlagen sehen
Lösche mal den Cache der MMC Konsolen und starte sie neu. Datei => Optionen > Dateien löschen.Gruß
Interessant, wusste gar nicht, dass das geht. Brachte aber leider nichts.
Werf mal ProcessMonitor an um zu sehen was im Background schief läuft.
Habs auch mal mit nem lokalen Admin ausprobiert, gleicher Effekt.
Date: 03.09.2024 16:00:44,1495003
Thread: 6916
Class: Registry
Operation: RegOpenKey
Result: NAME NOT FOUND
Path: HKLM\Software\Policies\Microsoft\Cryptography\PolicyServers
Duration: 0.0000163
Desired Access: Query ValueAlle anderen enden mit "SUCCESS"
EDIT: Gibt noch paar andere:
HKLM\System\CurrentControlSet\Services\CertSvc\Configuration
HKLM\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\LogLevel
HKLM\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEEventLogLevelDie enden auch mit Name not Found.
Die Name "not found" sind in der Regel uninteressant, dein genannter wäre ein Policy-Schlüssel der nur auf Inhalt gecheckt wird, wenn nicht vorhanden aber ignoriert wird. Interessant wären evt. AccessDenied Geschichten.
Die Issuing CA hat Anfang August ein neues Zertifizierungsstellenzertifikat bekommen
Das sieht wie aus? Mal alle Eigenschaften hier auflisten vielleicht hat sich da was reingemogelt was da nichts zu suchen hat.
Wenn die Issuing CA ein neues CA bekommen hat. Ist es dann das Richtige und ist die Issuing CA auch berechtigt WIRKLICH ALLE Zertifikate auszustellen - Kann man eingrenzen. Nicht das hier der Fehler liegt.
Vergleiche mal bitte das Alte und neue Zertifikat.
Vergleiche mal bitte das Alte und neue Zertifikat.
@14260433693 und @Mr-Gustav
Die Issuing-CA hat das Zertifikat nach Default Issuing-CA Vorlage erhalten.
Das alte Zertifkat hatte genau die selben Eigenschaften.
Die Issuing-CA hat das Zertifikat nach Default Issuing-CA Vorlage erhalten.
Basiseinschränkungen:
Typ des Antragstellers=Zertifizierungsstelle
Einschränkung der Pfadlänge=Keine
Schlüsselverwendung:
Digitale Signatur, Zertifikatsignatur, Offline Signieren der Zertifikatsperrliste, Signieren der Zertifikatsperrliste (86)Das alte Zertifkat hatte genau die selben Eigenschaften.
Ich würde sagen das hier die "Server Authentication" fehlt denn eine Digitale Signatur ist kein SSL Zertifikat was ein Webserver nutzen kann.
Zitat von @Mr-Gustav:
Ich würde sagen das hier die "Server Authentication" fehlt denn eine Digitale Signatur ist kein SSL Zertifikat was ein Webserver nutzen kann.
Ich würde sagen das hier die "Server Authentication" fehlt denn eine Digitale Signatur ist kein SSL Zertifikat was ein Webserver nutzen kann.
Die Issuing CA bietet aber keine SSL-Dienste an, wofür sie ein entsprechendes Zertifikat bräuchte.
Aber selbst wenn hätte sie ja ein Computerzertifikat, da ist Server Authentication mit drin. Das von mir beschriebene Zertifikat war ja lediglich das der Issuing CA, nicht das des Computers.
