Jump to content

daabm

Expert Member
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    5.202

  • Registriert seit

  • Letzter Besuch

 Inhaltstyp 

Beiträge erstellt von daabm

  2. Start Kontextmenü für Benutzer ausblenden

    in Windows Server Forum

    Geschrieben

    Schwafelt blödes Zeug und gibt nichtssagende Antworten. :-)

    BTT: Ich bin bei @cj_berlin - ein Nicht-Admin hat in diesem Menü nichts, womit er irgendwas anstellen kann, das irgendwelche Auswirkungen auf andere User oder den Computer hat. Also wozu? Aber wenn's Dich glücklich macht - erstell den relevanten AppData-Ordner per GPP Preferences und mach ihn Readonly/Hidden, dann sind alle Einträge weg bis auf Desktop. Behaupten manche - ich probier das nicht aus, weil ich ja das "wofür" nicht nachvollziehen kann :-)

    • Danke 2
    • Haha 1

  7. Security für Admin-Accounts

    in Windows Forum — Security

    Geschrieben

    vor 2 Stunden schrieb wznutzer:
    • Den lokalen Adminaccounts ist es auch verboten sich per Netzwerk zu verbinden.
    • RDP, WinRM usw. ist per Windows-Firewall auf bestimmte Endpunkte beschränkt.

     

    An den 2 Punkten scheitern wir. Den ersten hatten wir - aber jetzt liegen die PW der Builtin Admins in einem zentralen Store (Cyberark), der die auch rotiert. Und da wir dafür derzeit keinen Reconcile-Account aus der Domäne nutzen, muß Cyberark sich mit den aktuellen Credentials remote verbinden dürfen :-( (Nicht mein Design, ich kann die Welt nicht alleine retten). Den zweiten würden wir gern machen, geht aber nicht, weil wir zu viel Bewegung in unseren Netzen haben und zu viele Menschen für unterschiedliche Teile der RDP-Zugriffskette verantwortlich sind. Wobei ich die Idee mal mitnehme und mit ein paar Menschen besprechen werde, weil das eigentlich ein QuickWin wäre.

     

    Beim Rest Daumen weit hoch von mir. Für "nur" 100 MA hast Du da echt viel umgesetzt 👍

     

    PS: Network Access haben wir auf AuthUsers belassen - das hätten wir nie eingefangen bekommen, wenn da per Default niemand drinsteht und jeder, der nen Service aufbauen will, sich darum auch noch kümmern darf...

    • Like 1
    • Danke 1

  10. Security für Admin-Accounts

    in Windows Forum — Security

    Geschrieben

    vor 8 Stunden schrieb soulseeker:

    ein Wust an service-accounts als Do-Admins, wo keiner mehr wusste, wozu die mal da waren.

     

    Dagegen hilft nur striktes Identity Management und Review aller "ungeklärten" Accounts, bis sie weg sind. Wir sind dran, aber das ist auch ein größerer Act... Vor allem, wenn sich die Accounts sporadisch noch anmelden, keine Beschreibung haben und die in der Description händisch eingetragenen Ansprechpartner seit 8 Jahren nicht mehr im Unternehmen sind 🙈

    vor 3 Stunden schrieb testperson:

    Es ist nicht ganz "rechnung.zip.exe", aber hey: Videokonferenz voller KI-Klone: Angestellter schickt Betrügern 24 Millionen Euro | heise online

     

    Das ist rechnung.zip.exe auf Steroiden... Echt krasse Show :-)

  12. Security für Admin-Accounts

    in Windows Forum — Security

    Geschrieben

    Ach halt doch die Klappe 😂

    Um wieder auf was fachliches zurückzukommen: Alleine die Quirks, die uns Kerberos beschert hat, reichen für ein Buch. Disjoint Namespaces, DNS-Aliase ohne Ende (damit jeder "seinen" persönlichen Namen ansprechen kann), Accounts aus unterschiedlichsten AD-Domains, die auf DNS-Namen in "irgendwelchen" DNS-Domains zugreifen wollen - Du wirst nicht fertig. Bis jeder erst mal verstanden hat, daß ein FQDN hinten eben kein Realm hat, sondern nur nen DNS-Namensraum - da kriegst schon Junge. Und geschätzt 1/2 unserer FQDNs enden nicht auf Kerberos-Realms (=AD-Domains), sondern nur auf DNS. So viele Mappings kannst gar nicht machen...

     

    Und mit NTLM war das alles "gar kein Problem" 🙈

    • Haha 1
    • Traurig 1

  16. Security für Admin-Accounts

    in Windows Forum — Security

    Geschrieben

    Aus dem Alltag eines Umsetzungsveranstalters... Einführung von Tier-Trennung und Eliminieren von NTLM-Auth:

     

    Du mußt jedem erst mal erklären, warum er jetzt ne Domain mit angeben muß.

    Du mußt danach jedem auch erklären, daß es überhaupt verschiedene Domains gibt und warum das wichtig ist.

    Danach erklärst Du dann den "Doppel-Tier-Leuten", warum sie jetzt 2 Accounts haben und mit denen jeweils andere Dinge können bzw. eben nicht können. Und warum das alles vom Arbeitsplatz aus gar nicht mehr geht.

     

    Damit hast Du die Basics der Tier-Trennung aus Sicht "Admin-Accounts" beinahe durch - wenn man ignoriert, daß "eigentlich" auch alle Peripheriesysteme (Identity Management, Systems Management, Inventory Scanner etc.) getrennt aufgebaut werden müssen. Das bezahlt aber quasi niemand, da wirst Du Kompromisse eingehen müssen. Das Thema PAW ist damit auch noch ungelöst - wir haben's mit CyberArk gemacht. MFA ebenso.

     

    Und gegen "verschlüsselt in der Ecke" hilft das auch nur bedingt. Im Kontext des Work-Accounts kann man halt immer alles verschlüsseln, auf das der Work-Account Schreibrechte hat.

     

    Wenn Du (wie wir) gleichzeitig versuchst, NTLM loszuwerden, mußt Du dann jedem erklären, warum sein Adminserver jetzt nicht nur seine Zielserver erreichen muß, sondern auch ziemlich viele DCs. Und warum DNS-Aliase nicht mehr funktionieren. Und warum er plötzlich nicht mehr auf \\10.0.1.15\c$ kommt... ("Ging doch bisher immer")

    Dann aktivierst Du LDAP Channel Binding und stellst fest, daß Deine Loadbalancer für LDAPS über Nacht unbrauchbar geworden sind, weil sie SSL terminieren.

     

    Und dann merkst Du, daß die meisten MFP (Scan to Folder) zwar Kerberos unterstützen, aber daran sterben, wenn der Serviceaccount nicht im Realm der Domain ist. Und daß auch ganz viele Drittanbieter Kerberos "unterstützen", aber nur wenn alles in einem Realm liegt.

     

    Daran stirbt übrigens sogar .NET - System.DirectoryServices.AccountManagement verträgt es nicht, wenn der ausführende Account aus einer trusted Domain kommt: https://github.com/dotnet/runtime/issues/95676. Und es stirbt auch, wenn GetAuthorizationGroups aufgerufen wird, der Zielaccount Mitglied von Gruppen ist, die ForeignSecurityPrincipals als weitere Mitglieder haben (warum das überhaupt geprüft wird, weiß nur MS) und der ausführende Account keine Leserechte auf die FSP-Objekte hat.

    Citrix PVS hat auch ganz lustige Probleme mit Trusts. Die checken nämlich an bestimmten Stellen nicht "reale" Gruppenmitgliedschaften von Serviceaccounts, sondern schauen ins AD. Konkret mußte ein Serviceaccount aus einer trusted Domain dort (!) in eine domain local (!) Group... 🙈

     

    Wenn Du dann noch aufgrund "organisatorischer Anforderungen" (= Management-Wünsche) disjoint Namespaces hast, dann hast Du jetzt richtig Spaß an der Sache 😁 Und bist für mehrere Jahre unentbehrlich .

     

    Da fließt noch sehr viel Wasser ins Meer...

     

    PS: Wir haben ~8.000 MA im Konzern.

    • Like 1
    • Danke 2

  21. MSRC Blog Post vom 19.01.2024

    in Windows Forum — Security

    Geschrieben

    vor 46 Minuten schrieb cj_berlin:

    Ich habe das in nahezu jeder Umgebung gesehen, wo ich ein Audit gemacht habe. Richtig erschreckend finde ich halt auch, dass der Kram seit 10 Jahren nicht mehr funktioniert, die Accounts aber immer noch gültig sind.

     

    Korrektur... AFAIK: Man kann keine PW mehr eintragen im UI. Wenn sie aber drin sind, werden sie weiterhin verarbeitet. Und wenn dann keiner "call to action" ruft, ändert sich halt nix. MS hat damals leider versäumt, nicht nur das UI zu patchen, sondern auch die CSE.

×
×
  • Neu erstellen...