olc

Hi, das, was Du suchst, ist ein "Metadata Cleanup". Die Suchmaschine Deiner Wahl wird Dir entsprechende Hinweise zum Stichwort liefern. Des weiteren sollte das Computerkennwort des DCs und das krbtgt Konto in der Testumgebung zurück gesetzt werden, damit verringerst Du das Risiko, daß der Test DC doch mal Kontakt zu den anderen DCs aufnimmt. Dafür gibt es noch andere Möglichkeiten, aber die laß ich an dieser Stelle einmal bewußt raus. DNS Bereinigung, DNS TCP/IP Einstellungen auf dem Test DC und FSMO Rollen Übertragung ist obligatorisch. Aber ganz ehrlich: Ich habe schon ab und an gesehen, daß es mit dem "Clonen" *massive* Probleme gab, weil irgendwann der Test DC doch mal Verbindung zum produktiven Netz hatte usw. Wenn Du also nicht *ganz genau* weißt, was Du tust, dann laß es lieber oder nimm einen erfahrenen Dienstleister zur Hand. Mal abgesehen von den sicherheitsrelevanten Fragestellungen, wenn Du eine Kopie Deiner AD in einer Testumgebung betreibst. Inkl. aller SIDs und Kennworthashes usw. usf. Bitte nicht falsch verstehen, ich meine es nur gut. Viele Grüße olc

Hi zusammen, Der RODC wird bei aktivierter Kennwortreplikation für den Benutzer das Kennwort von einem RWDC wieder replizieren. Von daher speichert der RODC das Kennwort auch nach einer Änderung oder wie genau meinst Du das? Der Guide hat nichts damit zu tun, ob es eine "Empfehlung" oder ein "gängiges Szenario" ist. Vielmehr geht es eher darum, wie man die Firewall konfigurieren muß, was Vor- und Nachteile dieses Szenarios sind usw. D.h. der Guide ist kein Indiz dafür, daß es ein "sinnvolles" Anwendungsbeispiel ist. Dann kannst Du auch auf AD LDS in Verbindung mit Proxy-Objekten setzen, siehe dazu auch den Hinweis von "demtzger". Guter Thread - ich würde in dem Szenario ebenfalls eher auf AD LDS setzen, da scheinbar ausschließlich LDAP binds notwendig sind. Dabei sollte ein SSL bind eingesetzt werden. Mit ADAMsync können auch Proxy Objekte automatisch beim synchronisieren erzeugt werden, das vereinfacht das ganze ungemein. Viele Grüße olc

Hi Mao, bitte ins DFSR Eventlog schauen, nicht in die Debug Logs. Wenn Du nicht weißt, wie Du die lesen mußt, dann wird es schwierig... Ansonsten noch die Frage, welche Zusatzsoftware auf den Systemen installiert ist. "Zufällig" ein Virenscanner bzw. eine Firewall / Endpoint Protection? Ggf. spielt dies hier mit hinein, das habe ich leider schon sehr häufig als Fehlerquelle identifiziert. Viele Grüße olc

Hi tokra, schau einmal hier hinein für den Anfang: Read-only Domänencontroller und Passwörter ? Teil 1 - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Read-only Domänencontroller und Passwörter ? Teil 2 - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Viele Grüße olc

Hi Mao, was hältst Du dann davon, direkt den Microsoft Support oder aber einen Dienstleister zu kontaktieren? Einfach jemanden "remote" an Deine Systeme zu lassen kann mehr Probleme verursachen, als es Lösungen schafft. Viele Grüße olc

Hi, was sagt denn das DFSR Eventlog auf beiden Systemen? Viele Grüße olc

Hi, es gibt keine Office 2003 ADMX / ADML Dateien. Erst ab 2007 waren die dabei. Warum nutzt Du nicht einfach die alten ADM Templates für Office 2003? Binde diese im Gruppenrichtlinieneditor ein, dann erscheinen diese unterhalb der "Classic Administrative Templates" als neuer Knotenpunkt auch unter 2008 / 2008 R2. P.S.: Wenn man an Support und Fixes denkt, ist Office 2003 keine gute Wahl mehr. Zeit umzusteigen... Viele Grüße olc

Hi Ivey, ja - ein wenig irreführend. Der Hintergrund ist jedoch der: Die Zuordnung vom privaten Schlüssel zum öffentlichen Schlüssel erfolgt über das Zertifikat. Der Speicher kann nur dann den privaten Schlüssel nutzen, wenn er auch das Zertifikat als Referenz hat - sonst weiß er schlichtweg nicht, zu "wem" der private Schlüssel gehört. Daher mein Hinweis oben, am besten das KRA *.PFX zu importieren, dann hast Du nämlich gleich beide Teile im Speicher. :) Viele Grüße olc

Hi, Du hast oben geschrieben, daß Du das "Zertifikat" im Benutzerspeicher hattest - genau das *ist* der öffentliche Schlüssel, um genau zu sein enthält das Zertifikat den öffentlichen Schlüssel. Den privaten Schlüssel des KRA mußt Du nicht recovern, den hast Du ja beim Erstellen des Zertifikats + privaten Schlüssel irgendwo beantragt und exportiert. Aber gut, hauptsache es läuft nun. ;) Viele Grüße olc

Hi, bitte lies noch einmal meine Zeilen... Ich rede nicht nur vom Zertifikat des KRA, sondern vom *privaten Schlüssel* des KRA. D.h. am besten direkt das *.PFX importieren. Viele Grüße olc

Hi, mit FSRM sollte das möglich sein: File Server Resource Manager Viele Grüße olc

Hi, die Frage nach dem Key Recovery Agent Zertifikat habe ich oben schon gestellt. 3 Stunden testen können 2 Minuten lesen ersparen... Den Schlüssel mußt Du ja irgendwo erstellt haben - vielleicht auf der CA? Ggf. kannst Du die "request Maschine" herausfinden, indem Du wie folgst vorgehst und Dir die Benutzerkosten auf der Maschine anschaust: Von welchem Client aus wurde eine Benutzer-Zertifikatanforderung durchgeführt? - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Viele Grüße olc

Alles Gute auch von mir! :) Viele Grüße olc

Hi zusammen, Nur um es noch zu erwähnen: Bei 3 Kopien wäre es für einen Angreifer "einfacher", eine der Kopien in seine Gewalt zu bringen. D.h. hier zählt eher die Qualität der Sicherung als die Quantität. Bei den Kunden, mit denen ich bisher im PKI Umfeld zusammengearbeitet habe, gibt es daher *nicht* mehrere Kopien. Man kann sich je nach eigenem Lernvermögen ist fast alles hinein arbeiten. Die Frage ist, wie viel Zeit und Energie Du investieren kannst. Erfahrungen mit der Implementierung einer PKI kannst Du jedoch nicht lernen, die mußt Du sammeln. Wenn Du es also richtig machen möchtest für den Moment, würde ich bei dem, was Du schreibst, zu einem erfahrenen Dienstleister raten. 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, welche Meldung bekommst Du denn genau? Mit den angegebenen Informationen kann man nur raten... Welche Befehle hast Du genau genutzt, also inkl. Pfadangabe usw.? Hast Du den privaten Schlüssel und das Zertifikat des Key Recovery Agents im Speicher des Benutzers, der das "recoverkey" durchführt? P.S.: Solche Tests macht man normalerweise, BEVOR ein Recovery wirklich notwendig wird. ;) Viele Grüße olc

...und von mir noch der Hinweis, daß man dafür auch die altbekannten "Restricted Groups" nutzen kann. Jedoch sollte in jedem Fall dabei bedacht werden: Eine Maschine, auf der lokale Administratoren eingerichtet sind, die nicht den Domänen-Admins entsprechen, "gehört" auch nicht mehr den Domänen-Admins und sind aus Sicherheitsperspektive nicht mehr "voll verwaltet" im Domänen-Sinne. Im besten Fall sind also die lokalen Administratoren soweit als möglich zu beschränken, das wird leider häufig unterschätzt. Aber wie Nils schon sagte ist es nicht genau das, was der TO sucht. Viele Grüße olc

Gern. :) Schönes Wochenende und Gruß olc

DLL != Script. ;)

Hi, Group Policy Preferences: Using Group Policy Preferences to Map Drives Based on Group Membership - Ask the Directory Services Team - Site Home - TechNet Blogs Gruß olc

Hi Sebastian und willkommen an Board, :) was finanzierbar ist, liegt im Auge des Betrachters. Schau vielleicht einmal hier hinein: Varonis Products: Data Governance Suite Viele Grüße olc

Hi, so wie ich das auf die Schnelle sehe hängt der entsprechende Thread beim Auflösen eines DNS Namens, den ein Dienst im "Local Service" Kontext anfragt: USERENV(770.774) 20:25:51:125 lpProfileInfo->UserName = <LocalService> [...] USERENV(770.774) 20:25:51:125 GetUserDNSDomainName: Computer is running standalone. No DNS domain name available. [...] USERENV(770.774) 20:27:01:218 LoadUserProfile: Yes, we can impersonate the user. Running as self Prüfe einmal die DNS Konfiguration und stoppe (wenn das nicht hilft) einmal alle "nicht-Microsoft" Dienste. Danach kannst Du prüfen, ob das Problem weiterhin auftritt. Ich meine das Eventlog - Application, System und ab Vista / 2008 den "Group Policy" Channel. Viele Grüße olc

Hi, der von Dir gewählte Logging Modus war nicht korrekt - mit dem Auszug oben läßt sich nichts anfangen. Setz das UserEnvDebugLevel einmal auf HEX "10002" und reproduziere das Problem. Dann kannst Du z.B. mit dem von blub geposteten Tools eine erste Auswertung vornehmen. Das Ereignisprotokoll gibt keine zusätzlichen Hinweise? Viele Grüße olc

Hi carnivore, ich halte es zwar nicht unbedingt für zielführend Aktionen anhand dieses Logontypen durchzuführen (speziell per Script). Ein Weg dafür wäre mir im Moment auch nicht bekannt, schau einmal hier (insbesondere der letzte Post): How To Know Login Type | TheDailyReviewer Viele Grüße olc

Hi Fraat, legt lieber die Subnetze zu diesem Zeitpunkt korrekt an und die entsprechende Site-Konfiguration - ggf. Voreinstellung per Registry. Dann stellt sich die Frage nicht, denn es werden die korrekten DFSN-Targets gewählt. Ein manueller Weg auf dem Client wäre mir nicht bekannt - lediglich auf dem Server können präferierte Targets (first among all targets etc.) festgelegt werden. Aber das greift dann für alle Clients. Viele Grüße olc

Hi Robert, wenn ich mich recht entsinne sind in den Standardeinstellungen gleichzeitig nur 5 Kennwörter für das Enrollment freigegeben. Solange diese also nicht eingesetzt werden, werden auch keine neuen Kennwörter für die Geräte ausgestellt. Das ist die Grenze von "5". Das kann man aber über die Diensteinstellungen verändern. Wenn Dich das ganze Thema näher interessiert, gibt es dazu diverse Whitepaper, die auf das Verhalten eingehen. Falls nur für das Verständnis relevant sollte diese Information reichen. ;) Viele Grüße olc