toao

Hi, ohne mehr Informationen über den jeweiligen Zweck (use case) zu haben, lehne ich mich mal aus dem Fenster..., einige der separat erstellten Forward-Lookup Zonen bei euch hören sich nach "overkill" an. 1-2 Gründe für das Anlegen einer separaten Forward-Lookup Zone könnten sein: - Delegierung der Administration der DNS RR - "Dynamic updates" Konfiguration für die separate Zone muss angepasst werden und etwaige andere Gründe. Funktional ist es sicherlich bei Euch mit den separaten ForwardLookupZonen (sonst würde bestimmt schon jemand meckern :D), nur wäre ein gewisser "Standard" zu definieren schon hilfreich um einen "unnötigen" Wulst and ForwardLookupZonen zu verhindern als auch eventuell durch (versehentlich) verkehrte Konfigurationen der einzelnen ForwardLookupZonen, sich mögliche Probleme ins Haus zu holen. Gruß, toao Ps.: Denke bitte bei CNAME DNS RR an den Kerberos Kontext (richtigen SPN zu registrieren).

OffTopic Hi, ein kurzer Hinweis, bezüglich Deiner Aussage "Aber die GPOs der OUs können dann ja noch immer das "überschreiben". (Und da die DDP allgemein angesprochen wurde.) Dies trifft nicht auf Password Policy settings zu, diese werden by design ausschließlich über GPO's applied, die auf "domain level" verknüpft wurden. /Offtopic Gruß, toao

Der Austausch von DCs kommt in unserer Umgebung nicht so oft vor, dennoch ein valider Punkt, dem man berücksichtigen sollte, an den hatte ich nicht gedacht. Zu NTLM deaktivieren musste ich schmunzeln... Wir hatten schon Hürden zu nehmen, in dem wir von NTLM v1 auf v2 geschwenkt sind ;) Gute Idee mit dem heruntersetzen des Replikationsintervalls, werde ich in Erwägung ziehen. Danke auch dafür. Guten Morgen, eindeutig die passendere Platform solche Fragen zu stellen. Danke für den Link als auch die Erläuterung zu Purple Knight und darüberhinaus. Moin Moin, ich denke schon das jeder Hersteller der Beschreibungen nutzt, sich an diesen messen lassen kann auch wenn es sich um kostenlose Tools handelt. Mit Rückmeldungen solcher Art besteht die Möglichkeit für ein Produkt immer weiter zu wachsen und sich zu verbessern (nicht bezogen auf mein Beispiel, sondern generell), sofern es Sinn ergibt und manchmal kennt man die Hintergründe/Entscheidungswege nicht so gut, daher auch meine Nachfrage. Nun habe ich den Link vom @cj_berlin dankenswerterweise erhalten und werde die kommenden Nachfragen dort einstellen. Genau, für mehr Detail braucht man ein anderes Werkzeug.

Hi alle, es geht um den 'Indicator Name': Built-in domain Administrator account used within the last two weeks in Kombination mit der 'Description', welche das Wort 'recently' benutzt und als Basis das ADDS attribut 'lastLogonTimestamp' ausliest. Vorweg, ich denke das dieses attribut nicht ausreichend ist für "...within the last two weeks". lastLogonTimestamp im default Zustand nimmt den Wert 14 minus prozentual zufälligen Wert von 5 setzt diesen dann in Kontext mit dem aktuellen Datum minus aktuelle Datum von lastLogonTimestamp und auf dieser Basis wird dann je nach kleiner oder größer replieziert oder nicht. (Ich habs mal in einem Satz versucht, besser nachzulesen hier "https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/8220-the-lastlogontimestamp-attribute-8221-8211-8220-what-it-was/ba-p/396204" Würde bedeuten, dass es Szenarien gibt in denen in der ersten Woche bis hin zu 8 Tagen keine Replikation stattfindet obwohl eventuell ein Domain Controller theoretisch schon was zu replizieren hätte. Ferner gibt es Szenarien, in denen das lastLogonTimestamp aktualisiert wird, jedoch nicht durch einen tatsächlichen logon Versuch ausgelöst wurde (false-positiv), so zum Beispiel bei einem Windows Event 4624 mit der Info "authZ" unter Logon Process. Bitte korregiert mich sofern ich vom Verständnis her etwas verkerht interpretiert habe oder etwas übersehen habe. Jetzt wollte ich nach einer Alternative für lastLogonTimestamp schauen, wäre da zum Beispiel das attribut "Lastlogon" (nicht repliziertes, daher von allen DCs abzufragen und zu vergleichen) ein etwas stimmigeres Attribut für die Definition "...within the last two weeks"? Oder gar die Windows Event IDs 4768 (A Kerberos authentication Ticket (TGT) was requested / 4769 A Kerberos service ticket was requested auszulesen und auf Grundlage dessen den Report zu erstellen? Mir ist schon bewusst, dass meine Vorschläge (etwas) umfangreicher sind im Vergleich das "lastLogonTimestamp" auszulesen, wollte dennoch nach einer Alternativen schauen, sofern mein oben beschriebenes Verständnis stimmt. Gruß, toao

Hi, die "Kerberos Armoring" Zeilen lassen darauf schließen, dass auf dem endsystem kein Kerberos Armoring (FAST) genutzt wird. Deutlich wird dies mit der Zeile: Failed to query EnableCbacAndArmor. Das ist der Registry value name, welcher auf dem endsystem gesetzt werden würde, wenn die GPO setting "client support for claim,compound usw." (hklm\software\microsoft\windows\currentversion\policies\system\kerberos\parameters) konfiguriert wäre. Dann würde die Zeile aus dem gpsvc.log auch verschwinden. Ich vermute, dass ihr grundsätzlich kein "Kerberos Armoring" nutzt. Daher kannst Du diese Zeilen ignorieren, da Sie standardmäßig im gpsvc.log enthalten sind, vollkommen egal ob man etwas konfiguriert hat oder nicht. Ebenso ignorieren kannst Du alle Einträge bezüglich "Rsop entry point not found", ein überprüfen ob die dll's auf dem endsystem vorhanden sind wird mit sehr hoher wahrscheinlichkeit positiv enden, ein Versuch die dll's zu re-registern wird auch nicht helfen, diese Einträge aus dem gpsvc.log zu bekommen. Ich sehe diese seit Jahren im gpsvc.log und bisher waren diese Einträge nicht zielführend zur Fehlerbehebung. Eventuell kann noch jemand anderes im Forum hierzu etwas beisteuern. (Mein) Fazit: Diese beiden Informationen aus dem gpsvc.log werden leider nicht dazu beitragen die Ursache ausfindig zu machen. Gruß, toao

Hi, folgende Prüfungen könntest Du nun mal durchführen (DC Locator Prozess): Am Client\Server selbst den nachfolgenden Registry Eintrag HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName einsehen und schauen was unter "Data" steht. Steht dort die "Site", welche Du unter "Sites&Services" inklusive des Subnetztes konfiguriert hast und diese stimmig zum Standort des Clients\Servers ist, ist das ein guter Start. *Sidenote und bitte nur für den Troubleshooting Fall nutzen: Den DynamicSiteName Eintrag kann man über folgenden Registry Eintrag aushebeln: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters REG_SZ "SiteName" und unter Data dann die Site, die Du manuell eintragen möchtest. Wie erwähnt, sollte nur im Notfall/Troubleshooting Fall eingesetzt werden. Wozu das ganze? Jeder Windows domain joined Client schaut beim DynamicSiteName Eintrag nach um für seine Site die verfügbaren DCs zur Anmeldung herauszufinden, dass macht er dann über einen DNS request, welcher dann die "Site" enthält. Nachdem Du nun die "Sites&Services" Konfiguration geändert hast, könntest Du im "DNS" (ich gehe jetzt davon aus, Du hast die DNS Windows Rolle auf Euren DCs installiert) nachschauen, ob die DNS RR SRV Einträge korrekt aktualisiert wurden. Je nach Umgebung habe ich da von fantastisch aufgeräumten Einträgen bis hin zu Dschungel artigen Gegebenheiten gesehen. DNS Pfad Rootdomain: ForwardLookupZone _msdcs.[domain].dc._sites.[Sitename]._tcp DNS Pfad Childdomain: ForwardLookupZone [domain]._msdcs_dc.sites.[Sitename]._tcp *Sidenote, es gibt noch einige anderes DNS Pfade, die für andere Szenarien\Gegebenheiten als Quelle von 3rd Party Solution anbietern, etc. genommen werden, beim DC Locator Prozess sind es die oben genannten. Solltest Du nun DNS RR SRV Einträge sehen, die nicht stimmig sind, kannst Du diese entfernen (Obacht: Sofern nach Bereinigung gar keine SRV Einträge übrig bleiben würden, bitte nicht löschen und zunächst Troubleshooten ;) *Sidenote, sollten im DNS gar komplette DNS "Site" Einträge fehlen, kann ich dir wärmstens den folgenden Artikel empfehlen: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/sites-sites-everywhere-8230/ba-p/399239#:~:text=Domain Controllers cannot calculate site,first%3B that's up to you. Zu guter letzt sei die GPO Einstellung "Enabling Clients to Locate the Next Closest Domain Controller" zu erwähnen, dass verbessert quasi den DC Locator Prozess in der Hinsicht, dass bevor der letzte Prozess Schritt "find any Domain Controller" durchgeührt wird, der Schritt "find next closest site" zunächst in Erwägung gezogen wird. Eventuell habt Ihr diese Einstellung ja schon, daher nur sicherheitshalber erwähnt. Viele Grüße, toao

Hi, ein paar Fragen die bei der Analyse und der Entscheidungsfindung helfen könnten: - Liste an Fragen ob RODC (Liste nicht vollständig...): Phyisical security? - Locked Serverroom - Dedicated locked server rack? Phyisical access? - Restricted\Limited access to Serverroom and\or server rack? - Audited access process? - Liste an Fragen ob RODC oder DC grundsätzlich in Frage kommt (Liste nicht vollständig...): What is the connection bandwidth to next Datacenter? What is the connection latency to next Datacenter What is the connection reliability? What is the connection availability? Is there a secondary/backup connection line? How many users\computers on site? Systems, applications, services, it-solutions which are heavily using ADDS? Business criticality of the site? Über oben genannte Fragen lässt sich "diskutieren". Es soll hier vielmehr einen Eindruck vermitteln, wie man sich dem Thema nähern kann, um besser einschätzen zu können ob ein Einsatz eines RODC oder DC in Frage kommt und ob es vielleicht auch ohne geht. Zum Thema "Parallel DC und RODC an einer "site" zu betreiben, kann man sich diesen Artikel mal durchlesen (auch wenn er von 2008 stammt): https://learn.microsoft.com/en-us/previous-versions/orphan-topics/ws.10/cc730693(v=ws.10)?redirectedfrom=MSDN In der Tat, wie schon einige hier erwähnt haben, gibt es extrem wenige Fallbeispiele in dem ein RODC Sinn ergibt. Und ich möchte diese Aussage auch in der Hinsicht erweitern, dass manch ein Unternehmen oder Admin sich wundern würde, in wie vielen Fällen es auch funktioniert + vertretbar ist (mit allen potentiellen CON's) an einer "site" keinen RODC und keinen DC zu haben. Lasse Dir am besten von Deinem Berater eine Aufschlüsselung geben, eine Herleitung anhand Deiner Umgebung und Gegebenheiten, warum in Eurem Fall, diese "Sicherheitsmaßnahme" auch wirklich eine ist. Gruß, toao

Hi, "A Treatise on Group Policy Troubleshooting–now with GPSVC Log Analysis!" https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/a-treatise-on-group-policy-troubleshooting-8211-now-with-gpsvc/ba-p/400304 Gruß, toao

Immer wenn ich den Satz vom Nils lese, lese ich es anders raus Dann bin ich ja beruhigt, dass Nils das genauso meinte. Bye, toao

Hallo allerseits, wohl war und danke für die Ausführungen, bis auf: "Hier könnte ein Angreifer im System "überleben", wenn die beiden Änderungen innerhalb der Lifetime vorhandener Tickets geschehen." - Andersherum, je kürzer die Zeitspanne ist, desto eher wird der Angreifer "rausgekegelt". In einem Cyberattack Szenario kann dies sogar erwünscht sein, trotz der Tatsache, dass dies auch auf andere ausgestellte Tickets Auswirkungen hat, die dann ungültig werden und der (Business)-Service dahinter zum Erliegen kommt. Zu ein paar Punkten der Liste, auch wenn der TO schon mit NorbertFe sich weiter abgestimmt hat, eventuell bringt es dem einen oder anderen eine zusätzliche Sicht auf die Dinge: 1. Bitte sicherstellen, dass Backups & erfolgreiche Restore-Tests deines Forest vorhanden sind. Obwohl ich dies in all den Jahren nicht erlebt habe, dass etwas "schief" gelaufen ist, gäbe es in Deinem Falle von 2012 auf 2016 keine Rollback Möglichkeit. Daher würde ich dies eher beantworten mit: Likelihood, dass etwas "schief" geht: Nahezu unmöglich. 2. Vorab Analyse über das Log Deiner Domain Controller: Microsoft-Windows-SMBServer/Audit mit der ID 3000 durchführen und für eine Zeit lang auswerten. Best case, leer. 3. Bevor man dazu übergeht "Send NTLMv2 response only. Refuse LM & NTLM" einzustellen, am besten Vorab Analyse über die Logs Deiner Domain Controller: Log Name Security, ID4776 und Ausschau halten nach "Microsoft_Authentication_Package_V1_0" . Alternativ auf Memberservern die Logs von Security, ID4624 durchforsten. 5. Niemals alle priviledged accounts hinzufügen, je nach Szenario sägst Du Dir den Ast ab. Mindestens 1 (besser 2) priviledged accounts (idealerweise Built-In Administrator account (nicht deaktiviert) + 1 Break Glass Account) nicht hinzufügen. 7. Obacht, abhängig gemäß dem Status der ACL, führt das Entfernen dazu, dass 3rd Party Solutions auf die Nase fliegen. Praxisbeispiel, einige 3rd Party Solution setzen auf die Permission "Read Account restrictions" auf, dies is inkludiert in der ACE Pre-2000 aber nicht in der ACE Authenticated Users innerhalb derselben ACL. Vorab Analyse über Domain Controller Security Logs ist hier ratsam, zum Beispiel über Securty, 4662, welche Dir genau anzeigt welche Properties versucht werden auszulesen. *Randnotiz: Je nach Historie, alter des Forests, sollte in der Pre-Windows 2000 Compatible Access die zusätzlichen Einträge "ANONYMOUS LOGON" oder "Everyone" stehen, würde ich den Fokus eher darauf legen und hier etwas rigeroser vorgehen und diese (ohne Analyse) entfernen. Aber, dies muss jeder für sich (und die Firma) selbst entscheiden :) Sorry bin jetzt nicht wirklich auf die Reihenfolge und auf die Kritikalität eingegangen, hoffe dennoch das die eine oder andere Information weiterhilft und eventuell einen weiteren Denkanstoß mit sich zieht. Bye, toao

Hi Robinho1986, zum Thema "Wo wird der Domain-Admin genutzt" ein paar potentielle Anwendungsbereiche: - Scheduled Tasks - Local Services - IIS Application Pool - Scripts, batches - Tools, Applications Richtig, dass alles solltest Du versuchen mit einem Script abzufragen. Zusätzlich könntest Du auch etwas über die nachfolgenden Windows EventIDs (auf den Domain Controllern) herausbekommen (auch mit ins Script einarbeiten): Kerberos: 4768: A Kerberos authentication ticket (TGT) was requested. 4769: A Kerberos service ticket was requested. 4770: A Kerberos service ticket was renewed. NTLM: 4779: The computer attempted to validate the credentials for an account. *Bitte prüfe ob das Auditing zumindestens für die oben genannte EventID's, bei Euch entsprechend eingerichtet ist. Du erhälst in allen EventIDs zwar nicht den genauen Prozess, Service serviert, jedoch die IP-Adresse(Hostname) des Endsystems. Quasi ein Anfang um weitere Nachforschungen durchzuführen. Sobald es ans eingemachte geht, den Domain-Admins gegen einen Service-Account zu tauschen, bitte favorisiere als Service-Account immer einen MSA/GMSA (object class ms-DS-Group-Managed-Service-Account) wo immer es geht und nicht einen Service-Account auf Basis der object class: user. Je nach Größe des Unternehmens, kannst Du damit sicherlich ersteinmal ordentlich zu tun haben. Das Tiering- und Delegation Model würde ich sagen ist nie verkehrt. Da müsst Ihr schauen welche Kapazitäten ihr habt das parallel laufen zulassen , wie versiert Ihr mit der Delegierung von Berechtigungen im AD seid und einiges mehr. Da kann man sich schnell verlieren und soetwas muss sorgfältig geplant und durchgeführt werden. Viel Erfolg beim Aufspühren der Nutzung des Domänen-Admins in den nächsten Tagen und Wochen :) Toao