Користувач у групі адміністратора домену не може отримати доступ до каталогу, група має дозвіл на доступ


15

Я зіткнувся з досить цікавою проблемою, граючи з одним із моїх лабораторій домену.

На файловому сервері R2 2008 року є каталог, який використовується для перенаправлення папок для всіх користувачів в ОУ «Персонал». У каталозі встановлено такі дозволи:

  • FILESERVER \ Administrators: Дозволити повний контроль над каталогом, підкаталогами та файлами
  • DOMAIN \ Адміністратори домену: дозволити повний контроль над каталогом, підкаталогами та файлами
  • Автентифіковані користувачі: дозволяють створювати файли, створювати папки, писати атрибути та записувати розширені атрибути лише у верхній каталог

Окрім цього, каталог також є мережевою часткою із "Дозволити повний контроль" групі "Автентифіковані користувачі".

Коли користувач john.doe, член групи адміністраторів домену, намагається отримати доступ до каталогу через сервер файлів, він отримує помилку "Ви не маєте дозволу на доступ до цієї папки". Спроба отримати доступ до мережевої спільної доступу з одного сервера також призводить до помилки, у якій відмовлено у дозволі (хоча користувач все ще може отримати доступ до власного каталогу в межах спільної доступу).

Доступ до спільного доступу з іншого комп’ютера, на якому ввійшов той самий користувач, дозволяє отримати доступ до конфігурації.

Єдиний спосіб отримати доступ до файлів у каталозі під час входу на файловий сервер - це відкрити підвищений командний рядок. UAC вимкнено для всіх комп’ютерів у домені за допомогою групової політики (запустити всіх адміністраторів у режимі затвердження адміністратора, а поведінку за замовчуванням встановити для підвищення без підказки).

Усі дороги вказують на те, що користувачеві заборонено доступ, але йому все одно заборонено. Будь-які ідеї?


Чи є в ACL заборонені ІПСШ?
Шейн Медден

У доступі ACL для каталогу будь-якої групи або користувача не встановлено дозволів заборонити.
EnglishInfix

Відповіді:


13

Це за дизайном. UAC позбавляє облікових даних адміністратора від будь-якого непідвищеного процесу. Якщо ви намагаєтеся використовувати непідвищений процес для доступу до віддаленої спільної доступу, використовуючи лише облікові дані адміністратора, UAC позбавить облікових даних адміністратора з маркера безпеки процесу, і процес отримає помилку "в доступі заборонено".

Виправити це можна:

  1. Не використовуйте облікові дані адміністратора для захисту папки (створіть загальну групу саме для цієї мети), або

  2. Вимкнути UAC на файловому сервері (не рекомендується), або

  3. Увімкніть наступний ключ реєстру на сервері файлів, щоб вимкнути саме цю частину UAC.

Додаткова інформація: Опис контролю облікових записів користувачів та віддалених обмежень у Windows Vista


Тож я щойно помітив це з минулого травня. Не впевнений, чому він з’явився у моєму RSS-каналі сьогодні вранці ...
Джон Гомер

Джон, я радий змінити свою відповідь і підтримати тебе, але я хотів бути впевненим. У статті КБ під Domain user accountsрозділом написано "дивно", як ніби воно взагалі не має жодного стосунку. ОП заявило, що він перебуває на файловому сервері, що отримує доступ до локальних дисків та шляху UNC прямо з сервера. У мене немає швидкого способу (але, якщо це необхідно), протестувати реґі, але просто запитую, чи впевнені ви, що це дійсно виправить проблему саме так, як описано в ОП, а не лише для віддаленого доступу до UNC-шляху?
TheCleaner

Я не раз стикався з цим питанням. Локальний доступ до папки - це той самий процес, що і віддалений. Він все ще використовує переспрямовувач UNC для доступу до папки, і він буде піддаватися тій же поведінці. Я здогадуюсь, що віддалений апарат був старішою (не UAC) версією Windows. На жаль, ОП не надало цієї інформації. Саме на основі інформації, яку він надав (особливо необхідності підвищити її для правильної роботи), змушує мене вважати, що це проблема.
Джон Гомер

Так, зрозумів, але він заявив, що спочатку спробував місцевий драйв (без акцій), а потім частку UNC. Але я відволікаюсь… Я перероблю свою посаду і відкликаю вашу… Я не маю причин не довіряти вашій відповіді.
TheCleaner

Ключ реєстру для мене НЕ працював, навіть після перезавантаження. Відключення UAC також не вийшло. На мене працювала лише родова група.
skinneejoe

10

UAC знімає дані адміністратора домену на самому сервері, це частина того, як працює UAC (тупо IMO). Один із варіантів - повністю відключити UAC на сервері, щоб не отримувати підказку "Ви зараз не маєте дозволу на доступ до цієї папки".

EDIT: ось приклад теми btw: http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/9061bc1c-42ea-47ed-8c7d-56b07139fb86/

EDIT2: Відповідь Джона нижче може бути саме тим, що ви шукаєте. Спробуйте це і повідомте, якщо зможете.


5
Іншим варіантом було б додати ACL до папки для іншої групи, членом якої є користувач, з відповідними дозволами.
Грег Аскеу

Вибачте TheCleaner, але ви неправі. Вам не потрібно відключати UAC, щоб зробити цю роботу. Існує ключ реєстру (LocalAccountTokenFilterPolicy), який вимикає лише цю частину UAC. Більше інформації тут: support.microsoft.com/kb/951016
Джон Гомер

@JohnHomer - дивіться мій коментар у вашій відповіді. Я буду змінювати свою відповідь як можливість, але також зазначу та підтверджую вашу, якщо ви впевнені, що стаття KB стосується питань локального сервера, а також описаних в ОП.
TheCleaner

-1

Найкращий спосіб - змінити ключ реєстру на

registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies\system; key = EnableLUA
  • Переконайтеся, що встановлено значення 0 для відключення
  • Вам потрібно перезавантажити, щоб це набуло чинності.
  • Під час увімкнення реєстру інтерфейс може відображати його як відключений

3
Ключі політики не слід встановлювати вручну. Вони використовуються в управлінні груповою політикою для зберігання налаштувань. Більше інформації: technet.microsoft.com/en-us/library/cc962657.aspx
Джон Гомер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.