Jump to content

Relaunch 2018: Willkommen im neuen Forum - Das MCSEboard.de wurde runderneuert. Wir wünschen Euch viel Spaß an Board.

griscia

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

Empfohlene Beiträge

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...

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von griscia

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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...

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von griscia

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von AlbertMinrich

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von griscia

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

×