toao

Hi, nicht jeden ist richtig. Mittlerweile so viel das ich nach einer alternative zu "manuell" geschaut habe.

Hi an alle, folgende Anfrage aus dem business liegt mir vor: In einer DMZ (basierend auf ADDS) wird von den dort laufenden Diensten, Softwarelösungen, ... eine DNS Namensauflösung von Hostnamen benötigt, die sich in der Produktion (basierend auf ein eigentständiges ADDS) befinden. Mir fallen folgende Optionen ein - *ohne Bewertung hinsichtlich Aufwand, Sicherheit,...*: - DNS Proxy (z.B. Firewall) - Eingeschränktes (nur die DMZ Dienste, Softwarelösungen,.., die es brauchen) DNS port opening von DMZ zu PROD - Conditional Forwarder der DMZ DNS Server (Windows DNS Rolle) konfigurieren inkl. port opening - HOSTS Datei der DMZ Systeme nutzen - Auf den DNS Server (Windows DNS Rolle) der DMZ die DNS Zone der Produktion erstellen und pflegen - DNS zone transfer von Produktion zur DMZ Mir ist bewusst, dass viele dieser Ansätze problematisch sind - sei es aus Sicherheitsgründen oder wegen des Pflegeaufwands und weiteren Gründen. Undabhängig davon interessiert mich, welchen Ansatz ihr in solchen Fällen verfolgt und natürlich das "warum?". Grüße, toao

Hatte auch gerade herumgespielt, ein paar weitere Infos: Bei der Eingabe von "\\fqdn\netlogon" über SMB werden im TGS-REQ folgende 3 SnameStrings angefragt: cifs DCHOSTNAME.FQDN FQDN TGS-REP is successful und der SMB Tree Connect sieht am Ende so aus \\DCHOSTNAME.FQDN\netlogon. Bei der Eingabe von "\\fqdn über SMB werden lediglich im TGS-REQ 2 SnameStrings angefragt: cifs FQDN Die Anfrage wird mit einem ERR_S_Principal_Unknown quittiert. Ich hab's auf die schnelle mit dem hinzufügen des SPN Eintrags cifs/fqdn gelöst, aber wie oben schon von cj_berlin erwähnt, war dies nur auf einem Domain Controller möglich, da SPN = unique. Gruß, toao

Das wichtigste! Seid nett zum Azubi, dass passiert sogar den 'besten' mal. (Vollkommen egal aus welchen Gründen...) Gruß, Toao

Nun mach es doch nicht so spannend ;) setspn -q [DerZuSuchendeServicePrincipalName] By the way, den hier kann man sich auch mal für seine Umgebung zu Gemüte ziehen: setspn -x ... und ja der tsaenger sollte sich 'setspn -?' mal anschauen Schöne Woche, Toao

Guten Morgen, aktiviert lassen, ausreichendes Monitoring inklusive Alerting einrichten, das Kennwort offline sicher verwahren. Drills für den Forest Restore Process durchführen, Fehler beheben, dokumentieren. Gruß, toao

Link\Quelle " https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772815(v=ws.10)#service-principal-names", Titel "Built-in SPNs Recognized for Computer Accounts" Kurz zu "HOST", hält mehrere classes inne, setze mal ein query auf "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=[PLACEHOLDER],DC=[PLACEHOLDER]" ab, dann bekommst Du alle classes angezeigt, die HOST inne hält. (Oder ADSI Edit, wenn Dir die GUI mehr liegt). Sidenote: Jeder domain joined computer erhält by default (unteranderem) solch einen HOST SPN Eintrag. Wenn Du nun einen manuell setzen "musst", dann empfehle ich Dir (so wie in allen anderen Bereichen auch), konfiguriere immer nur das was benötigt wird. Macht Dokumentation, Troubleshooting, CleanUp, etc. um einiges transparenter, einfacher. ... "dann wird (wahrscheinlich) eine (NTLM) Authentizierung genutzt" ... die es natürlich zu verhindern gilt. Das fällt manchen nicht auf, setzen einen CNAME, Authentifizierung läuft in der Annahme es ist Kerberos, jedoch NTLM lässt grüßen... Gruß, 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