olc

Hi Eric, Wenn das Ereignisprotokoll nichts liefert, wird es schwer mit der Suche. Mir fällt da im Moment ehrlich gesagt nichts ein... Bringt ein "certutil -pulse" etwas? Viele Grüße, olc

Hi, bevor Du da nach anderen Produkten suchst, lese (und verstehe ;) ...) den folgenden Blog: Understanding (the Lack of) Distributed File Locking in DFSR - Ask the Directory Services Team - Site Home - TechNet Blogs Insgesamt ist eine dickere WAN Leitung + SharePoint o.ä. aus meiner Sicht die bessere Alternative. Viele Grüße olc

Gern, melde Dich einfach bei Rückfragen dazu. :) Viele Grüße olc

Hi, zu filtern, welche Attribute das Flag *nicht* gesetzt haben, sollte mit einem LDAP Filter möglich sein. Welche Attribute das Flag setzen *können*, halte ich da schon für schwieriger. Ich bin mir gerade nicht sicher, ob man das irgendwie anhand der Schema-Definition des Attributs erkennen kann, wäre aber sicherlich denkbar. Generell stellt sich mir die Frage, warum man so eine "Positivliste" überhaupt erstellen sollte. Es sollte im Unternehmen einen Anfragekatalog geben, welche Attribute *nicht* repliziert werden sollen. Und genau diese Attribute würde ich dann prüfen. Alles andere wäre meiner persönlichen Meinung nach overkill - denn wer will denn eine Ergebnisliste mit *möglichen* (übertriebenen) 20 Millionen Attributen prüfen? Hat m.E. keinen Sinn. Außerdem stellt sich generell die Frage: - Wenn am Ende kaum noch Attribute repliziert werden sollen - will ich dann tatsächlich einen RODC in die entsprechende Lokation stellen? - Müssen die Attribute dann generell überhaupt im AD vorhanden / befüllt sein? - Kommen all meine LDAP Applikationen am RODC Standort überhaupt ohne die Attribute zurecht oder gibt es Probleme / Fehler? - ... Viele Grüße olc

Hi, ist Deine Frage rein akademischer Natur oder wurde das Trust Kennwort tatsächlich nicht verändert? :) Wie hast Du das geprüft - über die Metadaten des Trust-Objekts? Auf beiden Seiten müssen sich die PDCs erreichen können. Diese benötigen dann einen sicheren Kanal (also generell RPC Zugriff) zueinander um das Kennwort ändern zu können. Viele Grüße olc

Hi, wenn es keine Ereignisprotokolleinträge gibt, wird es unter XP schwer die Ursache zu finden. Sicher, daß da nichts ist? Was sagt ein Netzwerktrace, auf LDAP gefiltert während einem 3x hintereinander ausgeführten GPUPDATE? Viele Grüße olc

Hi, Du hast es doch vollkommen richtig beschrieben. ;) Der RODC registriert standardmäßig nur SRV Einträge in der eigenen Site. Das ist auch wünschenswert so, denn wenn er generische Einträge registrieren würde, würden Clients ohne Subnetz (oder ohne erreichbaren DC im Subnetz) ggf. über die generischen _tcp Einträge auf einem RODC landen, was man im Normalfall nicht möchte (keine gecachten Kennwörter, ggf. nicht erreichbar per Netzwerk usw.). Die RWDCs jedoch sollen ja bei einem "fallback" auf die generischen _tcp Einträge erreichbar sein - deshalb registrieren sie sich dort. Jedoch kannst Du auch das verändern, sollte das notwendig werden. Siehe dazu auch: 7.3.1.10 DNSRegistrationSettings Viele Grüße olc

Hi Eric, was genau ist im AD veröffentlicht und vor allen Dingen wo? Am besten Du postest hier einmal einen Export der LDAP Daten (Public Key Container im Configuration NC). Ist auf dem betroffenen Client das Autoenrollment aktiviert (etwa per GPO)? Gibt es Fehler im Ereignisprotokoll? Wenn es sich nur um ein System handelt: Ist es die Mühe wert, das Problem zu verfolgen? Oder ist vielleicht eine Neuinstallation (mit einem aktuellen Betriebssystem) die "billigere" Alternative? Viele Grüße olc

Hi, der NETLOGON Dienst übernimmt diese Prozedur - mittels normaler RPC Kommunikation / secure channel. Im Kern gleich dem Vorgehen beim Ändern eines Computerkennworts. Was genau interessiert Dich denn an dem Thema bzw. worauf möchtest Du hinaus? :) Viele Grüße olc

Hi, einmal anders gefragt: Welche Attribute möchtest Du denn filtern? Außerdem solltest Du die searchFlags der Attribute ändern, nicht die systemFlags, um den FAS zu verändern. Siehe dazu auch: Appendix D: Steps to Add an Attribute to the RODC Filtered Attribute Set . Viele Grüße olc

Hi, wie genau hast Du den Sync denn nun hinbekommen? Wie gesagt, wenn Du mehrere Durchläufe machst, kann es mit den AD LDS Cookies Probleme geben. Habe ich noch nicht getestet. Was führst Du wie genau aus, bevor die Objekte verschwinden? Viele Grüße olc

Hi, ja, das war meines Wissens unter 2003 noch anders. Jedoch gibst Du mit der Base-DN ja an, was synchronisiert werden soll, also auch die OU, die in der ADAM Zielpartition genutzt werden wird. Von daher sehe ich eigentlich kein Problem. Rein theoretisch könntest Du als Alternative vor jedem Sync-Vorgang eine andere XML Datei einlesen - ich bin mir jedoch nicht sicher, daß es hier zu keinen Problemen mit den ADAMsync Cookies kommen würde oder Daten ggf. auch überschrieben werden. Ich habe schon etwas länger keine Tests mit ADAMsync durchgeführt - versuch es doch einmal mit mehreren XML Konfigurationen, die Du vor jedem Sync Vorgang mittels "/install" initialisierst. Oder Variante 1 - ob die Base OUs im Ziel ebenfalls mit angelegt werden. Alles natürlich in Deiner Testumgebung. ;) Sollte das alles mit ADAMsync in einer Partition nicht klappen, bleibt immer noch die "ausgewachsene" Lösung: Lifecycle Manager wie etwa der FIM. Viele Grüße olc

Hi, ok, hatte ich selbst nicht auf dem Schirm, scheinbar mußt Du als Target ab 2008 direkt den partition head angeben, siehe dazu: In Deinem Fall also: <?xml version="1.0"?> <doc> <configuration> <description>Test - Syncfile</description> <security-mode>object</security-mode> <source-ad-name>DC1.test.dom</source-ad-name> <source-ad-partition>dc=test,dc=dom</source-ad-partition> <source-ad-account>saadlds</source-ad-account> <account-domain>TEST</account-domain> <target-dn>dc=test,DC=adlds</target-dn> <query> <base-dn>ou=deine_ou,dc=test,dc=dom</base-dn> <object-filter>(|(objectClass=user))</object-filter> Viele Grüße olc

Hi, vermutlich gibt es ein Problem, da Du versuchst, eine komplette Domäne in eine Ziel-OU zu synchronisieren. Unterhalb von OUs kannst Du mit dem "standard" Schema meines Wissens keine Container anlegen, wie es bei "CN=Builtin" usw. der Fall ist. Ich vermute der Fehler kommt daher. Versuche einmal zur Fehlereingrenzung, als Quelle den BaseDN auf eine konkrete OU anzupassen: "<base-dn>OU=DeineOU,dc=test,dc=dom</base-dn>". Außerdem kannst Du mittels ADAMsync "/log" Parameter eine Logdatei erzeugen, die genaueren Aufschluß auf den Fehler gibt. Ich bin jedoch recht sicher, daß es an der oben angesprochenen Problematik liegt. Viele Grüße olc

Hi, das geht schon, nur passen Deine Angaben hier irgendwie nicht zusammen: <source-ad-partition>[color="Red"]dc=test,dc=dom[/color]</source-ad-partition> <source-ad-account>saadlds</source-ad-account> <account-domain>TEST</account-domain> <target-dn>ou=Benutzer,dc=test,DC=dom</target-dn> <query> <base-dn>[color="Red"]dc=life,dc=dom[/color]</base-dn> Viele Grüße olc

...genau. Was Du sagst, ist ebenso vollkommen korrekt. :) Schönen Abend Euch, viele Grüße olc

@Yusuf: Vrweg sei gesagt, daß ich mich wie gesagt mit dem Schlüssel irrte. D.h. er wird wie angesprochen nicht überschrieben. Ich meinte "Repl Perform Initial Synchronisations", aber das tut hier nichts zur Sache. Um Auf die Frage zurück zu kommen: Nach einem auth sysvol restore möchtest Du, daß der entsprechende DC authorativ ist, d.h. die DB neu aufbaut und seine Daten an die anderen DCs übertragen werden. Würde - direkt nach der Wiederherstellung der Daten, die Du authorativ zu den anderen DCs replizieren möchtest - der DC nicht im D4 Modus starten, würden ggf. Daten von anderen DCs zuerst "zurück" zum eigentlich authorativen DC repliziert werden. Folgt nun das D4, hast Du nicht mehr den Status des wiederhergestellten Backups, sondern schon wieder Änderungen. Oder gar Löschungen. Das nachträgliche Setzen von D4 kann Dir also den sauberen Backup Status verhageln. Nachvollziehbar? Viele Grüße olc

Hi zusammen, @Yusuf: Damit der DC schlichtweg nicht beim ersten Reboot als nicht authorativer Partner versucht, die Daten von einem anderen DC zu replizieren. Dann würden die wiederhergestellten Daten überschreiben. Wenn - wie Larry sagte - D4 korrekt bestehen bleibt (auch nach dem Reboot, so wie es sein sollte), dann entfällt der Schritt natürlich. @Larry: Mein Fehler, mir ist gerade aufgefallen, daß ich den Schlüssel "Repl Perform Initial Synchronisations" meinte, nicht die Burflags. Sorry für die Verwirrung. :) Deiner Aussage entnehme ich, daß Du das fragliche Vorgehen nun erfolgreich getestet hast? Alle Fragen geklärt? ;) Viele Grüße olc

Hi Larry, über welches Wiederherstellungsszenario redest Du - es existieren noch funktionstüchtige DCs (in dem Fall D2/d4 wie unter 2003) oder geht es um ein domain recovery, also keine anderen DCs existieren mehr in der Domäne (authsysvol). Authsysvol greift auch für FRS, siehe dazu: Performing a Nonauthoritative Restore of AD DS --> Problem kann hierbei nur werden, daß der D4 Wert beim Restart wieder überschrieben wird, da ja der Systemstate zurückgesichert wurde und damit beim Neustart auch der Schlüssel überschrieben wird. Meines Erachtens ein Fehler in der Logik des Restores. Daher nach dem Authsysvol noch einmal in den DS Restore Modus fahren, den D4 Schlüssel manuell setzen, neu starten. Damit sollte es klappen. Insgesamt ist es empfehlenswert, ab Domänenmodus 2008 die FRS zu DFSR SYSVOL Migration durchzuführen. Viele Grüße olc

Hi, Das ist in diesem Fall nicht notwendig, es sind ja keine Leerzeichen vorhanden. Certutil ist alles, nur nicht "simpel". ;) Und mit Punkten im Namen kommen im Normalfall alle aktuellen Programme zurecht - so auch certutil. Es liegt wie angesprochen mit hoher Wahrscheinlichkeit schlichtweg an der Angabe des LDAP Pfades, der nicht notwendig ist (zumal dieser dann auch noch Leerzeichen enthalten hätte). Viele Grüße olc

Hi Michael, solange Du nicht im Windows Server 2008 Domain Mode bist, fordern die Windows 7 Clients zwar eine "aes256-cts-hmac-sha1-96" Kerberos TGS Verschlüsselung an, aber bekommen diese nicht vom DC geliefert. Danach wird eine Aushandlung eines niedrigeren Standards durchgeführt, weshalb das Event meines Erachtens nicht weiter relevant sein sollte. Sobald Du "irgendwann einmal" auf den 2008er oder 2008 R2 Domänenmodus gehst, sollten die Events nicht mehr geloggt. werden. Viele Grüße olc

Hi neuland14, willkommen an Bo(a)rd, :) im Normalfall benötigst Du nicht die Angabe vom LDAP Objekt, es reicht ein simples: "cerutil -dsPublish -f RootCA.crt RootCA". Damit sollte es dann klappen. :) Ein "certutil -dspublish -?" gibt Dir eine Übersicht über die möglichen Optionen und die erforderliche Syntax. Viele Grüße olc

Hi, zeigt Dir ein "certutil -scinfo", angemeldet als ein Benutzer mit "installierter" SmartCard die Daten / Zertifikate der SmartCard an? Viele Grüße olc

Hi, Dir fehlen die korrekten ADML Dateien. Lade am besten das komplette Paket herunter und kopiere die ADMX + ADML Dateien (in der gewünschten Sprache) *komplett* in das PolicyDefinitions Verzeichnis. Download details: Administrative Templates (ADMX) for Windows Server 2008 R2 and Windows 7 Viele Grüße olc

Hi GeGe und willkommen an Bo(a)rd, :) verbiegst Du die Registry Einstellungen manuell oder nutzt Du Gruppenrichtlinien? Letzteres sind das mittel der Wahl dafür. Bei der Veränderung diverser Protokoll- und/oder SSPI-Einstellungen mußt Du beachten, daß auch die Gegenseite entsprechend konfiguriert sein muß, damit es paßt. Daher sind aus meiner Sicht die folgenden Einstellungen prädestiniert dafür, daß etwas nicht funktioniert: HKLM,"SYSTEM\ControlSet001\Control\Lsa","Security Packages",0x00010000,"kerberos,msv1_0,schannel,wdigest,tspkg,pku2u,livessp" HKLM,"SYSTEM\ControlSet001\Control\Lsa","Authentication Packages",0x00010000,"msv1_0" HKLM,"SYSTEM\ControlSet001\Control\Lsa","LsaPid",0x00010001,"0x00000254" HKLM,"SYSTEM\ControlSet001\Control\Lsa","LmCompatibilityLevel",0x00010001,"0x00000001" Was genau möchtest Du erreichen mit den Einstellungen? "Sicherheit" läßt sich nicht herstellen, wenn die Systeme nicht mal mehr sauber laufen - dazu gehört auch ein entsprechendes Betriebskonzept. Viele Grüße olc