Użytkownik w grupie administracyjnej domeny nie może uzyskać dostępu do katalogu, do którego grupa ma uprawnienia dostępu

Napotkałem dość interesujący problem podczas grania w jednym z moich laboratoriów domenowych.

Na serwerze plików 2008 R2 znajduje się katalog służący do przekierowywania folderów dla wszystkich użytkowników w jednostce organizacyjnej „Personel”. Katalog ma ustawione następujące uprawnienia:

FILESERVER \ Administrators: Zezwól na pełną kontrolę nad katalogiem, podkatalogami i plikami
DOMENA \ Administratorzy domeny: Zezwalaj na pełną kontrolę nad katalogiem, podkatalogami i plikami
Użytkownicy uwierzytelnieni: zezwalaj na tworzenie plików, tworzenie folderów, zapisywanie atrybutów i zapisywanie rozszerzonych atrybutów tylko w głównym katalogu

Ponadto katalog jest także udziałem sieciowym z „Zezwalaj na pełną kontrolę” grupie uwierzytelnionych użytkowników.

Gdy użytkownik john.doe, członek grupy administratorów domeny, próbuje uzyskać dostęp do katalogu z serwera plików, pojawia się błąd „Obecnie nie masz uprawnień dostępu do tego folderu”. Próba uzyskania dostępu do udziału sieciowego z tego samego serwera powoduje również błąd odmowy uprawnień (chociaż użytkownik nadal może uzyskać dostęp do własnego katalogu w tym udziale).

Dostęp do udziału z innego komputera zalogowanego jako ten sam użytkownik zezwala na dostęp zgodnie z konfiguracją.

Jedynym sposobem uzyskania dostępu do plików w katalogu podczas logowania do serwera plików jest otwarcie wiersza polecenia z podwyższonym poziomem uprawnień. Kontrola konta użytkownika jest wyłączona dla wszystkich komputerów w domenie za pomocą Zasad grupy (Uruchom wszystkich administratorów w trybie zatwierdzenia administratora, a domyślne zachowanie ustawione na podniesienie poziomu bez monitowania).

Wszystkie drogi wskazują, że użytkownik ma dostęp, ale wciąż odmawia się dostępu. Jakieś pomysły?

windows active-directory permissions

— EnglishInfix
źródło

Czy w ACL są jakieś odmowy ACE?

— Shane Madden

W ACL nie ma ustawionych uprawnień odmowy dla katalogu dla dowolnej grupy lub użytkownika.

— EnglishInfix

Odpowiedzi:

To jest z założenia. Kontrola konta użytkownika usuwa dane administratora z dowolnego procesu bez podwyższonego poziomu uprawnień. Jeśli próbujesz użyć procesu bez podwyższonego poziomu uprawnień, aby uzyskać dostęp do udziału zdalnego przy użyciu tylko poświadczeń administratora, UAC usunie poświadczenia administracyjne z tokena zabezpieczającego proces, a proces otrzyma błąd „odmowa dostępu”.

Aby temu zaradzić, możesz:

Nie używaj poświadczeń administratora, aby zabezpieczyć folder (utwórz w tym celu grupę ogólną) lub
Wyłącz kontrolę konta użytkownika na serwerze plików (niezalecane) lub
Włącz następujący klucz rejestru na serwerze plików, aby wyłączyć tylko tę część UAC.

Więcej informacji: Opis Kontroli konta użytkownika i ograniczeń zdalnych w systemie Windows Vista

— John Homer
źródło

Właśnie zauważyłem, że to jest z zeszłego maja. Nie jestem pewien, dlaczego pojawił się w moim kanale RSS dziś rano ...

— John Homer

John, cieszę się, że mogę zmienić odpowiedź i głosować, ale chciałem być pewien. Artykuł KB brzmi „dziwnie” pod Domain user accountssekcją, jakby nie miał żadnego znaczenia. OP stwierdził, że był na serwerze plików uzyskującym dostęp do lokalnych dysków i ścieżki UNC prosto z serwera. Nie mam szybkiego sposobu (ale mógłbym w razie potrzeby) przetestować regkey, ale tylko pytam, czy jesteś pewien, że to naprawi problem dokładnie tak, jak opisano OP, a nie tylko dla zdalnego dostępu do ścieżki UNC?

— TheCleaner

Wiele razy natknąłem się na ten problem. Lokalny dostęp do udziału jest tym samym procesem, co udział zdalny. Nadal korzysta z readresatora UNC, aby uzyskać dostęp do folderu i będzie podlegał temu samemu zachowaniu. Domyślam się, że maszyna zdalna była starszą wersją systemu Windows (inną niż UAC). Niestety OP nie podał tych informacji. Na podstawie informacji, które podał (szczególnie potrzeby podniesienia, aby działał poprawnie), sądzę, że to jest problem.

— John Homer

Tak, zrozumiałe, ale stwierdził, że najpierw spróbował napędu lokalnego (brak udziału), a następnie udziału UNC. Ale dygresję ... Zmienię mój wpis i głosuję na twoim ... Nie mam powodu, by nie ufać twojej odpowiedzi.

— TheCleaner

Klucz rejestru NIE działał dla mnie, nawet po ponownym uruchomieniu. Wyłączenie UAC również nie działało. Pracowała tylko dla mnie grupa ogólna.

— skinneejoe

UAC zdejmuje poświadczenia administratora domeny na samym serwerze, to część tego, jak działa UAC (głupio IMO). Jedną z opcji jest całkowite wyłączenie UAC na serwerze, aby nie otrzymywać monitu „Obecnie nie masz uprawnień dostępu do tego folderu”.

EDYCJA: oto przykładowy wątek btw: http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/9061bc1c-42ea-47ed-8c7d-56b07139fb86/

EDYCJA 2: Odpowiedź Johna poniżej może być dokładnie tym, czego szukasz. Wypróbuj i zgłoś się, jeśli możesz.

— TheCleaner
źródło

Inną opcją byłoby dodanie listy ACL do folderu dla innej grupy, której członkiem jest użytkownik, z odpowiednimi uprawnieniami.

— Greg Askew

Przepraszam TheCleaner, ale się mylisz. Aby to działało, nie musisz wyłączać UAC. Istnieje klucz rejestru (LocalAccountTokenFilterPolicy), który wyłącza tylko tę część UAC. Więcej informacji tutaj: support.microsoft.com/kb/951016

— John Homer

@JohnHomer - zobacz mój komentarz w swojej odpowiedzi. Zmienię moją odpowiedź jako możliwą, ale wskazuję i głosuję również na twoją, jeśli jesteś pewien, że artykuł KB dotyczy problemów z dyskiem lokalnym, a także opisanego PO.

— TheCleaner

-1

Najlepszym sposobem jest zmiana klucza rejestru na

registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies\system; key = EnableLUA

Upewnij się, że jest ustawiony na wartość 0, aby wyłączyć
Musisz ponownie uruchomić komputer, aby zadziałał.
Interfejs może pokazywać go jako wyłączony, gdy rejestr jest włączony

— Ben
źródło

Klucze zasad nie powinny być ustawiane ręcznie. Są one używane przez zarządzanie zasadami grupy do przechowywania ustawień. Więcej informacji: technet.microsoft.com/en-us/library/cc962657.aspx

— John Homer