11
Herausforderungen mit Protected User Gruppe
Hi
wir testen gerade die Einführung der "Protected User" Gruppe, bzw. die Implementierung dieser und stoßen dabei auf ein paar Herausforderung die ich auch nicht über Google und "Try and Error" gelöst bekomme:
Was nicht funktioniert:
Ich tippe, dass er irgendwo immer auf NTLM zurückfällt, weiß aber nicht genau so ich nachschauen soll.
Vielleicht weiß ja jemand, wo man ansetzen kann, das währen bei uns die letzten Herausforderungen um den "privelegierten" Accounts ein wenig mehr Sicherheit zu geben
Gruß
@clSchak
wir testen gerade die Einführung der "Protected User" Gruppe, bzw. die Implementierung dieser und stoßen dabei auf ein paar Herausforderung die ich auch nicht über Google und "Try and Error" gelöst bekomme:
- RDP Anmeldung funktioniert anstandslos
- MFA / SmartCard funktioniert anstandslos
- Anmeldung allgemein auch
- diverse Tools musste von "normaler" AD Anmeldung auf Kerberos umgestellt werden, laufen dann auch
- Zugriff auf DFS Share die nicht als Domänenshare eingerichtet sind
- Zugriff auf reguläre Dateifreigaben
- Regelbetrieb an sich also "Ok"
- Kerberos verwendet nur AES Verschlüsselung (via GPO festgelegt)
- SMB Signing ist aktiv am DC
- Domänenfunktionsebene ist Server 2016, Server OS der DC 2019-2022
Was nicht funktioniert:
- Zugriff auf AD integrierte DFS Shares. Auf den dahinter liegenden Server die den Share bereitstellen, kann man ohne Probleme direkt zugreifen, tippe auf ein SPN Problem, aber ich wüsste jetzt nicht ich den für die gesamte Domäne korrekt setze
- MMC Zugriff funktioniert gar nicht, SPN des Quell- und Zielhost in Form von HOST/server.fqdn ist gesetzt, ich kann mich z.B. mit den AD MMC-Steuerungstools nicht an die Domäne anmelden, er findet die dann scheinbar nicht (evtl. DNS?), Zugriff auf SYSVOL ist möglich
Ich tippe, dass er irgendwo immer auf NTLM zurückfällt, weiß aber nicht genau so ich nachschauen soll.
Vielleicht weiß ja jemand, wo man ansetzen kann, das währen bei uns die letzten Herausforderungen um den "privelegierten" Accounts ein wenig mehr Sicherheit zu geben
Gruß
@clSchak
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4447485205
Url: https://administrator.de/contentid/4447485205
Ausgedruckt am: 25.11.2024 um 00:11 Uhr
11 Kommentare
Neuester Kommentar
Wenn RDP funktioniert, könntest du als workaround die Verwaltung per RDP machen oder die MMC gar als remoteapp vom DC starten.
so, sehr interessant, es funktioniert alles, aber frage mich nicht warum, vielleicht war ich auch nur zu ungeduldig . Gerade auch noch mal geprüft ob die Gruppen korrekt gezogen wurden.
Als nächstes mal ermitteln wo die ganzen "priveligierten" Accounts als Dienst oder Task laufen und dort vorab schon mal die Anmeldenamen auf <username>@fqdn umstellen, damit es da nicht direkt "knallt" wenn die in der Gruppe landen.
Aber die Idee mit RDP / RemoteApp hatte ich auch, aber am Ende verworfen weil der Benutzer die MMC auch nicht auf dem DC starten konnte
. Gerade auch noch mal geprüft ob die Gruppen korrekt gezogen wurden.- Kerberos Tickets sind bei 4h (also unterhalb der 240 Minuten Marke)
- Mimikatz sieht keine NTLM Hashes von Benutzer, habe additiv einen anderen Benutzer auf den Server angemeldet und dort sind dann die NTLM Hashes sicht- und verwertbar
Als nächstes mal ermitteln wo die ganzen "priveligierten" Accounts als Dienst oder Task laufen und dort vorab schon mal die Anmeldenamen auf <username>@fqdn umstellen, damit es da nicht direkt "knallt" wenn die in der Gruppe landen.
Aber die Idee mit RDP / RemoteApp hatte ich auch, aber am Ende verworfen weil der Benutzer die MMC auch nicht auf dem DC starten konnte
Setze keine Nutzer als Dient/Taskkonten ein. Ich nehme fast immer das Systemkonto.
Ich weiß ... sag das mal Herstellern von "Enterprise" Software jenseits der 200k€ Marke die einen bei der Implementierung verwirrt anschauen wenn man denen den SQL als AOG bereitstellt oder verlangt, dass die kein NTLM nutzen. Du willst gar nicht wissen, wie viele SPN Einträge alleine für die ERP gesetzt sind :x
So Tools wie "Purple Knight" usw. melden einen so etwas immer gerne und geben einen da ein paar gute Anhaltspunkte, ebenso eine Lösung für Schwachstellenmanagement.
So Tools wie "Purple Knight" usw. melden einen so etwas immer gerne und geben einen da ein paar gute Anhaltspunkte, ebenso eine Lösung für Schwachstellenmanagement.
Ich kenne auch so ERP Software die schon gut Geld kostet und einen angemeldeten User auf dem Server mit offener Console erfordert.
Wenn de dem Hersteller dann verklickern willst, dass sowas grober Mist ist können die da nicht mit um.
Wenn de dem Hersteller dann verklickern willst, dass sowas grober Mist ist können die da nicht mit um.
1
Nun ja wie wahr wie wahr.
Habe da im Enterprise Segnet bezüglich Software schon einiges mitgemacht.
Wenn du ( also als Hersteller der Software ) der einzige bist der die passende Software bzw. Funktionen für Anwendungsfall X herstellst dann kannst du das bis zum gewissen Punkt auch so festlegen dass das ein oder andere so sein soll/muss und sagen das sind Unsere Anforderungen.
Hatte da auch schon lustige Erlebnisse mit Herstellern für SAP Plug Ins bzw. SAP Erweiterungen. Teilweise aber auch schon mit SAP die unbedingt einen normalen LDAP benötigen weil sie LDAPs nicht können oder wollen. Wenn aber nur LDAPs vorhanden ist weil umgestellt dann ist das z.B. ein Problem.
Liegt halt teilweise daran das der Code der hier als Unterbau verwendet wird bei der meisten Software schon älter ist und je nach aktuellem Stand der Technik angepasst werden muss. Teilweise muss dann u.U. je nach dem wie das ganze gestrickt ist die Komplette Software neu aufgebaut werden. Aber ja das Problem ist hier und da hausgemacht weil die Hersteller, wenn diese Rechtzeitig reagiert hätten, die Software hätten eben anpassen können
Aber zurück zum Thema.,
Zu den AD Integ. DFS Shares:
Du sagt das du auf den Server der den Share selbst bereitstellt zugrifen kannst aber auf den DFS Pfad an sich nicht ? Sprich \\FILEServer.Domain.TLD\Ordner geht aber \\DFSSHARE.Domain.tld\FILEServerShare\Ordner geht nicht ?
Wir setzten bereits seit langem Prot. Users ein ( Laaaaanger Test weil mein vorgesetzter dem "Mist", wie er sagt, nicht traut) und da hatten wir anfangs mal Probleme aber nur mit DFS.
Haben dann die SPN angepasst ( geändert oder erstellt weis ich nicht mehr genau ) und dann hat das Funktioniert. Berechtigungen wurden dabei auch angepasst.
Das mit dem FQDN hast du ja bereits geschrieben.
Wir hatten einige IT Kollegen die weiterhin versucht hatten den DFS über \\DFSShare\Ordner anzusprechen. Geht natürlich nicht mehr wenn Prot.User
Ich kann mich noch erinnern das im Eventlog ein Fehler aufgetaucht ist welcher mich bzw. meinem Kollegen direkt auf die Lösung brachten.
Was sagt denn eigentlich das Eventlog auf dem Server ( DFS Server ) und auf dem Client zu den Problem ?
Bei uns lief das eigentlich relaativ zügig durch
Habe da im Enterprise Segnet bezüglich Software schon einiges mitgemacht.
Wenn du ( also als Hersteller der Software ) der einzige bist der die passende Software bzw. Funktionen für Anwendungsfall X herstellst dann kannst du das bis zum gewissen Punkt auch so festlegen dass das ein oder andere so sein soll/muss und sagen das sind Unsere Anforderungen.
Hatte da auch schon lustige Erlebnisse mit Herstellern für SAP Plug Ins bzw. SAP Erweiterungen. Teilweise aber auch schon mit SAP die unbedingt einen normalen LDAP benötigen weil sie LDAPs nicht können oder wollen. Wenn aber nur LDAPs vorhanden ist weil umgestellt dann ist das z.B. ein Problem.
Liegt halt teilweise daran das der Code der hier als Unterbau verwendet wird bei der meisten Software schon älter ist und je nach aktuellem Stand der Technik angepasst werden muss. Teilweise muss dann u.U. je nach dem wie das ganze gestrickt ist die Komplette Software neu aufgebaut werden. Aber ja das Problem ist hier und da hausgemacht weil die Hersteller, wenn diese Rechtzeitig reagiert hätten, die Software hätten eben anpassen können
Aber zurück zum Thema.,
Zu den AD Integ. DFS Shares:
Du sagt das du auf den Server der den Share selbst bereitstellt zugrifen kannst aber auf den DFS Pfad an sich nicht ? Sprich \\FILEServer.Domain.TLD\Ordner geht aber \\DFSSHARE.Domain.tld\FILEServerShare\Ordner geht nicht ?
Wir setzten bereits seit langem Prot. Users ein ( Laaaaanger Test weil mein vorgesetzter dem "Mist", wie er sagt, nicht traut) und da hatten wir anfangs mal Probleme aber nur mit DFS.
Haben dann die SPN angepasst ( geändert oder erstellt weis ich nicht mehr genau ) und dann hat das Funktioniert. Berechtigungen wurden dabei auch angepasst.
Das mit dem FQDN hast du ja bereits geschrieben.
Wir hatten einige IT Kollegen die weiterhin versucht hatten den DFS über \\DFSShare\Ordner anzusprechen. Geht natürlich nicht mehr wenn Prot.User
Ich kann mich noch erinnern das im Eventlog ein Fehler aufgetaucht ist welcher mich bzw. meinem Kollegen direkt auf die Lösung brachten.
Was sagt denn eigentlich das Eventlog auf dem Server ( DFS Server ) und auf dem Client zu den Problem ?
Bei uns lief das eigentlich relaativ zügig durch
Zitat von @Mr-Gustav:
Nun ja wie wahr wie wahr.
Habe da im Enterprise Segnet bezüglich Software schon einiges mitgemacht.
Wenn du ( also als Hersteller der Software ) der einzige bist der die passende Software bzw. Funktionen für Anwendungsfall X herstellst dann kannst du das bis zum gewissen Punkt auch so festlegen dass das ein oder andere so sein soll/muss und sagen das sind Unsere Anforderungen.
Hatte da auch schon lustige Erlebnisse mit Herstellern für SAP Plug Ins bzw. SAP Erweiterungen. Teilweise aber auch schon mit SAP die unbedingt einen normalen LDAP benötigen weil sie LDAPs nicht können oder wollen. Wenn aber nur LDAPs vorhanden ist weil umgestellt dann ist das z.B. ein Problem.
Liegt halt teilweise daran das der Code der hier als Unterbau verwendet wird bei der meisten Software schon älter ist und je nach aktuellem Stand der Technik angepasst werden muss. Teilweise muss dann u.U. je nach dem wie das ganze gestrickt ist die Komplette Software neu aufgebaut werden. Aber ja das Problem ist hier und da hausgemacht weil die Hersteller, wenn diese Rechtzeitig reagiert hätten, die Software hätten eben anpassen können
Aber zurück zum Thema.,
Zu den AD Integ. DFS Shares:
Du sagt das du auf den Server der den Share selbst bereitstellt zugrifen kannst aber auf den DFS Pfad an sich nicht ? Sprich \\FILEServer.Domain.TLD\Ordner geht aber \\DFSSHARE.Domain.tld\FILEServerShare\Ordner geht nicht ?
Wir setzten bereits seit langem Prot. Users ein ( Laaaaanger Test weil mein vorgesetzter dem "Mist", wie er sagt, nicht traut) und da hatten wir anfangs mal Probleme aber nur mit DFS.
Haben dann die SPN angepasst ( geändert oder erstellt weis ich nicht mehr genau ) und dann hat das Funktioniert. Berechtigungen wurden dabei auch angepasst.
Das mit dem FQDN hast du ja bereits geschrieben.
Wir hatten einige IT Kollegen die weiterhin versucht hatten den DFS über \\DFSShare\Ordner anzusprechen. Geht natürlich nicht mehr wenn Prot.User
Ich kann mich noch erinnern das im Eventlog ein Fehler aufgetaucht ist welcher mich bzw. meinem Kollegen direkt auf die Lösung brachten.
Was sagt denn eigentlich das Eventlog auf dem Server ( DFS Server ) und auf dem Client zu den Problem ?
Bei uns lief das eigentlich relaativ zügig durch
Nun ja wie wahr wie wahr.
Habe da im Enterprise Segnet bezüglich Software schon einiges mitgemacht.
Wenn du ( also als Hersteller der Software ) der einzige bist der die passende Software bzw. Funktionen für Anwendungsfall X herstellst dann kannst du das bis zum gewissen Punkt auch so festlegen dass das ein oder andere so sein soll/muss und sagen das sind Unsere Anforderungen.
Hatte da auch schon lustige Erlebnisse mit Herstellern für SAP Plug Ins bzw. SAP Erweiterungen. Teilweise aber auch schon mit SAP die unbedingt einen normalen LDAP benötigen weil sie LDAPs nicht können oder wollen. Wenn aber nur LDAPs vorhanden ist weil umgestellt dann ist das z.B. ein Problem.
Liegt halt teilweise daran das der Code der hier als Unterbau verwendet wird bei der meisten Software schon älter ist und je nach aktuellem Stand der Technik angepasst werden muss. Teilweise muss dann u.U. je nach dem wie das ganze gestrickt ist die Komplette Software neu aufgebaut werden. Aber ja das Problem ist hier und da hausgemacht weil die Hersteller, wenn diese Rechtzeitig reagiert hätten, die Software hätten eben anpassen können
Aber zurück zum Thema.,
Zu den AD Integ. DFS Shares:
Du sagt das du auf den Server der den Share selbst bereitstellt zugrifen kannst aber auf den DFS Pfad an sich nicht ? Sprich \\FILEServer.Domain.TLD\Ordner geht aber \\DFSSHARE.Domain.tld\FILEServerShare\Ordner geht nicht ?
Wir setzten bereits seit langem Prot. Users ein ( Laaaaanger Test weil mein vorgesetzter dem "Mist", wie er sagt, nicht traut) und da hatten wir anfangs mal Probleme aber nur mit DFS.
Haben dann die SPN angepasst ( geändert oder erstellt weis ich nicht mehr genau ) und dann hat das Funktioniert. Berechtigungen wurden dabei auch angepasst.
Das mit dem FQDN hast du ja bereits geschrieben.
Wir hatten einige IT Kollegen die weiterhin versucht hatten den DFS über \\DFSShare\Ordner anzusprechen. Geht natürlich nicht mehr wenn Prot.User
Ich kann mich noch erinnern das im Eventlog ein Fehler aufgetaucht ist welcher mich bzw. meinem Kollegen direkt auf die Lösung brachten.
Was sagt denn eigentlich das Eventlog auf dem Server ( DFS Server ) und auf dem Client zu den Problem ?
Bei uns lief das eigentlich relaativ zügig durch
habe ja bereits geschrieben, dass ich zu ungeduldigt war
, läuft mittlerweile alles wie es soll. Aktuelle Herausforderungen sind da irgendwelche Java Anwendungen wo man den kac* KeyStore bearrbeiten muss, damit der das Zertifikat vom DC annimmt - was aber wiederrum nur durch den Hersteller geht weil wir das Passwort davon nicht haben und auch nicht bekommen.Das einzige was (noch) nicht korrekt funktioniert ist der Mailversand über SQL-Reportingtools, das will auf "Teufel komm raus" kein Kerberos für die Authentifizierung sprechen, aber wir sind dran.
Für's interesse:
Seit dem 2022-11er Patch funktionieren die Anmeldungen auf Server <2019 nicht mehr für die Benutzer in der Gruppe, selbst wenn wir per GPO am DC die Einstellungen "Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren" RC4 neben AES zulassen oder die Einstellung komplett deaktiveren, funktioniert es aktuell nicht. Mal schauen...
Seit dem 2022-11er Patch funktionieren die Anmeldungen auf Server <2019 nicht mehr für die Benutzer in der Gruppe, selbst wenn wir per GPO am DC die Einstellungen "Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren" RC4 neben AES zulassen oder die Einstellung komplett deaktiveren, funktioniert es aktuell nicht. Mal schauen...
Hi @clSchak
Doch, hier klappt das. Allerdings kann ich bestätigen, dass ich für Server 2016 die Verschlüsselungstypen AES128 und AES256 zulassen muss. Ließe ich hier nur AES256 zu, klappt kein RDP zu Server 2016 mehr!
PC nach jeder Änderung neu starten!
Doch, hier klappt das. Allerdings kann ich bestätigen, dass ich für Server 2016 die Verschlüsselungstypen AES128 und AES256 zulassen muss. Ließe ich hier nur AES256 zu, klappt kein RDP zu Server 2016 mehr!
PC nach jeder Änderung neu starten!
es ist bei uns ja aktuell nur auf den DC's aktiv, die Regelung betrifft keine Memberserver. Trotzdem schlägt die Authentifizierung fehl bzw. kommt der Hinweis, wenn man sich per RDP anmelden möchte:
Server 2019 läuft ohne Probleme durch, aber ich teste es mal, wenn ich dem Server die Einstellung via gpedit.msc mitgebe, dass der nur AES verwenden soll.
Server 2019 läuft ohne Probleme durch, aber ich teste es mal, wenn ich dem Server die Einstellung via gpedit.msc mitgebe, dass der nur AES verwenden soll.
hmm, wenn ich das auf einem Server 2012R2 einstelle, stellt der den Netzwerkadapter auf "Public Network" um und es greifen dann auch die entsprechende Firewallregeln .
Und zurückstellen geht auch nicht, bzw. half nichts, der Netzwerkadapter wollte unter gar keinen Umständen zurück auf "Domänennetzwerk", interessanter Fehler, DNS usw. lief problemlos. Habe die VM nun wiederhergestellt, werde heute abend mal ausgiebiger testen :> ... und vielleicht nicht am "offenen Herzen" :x
.Und zurückstellen geht auch nicht, bzw. half nichts, der Netzwerkadapter wollte unter gar keinen Umständen zurück auf "Domänennetzwerk", interessanter Fehler, DNS usw. lief problemlos. Habe die VM nun wiederhergestellt, werde heute abend mal ausgiebiger testen :> ... und vielleicht nicht am "offenen Herzen" :x
