[English]Ein Blog-Leser hat mich die Tage auf ein möglicherweise bei einigen Active Directory-Systemen bestehende Sicherheitsrisiko hingewiesen. Sind in der Active-Directory-Gruppe Authenticated Users externe Konten enthalten, könnten Freigaben interner Dienste (Drucker etc.) ungewollt externen Nutzern offen stehen.
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
Blog-Leser mmx24816 hat mich in einer E-Mail auf eine latente Sicherheitslücke in der Active Directory-Konfigurierung hingewiesen, die wohl nicht breit bekannt ist (danke dafür). Ich stelle es mal als Information hier im Blog ein, vielleicht hilft es dem einen oder anderen Blog-Leser.
Problem Authenticated Users
Der Leser schrieb, dass er mich auf ein weit verbreitetes, aber kaum kommuniziertes Sicherheitsrisiko im Microsoft-Ökosystem aufmerksam machen möchte, das insbesondere ältere Active-Directory-Infrastrukturen betrifft. Hier die Ausgangssituation bzw. Annahme des Blog-Lesers:
- Die Gruppe Authenticated Users wurde früher – wie viele Admins noch heute annehmen – als Sammlung aller Benutzer der eigenen AD-Domäne verstanden.
- Seit Jahren umfasst diese Gruppe – durch die Integration von Azure AD, föderierten Identitäten und Microsoft-Cloud-Diensten – auch externe Konten. Dies können z. B. Konten von Partnerunternehmen oder Microsoft-Diensten (Outlook.com, Azure AD B2B etc.) sein.
Diese Erweiterung wurde, so der Blog-Leser, nie von Microsoft klar kommuniziert und sei in vielen Umgebungen bis heute unbekannt.
Wo liegt das Problem?
Der Leser schrieb, dass in etlichen Unternehmensnetzwerken Fileserver-Freigaben, Drucker oder Anwendungen seit Jahren für Authenticated Users freigegeben sind. Die zuständigen Administratoren wähnen sich in der Annahme, dass damit nur eigene Domänenbenutzer gemeint sind, auf der sicheren Seite.
In Wirklichkeit, so schreibt der Leser, könnten diese Freigaben seit Jahren externen Benutzern offenstehen, sobald diese Nutzer sich erfolgreich über föderierte Microsoft-Dienste authentifizieren. Das hat zur Folge, dass ein externer Benutzer mit Azure AD-Föderation oder Microsoft-Konto potenziell Zugriff auf sensible Dateifreigaben erhalten könnte – und dies ganz ohne klassische Einladung oder Gruppenmitgliedschaft im AD.
Als besonders kritisch betrachtet der Blog-Leser, dass diese Art von Zugriff in vielen Audits nicht gesondert auftaucht, weil technisch gesehen ein "authentifizierter Benutzer" zugreift.
Der Leser zieht das Fazit, dass es sich bei obiger Konstellation sicherheitstechnisch um eine Zeitbombe handelt. Was viele Administratoren einst als internen Zugriff konfiguriert haben, öffnet unter den heutigen Rahmenbedingungen unter Umständen Tür und Tor für externe Identitäten – ohne dass dies jemals offiziell kommuniziert wurde. Der Leser meinte: "Ich würde mich freuen, wenn dieses Thema über Ihren Blog weitere Aufmerksamkeit erfährt."
Empfohlene Maßnahmen
Der Blog-Leser hat mir in seiner E-Mail einige schnellstmöglich durchzuführende Maßnahmen zum Absicherung des Active Directory vorgeschlagen. Hier die betreffenden Maßnahmenliste im Telegramm-Stil:
- Sofortige Überprüfung aller Ressourcenberechtigungen, die für Authenticated Users gesetzt wurden.
- Austausch durch spezifische Gruppen wie Domain Users oder eigene Sicherheitsgruppen, die ausschließlich interne Konten enthalten.
- Einführung von Conditional Access Policies (bei Azure AD), um Zugriff aus unsicheren Quellen auszuschließen.
- Kommunikation und Sensibilisierung innerhalb der IT-Teams – viele Admins sind sich dieser stillen Ausweitung nicht bewusst.
Vom Leser wurden mir noch folgende Quellen zur weiteren Recherche geschickt, die ich hier einfach verlinke:
- Microsoft Learn: Special identity groups
- Microsoft Learn: Authentication and Conditional Access for External ID
- Microsoft Docs: Grant Everyone claim to external users
MVP: 2013 – 2016
Ich: "Hey Chef, soll ich mal die Vertrauensstellung zum Active Directory der Firma XY löschen, mit der wir seit Jahren (vor meiner Zeit!) nicht mehr zusammenarbeiten?"
Eh Nein, Nein, Nein und Nein. Es ist unbeschriebens Gesetz und Admin Regel seit Dekaden, dass etwaigen Defaultgruppen wie z.B."Authenticated Users", "Backup Admins" etc. explizit nie nie nie vertraut werden sollte und man gefälligst Servicekonten, -gruppen etc. selbst erstellt und Vertrauensstellungen einrichtet. Bzw. seine Systeme härtet und den Default Gruppen Rechte entzieht. Da gibt es seit Äonen Checklisten und Best-Practise Anleitungen für.
Welcher Depp macht sowas? Ein "authenticated User" könnte unter Umständen auch ein IISUser sein.
Als ich hier bei uns vor Jahren neu angefangen hatte, musste ich den lieben Kollegen erstmal die Unsitte austreiben, Sharefreigaben auf "Everyone" zu berechtigen. Gut, Ok, sie haben dann auf NTFS-Berechtigung größtenteils sinnvolle Berechtigungen auf selbst definierte Gruppen (für die Unterordner von Profilen, Projekten usw.) vergeben, aber wenn man da einen Fehler macht, steht halt alles offen. Die Unterschiede zwischen "Everyone", "Authenticated User" und "Domain-User" kennt halt nicht jeder. Zum Glück aber findet man beim BSI im Grundschutz eine entsprechende Anforderung, das hat dann Gewicht und Autorität zur Einsicht. Aber es wird gelegentlich immer noch/wieder falsch gemacht, weil man es vergessen hat, oder neue Kollgen das auch nicht wissen. So bleibt mir nichts anderes übrig, als mir gelegentlich alle Shareberechtigungen anzusehen…
wer Share Berechtigungen granularer als Everyone Modify setzt hat meiner Meinung nach eifach Probleme mit richtiger NTFS Berechtigungen und fährt wohl auch mit 2 Helmen Fahrrad. Absolute Unart, schlechte Basis mit unnötiger Verkomplizierung lösen zu versuchen.
klar wer bei einem Fileshare nicht erst die Creator und Everyone Default Berechtigungen entfernt, gehört sollte seine Adminrechte sowieso längstens abgeben.
> klar wer bei einem Fileshare nicht erst die Creator und Everyone Default Berechtigungen entfernt, gehört sollte seine Adminrechte sowieso längstens abgeben.
Da liegst Du etwas falsch. Creator Rechte werden zwingend bei servergespeicherten Profilordnern benötigt. Sonst fehlt einem neuen User sein Profil.
Diese "Unsitte" wurde von Microsoft in Schulungen explizit so gelehrt: Share-Berechtigungen sind nur dann zu setzen, wenn via Netzwerk weniger Rechte als lokal gelten sollen (dann gilt ja NTFS. Share-Berechtigungen seien letztlich Relikte für Freigaben auf FAT-Dateisysteme.
Es kommt auch noch erschwerend hinzu das auch alle Computer-Accounts der Domäne zu "AuthenticatedUsers" gehören. Das wird gerne übersehen bzw. ist teilweise nicht bekannt.
Ist für mich ein Admin Problem. Sowas ist normalerweise vom AD-Team in Vorfeld klar geregelt und daran hat man sich zu halten.
Zudem sollten durch Netzsplittings (Vlan etc.) nicht das ganze Netz "extern" zur Verfügung stehen, falls man doch mal jemanden hat, der nicht klar denken kann.
Letztendlich hat man auch Sicherheit/Audit Tools im AD laufen, die normalerweise auf solche Fehler aufmerksam machen.
Welche Audit-Tools kennst du, welche Share-, NTFS- und sonstige Berechtigungen überwachen und bewerten ? Die meisten Audit-Tools reporten duch nur, wer welche User bearbeitet hat, vielleicht noch GPOs, aber das?
Aloha
@Wetterchen, ja im Normalfall wird sowas geplant, durchgespielt, als Konzept verewigt und vorallem durchgesetzt.
Leider werden von MS immer wieder die "Spielregeln" im laufenden Betrieb geändert. Was die Planung im Vorweld zunichte macht. Womit Tomas vollkommen recht hat wenn er sagt das man Default Gruppen die Rechte entziehen und eigene Gruppen berechtigen sollte.
@Gänseblümchen: Ich scanne von zeit zu Zeit meine lokalen Freigaben per Powershell und lasse es mir dann in CSV exportieren. Schon allein weil ich meinen DSGVO beauftragten gerne mit Arbeit proaktiv so zu mülle bis er keinen Bock mehr hat. Bei Bedarf kann ich dir das Script auf einen Share freigeben.
ich hätte da auch Interesse dran.
wenn du es auf einem GitHub gist o.ä. bereitstellen kannst, wäre das super Klasse.
=)
Ja, kann man so machen, wenn man nur ganz wenige Server hat, aber wenn du ein mittleres dreistelliges "Rudel" hast, was dann?
Aloha,
ja im Normalfall wird sowas geplant, durchgespielt, als Konzept verewigt und vorallem durchgesetzt.
Leider werden von MS immer wieder die "Spielregeln" im laufenden Betrieb geändert. Was die Planung im Vorweld zunichte macht. Womit Tomas vollkommen recht hat wenn er sagt das man Default Gruppen die Rechte entziehen und eigene Gruppen berechtigen sollte.
Ich scanne von zeit zu Zeit meine lokalen Freigaben per Powershell und lasse es mir dann in CSV exportieren. Schon allein weil ich meinen DSGVO Beauftragten gerne mit Arbeit proaktiv so zu mülle bis er keinen Bock mehr hat. Bei Bedarf kann ich das Script auch auf einen Share freigeben.
Wenn das hier erlaubt ist?
Du könntest mir das Script per Mail zukommen lassen – ich kann es dann ggf. im Artikel nachreichen.
Hi,
ging es mit dem Punkt (Script) weiter?
Bin mir unsicher ob ich es übersehe oder einfach nicht da ist. :)
Grüße
Ich habe erinnerungsmäßig nie was bekommen. Martin hatte keine E-Mail-Adresse im Kommentar hinterlassen und wohl auch meinen Kommentar nie gelesen.
Schade, danke für die schnelle Rückmeldung.
Kapiere ich nicht. In dem verlinkten Microsoft Dokument von 2018 ist doch ausschließlich von Entra Gruppen und "All Authenticated Users" die Rede. Also nicht die "Authenticated Users" von on-prem. Außerdem wie soll ein guest user in Entra, der keine Repräsentation im AD hat, auf lokale Fileserver zugreifen? Passt für mich alles nicht zusammen.
Das einzige Sicherheitsproblem sind hier ungebildete Admins und/oder die, die die zwei Wörter nicht übersetzen können.
Wie oben schon von jemandem geschrieben ist es fast immer extrem dämlich, Everyone/Jedem und Konsorten Rechte zu erteilen, auch wenn danach noch die hoffentlich besser durchdachten NTFS-Rechte als zusätzlicher Filter angewendet werden.
Und nein, Microsoft hat hier niemals zu Dummheit aufgerufen. Nur bei Apple war die Devise "Don't make me think".
"Wie oben schon von jemandem geschrieben ist es fast immer extrem dämlich, Everyone/Jedem und Konsorten Rechte zu erteilen, auch wenn danach noch die hoffentlich besser durchdachten NTFS-Rechte als zusätzlicher Filter angewendet werden.
Und nein, Microsoft hat hier niemals zu Dummheit aufgerufen."
Die NTFS-Rechte sind der einzig sinnvolle Filter, es sei denn, jemand will aus irgendeinem Grund übers Netz restriktivere Zugriffsrechte als lokal auf dem freigebenden PC – ich wüsste eigentlich keinen. Die getrennte Rechtevergabe für die Freigabe selbst ist eindeutig ein Überbleibsel aus der Zeit, als Ordner auf FAT-Dateisystemen freigegeben werden mussten. Auf Datenträgern mit NTFS haben die Freigaberechte mMn keinerlei Berechtigung mehr (ich entschuldige mich für das schlechte Wortspiel.)
Ich erinnere mich noch gut an die Schulungs-Unterlagen und Bücher zum Thema:
– Zugriffs-Rechte werden an EINEM Ort vergeben: im Dateisystem
– damit sind die Berechtigungen an EINEM Ort überblickbar
– und durch die NTFS-ACLs auch viel differenzierter zuzuordnen (und einiges geht *nur* per ACL)
Wer darauf hoffen muss, dass die "hoffentlich besser durchdachten NTFS-Rechte als zusätzlicher Filter" fungieren, hofft hoffentlich nicht vergeblich ;-)
Dass bei freigegebenen Ordnern die nicht sinnvollen ACLs wie "Benutzer: Lesen" und "Authentifizierte Benutzer: Ändern" gelöscht weren sollten, versteht sich von selbst.
Und in einer Domäne sind die Zugriffsrechte freigegebener Ordner – nicht hoffentlich, sondern selbstverständlich – ordentlich geplant und dokumentiert.
> Ich erinnere mich noch gut an die Schulungs-Unterlagen und Bücher zum Thema:
– Zugriffs-Rechte werden an EINEM Ort vergeben: im Dateisystem
– damit sind die Berechtigungen an EINEM Ort überblickbar
– und durch die NTFS-ACLs auch viel differenzierter zuzuordnen (und einiges geht *nur* per ACL)
Du meinst wohl das AGDLP! Accounts -> Global Groups -> Domain Local Groups ==> Granted Persmissions
Link: https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/
Das ist / sollte eigentlich Standardhandwerk von Administratoren sein!