olc

Hi, warum möchtest Du unbedingt einen WMI Filter verwenden? Gibt es einen konkreten Grund dafür? Von der Abarbeitung ist ein Security Filter schneller. Viele Grüße olc

Ja, Du solltest das AD vorher säubern - auch, wenn die Namen dieselben sein sollten: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000 Viele Grüße olc

Hi, die Punkte bekommst Du gar nicht mehr weg - die Zertifikate müssen solange verfügbar sein, bis das letzte Zertifikat abgelaufen ist, daß auf Basis dieses Root oder Issuing CA Zertifikat ausgestellt wurde. Das Sperren eines alten Zertifikats kann eigentlich nicht die Ursache sein. Und damit solltest Du bei CAs auch vorsichtig sein - sperrst Du ein CA Zertifikat, sind ab diesem Zeitpunkt alle Zertifikate ungültig, die durch diese CA (bzw. durch dieses Zertifikat / private key) ausgestellt wurden. Wenn Du auf Stammzertifizierungsstelle klickst siehst Du die Verteilungspunkte, auf die Issuing CAs zugreifen werden (da diese in den Issuing CA Zertifikaten stehen). Wenn Du auf Issuing CA klickst siehst Du die URLs, die in den Client / User Zertifikaten stehen werden. Und ob diese erreichbar sind. ;) Viele Grüße olc

Hi, das ist genau der Punkt - wenn Du ein neues Zertifikat inkl. eines neuen privaten Schlüssels ausstellst, dann werden auch neue CRLs und Delta CRLs ausgestellt - deshalb siehst Du den Punkt jetzt 2x. Dann warst Du die ganze Zeit schon auf dem richtigen Weg - nur fehlte Dir der Transfer dahingehend, daß Du ein Zertifikat neu ausstellen mußt, damit die URLs verändert werden können (egal ob mit oder ohne private key). Daher ist es auch recht wichtig, vor der Inbetriebnahme einer CA die URLs zu prüfen - sonst wird es schnell unübersichtlich (wie bei Dir im Moment in der Testumgebung). Viele Grüße olc

Jau, das Root CA Zertifikat sieht gut aus. Keine URLs vorhanden. Doch, eigentlich schon. Erneuern oder neu aktualisieren resultiert immer in einem neuen Zertifikat. Daher sollte im neuen Zertifikat nur noch die gewünschte URL auftauen. Die Root CA selbst hattest Du nacvh der Änderung an den Einstellungen auch schon einmal neu gestartet, korrekt? Gern. ;) Viele Grüße olc

Hi, ok, dann würde ich sagen, daß Du das Issuing CA Zertifikat noch nicht neu ausgestellt hast, nachdem Du auf der Root CA die Änderung durchgeführt hast (also die LDAP oder HTTP URL entfernt hast) - denn das Datum des Zertifikats ist vom "05.02.2010 18:07". Oder das ist der Dump des falschen Zertifikats, also eines alten Issuing CA Zertifikats. Kann es sein, daß wir ein wenig aneinander vorbei reden? ;) Du weißt, daß Du bestehende Zertifikate nicht ändern kannst, sondern diese neu ausstellen mußt? Wie sieht es mit dem Root CA Zertifikat aus? Auch ein Dump verfügbar? Viele Grüße olc

Hi, dann hast Du scheinbar doch AIA und CDP im Root CA Zertifikat hinterlegt. Wir drehen uns im Kreis. Anders: Poste bitte einmal die Ausgabe von C:\> certutil -v -dump RootCA.cer C:\> certutil -v -dump IssuingCA.cer "RootCA.cer" und "IssuingCA.cer" sind dabei die jeweils exportierten Zertifikate der Root und Issuing CA. Darin kann man dann sehen, ob AIA oder CDP URLs eingetragen sind. Falls ja, dann muß das Root CA Zertifikat ohne diese URLs mittels CAPolicy.inf Datei neu erstellt werden. Falls nicht, schauen wir weiter. Viele Grüß olc

Hi, wenn die Verteilungspunkte des Root CA Zertifikats jetzt schon leer sind, dann brauchst Du die CAPolicy.inf natürlich nicht mehr anlegen / anpassen. ;) Ich hatte es so verstanden, daß auch das Zertifikat der Root CA derzeit (ungewünschte) URLs enthält. Viele Grüße olc

Hi toasti, noch einmal Schritt für Schritt: 1. Root CA Das Zertifikat der Root CA enthält im Normalfall keine AIA und keine CDP. Wenn das Zertifikat der Root CA also diese Verteilungspunkte nicht enthalten soll, mußt Du diese über die CAPilcy.inf Datei als leer markieren. 2. Issuing CA Die Issuing CA bekommt in ihr Zertifikat diejenigen Verteilungspunkte, die Du auf der Root CA in den CA Eigenschaften festgelegt hast. D.h. die Root CA stellt das Issuing CA Zertifikat aus - daher muß die Einstellung auf der Root CA durchgeführt werden. 3. Ausgestellte Zertifikate der Issuing CA Die von der Issuing CA ausgestellten Zertifikate enthalten diejenigen URLs, die Du in den Eigenschaften der Issuing CA definiert hast. Sollen also die ausgestellten Zertifikate für Benutzer und Clients keine LDAP URL o.ä. bekommen sollen, dann mußt Du auf der Issuing CA diese URLs deaktivieren und die Benutzer bzw. Computer Zertifikate neu ausstellen. Viele Grüße olc

Hi Dustin, besten Dank für die Rückmeldung. Dann solltest Du Dir jetzt einmal Gedanken machen, wer die Berechtigungen dort verdreht hat - automatisch passiert das im Normalfall nicht. ;) Viele Grüße olc

Hi, ok - versuche einmal testweise das Zertifikat in den "Trusted Root Certificate Authorities" Speicher des Computers zu importieren (MMC --> Add Snap-in --> Certificates --> Computer account); funktioniert es dann? Viele Grüße olc

Hi toasti, Nicht meine Worte durcheinander bringen ;) : Nicht empfehlenswert ist es, in den CA Eigenschaften keine AIA / CDP Lokationen anzugeben. Denn dann würden die von der CA ausgestellten Zertifikate keine Möglichkeit zum revocation check bekommen. Die Einstellung gilt jedoch nicht für die Root CA selbst, daher bringt Dir die Aktion nichts (zumindest nicht für das Root CA Zertifikat). In den von der CA ausgestellten Zertifikaten verschwinden die URLs, nicht aus dem Root CA Zertifikat. Wie gesagt, wenn Du die Verteilungspunkte im Root Zertifikat selbst verändern möchtest, mußt Du eine CAPolicy.inf Datei verwenden und das Zertifikat der Root CA erneuern (siehe Link oben). Wenn man sonst nichts damit zu tun hat, ist der Einstieg sicher nicht einfach. Aber das ist doch eigentlich bei jedem Thema so - nur die Lernkurve ist bei PKI Themen recht steil. ;) Viele Grüße olc

Hi, die Bereitstellung der AIA / CRLs sind in so einem Migrationsszenario eines der kritischsten Punkte. Es gibt dazu übrigens auch einen Migration Guide, der die problematischen Punkte inkl. Lösungsvorschläge anspricht: http://www.microsoft.com/downloads/details.aspx?FamilyID=c70bd7cd-9f03-484b-8c4b-279bc29a3413&displaylang=en Darin findet man auch Hinweise, wie man eine CA weg von einem DC umziehen kann (oder anders herum). Viele Grüße olc

Hi, was sagt denn ein "certutil -v -store Root > root.txt" bzw. "certutil -v -store AuthRoot > authroot.txt"- wird das Root Zertifikat angezeigt oder taucht es nach dem Import nicht in den Exporten auf? Importierst Du das Zertifikat in den Benutzer Root Speicher angemeldet als der Benutzer, der es "nutzen" soll oder als anderer Benutzer? Wenn es ein anderer als der angemeldete Benutzer nutzen soll, dann müßtest Du es in den Computer Speicher speichern, nicht in den Benutzer Speicher. Viele Grüße olc

Hi pastors, ganz genau - der Filter war also "negativ". ;) Es macht sich zu Testzwecken immer gut, die Filter zuerst auf einem potentiellen Zielsystem zu testen (etwa mit PowerShell "Get-WMIObject -query" oder mit WMIC), dann sieht man, was als Ergebnis des Filters herauskommt. :) Viele Grüße olc

Hi, so richtig verstanden habe ich das Problem ehrlich gesagt nicht. Daher noch einmal die Nachfrage: Du möchtest die AIA und CDP Lokationen aus dem Zertifikat Deiner Root CA "entfernen", korrekt? Für von der Root CA ausgestellte Zertifikate funktioniert es (wobei das in den meisten Fällen nicht empfehlenswert ist), aber die Root CA selbst hat auch nach der Neuerstellung des Root CA Zertifikats die URLs weiterhin im Zertifikat. Habe ich das korrekt verstanden? Falls ja, dann wäre das "normal" - Du kannst die Verteilungspunkte, die die Root CA in Ihr Zertifikat einträgt, nicht über die GUI regeln, über die Du die Einstellungen für die auszustellenden Zertifikate setzt. Du benötigst dafür eine "CAPolicy.inf" Datei, siehe dazu: CAPolicy.inf Syntax In den Beispielen des Technet Artikels siehst Du, daß die AIA und CDP Einträge leer gelassen werden: [CRLDistributionPoint] [AuthorityInformationAccess] Solltest Du jetzt das Root Zertifikat neu erstellen, dann bedenke dabei, daß ausgestellte Zertifikate auf das alte Root CA Zertifikat / den Private Key Thumbprint etc. verweisen. Daher werden die damit ausgestellten Zertifikate auch weiterhin Probleme melden. Ich bin mir gerade nicht sicher - aber wenn Du den alten privaten Schlüssel der Root CA für die Zertifikaterneuerung der CA nutzt, könnte es klappen. Kannst das ja einmal testen. ;) Viele Grüße olc

Hi pastors, der WMI-Filter wurde offensichtlich ausgeführt - das Ergebnis war dann die Verweigerung der GPO-Anwendung aufgrund des Filters. Wenn Du das Betriebssystem, den Filter und ein paar mehr Informationen geschrieben hättest, wie Deine Umgebung aussieht, hätte man vielleicht auch mehr Hinweise geben können. ;) Viele Grüße olc

Hi toasti, die Frage von Dir geht in eine vollkommen andere Richtung als die Themen oben - ein neuer Thread wäre also durchaus sinnvoll. ;) Hast Du den CA Dienst nach den Änderungen neu gestartet? Viele Grüße olc

Hi Gruffy, der Link von Dir ist sehr gut - nur sollte man dabei beachten, daß es sich noch um eine "Beta" Version handelt. Es kann also durchaus noch kleinere Ungenauigkeiten darin geben. An Literatur findet man bei Microsoft schon recht vieles kostenfrei. Sehr gut ist meiner Meinung nach (neben den ganzen CA und PKI Whitepapern) folgender Artikel: Certificate Revocation and Status Checking Man beachte auch die Linkliste unten in dem Artikel. ;) Das Whitepaper gibt es mittlerweile auch für Vista / 2008 (mit den entsprechenden Neuerungen). Ansonsten wird in diesem Kontext meist Brian Komar genannt: http://www.microsoft.com/learning/en/us/book.aspx?ID=9549&locale=en-us . Ich finde die PKI Reihe eigentlich auch recht gut für den strukturierten Einstieg in das Thema. [EDIT] Daim war schneller. :) [/EDIT] Viele Grüße olc

Hi, schau Dir unten die Kommentare in dem von Norbert verlinkten Artikel an - der Link führt Dich zu einem Whitepaper, welches auf diese Frage eingeht. Erst ab Windows Server 2008 und höher ist ein rename grundsätzlich möglich, jedoch hat das diverse Implikationen, die Du beachten solltest. Auch dazu findest Du Hinweise in dem Whitepaper. Viele Grüße olc

Hi, versuch einmal, die Domäne vor dem Benutzernamen mit anzugeben, also etwa "CONTOSO\NASUser" bzw. NASUser@contoso.com. Viele Grüße olc

Hi, wichtig ist, daß Du die Prozesse und Threads im UserEnv Log beachtest. Aber in Deinem Fall wäre es ja schnell getestet - entferne die Datei aus dem Autostart oder deaktiviere die dazugehörigen Dienste und prüfe, ob die Verzögerung dann immer noch neu auftritt. MSCONFIG und "alle Microsoft Dienste ausblenden" ist Dein Freund. ;) Viele Grüße olc

Moin, genau - daher auch oben meine Frage, ob es teurer wäre, einen neuen Request zu starten. :) Viele Grüße olc

Hi, Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path" --> Methode 1. Dort registrierst Du den CNAME. Viele Grüße olc

...ich habe übrigens gerade noch einmal geschaut: Die City/locality wird doch auch beim IIS 6 Zertifikat Wizard abgefragt (ebenso wie beim IIS 7) - letzter Dialog. Oder habe ich das Problem falsch verstanden? Beschreibe doch noch einmal ganz konkret, wie Du vorgegangen bist. Schritt für Schritt. ;) Viele Grüße olc