cj_berlin

Das Gesetz #8 der "10 Immutable Laws of Security Administration" besagt:

Zitat

The difficulty of defending a network is directly proportional to its complexity.

Das solltest Du beherzigen. Ich kenne die USG nicht, aber vermutlich kannst Du alles Gewünschte dort abwickeln, ohne noch einen Windows-Rechner als Bastion zu involvieren.

Moin,

diese Forderung habe ich auch ein paarmal gesehen. Ich bin mir nur nicht sicher, ob sie bedeutet, dass die Prüfer nicht begriffen haben, dass AD kein IAM ist, oder ob sie nur zu genau wissen, dass die auditierten Kunden diesem Missverständnis aufgesessen sind.

Wer ein IDAM/IAM hat, kann auch ohne Objekte im Live-System sagen, von wann bis wann User X Schreibrechte auf Ordner Y und ein aktives Anmeldekonto hatte. Und wer dafür nur das AD hernimmt, die Gruppenmitgliedschaften aber zum Ausscheiden entfernt, wird diese Aussage nicht retroaktiv treffen können, auch wenn die Accounts erhalten werden.

Scheint DNS zu sein.

Moin,

als erstes begreifst Du diese Situation bitte als Chance, endlich vom "God Mode" wegzukommen und alle Rechte nur an Domain Admins zu vergeben. Leg eine Gruppe "Profile Admins" an, berechtige die und packe die Admin-Accounts da rein, die das auch machen sollen. Selbst wenn im ersten Schritt dieselben Accounts da drin sind wie in den Domain Admins. Dies nur nebenbei, hilft Dir bei der Berechtigungsvergabe erst mal nicht weiter.

Vermutlich stört UAC die Berechtigungsvergabe. Versuche es über die Dollar-Freigabe das Laufwerks, auf dem die Freigabe liegt. Oder mit dem lokalen "Administrator"-Account des File-Servers. Oder Du schaltest kurz UAC ab.

Moin,

Nachdem das geklärt wäre, müsstest Du

1. VORHER das Advanced Auditing aktiviert haben - in der Policy *und* in den SACLs

2. Die Logs über die gesamte Zeitspanne gesammelt haben

3. Die Logs auswerten können.

Da Änderungen am Verzeichnis defaultmäßig nicht auditiert werden, scheitert Dein Vorhaben bereits am Punkt 1.

vor 1 Stunde schrieb HeizungAuf5:

 

Kennt jemand eine Möglichkeit, bzw. Software, welche in der Lage ist, die Datenbank ohne vorherigen Export - am besten geplant - zu kopieren? Gefunden habe ich bisweilen nur Software aus dem Enterprise Bereich, die uns um vier- bis fünfstellige Beträge erleichtern würde und diese Funktion nur ein "Mitbringsel" ist und ansonsten noch Funktionen mit bringt, die wir gar nicht brauchen

https://docs.dbatools.io/Copy-DbaDatabase

Zur Supportability von Replica für DCs: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/support-for-using-hyper-v-replica-for-virtualized-domain-controllers . Mit nur einem DC geht in dieser Hinsicht einiges  

Dein Problem ist die Zeitdienst-Konfig, das sagt ja auch die Ausgabe. Mach sie per Gruppenrichtlinie (dieser Artikel ist sehr lesenswert, wenn man gerade neu in das Thema einsteigt: https://theitbros.com/configure-ntp-time-sync-group-policy/).

Zum ursprünglichen Thema: Alle notwendigen DNS-Einträge müsste der DC neu erstellen, wenn man ihn (oder den NETLOGON-Dienst) neu startet.

vor 26 Minuten schrieb zahni:

Wir hatten am Ende 8.5.xx. Noch unter dem IBM-Namen. Der Verkauf ist mir bekannt. Eigentlich ist es immer noch eine Alternative zu Exchange. Der Webclient wurde schon damals groß ausgebaut. 

Wir gehen aber lieber in Cloud....

Ja, ich dachte, dieses "Verse" könnte vielleicht was werden, aber da ist ja sehr schnell sehr still drum geworden...

Moin,

kann es *irgendwie* sein, dass Deine iCloud auf die gleiche Mail-Adresse gekoppelt ist, die auch den UPN von Deinem AD-Konto stellt? Du schreibst zwar "private Anmeldedaten", aber vielleicht?

Fehlgeschlagene Logons (Event 4625) werden nicht im Default protokolliert, Du musst die Advanced Audit Policy für Deine DCs bearbeiten: https://www.manageengine.com/products/active-directory-audit/how-to/how-to-find-the-source-of-failed-login-attempts.html Auch die Kontosperrung (Event 4740) wird nicht per Default protokolliert - dafür musst Du die Policy "Audit User Account Management" aktivieren.

Am 21.2.2024 um 15:56 schrieb Nobbyaushb:

/OT: egal was ihr macht - OL-Dateien auf shares, egal wie sind nicht supportet - punkt
Aber das weißt du alles selber OT/

Das ist tatsächlich nicht 100% korrekt. PST auf Shares sind sehr wohl supported, das Szenario ist explizit auf VDI fokussiert, gemeint ist aber, dass das Netz zwischen Outlook und Filer sehr robust und sehr performant sein soll. Und der Support erstreckt sich nur auf Funktionalität, nicht aber auf die Performance des Konstrukts.

Zitat

Outlook 2010 or later versions hosted remotely by using Windows Server 2008 R2 or later RDSH or VDI configuration

Outlook 2010 or later versions functionality is supported when networked .pst or .ost files are used under the following conditions:

• A high bandwidth/low latency network connection is used.
• There's single client access per file (one Outlook client per .pst or .ost).
• Either Windows Server 2008 R2 or later Remote Desktop Session Host (RDSH), or Windows Server 2008 R2 or later Virtual Desktop Infrastructure (VDI) is used to run Outlook remotely.

If a specific Outlook feature stops working or the .pst or .ost file becomes corrupt and you can reproduce the issue in the above environment, contact Microsoft Support.

 

aus https://learn.microsoft.com/en-us/outlook/troubleshoot/data-files/limits-using-pst-files-over-lan-wan

Am 19.2.2024 um 17:37 schrieb illuminaten:

Könnt ihr mir bitte mitteilen wie die DNS Konfiguration bei einer RDS 2016 Farm aussehen muss.

Wenn Dein Farmname gleich Broker-FQDN ist, brauchst Du gar keine Einträge extra. Wenn Dein Farmname sowas wie "rds.firma.de" ist, muss dieser A-Eintrag auf den Broker zeigen. Oder die Broker, wenn Du Broker-HA hast.

vor 1 Minute schrieb Nobbyaushb:

Eine Lösung dafür hat Evgenij gepostet, ich würde das so nicht umsetzen wollen - wenn du mal irgendwo im realen Betrieb bist kann einem sowas schnell auf die Füße fallen - meine Meinung

Diese Lösungsansätze *sind* aus dem realen Betrieb. Nur weil ich nie Inhouse-Admin war (abgesehen von 7 Monaten in 1999-2000) heißt nicht, dass ich den "realen Betrieb" nicht kenne.

Und ordentliche kurze Label an Netzlaufwerken sind elementare Arbeitsplatz-Ergonomie. UNC-Pfade, die nur teilweise sichtbar sind, gerade auch wenn man DFS verwendet, würde ich auch nicht in meiner täglichen Arbeitsumgebung haben wollen. 

Da oben steht doch die Lösung für Dein vorhaben.

Was mich vor allem angesichts der Person des Urhebers wundert, ist, dass die Tests und die Misere am Ende mit ADWS und nicht mit LDAP erfolgten  @daabm  Du kannst das Ergebnis doch bestimmt auch mit dem DirectorySearcher reproduzieren - erhöhen sich da die Limits vielleicht?

Moin,

es gibt zwei Möglichkeiten: ganz einfach und recht einfach.

1. Wenn Du nur ein individuelles gemapptes Laufwerk brauchst, aber nicht diese Homedrive-Funktionalität, mappst Du das Laufwerk einfach per Group Policy Preference, da gibt es das Feld "Label", das funktioniert sofort.
2. Du kannst probieren, das Homedrive per GPP zu mappen und dann beim Logon im Skript SET HOMEDRIVE=H: und SET HOMESHARE=\\UNC\Pfad\zur\Share zu setzen, manchmal reicht's schon
3. Muss es aus Gründen zwingend ein "echtes" Homedrive sein, dann schreibst Du beim Logon das gewünschte Label nach HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##<FILESERVER>##<SHARE>#<ORDNER> in  den Wert _LabelFromReg (am besten im Explorer manuell umlabeln und dann einfach exportieren)
4. Alternativ kannst Du eine Desktop.ini in den Home-Ordner packen, da muss man aber ein wenig fummeln, bis das gelingt.

Das macht man dann optimalerweise dann, wenn *der* Anruf kommt, so in der Nacht von Samstag auf Sonntag  

Die Auswirkungen sind in beiden Fällen identisch: Der Kunde taucht eher früher als später in der Ransomware-Statistik auf. Und die Feststellung, dass wir als Berater nichts weiter tun können als darauf hinzuweisen, entbindet uns nicht von der Pflicht, dies dennoch ständig zu tun. Steter Tropfen und so weiter. Den Leuten, die nicht hören, ist eh nicht zu helfen - sie müssen fühlen und werden es auch.

Und weil es so schön ins Thema passt, gerade ganz neu: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/protecting-tier-0-the-modern-way/ba-p/4052851 Gefühlt der erste Artikel von Microsoft über Authentication Policies.

vor 5 Stunden schrieb NilsK:

ich finde es wichtig, hier noch mal darauf hinzuweisen, dass es zwar durchaus Umgebungen mit "Tier 0", dedizierten DCs usw. gibt,

Tier 0 hat nichts mit formal eingeführtem und technisch erzwungenem Tiering zu tun. Jede Umgebung hat Tier 0-Objekte, und das Ausführen der Apothekenverwaltung auf einem DC macht nicht den DC zu Tier 2, sondern die Apothekenverwaltung zu Tier 0. Mit allen Konsequenzen. Auch in "der Cloud".

Moin,

irgendwo in der Signalkette zwischen Angreifer und Tier 0 muss XDR - nicht ein einfacher filesystembasierter Virenscanner! - vorhanden sein, das steht fest.

Wenn also die Firewall so konfiguriert ist, dass ausschließlich Maschinen mit aktiviertem und entsprechend konfiguriertem XDR ("entsprechend" = "in der Lage, auch einen Angriff auf AD zu erkennen") zu Tier 0-Systemen Kontakt aufnehmen können (und damit meine ich *jeglichen* Kontakt), kann man auf Tier 0-Systemen schweren Herzens darauf verzichten.

Ist es nicht der Fall, und es ist tatsächlich möglich, von ungemanagten/ungeschützten Endgeräten ins Tier 0 zu kommunizieren, muss im Tier 0 selbst XDR-Schutz aktiv sein.

Am 16.2.2024 um 09:50 schrieb MiLLHouSe:

 

Hat jemand eine Idee, was das bitte sein soll? 

Moin,

zwei Fragen:

1. hast Du anhand der Event Log-Einträge verifiziert, von welchem Host die fehlgeschlagenen Anmeldeversuche kommen? Vielleicht haben sich da zwei Phänomene überschnitten, die nicht im Zusammenhang stehen...

2. Ist bei euch in der Default Domain Policy die Kennwort-Historie aktiviert? In diesem Fall würde die Sperrung ja bedeuten, dass nicht nur nicht das aktuelle, sondern auch nicht das letzte Kennwort verwendet wird.

So isses. Und als Merkprinzip dabei, wer es nicht täglich macht (gilt 99%, Ausnahmen bestätigen die Regel):

Zitat

Niemand verarbeitet AD-Daten so schnell und effizient wie ein Domain Controller 

vor 16 Minuten schrieb Nobbyaushb:

OT/ Warum baut man eine Windows-Domäne ohne DNS auf den DC oder zumindest einem Server?
Geht das eigentlich supportet?

/OT

Klar, der Artikel dazu ist so alt wie AD.

vor 2 Stunden schrieb lotsch17:

DerPfad ist aus einer KI

Für Dich, von der letzten BSides Berlin: 

Das macht die Frage nach dem "Warum, eigentlich?" umso spannender. Was können die User denn in diesem Menü so schlimmes ausrichten, dass Du es ihnen verweigern möchtest? Beim echten Kontextmenü würden mir vielleicht noch 1,5 Erklärungen einfallen, aber hier?..

Und wenn der Screenshot von dem betroffenen Server stammt, dann hat Deine Policy möglicherweise wirklich nicht gegriffen.