tokra

Hallo zusammen, Firma xy hat vor kurzem einen Silber-MS-Partnerstatus erreicht. Nun hat ein Mitarbeiter mit einigen Zertifizierungen, welche ja "Punkte" bringen, gekündigt. Kann mir jemand sagen, ob das Unternehmen den Partnerstatus / Punkte verliert oder wie das abläuft? Bzw. wo ich es nachlesen kann.

Problem hat sich gelöst. Falls es mal jemand haben sollte: Es lag an einem nicht aktualisierten PTR-Eintrag in der Reverse-Lookup-Zone.

Hi, es handelt sich um einen ServerCore, der gleichzeitig RODC ist. Ein "netsh dhcp show server" zeigt alles richtig an. Auch der ADSI-Editor zeigt in der Konfigurationspartition des RODC alles richtig an, wodurch ich Replikationsprobleme ausschließen kann. Interessanterweise: Wenn ich mich mit einem Windows Server 2003 R2 am mit der DHCP-Server Konsole mit dem DHCP-Server verbinde, funktioniert es. Allerdings wird hier ein rotes Symbol für einen nicht autorisierten Server angezeigt, obwohl der Server eindeutig autorisiert ist (laut ADSI-Editor und er vergibt auch DHCP Leases). Diesen Anzeigefehler hatte ich allerdings schonmal irgendwo gesehen. Dieses Phänomen ist reproduzierbar; habe es jetzt auch mehreren W2K3 Maschinen getestet. Zu dem verlinkten MS-Artikel von "carlito" fällt mir noch ein: Ich habe auch das Objekt mit dem Namen "CN=DhcpRoot", Eigenschaft "dhcpServers" überprüft. Hier sind keine Einträge vorhanden.

Hi, danke für den Hinweis. Ich habe, wie im Artikel beschrieben, nochmal den alten DHCP-Server autorisiert. Danach steht auch bei beiden (nacheinander autorisiert) die richtige IP-Adresse im der DHCP-Konsole. Obwohl dort die richtige IP-Adresse und der richtige Name steht, verbindet er sich nach wie vor immer mit dem alten Server. Ich habe mir auch einmal das Objekt der Klasse "dHCPClass" im Configuration Context angeschaut (CN=Services,CN=NetServices). Dort steht beim Attribut "dhcpServers" des betroffenen DHCP-Server-Objektes die richtige IP-Adresse drin. Auch wenn man den alten Server nochmal autorisiert, bekommt er hier die richtige IP-Adresse. Das Löschen dieses Objektes und Neu-Autorisieren hat leider auch keine Abhilfe gebracht. Alle Sites sind vollständig repliziert. Auch auf anderen Sites sind die Objekte aktuell.

Hi, der DHCP-Server auf dem alten Server ist deaktiviert (auch der Dienst). Der neue wurde bereits neu gestartet. Wenn ich per DHCP-Konsole einmal die Autorisierung des neuen Servers aufhebe, und dann per "Autorisieren"-Button die IP-Adresse des neuen Servers eintrage, zeigt er hier immer den alten Server mit Namen an. Obwohl DNS ihn wie gesagt richtig auflöst. Es scheint so, als ob die IP-Namenszuordnung für die autorisierten DHCP-Server noch irgendwo im AD gespeichert werden; unabhängig vom DNS-Server.

Hallo zusammen, ich habe hier ein interessantes Phänomen vorliegen. Ein DHCP-Server wurde auf einen anderen Server umgezogen; die IP-Adressen der Server wurden getauscht. Die Server haben dynamisch ihre Registrierung beim DNS-Server erneuert. Der DNS-Server löst die richtigen IP-Adressen zu den Servernamen auf. In der DHCP-Server Konsole bei der Auswahl eines Servers "Autorisierte Server verwalten" sind dort zwei Felder "Name" und "IP-Adresse". Hier steht ausschließlich der neue Server (der im AD autorisiert wurde; dem alten wurde die Autorisierung entzogen), jedoch die falsche / alte IP-Adresse. Dadurch verbindet sich die Konsole immer mit dem alten Server. Weiß jemand, ob die Zuordnung der IP-Adresse noch woanders gespeichert wird? Alle DNS-Server sind repliziert und verweisen auf die richtige / neue IP-Adresse.

Hi, vielen Dank. Werde das mal ausprobieren.

Hallo zusammen, ich möchte das Windows 7 Wartungscenter auf Clients per GPO konfigurieren; dabei geht es mir um den Bereich "Meldungen aktivieren bzw. deaktivieren", in dem die einzelnen Überwachungsbereiche des Wartungscenters eingestellt werden können. Vorweg: Ich möchte das Action Center nicht abschalten, wie es in jedem anderen Eintrag der Fall ist, wenn man eine Suchmaschine bemüht. Das Wartungscenter soll eingeschaltet bleiben. Es sollen lediglich die Meldungsbereiche nicht mehr konfigurierbar / ausgegraut sein. Wie ich herausgefunden habe, speichert Windows die gewünschten Werte in folgenden Registry Keys: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Action Center\Checks] Nun wollte ich per Group Policy Preferences diese Registry Settings verteilen. Diese habe ich zuvor auf einem Clients exportiert und mir in einer Textdatei geöffnet. Beispiel für einen der vielen Werte: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Action Center\Checks\{01979c6a-42fa-414c-b8aa-eee2c8202018}.check.101 Wert (binär): hex:23,00,41,00,43,00,42,00,6c,00,6f,00,62,00,00,00,00,00,00,00,\ 00,00,00,00,01,00,00,00,10,00,00,00,00,00,09,00 Wenn man genau das in die Registry-Elemente der GPP einträgt, zeigt es auf dem Client, der die GPO anwendet, keine Wirkung. Als Aktion des Registry Elements in der GPP wurde "Ersetzen" und auch ein mal "Aktualisieren" gewählt - beides zeigt keinerlei Wirkung. Als Werttyp wurde "REG_BINARY" ausgewählt. Hat hier jemand eine Idee?

Was spricht aus deiner Sicht dagegen? Ich sehe in der AD-LDS Instanz in der DMZ keinen Vorteil gegenüber einem RODC ohne cached Credentials - das scheint ja die hier bevorzugte Lösung zu sein.

Vielen Dank für eure Anregungen. Was mich noch interessieren würde: Habt ihr selbst oder kennt ihr Infrastrukturen, wo RODCs in der DMZ im Einsatz sind? Wenn ja, in welchen Szenarien werden diese dort ingesetzt? Ich würde auf dem RODC in der DMZ trotzdem kein Password Caching zulassen. Ich sehe da keinen Sinn drin, da sich DMZ und LAN physikalisch am gleichen Standort befinden. Die Kennwortreplikation macht ja eher bei Zweigstellen Sinn, um eine langsame WAN-Verbindung zu entlasten oder einem WAN-Ausfall vorzubeugen.

Wenn er Domänen-Admin-Rechte hat, kann er auch gleich Verbindung mit dem beschreibbaren DC im LAN aufnehmen. Alternativ könnte er die ADDS neu installieren und diesmal nicht als RODC.

Nehmen wir an ein Angreifer kompromittiert den RODC. Jetzt gibt es zwei Möglichkeiten: 1. Er kann die cached Password Hashes auslesen und versuchen diese zu knacken 2. Er kann zunächst keine Passwort Hashes auslesen -> Da so oder so eine Kommunikation vom RODC zu einem beschreibbaren DC im LAN notwendig ist, halte ich es für einen Sicherheitsgewinn, die Hashes nicht in der DMZ zu speichern Weiteres Angriffsszenario: Ein Angreifer kompromittiert den RODC und findet eine Sicherheitslücke, Daten auf einen beschreibbaren DC zu injizieren. Die Eintrittswahrscheinlichkeit dieses Risikos halte ich für gering, wodurch ein RODC in der DMZ durchaus in Frage kommt.

Hi, es ist angedacht, die Struktur später mit AD-FS auf ein zweites AD auszudehnen, was sich in der DMZ befinden wird. Ich müsste jetzt schauen, ob die AD-LDS mit den AD-FS kombiniert werden können, aber momentan sehe ich bei den AD-LDS im Gegensatz zu einem RODC keinen Vorteil. Wenn eine Kommunikation aus der DMZ ins LAN so oder so nötig ist, halte ich es für den sinnvollsten Weg, die Kennwörter gar nicht erst in der DMZ zu speichern. Demnach würde die AD-LDS Instanz oder ein RODC in der Standardkonfiguration (speichert keine Kennwörter) in Frage kommen.

Hallo zusammen und danke für eure Rückmeldungen, Eben, er wird sie WIEDER replizieren, aber erst wenn eine Authentifizierung stattfindet und dann muss der RODC Kontakt zu einem RWDC aufnehmen -> DMZ->LAN-Kommunikation nötig Wenn ich alles in eine AD-LDS Instanz synchronisiere, liegen wiederrum alle Kennwörter in der DMZ. Ich frage mich gerade was das geringere Übel ist: Szenario 1: Egal ob durch RODC mit cached Passwords oder durch eine AD-LDS Instanz: Die Kennwörter liegen auf einem Server in der DMZ Szenario 2: Eine Art LDAP-Proxy (z.B. RODC ohne cached Passwords) fragt jedes mal bei einem RWDC im LAN nach -> Firewall muss von der DMZ ins LAN geöffnet werden

Hallo und danke für den Link, wie es aussieht, speichert der RODC also kein Kennwort mehr, sobald es geändert wird. Ich überlege gerade, ob es sinnvoll ist, einen RODC in die vorliegenden Umgebung zu stellen (gewisse Extranetapplikationen benötigen zwingend LDAP-Zugriff für Authentifizierungen). Ich wollte aber keinen Zugriff von der DMZ in das LAN, respketive auf einen beschreibbaren DC im LAN, gestatten, was ja in diesem Fall nötig wäre, damit der RODC Kennwörter abfragen kann (spätestens, wenn sie geändert wurden). Ich bin mir auch immer noch sehr unsicher, ob der RODC hier eine geeignete Maßnahme darstellt, da es ja primär für Zweigstellenszenarien entwickelt wurde. Andererseits gibt es ja nicht umsonst einen "Deploying RODC in perimeter networks" Guide von Microsoft. Prinzipiell würde es natürlich Sinn ergeben, auf dem RODC überhaupt keine Kennwörter zu speichern, so dass der RODC nur als Proxy für LDAP-Anfragen der DMZ agiert.