olc

Hi, warum ist der 2008 R2 DC ein "Datacenter" System? Werden dort irgend welche anderen Dienste mit auf dem DC betrieben? Dies wäre nicht gut. Falls dem nicht so ist - spricht etwas dagegen, den DC per DCPROMO neu zu promoten? Damit erledigen sich die Probleme "von selbst". Jedoch macht das nur Sinn, wenn der DC tatsächlich nur DC ist und Du mit dem Vorgang keine anderen Probleme riskierst. Generell empfiehlt sich, bei einem 2008er Domänenmodus die SYSVOL Replikation auf DFSR umzustellen. Ich gehe davon aus, daß das bei Dir nicht der Fall ist? Oder liegt genau hier das Problem - die Umstellung ist erfolgt, nur der 2008 R2 scheint das nicht "mitgenommen" zu haben? Genügend freie Festplattenkapazität ist auf dem 2008 R2 vorhanden (SYSVOL Laufwerk)? P.S.: Ein weiterer möglicher Lösungsweg wurde in dem Eventtext selbst genannt: Erstelle im SYSVOL die Datei "NTFRS_CMD_FILE_MOVE_ROOT" und warte 60 Minuten. Zu dem Thema gibt es diverse KB Artikel. Vielleicht reicht das ja schon. Viele Grüße olc

Hi Nils, als Kompatibilitäts-Funktion ist die UAC tatsächlich von unschätzbarem Wert. Sie erlaubt nicht nur den Administratoren, mit eingeschränkten Rechten zu arbeiten, sondern virtualisiert, wie von Dir angesprochen, Dateisystem- und Registry Zugriffe. Zusätzlich erleichtert es auch das Anheben der Rechte eines "Benutzers" bei Installationen etc., so daß es kaum noch notwendig ist, als Administrator zu arbeiten. Nur der Aussage, daß die UAC eigentlich eine Sicherheitsfunktion ist, möchte ich widersprechen, siehe dazu auch: Microsoft: UAC not a security feature - Techworld.com :) Es hebt zwar die Sicherheit eines Windows Systems grundsätzlich an, war jedoch nicht als Sicherheitsfunktion im Wortsinne gedacht. Viele Grüße olc

Hi, wenn der Link (korrekt) deaktiviert wurde, dann sollten die Clients auch nicht darauf zugreifen. Bist Du Dir sicher, daß Ihr die Aktionen korrekt durchgeführt habt? Mittels DFSUTIL /PKTINFO kannst Du prüfen, welche Server für einen Link angegeben werden. Und insbsondere nach Deiner Beschreibung noch einmal der von dmetzger und mir gegebene Hinweis, daß es wahrscheinlich der falsche Weg ist. Denn Du erreichst mit diesem Vorgehen nicht das, was Du erreichen möchtest. Du solltest über einen Cluster oder ein replizierendes Storage nachdenken. Viele Grüße olc

Hi, per Rechtsklick auf das "ungewünschte" Ziel könntest Du den Link deaktivieren. Bedenke dabei jedoch, daß es bei Aktivierung des Links ein wenig dauern kann, bis die Clients diesen dann nutzen. Ansonsten kannst Du auch die folgende Option nutzen, um das Verhalten zu beeinflussen: http://www.serverhowto.de/index.php?eID=tx_cms_showpic&file=uploads%2Fpics%2FAbbildung_02.png&width=800m&height=600m&bodyTag=%3Cbody%20style%3D%22margin%3A0%3B%20background%3A%23fff%3B%22%3E&wrap=%3Ca%20href%3D%22javascript%3Aclose%28%29%3B%22%3E%20%7C%20%3C%2Fa%3E&md5=afc41069a9163aa32c9b4fdb51101b59 Bitte denk daran, daß ein DFSN / DFSR Kombi-System kein Ersatz für einen Cluster darstellt - dies ist im Kern der falsche Ansatz. Viele Grüße olc

Hi, was ist Deine Frage? Viele Grüße olc

Hi, wofür möchtest Du einen solchen Export generieren? Geht es hier um die Überwachung eines Benutzers? Viele Grüße olc

Hi Volker, vielen Dank für Deine Vorstellung und viel Spaß an Bo(a)rd. :) Viele Grüße olc

Hi, versuch einmal das Folgende: FOR /F "tokens=2 delims==" %%a in ('wmic computersystem get Model /value') DO set machine %%a Oder kann MDT2010 auch PowerShell Scripts ausführen / nutzen? Viele Grüße olc

Hi, Du hast einen USN Rollback: How to detect and recover from a USN rollback in Windows Server 2003 Viele Grüße olc

Alles klar, danke für die Rückmeldung und Anleitung. :) Viele Grüße olc

Hi carnivore, check einmal, ob beide Fixes installiert sind oder nur MS09-059: WinRM Operations over HTTPS fail with Access Denied for some systems Ist nur MS09-059 drauf, muß zusätzlich KB968389 installiert werden. Am besten auf *beiden* Maschinen. Ansonsten noch einmal prüfen, ob WinRM korrekt eingestellt ist ("winrm qc"). Viele Grüße olc

Hi, Entgegen anfänglicher Dokumentation auch von Microsoft, ist die Sicherheitsgrenze eines AD der Forest, nicht die Domäne. Das ist nach meinem Kenntnisstand auch seit einigen Jahren bei Microsoft die Argumentation. Bei Trusts weitet sich diese Grenze je nach Konfiguration weiter aus, obwohl hier nur "eingeschränkt". Da also hinlängst bekannt ist, daß die Domäne keine Sicherheitsgrenze darstellt, also auch nicht für die domänenlokalen Administratoren, ist die Argumentation zur "Geheimhaltung" meiner Meinung nach nicht schlüssig. Ein Domänen-Administrator kann sich mit "geringen Mitteln" auch erweiterte Berechtigungen innerhalb des Forests erschleichen. Verteilte Administration erreicht man durch Delegierung, nicht durch Domänen. Selbst DNS Namensräume kann man berechtigungstechnisch delegieren. Die Aussage, daß Ihr alle MS Unterstützung, die man für Geld kaufen kann, bekommen würdet, beantwortet nicht die Frage, wer involviert war. Es macht einen Unterschied, ob Ihr Sales Mitarbeiter, Consultants oder Support Leute als Ansprechpartner hattet. Ich möchte an dieser Stelle noch einmal explizit betonen, daß 30 Subdomänen, die nach Standort eingerichtet werden, in den allermeisten Fällen nicht sinnvoll sind. Je nach Größenordnung des Unternehmes kann jedoch vielleicht eine Aufteilung nach Regionen sinnvoll sein, aler AMER, APAC, EMEA usw. Jedoch nicht aus "Sicherheitsgründen", wie oben schon angesprochen. Da Du den Fokus jedoch auf die Ursprungsfrage zurück lenken möchtest (was absolut in Ordnung ist), können wir das Desig-Thema wohl begraben. Ansonsten stimme ich Nils und dmetzger voll zu. Viele Grüße olc

... woher genau soll denn die Empfehlung von "MS München" gekommen sein? Habt Ihr dort einen Call aufgemacht, hattet Ihr einen Consultant bzw. generell einen strategischen Berater oder wurde der Hausmeister befragt? Selbst ohne die genauen Umstände einer eventuellen Anfrage zu kennen kann ich mir beim besten Willen kaum vorstellen, daß es eine solche Empfehlung gab. Multi-Domänen Modelle sind schon lange "out", wenn ich das einmal so generisch sagen darf. Welchen Vorteil soll denn eine solch Umständliche Anordnung genau haben? Wenn Ihr eine solche Empfehlung tatsächlich bekommen habt, auf welchen Entscheidungsgrundlagen beruhte diese? Ganz ehrlich? Hier paßt einiges nicht zusammen - holt Euch wie schon angesprochen jemanden ins Haus, der einen Plan hat und Euch beraten kann... Warum auch nicht? Zum einen spielt immer ein Stück eigener Erfahrung des Ansprechpartners eine Rolle bei Empfehlungen, zum anderen ist neben dem Kunden selbst auch jeder Markt ein anderer. In den USA sind viele Firmen viel "schmerzfreier" als in Europa. Dadurch ergeben sich von Natur aus unterschiedliche Anforderungen oder Vorgehensweisen. Letztendlich sind Empfehlungen bei jedem Hersteller im Wortsinne eben keine Vorgaben. Ob eine Empfehlung für einen selbst sinnvoll ist oder nicht, muß man am Ende selbst entscheiden. Man muß sich also nicht jedem Vorschlag hingeben. Viele Grüße olc

Hi zusammen, @Nils: Danke für den Link. Zugegeben, ich bin mir gerade nicht 100% sicher - aber ich meine mich zu erinnern, daß bei Konflikten zwischen ADMX und ADM Einstellungen die ADMX Einstellung "gewinnt". Da der Parser die registry.pol durchgeht und zuerst ein mapping zu den ADMX Dateien vornimmt, danach nur die restlichen Registry Schlüssel gegen eventuell vorhandene ADM Dateien prüft, dürfte das Problem eigentlich kein Problem sein. Zumindest nicht bei ADMX / ADM Mischungen. Aber davon ab geht es scheinbar ja um zwei Policies und zahni hat die Fragestellung damit beantwortet. Viele Grüße olc

Hi, woher stammt das Zitat? Viele Grüße, olc

...oder veröffentliche die CRLs entsprechend häufiger. Fast "real-time" bekommst Du aber nur wie zahni erwähnte mit OCSP. Viele Grüße olc

Hi Olli und willkommen an Board, :) es könnte am Subject des Zertifikats liegen - wenn dort der DN anstatt des CN vermerkt ist, kann es je nach Dienst / Applikation zu dem Effekt kommen. Entferne einmal irrelevante / datenschutztechnisch relevante Daten und poste den Export Dump eines unter 2003 ausgestellten Zertifikats und eines mit 2008 ausgestellten Zertifikats: "certutil -dump Zertifikat.cer" Viele Grüße olc

Hi, ein Neustart des Systems sollte helfen oder ein "certutil -setreg chain\ChainCacheResyncFiletime @now". Siehe dazu auch: How to refresh the CRL cache on Windows Vista - Windows PKI blog - Site Home - TechNet Blogs Viele Grüße olc

Nein, zumindest nicht als generische Aussage. Zumal das Wort "DMZ" schon allerlei Spielraum bietet... :)

Hi zusammen, seht Ihr - genau darauf wollte ich hinaus. ;) Die Szenarien sind (bitte nicht falsch verstehen) an den Haaren herbei gezogen. Wie das kleine Beispiel von dmetzger zeigt, gibt es ganz andere potentielle Probleme in dem Szenario. Die alte "Binsenweisheit", daß man solche Systeme nicht in die DMZ legen soll, ist zumindest bei geöffneter RODC Kommunikation ins Produktivnetz, schilichtweg nicht sinnvoll. Auch aus diesem Grund gibt es immer mehr Systeme, die sich direkt im internen Netz betreiben lassen, obwohl sie externe Anbindungen haben. Oben wurden einige Alternativen genannt - je nach gefordertem Sicherheitslevel könnt Ihr auch mit einem externen Directory arbeiten usw. Application Firewalls usw. können das Sicherheitsniveau zusätzlich steigern. Wenn es jemand schafft, in Eure DMS einzudringen und den RODC "zu übernehmen", dann habt Ihr an dem Puntk schon ganz andere Probleme. Viele Grüße olc

Hi, es ist im Kern doch "egal", ob die Kennwörter (oder besser: Die Hashes, die ja zusätzlich "abgesichert" sind) in der DMZ liegen oder ob man sich von dort ins produktive Netz verbinden kann. Also noch einmal die Frage: Was genau möchtest Du eigentlich mit der DMZ absichern und wovor möchtest Du Dich schützen? Um welche Angriffszenarien geht es Dir? Eine DMZ "nur so " aufzubauen ist nicht sinnvoll. Zuallererst steht die Schutzdefinition, Schutzbedürfnis und die Defintion möglicher Angriffsszenarien. BTW: AD LDS benötigt keine Infrastrukturdienste wie DNS oder ähnliches und ist daher leichter zu warten und zu betreiben. Es gibt einige zusätzliche Unterschiede, die jedoch erst nach Betrachtung der Anforderungen sinnvoll zu betrachten sind. Viele Grüße olc

Hi, was ist mit der Beantwortung meiner anderen Fragen? Ich denke nicht, daß sich das hier auf Basis des Forums diskutieren läßt. Folge lieber dem Hinweis von oben uns involviere einen Dienstleister oder MS. Viele Grüße olc

Hi, AD LDS synchronisiert die Kennwörter nicht, bzw. kann ADAMsync das nicht. Dafür würdest Du eine eigene Sync Lösung benötigen, so zum Beispiel "FIM". In jedem Fall benötigst Du Kommunikation zwischen den Systemen. Ohne geht es nicht, es sei denn Du baust in der DMZ ein eigenes Directory auf. Wovor genau willst Du Dich eigentlich schützen? Viele Grüße olc

Genau. :)

Hi, was ist mit meiner Frage zur Firewall / AV-Scanner? Welche Dienste laufen zusätzlich auf dem DC? Ist der DC gleichzeitig DNS Server - hier werden ggf. eine ganze Menge dynamischer Ports belegt? Was sagt ein "netstat -anob"? Habt Ihr die dynamischen RPC Ports eingeschränkt oder liegt (neben der lokalen Firewall) ggf. auch eine zusätzliche Firewall zwischen den Systemen? P.S.: Noch einmal der Hinweis, daß Du ggf. schneller bist, wenn Du Microsoft involvierst oder einen Dienstleister in Deinem Umkreis. :) Viele Grüße olc