michelo82

Hallo, ich habe damit diverse Drucker, Server u.s.w ohne Authentifizierung intern Mails senden können, ein internes Relay angelegt. Nach hinzufügen der IP-Adresse des jeweiligen z.b. Druckers im neuen Empfangsconnector funktioniert der Mailversand. Soweit so gut. Nun möchte ich, dass Exchange selbst über die Aufgabenplanung ein Powershellskript antriggert und mir eine Statusmail sendet. Das funktioniert sowohl unauthentifiziert oder mit Credentials nicht. Die IP des Exchange-Servers ist ebenfalls in dem internen-Relay Connector eingetragen. Ich erhalte: Send-MailMessage -To $emailAddress -From $emailFrom -Subject "Status" -SmtpServer "exchchange.meinefirma.de" -Body $tasks Send-MailMessage : Für den SMTP-Server ist eine sichere Verbindung erforderlich, oder der Client wurde nicht authentifiziert. Die Serverantwort war: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM Was mache ich denn falsch?

Super! Das hat funktioniert. Danke!

Ich habe die DDCP Einstellungen bezüglich der Zeit auf "nicht konfiguriert" gesetzt und die neue GPO wie im Link beschrieben aktiviert. Auf dem PDC ist die Einstellung korrekt: C:\Windows\system32>w32tm /query /status Sprungindikator: 0(keine Warnung) Stratum: 3 (Sekundärreferenz - synchr. über (S)NTP) Präzision: -23 (119.209ns pro Tick) Stammverzögerung: 0.0134410s Stammabweichung: 7.7806677s Referenz-ID: 0xC0A86424 (Quell-IP: 192.168.100.xx) Letzte erfolgr. Synchronisierungszeit: 29.04.2021 15:02:40 Quelle: gateway01.meinefirma.de Abrufintervall: 6 (64s) C:\Windows\system32>w32tm /query /source gateway01.meinefirma.de Einer der alten DCs zeigt es auch korrekt: C:\Windows\system32>w32tm /query /status Sprungindikator: 0(keine Warnung) Stratum: 4 (Sekundärreferenz - synchr. über (S)NTP) Präzision: -6 (15.625ms pro Tick) Stammverzögerung: 0.0447388s Stammabweichung: 7.8287715s Referenz-ID: 0xC0A86411 (Quell-IP: 192.168.100.xx) Letzte erfolgr. Synchronisierungszeit: 29.04.2021 15:00:01 Quelle: DC01.meinefirma.de Abrufintervall: 10 (1024s) C:\Windows\system32>w32tm /query /source DC01.meinefirma.de Nur die beiden anderen "hängen" auch nach einem gpupdate und Neustart des Zeitdienst auf der alten Einstellung.

Die Einstellungen der Policy finde ich auch so garnicht in der Registry.

Danke. Die Einstellungen in der Default Domain Controller Policy einfach wieder "zurücknehmen" klappt? Bei manchen Einstellunge bleiben die ja in der Registry vorhanden und werden nicht "zurückgenommen".

Hallo zusammen, und zwar bin ich dabei 2x Server 2012 R2 Domänen-Controller gegen zwei frische Server 2019 DC's abzulösen. Aktuell stolpere ich allerdings über ein Problem bei der Zeitsynchronisation. Das alte Systemhaus hatte "leider" an der Default Domain Controller Policy Hand angelegt und folgende Einstellungen getroffen die jetzt auf alle in Betrieb befindlichen DC's wirken. (2x alte Server 2012R2 und 2x neue Server 2019): Die IPs sind unsere alten VPN Gateways (inkl. NTP) die demnächst Offline gehen. Also muss hier eine andere Quelle eingetragen werden. Das soll unser Internetgateway (Firewall) werden. Da ich mir nicht sicher war, ob ich die EInstellungen in der Default Domain Controller Policy einfach wieder auf "nicht konfiguriert" stellen kann, habe ich erstmal die IP des Internetgateways eingetragen. Soweit so gut. Leider zeigt mir DCDIAG nach 2 Tagen des "DCPROMO" auf meinem neuen DC01 (besitzt alle FSMO Rollen): Starting test: SystemLog Warnung. Ereignis-ID: 0x0000008E Erstellungszeitpunkt: 04/29/2021 11:42:44 Ereigniszeichenfolge: Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lokale Systemuhr nicht synchronisiert ist. Warnung. Ereignis-ID: 0x00000032 Erstellungszeitpunkt: 04/29/2021 11:42:44 Ereigniszeichenfolge: Der Zeitdienst hat eine Zeitdifferenz von mehr als 128 ms auf 90 Sekunden festgestellt. Die Zeitdifferenz wurde möglicherweise durch die Synchronisation mit einer ungenauen Zeitquelle oder durch schlechte Netzwerkbedingungen verursacht. Von nun an wird der Zeitdienst nicht mehr synchronisiert, die Zeit keinem weiteren Client mehr zur Verfügung gestellt und die Systemuhr nicht mehr synchronisiert. Sobald ein gültiger Zeitstempel von einem Zeitdienstanbieter empfangen wird, wird der Zeitdienst sich selbst korrigieren. Warnung. Ereignis-ID: 0x000003FC Nach einem: w32tm /resync Verschwindet vorest die Fehlermeldung. Dafür bekomme ich auf einem der alten DC's, nach dem ich dort ebenfalls den Befehl ausgeführt habe, folgenden Fehler im Eventlog: EventID: 142 Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lokale Systemuhr nicht synchronisiert ist. Nun ist es doch so, dass nur der PDC mit der externen Zeitquelle synchronisiert werden sollte. Dadurch aber die Zeiteinstellung in der Default Domain Controller Policy konfiguriert ist, erhalten immer alle DCs die externe Quelle. Wie kann ich die Zeitserver jetzt wieder sauber einstellen? Bzw. kann ich gefahrlos die Default Domain Controller Policy zurückbauen? Wenn ich eine GPO verwende dann lieber nach dem Bsp. von Mark: https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo Oder manuell: w32tm /config /syncfromflags:manual /manualpeerlist:"<IP Gateway>" /update

Doch. Nur führen die Links nicht dahin. Aber ich suche mal die 12/2016.

Das wäre eine wichtige Maßnahme die Credentials zu schützen. Danke für die Links - die funktionieren aber leider nicht.

Ja richtig das DR-Konzept sollte da nicht vermischt werden. Aber stimmt, ein lokaler User könnte sich dennoch anmelden, auch bei einem Domänen-Mitglied. Die Workstations haben kein Win10 Enterprise BS um Credentials Guard zu nutzen - das kann aber wiedderum auf den Adminhost, da es ein Server BS ist, genutzt werden.

Diejenigen die auf die Adminmaschinen Zugriff haben, haben ebenso Zugriff auf die VMWare Umgebung - es ist der gleiche Personenkreis. Wir vertrauen uns. Wird das Passwort bei RDP zwischengespeichert? Das spricht dann dagegen. Da bin ich mir aber gerade nicht sicher. Ich habe bis jetzt noch nichts nachteiliges festgestellt, wenn die VM kein Domänenmitglied ist. Sinn war, dass die Maschine so immer autark betrieben werden kann, auch wenn die Domäne nicht verfügbar wäre (Disaster). EDIT: Vorläufig ja. Da wir nicht die (zeitlichen) Ressourcen haben einen weiteren Host bereitzustellen. Aber das zu ändern, habe ich bereits im Hinterkopf. Wenn man es ganz genau nimmt müsste ja nach dem PAW/SAW Prinzip, ein separater physicher Admin-PC in einem abgesperrten Raum stehen. Das ist nur im Alltag garnicht umzusetzen. Ein dedizierte Admin-VM um überhaupt erstmal eine Trennung zur Office-Workstation zu schaffen, war ein wichtiger Schritt.

Ja, warum nicht?

Hallo zusammen, Microsoft selbst empfiehlt ja die Nutzung dedizierter Maschinen für die administrative Verwaltung. https://docs.microsoft.com/de-de/windows-server/identity/securing-privileged-access/privileged-access-workstations Dazu existieren verschiedene Begrifflichkeiten um die Verwirrung komplett zu machen. Wir haben uns für die Variante Admin-Host bzw. Jump-Host entschieden. Jeder Admin hat seine eigene Server 2019 VM, die nicht Mitglied der Domäne ist, auf einem ESX. Die VM wurde mit den Microsoft Security Baseline gehärtet. Darin sind einige Tools und ein RDP-Manager. Auf diese Maschine wird per VMWware-Konsole zugegriffen. Mich würde interessieren, wie ihr das umgesetzt habt bzw. damit arbeitet? Spricht etwas dafür- bzw. dagegen, dass ein Adminhost nicht Mitglied der Domäne ist? MfG bleibt gesund!

Okay. Das habe ich soweit verstanden und auch die Forum-Suche genutzt. Sehr viel zu dem Thema findet man nicht. In diesem Thema hat jemand quasi von 0 angefangen: Dazu kann ich sagen, dass das ab jetzt so umgesetzt ist. Im aktuellen Schritt habe ich die persönlichen Admin-Konten für das Tier 0 erstellt und die Gruppe den Domänen-Admins hinzugefügt. Meine Gruppe mit delegierten Berechtigungen auf bestimmte OU belasse ich trotzdem. Das ist vielleicht für die Zukunft Interessant um einen "abgespeckten" Zugriff auf bestimmte OU's für bestimmte User freizugeben. Kennt jemand weitere gute Quellen, die die praktische Umsetzung des Themas veranschaulichen?

Hallo, und danke für die ausführliche Antwort. Damit meine ich das Default Administrator-Konto. Das Passwort dazu möchte ich idealerweise versiegelt in den Safe legen, da es nicht mehr verwendet werden soll. Die Tier0-Admins möchte ich delegieren um diese dadurch von den Berechtigungen her einzuschränken. Meine Idee war, dass die Tier0-Admins nicht generell, sondern nur temporär Domain-Admin-Berechtigungen bekommen. Einfache Tätigkeiten im AD sollen die noch weiter beschränkten daily-use-Konten erledigen. Vielleicht liegt hier mein Verständnisproblem und es stellt kein Sicherheitsproblem dar, wenn die Tier0-Admins generell zu den Domain-Admins gehören? Die Anmeldebeschränkung nur auf die DC's ist bereits geregelt. Ein Red Forest bzw. das ESAE-Modell zu implementieren scheint mir aktuell zu hoch gegriffen. Ich würde erstmal Schritt für Schritt vorgehen und eine verbesserte Basissicherheit mit der Tier-Level Implementierung und separierung der Administrativen-Anmeldungen herstellen. Wir haben nur einen Forest, eine Domäne. Ich verlange ja auch kein fertiges Konzept von euch. Das ist schon klar. Eher etwas unter die Arme greifen. Ich habe mir erhofft, dass sich mein Verständnisproblem auflöst. Über die Strukturänderungen mache ich mir bereits einige Wochen Gedanken. Ganz so hemdsärmelig bin ich dann doch nicht. Mich bringt vielleicht einfach ein Umriss weiter, wie andere Organisationen die Tier-Level und Berechtigungsdelegierung lösen. Eben die Notizen und Anmerkungen sind der Anstoß in die richtige Richtung weiterzugehen.

Hallo zusammen, ich benötige etwas Hilfe bei der implementierung der Tier-Level. Ich habe in meiner Umgebung eine OU “Administration” und darunter liegend die OUs “Administrative Gruppen” und “Administrative Konten”. Darunter entsprechend befinden sich dann die Gruppen “Tier0Admins”, “Tier1Admins” und “Tier2Admins”, sowie personalisierte Admin-Konten für jedes Tier-Level. Wir sind mehrere Admins. Die Tier1- und Tier2Admins werden per GPO als lokale Administratoren auf Server bzw. Clients verteilt. Eine Anmeldung auf ein System (z.b. Server) ist nur mit entsprechendem Login aus dem entsprechendem Tier(1)-Level erlaubt. Anmeldungen zwischen den Tier-Level ist nicht erlaubt. Kein higher oder lower Tier logon möglich - ebenfalls per GPO geregelt. Die Tier0-Verwaltung stellt mich allerdings noch vor offene Fragen. Bis jetztwurde sich immer direkt als Domänen-Admin remote am AD angemeldet und die Domäne verwaltet. Zukünftig soll das anders werden: - zunächt erfolgen sämtliche administrativen Aufgaben und Zugänge von einem speziell gehärteten Adminhost über z.b. RSAT etc. - für die täglichen Arbeiten (wie z.b. Passwort zurücksetzen, eine Gruppe oder Nutzer anlegen etc.) erhält jeder Admin ein persönliches ("daily-use-admin") Admin-Konto und hat die entsprechende delegierungen auf die OU "User" und "Clients". - die daily-use-admin Konten bekommen allerdings keine delegierung auf die OU “Administration” um sich nicht selber höher privilegieren zu können. - die daily-use-admin Konten dürfen sich nirgends anders im Netzwerk mit ihrer Kennung anmelden. Problem: - da es sich manchmal nicht vermeiden lässt auch Remote an den DC's zu arbeiten (gerade jetzt bei Einführung der Tier-Level wird noch nicht alles sofort rundlaufen), benötige ich dafür ebenfalls einen Admin-Account. Mit diesen sollte bei Bedarf die komplette Verwaltung des AD's möglich sein. Aktuell nutze ich dafür den Domänen-Admin. Dieser soll aber nicht mehr für die täglichen Arbeiten verwendet werden. Das Passwort des Domänen-Admins soll in noch kürzeren Abständen geändert werden können. Meine Lösung könnte so aussehen (wenn ich denn damit auf der richtigen Fährte bin : Die Tier0Admins in welcher wieder ein neues persönliches Admin-Konto steckt, habe ich in die Builtin-Gruppe Remotedesktopbenutzer geschoben und in der DDCP unter "Anmelden über Terminaldienste zulassen" eingetragen. Somit ist erstmal ünerhaupt die RDP anmeldung auf den DC's möglich. Eine Verwaltung der DC's bzw. des AD's funktioniert so aber logischerweise noch nicht. Ich würde dieser Tier0Admin-Gruppe per Delegierung Rechte auf die OU “Administration” und "Domänen-Admins" geben. So könnte ich bei Bedarf die Tier0Admins temporär in die Gruppe der Domänen-Admins verschieben und damit arbeiten. Nach erledigter Arbeit wird die Gruppe wieder entfernt. Später soll dafür das Privileged Access Management Feature verwendet werden. Das bearbeiten der Administrativen Gruppen soll überwacht werden. Meine Frage: Wäre das eine passable Lösung um das arbeiten mit dem Domänen-Admin Konto zu vermeiden? Oder wie macht ihr das? Ich bedanke mich schonmal für zahlreiche Tipps :) Bis bald.

Hallo Nils, ja du hast Recht!

Guten Morgen, Danke für das Feedback. die Rahmenbedingungen wären: - die tägliche Arbeit (Passwort zurücksetzen, eine Gruppe anlegen, einen Nutzer anlegen etc.) erfolgt von einem Adminhost über RSAT. Das verwendete Konto dafür hat die entsprechende delegierung(en) und darf sich sonst nirgends im Netzwerk damit anmelden. Vorher wurde sich immer direkt als Domänen-Admin remote am AD angemeldet. Problem: Da es sich manchmal nicht vermeiden lässt auch Remote an den DC's zu arbeiten (gerade jetzt bei Einführung der Tier-Level wird noch nicht alles sofort rundlaufen), benötige ich dafür einen Account. Dieser sollte die Serverwaltung möglich machen. Aktuell nutze ich dafür den Domänen-Admin. Dieser soll aber nicht mehr verwendet werden. Meine Lösung: Ich habe eine neue Gruppe angelegt (für das Tier 0) in welcher ein neues "Admin"-Konto steckt. Diese Gruppe habe ich in dei Builtin-Gruppe Remotedesktopbenutzer geschoben und in der DDCP unter "Anmelden über Terminaldienste zulassen" eingetragen. Meine Frage: Wäre das eine passable Lösung? Ich würde nur gerne wissen, ob es sich lohnt in diese Richtung weiter zu arbeiten. Wenn ja, kann ich diesen Nutzer auch in den anderen Gruppen (Serveroperatoren) berechtigen. (So dass er überhaupt was darf, außer nur über RDP anmelden).

Ich habe es mir eben so vorgstellt, dass die Gruppe der Tier0 Administratoren vollen Zugriff auf den DC hat, aber eben entsprechend selten verwendet wird. Es soll damit eigentlich nur ein lokales / RDP anmelden möglich sein um die "Administrative" OU verwalten zu können. Ein Konto muss doch ähnlich des Domain-Admins handlungsfähig sein . Gibt es eine bessere Lösung?

Hallo nochmal, Ich nutze für meinen dedizierten Admin (Tier0) - die Builtin Gruppe Administratoren. So hab ich vollen Zugriff auf den DC. Bin aber kein Domain-Admin. Der Login soll nur für die Verwaltung (lokale Anmeldung / RDP Anmeldung) der DC's genutzt werden bzw. um Administrative Konten/Gruppen zu verwalten. Der Ziugriff mit diesen Konto auf Tier1 / Tier2 ist verboten. Für die tägliche Arbeit gibt es ein weiteres Konto mit dem über RSAT von einem Adminhost bestimmte delegierte OU's verwaltet werden dürfen. Spricht da sicherheitstechnisch etwas dagegen? MfG

Weil es ja Ursprünglich um einen Inhalt aus einem Buch ging...was empfehlt ihr in die Richtung GPO's?

Danke für den Tipp. Ich schaue mich mal um!

@daabm Finde ich nicht

Ich danke euch für die nützlichen Infos! Dann ein schönes Wochenende - bleibt gesund!

Genau das ist die Erklärung! Danke. Ich habe es mir zusammengereimt ;) Erstens das gelesene aus dem Buch + Und das Missverständnis war perfekt! Ein anderes Beispiel: Mir ist noch unklar, warum meine Auditing-Einstellung durch meine neue Richtlinie außer Kraft gesetzt wurden. Hier habe ich die Erweiterte Überwachungskonfiguration bearbeitet. Danach waren die Audit-Events aus der DDCP nicht mehr im Ereignislog zu sehen. (z.b. 4771).

Ich habe mich hierrauf bezogen https://www.rheinwerk-verlag.de/sichere-windows-infrastrukturen-das-handbuch-fuer-administratoren/ Und hier wird eine eigene Policy auf die DC losgelassen: