Server 2016: ntfs-Rechte nur remote / Server 2008 normal

[griscia 0]

Ich habe einen Server A mit Server 2008 und einen Server B mit Server 2016

 

Auf beiden Servern erstelle ich einen "Testordner" mit folgenden Rechten (Vererbung unterbrochen):

System: Vollzugriff + lokale (!) Administratoren: Vollzugriff

Benutzer "testroot" ist Mitglied der lokalen Administratoren

 

Auf beiden Servern erstelle ich eine Freigabe mit "Vollzugriff - Jeder".

 

Server 2008:

 

Alles funktioniert lehrbuchmäßig, "testroot" hat Vollzugriff auf den Testordner, sowohl per Freigabe als auch lokal (per RDP)

 

Server 2016: 

 

Bei Zugriff über Freigabe ist alles wie es sein soll.

 

Bei lokalem Zugriff (via RDP) wird dem Nutzer "testroot" der Zugriff verweigert ("Sie verfügen momentan nicht über die Berechtigung...") - allerdings kann er sich den Zugriff verschaffen.

 

Bin ziemlich ratlos...

[zahni 558]

Das wird  an UAC liegen. Füge den User  mal direkt hinzu oder über eine andere Gruppe.

Die Gruppe "Administratoren" wird durch UAC  speziell behandelt.

[griscia 0]

UAC ist komplett deaktiviert...

 

und ja: Füge ich ihn direkt hinzu, hat er die erwarteten Rechte.

 

Es liegt also definitiv an der Rechtezuweisung via "lokale Administratoren" - aber genau das erwartet Microsoft:

 

lokale Ressourcen mit lokalen Gruppen verwalten.

Benutzer in Gruppen aufnehmen und die Gruppen dann in die lokalen Gruppen aufnehmen.

 

Und zumindest bis Server 2008 ging das auch problemlos...

bearbeitet 14. Dezember 2017 von griscia

[zahni 558]

UAC lässt sich ab  2012R2 nicht  mehr Registry-Eingriff komplett deaktivieren. Daher liegt es doch an UAC.

[griscia 0]

ich habe gerade eine neue lokale Gruppe erstellt.

Dieser Gruppe Vollzugriff gegeben.

den Testnutzer dort aufgenommen:

 

Immer noch kein Zugriff erlaubt.

 

D.h. jede Rechtezuweisung via lokale Gruppe funktioniert nicht (mehr)

[zahni 558]

Hat Du ihn aus der Gruppe "Administratoren" entfernt bzw. diese Gruppe  aus  der ACL des  Verzeichnisses?

Sorry, ich habe keine zeit  das im Detail zu testen...

[griscia 0]

Entfernen aus allen anderen Gruppen bringt auch nichts.

[NilsK 2.968]

Moin,

 

hast du dich mit dem Account neu angemeldet, nachdem du ihn der neuen Gruppe hinzugefügt bzw. ihn aus anderen entfernt hast? Nur dann werden die Gruppenmitgliedschaften wirksam.

Ich tippe auch auf UAC.

 

Gruß, Nils

[griscia 0]

wenn Ihr auf UAC tippt, man dies aber nicht deaktivieren kann, was ist dann die Schlussfolgerung?

 

Ich habe nochmal weiter getestet (diesmal zur Sicherheit immer dazwischen abgemeldet - mal hat dies Auswirkungen, mal nicht):

 

Gebe ich den lokalen Administratoren Vollzugriff (und mein Testaccount ist Mitglied der Administratoren, funktioniert es nicht.

 

Gebe ich einer anderen Gruppe Vollzugriff (und mein Testaccount ist Mitglied davon), funktioniert es.

 

Das heißt: das Problematische (oder der Ausreißer) ist die lokale Administratorengruppe.

 

Hat hier Microsoft etwas geändert?

 

Danke schon jetzt für Eure Mühe!

bearbeitet 14. Dezember 2017 von griscia

[AlbertMinrich 12]

Um die UAC wirklich komplett zu deaktivieren, mach ich immer folgendes:

 

1. Systemsteuerung > Benutzenkontensteuerung > Schieberegler ganz nach unten

2. gpedit.msc > Computer Konfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen

Und hier alphabetisch sortieren und die obersten beiden Punkte:

- "Benutzerkontensteuerung: Administratorbestätigungsmodus für das integrierte Administratorkonto"

- "Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen"

deaktivieren

3. Reboot

 

Um zu prüfen, ob die UAC wirklich deaktiviert ist:

Taste [Windows] + [R] > cmd

"whoami /groups"

 

Wenn hier in der letzten Zeile in der Spalte SID die SID mit 12288 endet, ist UAC deaktiviert.

Endet sie mit einer vierstelligen Zahl, beginnend mit 8 (den Rest weiß ich jetzt Grad nicht), ist UAC aktiv.

 

Gruß

Martin

bearbeitet 14. Dezember 2017 von AlbertMinrich

[NilsK 2.968]

Moin,

 

Microsoft hat nichts geändert, das ist normales UAC-Verhalten. Statt die UAC abzuschalten, sollte man lieber richtig damit umgehen. Genau wie man eine Firewall auch nicht abschaltet, sondern konfiguriert.

 

[Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net]
https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/

 

[benutzerkontensteuerung (UAC) richtig einsetzen | faq-o-matic.net]
https://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/

 

Gruß, Nils

[griscia 0]

wenn ich aber bei absolut identischen Einstellungen bei Server 2008 ein anderes Ergebnis bekomme als bei Server 2016, liegt zumindest die Vermutung nahe, dass sich etwas geändert hat, oder?

[Doso 77]

Ja, es sind 2 Generationen Betriebssysteme dazwischen. Windows Server 2008 teilt sich den Kern mit Windows Vista, Windows Server 2016 mit Windows 10.

 

UAC abschalten ist nicht mehr. Gewöhn dich lieber daran.

[NilsK 2.968]

Moin,

 

an Logik und Verhalten der UAC hat sich nichts geändert. Nur an der Abschaltbarkeit.

 

<erhobener Zeigefinger>

Und damit haben wir wieder den klassischen Fall: Wer UAC bislang routinemäßig abgeschaltet hat, kommt damit nicht klar. Wer stattdessen damit umgegangen ist, sieht kein Problem. Genauso wie wir es von Betriebssystem-Firewalls kennen: Die stellen auch nur dann ein Problem dar, wenn man sie abschaltet.

</erhobener Zeigefinger>

 

Gruß, Nils

[griscia 0]

Vielen Dank an alle, die sich um die Lösung bemüht haben.

 

<zerknirscht> Leider hab ich genau das gemacht: die nervige UAC abgeschaltet</zerknirscht aus>

 

Finde ich auch bei Linux besser gelöst.

 

Admin-Passwort erfragen - korrekte Rechte einräumen.

 

Aber egal. Die 2 Links waren goldrichtig und ich werde genau das nun machen: Eine eigene Gruppe einrichten.

 

Ist nur umständlich: Bei der Aufnahme in die Domäne wird man ja gefragt, ob man die Domänen-Admins in die lokalen Administratoren aufnehmen will - und denkt, bei "Ja" hätte man alles Nötige gemacht... Und dann kann ich als solcher Domänenadmin nicht einmal einen Ordner anschauen :-(

 

Unklar bleibt weiterhin, wieso es dann remote wie gedacht funktioniert (alle haben Vollzugriff, das Nähere regeln - diesmal korrekt - die ntfs-Rechte...)

 

Und etwas Weiteres ist nicht durchdacht: Für einen normalen PC ist dies Konzept sehr sinnvoll (niemand arbeitet bei uns normalerweise als Administrator bzw. mit dessen Rechten).

 

An einem Server jedoch hat niemand etwas auf der Oberfläche (egal ob lokal oder per RDP angemeldet) zu suchen. Und wer sich dort interaktiv anmeldet, hat ausschließlich administrative Aufgaben zu erledigen, die tatsächliche Administratorrechte erfordern. Insofern ist UAC auf einem Server kontraproduktiv...

bearbeitet 9. Januar 2018 von griscia