ketanest112
Goto Top

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:
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 
Außerdem wird mir bei einem gpupdate auf dem WSUS folgender Fehler ausgespuckt (hängt evtl. auch mit dem Ganzen zusammen):
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.  
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

Content-ID: 667823

Url: https://administrator.de/contentid/667823

Ausgedruckt am: 01.11.2024 um 02:11 Uhr

Mr-Gustav
Mr-Gustav 02.09.2024 um 14:15:02 Uhr
Goto Top
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 ?
ketanest112
ketanest112 02.09.2024 um 14:39:41 Uhr
Goto Top
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.
ketanest112
ketanest112 02.09.2024 um 14:51:58 Uhr
Goto Top
Laut überlegt: Mit dem eingesetzten Tiering sollte es eigentlich auch nicht zusammenhängen, wenn mich nicht alles täuscht hat es auch bislang funktioniert.
Tier 0: Hypervisoren
Tier 1: DCs, CAs, DHCP, Admin-Jumphost
Tier 2: Monitoring, WSUS, WLAN-Controller, Client Management
Tier 3: Anwendungen (Fachanwendung)
Tier 4: Clients
Per GPO ist es verboten, sich aus einem anderen Tier anzumelden, sprich:
Anmelden als Batchauftrag verweigern 
Anmelden als Dienst verweigern 
Anmelden über Terminaldienste verweigern 
Lokal anmelden verweigern 
Zugriff vom Netzwerk auf diesen Computer verweigern
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.
ketanest112
ketanest112 02.09.2024 um 14:59:05 Uhr
Goto Top
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.
Mr-Gustav
Mr-Gustav 03.09.2024 um 09:19:54 Uhr
Goto Top
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.
ketanest112
ketanest112 03.09.2024 um 09:34:50 Uhr
Goto Top
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.
NordicMike
NordicMike 03.09.2024 um 12:08:50 Uhr
Goto Top
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
ketanest112
ketanest112 03.09.2024 um 12:18:25 Uhr
Goto Top
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

Jo, sehr spezifisch, Danke. Nach was genau soll ich denn da schauen?
Mr-Gustav
Mr-Gustav 03.09.2024 um 15:18:51 Uhr
Goto Top
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 ?
ketanest112
ketanest112 03.09.2024 aktualisiert um 15:27:15 Uhr
Goto Top
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.
14260433693
14260433693 03.09.2024 aktualisiert um 15:49:22 Uhr
Goto Top
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ß
ketanest112
ketanest112 03.09.2024 um 15:51:54 Uhr
Goto Top
Zitat von @14260433693:

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.
14260433693
14260433693 03.09.2024 aktualisiert um 15:54:01 Uhr
Goto Top
Werf mal ProcessMonitor an um zu sehen was im Background schief läuft.
ketanest112
ketanest112 03.09.2024 um 15:54:38 Uhr
Goto Top
Habs auch mal mit nem lokalen Admin ausprobiert, gleicher Effekt.
ketanest112
ketanest112 03.09.2024 aktualisiert um 16:04:36 Uhr
Goto Top
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 Value

Alle 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\AEEventLogLevel

Die enden auch mit Name not Found.
14260433693
14260433693 03.09.2024 aktualisiert um 16:22:06 Uhr
Goto Top
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.
Mr-Gustav
Mr-Gustav 04.09.2024 um 08:48:59 Uhr
Goto Top
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.
ketanest112
ketanest112 05.09.2024 um 16:32:30 Uhr
Goto Top
@14260433693 und @Mr-Gustav
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.
Mr-Gustav
Mr-Gustav 06.09.2024 um 13:11:05 Uhr
Goto Top
Ich würde sagen das hier die "Server Authentication" fehlt denn eine Digitale Signatur ist kein SSL Zertifikat was ein Webserver nutzen kann.
ketanest112
ketanest112 06.09.2024 um 13:18:15 Uhr
Goto Top
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.

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.