olc

Hi, schau hier einmal hinein: Userenv errors occur and events are logged after you apply Group Policy to computers that are running Windows Server 2003, Windows XP, or Windows 2000 Ansonsten: Ist ein Symantec Virenscanner installiert? Falls ja deinstalliere (!) ihn testweise einmal und versuche es erneut. Viele Grüße olc

Hi maeck, das Autoenrollment kann per GPO konfiguriert werden - sprich festlegen, ob das Autoenrollment *überhaupt* aktiviert ist oder nicht. Eine andere Einschränkung auf OU Basis gibt es nicht. Aber: Warum veröffentlicht Ihr die Zertifikate nicht bei Ausstellung im AD (Benutzerobjekt Attribut "userCertificate")? Siehe dazu: Configuring certificate publishing in Active Directory: Public Key Sobald das Zertifikat dort veröffentlicht ist und im Template die Option gesetzt wurde, wird kein neues Zertifikat ausgestellt, sobald sich die Admins an den anderen Workstations anmelden. Viele Grüße olc

Hi, zwei Hinweise zur DFSN / DFSR Thematik: Und: Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario Viele Grüße olc

Hi, wird denn wirklich die OCSP URL für die Prüfung verwendet? Wie hast Du das gegengeprüft? Der OCSP Client speichert wie von Dunkelmann erwähnt die Abfrageinformationen zwischen, sofern er in der Vergangenheit eine Antwort zu einem bestimmten Zertifikat / einer Seriennummer erhalten hat (egal ob positiv oder negativ). Du kannst diese Cache-Zeit jedoch anpassen, siehe dazu auch: Außerdem solltest Du die von Dunkelmann angesprochenen CRL Veröffentlichungen nicht vergessen: Nur, wenn die "normale" CRL, auf die der OCSP Server zugreift, die Sperrinformationen enthält, wird er auch die korrekte Information an den Client herausgeben können. Viele Grüße olc

Hi Nizo, ich wiederhole mich ungern, aber noch einmal: Nur, weil 2x DCPROMO das Problem "scheinbar" behoben hat, heißt es nicht, daß es ein Problem mit der DB gibt. Wie Du mit dieser simplen Aktion Deine 100% Sicherheit begründen möchtest ist mir nicht klar. Sofern Du keine Hinweise z.B. in den Eventlogs, innerhalb der NTDSUTIL symantic database analysis o.ä. hast, ist alles andere nur eine Vermutung, die durch nichts bestätigt ist als durch ein DCPROMO. Letzteres kann auch hunderte andere Probleme adressiert haben. P.S.: Warum Dir Kerio bei einem vermeintlichen AD Problem helfen können sollte, ist mir nicht klar. ;) Da wäre der MS Support wahrscheinlich sinnvoller gewesen. Der findet dann auch ggf. Probleme in der AD Datenbank, sollte es diese tatsächlich gegeben haben / geben. P.P.S.: Daß Du den letzten DC nicht demoten kannst aufgrund der AD CS Installation zeigt einmal mehr sehr schön, warum man keinen Rollenmix auf einem System einsetzen sollte... Viele Grüße olc

Hi, jetzt sehe ich erst, daß Du 3 Mal verschiedene Threads mit dem Thema belastet hast. Das ist nicht gut und Du solltest in Zukunft vielleicht diese Art und Weise überdenken. Auch hier noch einmal der Hinweis, daß es meines Erachtens nicht an der AD DB lag. Wenn den Thread hier einer liest, dann wird er u.U. auf die falsche Fährte geführt, sollte er der AD DB These folgen. Daher der Hinweis. Falls Du einen konkreten Grund außer dem DCPROMO äußerst, der auf die AD DB hinweist (etwa Ereignisprotokoll-Meldungen, sematic database analysis o.ä.), dann könnte man darüber noch einmal nachdenken. Vermutlich hast Du per DCPROMO nur nebenbei das darunter liegende Problem behoben. Viele Grüße olc

Hi, der Fehler lag mit sehr hoher Wahrscheinlichkeit *NICHT* an der AD DB. Die oben genannten 5 Punkte zeigen in vollkommen andere Richtungen. Vermutlich hast Du diese nur "nebenbei" mit dem DCPROMO ebenfalls mit erledigt. Dennoch danke für die Rückmeldung. Viele Grüße olc

Hi, also meine bevorzugte Suchmaschine gibt mir so ziemlich als erste Antwort die Lösung auf Deine Frage... ;) Migrate a Domain-based Namespace to Windows Server 2008 Mode Viele Grüße olc

Gern, melde Dich bei Fragen. :) Viele Grüße olc

Hi, Ihr habt das Autoenrollment aktiviert, jedoch scheint das anfragende System keine Verbindung zur CA aufnehmen zu können. Entweder es liegt eine Firewall o.ä. dazwischen oder es wurde etwas an den DCOM Berechtigungen verdreht. Viele Grüße olc

Hi, Microsoft geht in seinen best practices davon aus, daß Du eine offline Root CA und eine (issuing) Subordinate CA betreibst. In diesem Fall benötigt die Root CA keine CRL Lokationen *im eigenen* Zertifikat, da sich dieses ja nicht gegen sich selbst revozieren läßt. Im Zertifikat der SubCA, welches durch die Root CA ausgestellt wird, ist dann der CDP für die CRL der Root CA enthalten. Ich vermute, da liegt das Verständnisproblem. :) Daß auf den Clients 2 Root-Zertifikate liegen (also Nummer 0 und Nummer 1) ist also durch Deine Erneuerung des Root CA Zertifikats korrekt und im Grunde stört es ja auch nicht. ;) Viele Grüße olc

Hi, warum möchtest Du das Zertifikat unbedingt weg bekommen? Du benötigst das Zertifikat "0" weiterhin, da die alten Zertifikate mit diesem Schlüssel signiert wurden. Entfernst Du es, kann durch die CA keine CRL gegen diese alten Zertifikate ausgestellt werden und es kommt zu Problemen. Es gibt keinen technischen Grund, der für die Entfernung des alten Zertifikats spricht. Laß es also am besten einfach so, wie es ist. ;) Viele Grüße olc

Hi, Du mußt noch auf dem AD Container "CN=Policies,CN=SYSTEM,DC=domain,DC=tld" die Einstellung vornehmen, daß überwacht werden soll. D.h. die ACL (genauer: SACL) anpassen. Siehe dazu auch: HOW TO: Audit Active Directory Objects in Windows Server 2003 . BTW: Richtig viel Freude hast Du mit dieser Art der "Gießkannenüberwachung" sicher nicht. Wenn Du es "richtig" machen möchtest, schau Dir einmal Zusatzprogramme wie den Quests GPOAdmin oder Microsofts AGPM an. Viele Grüße olc

Hi André, willkommen bei uns, :) führe die CMD, von der aus Du das GPRESULT Kommando absetzt, einmal "elevated" aus. Also Rechtsklick auf die CMD und "als Administrator ausführen" wählen. Viele Grüße olc

Hi, ich verstehe Dein Problem einfach nicht. Tut mir Leid. Der IE holt sich die Zertifikate natürlich nicht einfach so in den vertrauenswürdigen Root Certification Authority Speicher - sonst hätte das ganze Zertifikatthema keinen Sinn. Daher verteilst Du die Root Zertifikate ja per AD, GPO o.ä. - und Du bestätigst ja, daß es damit funktioniert. Also wo liegt das Problem? Viele Grüße olc

Hi dreissigd, willkommen bei uns im Forum, :) korrekt, Antwort C ist die richtige. Da sich die beiden (stand alone) Instanzen gegeneinander authentifizieren müssen, benötigen sie einen gleichen Servcie Account. Mit dem Netzwerkdienst wäre dies nicht möglich. Beide Maschinen werden also mit einem gleichnamigen Service Account ausgestattet, der das selbe Kennwort erhält. Alternativ in Domänenumgebungen einen AD Account, dann haben beide Instanzen den Zugriff auf die notwenigen Account Informationen. Viele Grüße olc

Hi, dann ist im Webinterface eine andere Schlüsselgröße angegeben, als diejenige, die im Template definiert wurde. Die beiden Werte müßtest Du aneinander angleichen, dann sollte es klappen. Auf den ersten Blick hat das nichts mit der Gültigkeitsdauer zu tun. Die hast Du nach Deinen Ausführungen oben korrekt verändert (vorletzter Post von Dir). :) Viele Grüße olc

...die als "vertrauenswürdige Instanz" anzusehen ist. Wenn die Organisations-Admins nicht vertrauenswürdig sind, dann sollten sie nicht Org-Admin sein. Das ist nicht neunmalklug gemeint - aber wie schon von Nils angesprochen gibt es keine andere sinnvolle Lösung für diese Thematik außer getrennten Forests. Viele Grüße olc

Hi, sichern kannst Du wie folgt: Back up a certification authority: Public Key ("certutil.exe -backup"). Dazu noch die Registry Schlüssel des "CertSrv" Zweigs unter HKLM\System\CurrentControlSet\Services\CertSrv. Alles andere (VM Sicherung usw.) kannst Du zusätzlich machen. Mit Deiner anderen Frage kann ich nichts anfangen - Du mußt ein wenig genauer beschreiben, was konkret Du an Reg-Schlüsseln angepaßt hast, ob Du die CA danach neu gestartet hast und was danach passiert ist, als Du ein angepaßtes Template für die Zertifikatausstellung genutzt hast. Viele Grüße olc

Hi, falls Du eine Intel Grafikkarte hast, schau auch einmal hier hinein: Reported issues with Flash Player 10.3 and Internet Explorer 9 « Adobe AIR and Adobe Flash Player Team Blog Viele Grüße olc

Hi, Templates sind in Deinem Szenario nicht notwendig - Du möchtest ja vorhandene Zertifikate verteilen. Du bestätigst also, daß die Root Zertifikate im lokalen Computer Speicher für Root Zertifikate liegen? Falls ja schaut sie der IE auch an. Ohne eine genaue Fehlermeldung / Problembeschreibung wird das hier aber nichts... P.S.: Ich meine es wirklich nicht böse - aber ich denke, wir kommen hier so nicht weiter. Hast Du Dir ein paar Grundlagen zum Thema bei MS angelesen? Viele Grüße olc

Hi, noch einmal die Frage, was "geht nicht" heißt - liegen die Zertifikate im "Trusted Root Certification Authority" Speicher der Clients oder nicht (öffne die MMC, Snapin "Certificates" --> local computer)? Ist Autoenrollment aktiviert (bei LDAP Verteilung)? Die Erklärung für Firefox hast Du ja schon erhalten. Usw. Viele Grüße olc

Hi, WMI Filter halte ich für nicht sinnvoll in diesem Szenario - das ganze läßt sich mittels Sicherheitsfilterung au fdie Gruppenrichtlinien eleganter lösen. Dazu müssen die Benutzer dann in die entsprechenden Gruppen, die die Abteilung darstellen. Siehe auch (erstes Beispiel): Security Filtering, WMI Filtering, and Item-level Targeting in Group Policy Preferences - Group Policy Team Blog - Site Home - TechNet Blogs Viele Grüße olc

Hi, der Artikel ist von mir, getestet wurde also korrekt. ;) Schau direkt einmal in die Syntax der BROFMON Dateien - da die Fehlermeldung auf einen fehlerhaften SchTasks.exe Befehl hinweist, könnte man dies gegenprüfen. Ich vermute fast, daß es ein Problem mit der Sprache des Betriebssystems gibt - schau einmal hinein, ob in der BROFMON Datei irgend etwas von "monthly" oder "last date" oder ähnliches steht - da könnte auf Deinen deutschen Systemen das Problem liegen. Viele Grüße olc

Hi, mit dem Firefox wirst Du kein Glück haben, der bringt eine eigene Liste an Root-Zertifikaten mit und nutzt meines Wissens nicht die Windows Container. Beim IE sollte es klappen mit der Verteilung per GPO oder LDAP - in letzterem Fall muß jedoch das Autoenrollment aktiviert sein (Computerteil per GPO), sonst funktioniert der Download nicht. An den Enrollment Container solltest Du nicht ran gehen, zumindest nicht in Deinem Fall. Der hat damit nichts zu tun. Sofern Du eine genauere Beschreibung von "geht nicht" gibst (etwa, ob das Zertifikat gar nicht im lokalen "Trusted Root Certification Authority" Container ankommt oder ob nur der Browser nichts erkennt, können wir Dir vielleicht weiterhelfen. Viele Grüße olc