This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

STAS und Read Only Domain Controller

Moin Zusammen

wir haben ein Problem mit STAS der Authentifizierung in Verbindung mit einem RODC.

Das Thema haben wir auch schon an den SOPHOS Support herangetragen aber kommen dort irgendwie nicht weiter.

Wir sind vor kurzem erst von Watchguard Produkten zu SOPHOS gewechselt. Wir haben 3 Standorte und betreiben je Standort 2 SOPHOS XGS4300 im HA Cluster.

Wir benutzen an allen Standorten STAS zur Benutzerauthentifizierung. An 2 von 3 Standorten funktioniert das auch Problemlos.

Jedoch betreiben wir an einem der Standorte einen Read Only Domain Controller, da wir von dort aus bestimmte Gruppen bzw, Benutzer in ein Cloudbasiertes MDM System syncen.

Solang der RODC läuft funktioniert an diesem Standort die STAS Authentifizierung bei einigen Benutzern nicht richtig. Und zwar, so wie es ausschaut, bei allen die sich über den RODC anmelden.

Die Benutzer tauchen dann zwar in den Live Users auf der SOPHOS auf, allerdings nicht mit ihrer Client IP sondern mit der Adresse des RODC.

Wir vermuten aktuell das es an der Art und Weise wie liegt, wie der RODC Benutzeranmeldungen verarbeitet. Da er selber keine Kennwörter speichern darf, wird die Anmeldung ja immer an den nächsten beschreibbaren DC gegeben. Dort wird dann auch ein Event mit der ID 4768 generiert. Auf dem RODC sind in dem Zusammenhang nur Events mit der ID 4624 zu sehen, welche ja nicht vom STAS überwacht werden?

Wir haben auch schon unterschiedliche Szenarien mit der STAS Suite auf dem DCRO durch probiert. Es brachte aber keinen Unterschied ob wir die Suite vollständig installiert haben, nur den Agent oder gar nichts.

Hat hier vielleicht schon jemand Erfahrungen mit dem Thema gemacht und hat einen Tipp wie wir das Problem lösen können?



This thread was automatically locked due to age.
  • Ich würde vermuten, dass etwas mit dem Windows RODC nicht stimmt.

    https://resources.infosecinstitute.com/topic/relevance-of-windows-eventids-in-investigation/

    Wenn man sich das anschaut, sieht man, dass diese Events eher die falschen sind. 

    As you might be confused by now that how 4624, 4625 is different from 4776 since they both indicates successful or failed login. Actually, EventID 4624, 4625 are generated when credentials are stored in local machine/ when the system cannot reach Domain Controller. When the machine is connected to Domain, it is the duty of Domain Controller to authenticate the user using Kerberos. Thus in this EventID like 4771, 4768, 4776 will be generated.

    __________________________________________________________________________________________________________________

  • Danke erstmal für die schnelle Antwort.

    Ja genau das ist der Punkt, im ersten Moment scheinen auf dem RODC nicht die richtigen Events generiert zu werden, aber das stimmt auch wieder nur so halb. Deswegen bin ich mir unsicher ob mit dem RODC wirklich etwas nicht stimmt, oder ob er eigentlich arbeitet wie er soll.

    Grundsätzlich haben wir, genau wie es auch in den SOPHOS Guides beschrieben ist, die Default Domain Policy so konfiguriert, dass Events mit der ID 4768  auf den DCs generiert werden. (Anmeldungen überwachen usw.) Das mussten wir auch schon für die alten Watchguard Agents machen.

    Auf dem RODC taucht auch hin und wieder mal ein Event mit der richtigen ID auf, also zieht die Policy. Aber scheinbar wird eben kein Event mir der ID 4768 generiert wenn der DCRO eine Anmeldung an einen beschreibbaren DC weiterleitet. Wenn man sich mal anschaut wie ein DCRO eine Anmeldung verarbeitet, könnte das aber ein gewolltes verhalten sein. Hier mal Auszug  aus einem Artikel...

    1. Ein Anwender meldet sich am Standort des RODC an.
    2. Der RODC überprüft, ob das Kennwort des Anwenders auf den Server repliziert wurde. Falls ja, wird der Anwender angemeldet.
    3. Ist das Kennwort nicht auf dem RODC verfügbar, wird die Anmeldeanfrage an einen vollwertigen DC weitergeleitet.
    4. Ist die Anmeldung erfolgreich durchgeführt, wird dem RODC ein Kerberos-Ticket zugewiesen.
    5. Der RODC stellt dem Anwender jetzt noch ein eigenes Kerberos-Ticket aus, mit dem dieser Anwender arbeitet. Gruppenmitgliedschaften und Gruppenrichtlinien werden übrigens nicht über die WAN-Leitung gesendet. Diese Informationen werden auf dem RODC gespeichert.
    6. Als Nächstes versucht der RODC, das Kennwort dieses Anwenders in seine Datenbank von einem vollwertigen DC zu replizieren. Ob das gelingt oder nicht, hängt von der jeweiligen Gruppenmitgliedschaft ab.
    7. Bei der nächsten Anmeldung dieses Anwenders beginnt der beschriebene Prozess von vorne

    Best Practices Active-Directory-Security (2) | it-administrator.de

  • Ich kann dazu leider auch nicht mehr sagen außer das wir nach dem 4768 Event schauen und nicht nach der anderen ID. Warum der RDDC das so macht, kann ich nicht beurteilen - Das sollt ggf. mit Microsoft abgestimmt werden. Laut dem Artikel oben sieht das falsch aus.  

    __________________________________________________________________________________________________________________

  • Moin, um das ganze noch aufzulösen... Wir hatten ja parallel noch ein Ticket bei Sophos zu laufen und irgendwann hat dort ein Support Engineer den Fall übernommen, der das ganze dann auch ziemlich schnell auflösen konnte. Zusammengefasst kann man sagen der RODC arbeitet wie er soll und das STAS arbeitet wie es soll.

    Wie  schon richtig beschrieben hat, wird nur die Event ID 4768 ausgewertet. Da der RODC aber keine Kennwörter speichern darf, reicht er Anmeldungen die bei ihm ankommen immer weiter an den nächsten beschreibbaren DC. Daraus ergibt sich dann, dass auf dem DCRO keine Events mit der ID 4768 generiert werden. Leider gibt der DCRO auch nicht die richtige Client IP mit wenn er Anmeldungen weiterleitet, sondern immer seine eigene. Daher tauchen dann im STAS Live User mit der Adresse des RODC auf, wenn eine weitergeleitete Anmeldung letztlich an einem beschreibbaren DC ausgewertet wird.

    Wir hatten dafür jetzt 3 Lösungsansätze:

    - Den RODC in ein anderes Netz schieben (z.B DMZ oä.), wo er für Clients nicht erreichbar ist und somit nicht für Anmeldungen genutzt werden kann > dabei wäre aber zu beachten das in jedem Fall entsprechende Ports zum Replizieren mit anderen DC offen bleiben müssen

    - Die Benutzer in die Password Replication Group aufnehmen. > Das war der Vorschlag vom Sophos Support. Der RODC darf die Kennwörter der Mitglieder dieser Gruppe speichern und kann dann die Anmeldung  für diese Benutzer selbst durchführen. Das wollten wir aber aus Gründen der Sicherheit nicht.

    - Die Gewichtung des RODCs ändern > so haben wir es jetzt gelöst. Wir haben mittels Gewichtung die Priorität des RODC so niedrig gestellt des er von Clients nicht mehr für die Anmeldung genutzt wird. Funktioniert bisher problemlos