Пользователь в группе администраторов домена не может получить доступ к каталогу, к которому у группы есть права доступа

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

В файловом сервере 2008 R2 есть каталог, который используется для перенаправления папок для всех пользователей в подразделении «Персонал». В каталоге установлены следующие разрешения:

FILESERVER \ Administrators: разрешить полный контроль над каталогом, подкаталогами и файлами
ДОМЕН \ Администраторы домена: полный доступ к каталогу, подкаталогам и файлам
Прошедшие проверку пользователи: позволяют создавать файлы, создавать папки, записывать атрибуты и записывать расширенные атрибуты только в верхний каталог

Кроме того, каталог также является сетевым ресурсом с «Разрешить полный контроль» для группы «Прошедшие проверку».

Когда пользователь john.doe, член группы администраторов домена, пытается получить доступ к каталогу с файлового сервера, он получает сообщение об ошибке «У вас нет прав доступа к этой папке». Попытка получить доступ к сетевому ресурсу с того же сервера также приводит к ошибке отказа в доступе (хотя пользователь все еще может получить доступ к своему собственному каталогу в общем ресурсе).

Доступ к общему ресурсу с другого компьютера, вошедшего в систему под тем же пользователем, разрешает доступ в соответствии с настройками.

Единственный способ получить доступ к файлам в каталоге при входе в систему на файловом сервере - открыть командную строку с повышенными привилегиями. Контроль учетных записей отключен для всех компьютеров в домене с помощью групповой политики (запуск всех администраторов в режиме одобрения администратором включен, а поведение по умолчанию установлено на повышение без запроса).

Все дороги указывают на то, что пользователю разрешен доступ, но ему все еще отказано. Есть идеи?

windows active-directory permissions

— EnglishInfix
источник

Есть ли какие-либо запреты ACE в ACL?

— Шейн Мэдден

В списке управления доступом нет никаких запрещающих разрешений для каталога для какой-либо группы или пользователя.

— EnglishInfix

Ответы:

Это по замыслу. UAC удаляет учетные данные администратора из любого необновленного процесса. Если вы пытаетесь использовать процесс без повышенных прав для доступа к удаленному общему ресурсу, используя только учетные данные администратора, UAC удалит учетные данные администратора из маркера безопасности процесса, и процесс получит ошибку «Отказано в доступе».

Чтобы исправить это, вы можете:

Не используйте учетные данные администратора для защиты папки (создайте общую группу только для этой цели), или
Отключите UAC на файловом сервере (не рекомендуется) или
Включите следующий раздел реестра на файловом сервере, чтобы отключить только эту часть UAC.

Подробнее: Описание контроля учетных записей и удаленных ограничений в Windows Vista

— Джон Гомер
источник

Так что я только что заметил, что это с мая прошлого года. Не уверен, почему это появилось в моей ленте RSS этим утром ...

— Джон Гомер

Джон, я рад изменить свой ответ и отозвать тебя, но я хотел быть уверен. В статье базы знаний в Domain user accountsразделе читается «странно», как будто это не имеет никакого отношения. ОП заявил, что он находится на файловом сервере, который получает доступ к локальным дискам и UNC-пути прямо с сервера. У меня нет быстрого способа (но может ли при необходимости) протестировать regkey, но я просто спрашиваю, уверены ли вы, что это действительно решит проблему именно так, как описано в OP, а не только для удаленного доступа к пути UNC?

— TheCleaner

Я сталкивался с этой проблемой много раз. Доступ к общему ресурсу локально - это тот же процесс, что и для удаленного ресурса. Он по-прежнему использует перенаправитель UNC для доступа к папке и будет подвергаться такому же поведению. Я предполагаю, что удаленная машина была более старой (не UAC) версией Windows. К сожалению, ОП не предоставил эту информацию. Просто на основе информации, которую он предоставил (особенно необходимость повысить его для правильной работы), я могу поверить, что это проблема.

— Джон Гомер

Да, понял, но он заявил, что сначала попробовал локальный диск (без общего ресурса), а затем общий ресурс UNC. Но я отвлекся ... Я изменю свой пост и добавлю ваш голос ... У меня нет причин не доверять вашему ответу.

— TheCleaner

Ключ реестра НЕ работал у меня даже после перезагрузки. Выключение UAC тоже не сработало. У меня работала только общая группа.

— skinneejoe

UAC удаляет учетные данные администратора домена на самом сервере, это часть работы UAC (тупо IMO). Один из вариантов - полностью отключить UAC на сервере, чтобы не получать приглашение «У вас нет прав доступа к этой папке».

РЕДАКТИРОВАТЬ: вот пример потока: http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/9061bc1c-42ea-47ed-8c7d-56b07139fb86/

РЕДАКТИРОВАТЬ 2: Ответ Джона ниже может быть именно то, что вы ищете, хотя. Попробуйте и сообщите, если сможете.

— Очиститель
источник

Другой вариант - добавить ACL в папку для другой группы, членом которой является пользователь, с соответствующими разрешениями.

— Грег Аскью

Извините TheCleaner, но вы не правы. Вам не нужно отключать UAC, чтобы это работало. Существует раздел реестра (LocalAccountTokenFilterPolicy), который отключает только эту часть UAC. Более подробная информация здесь: support.microsoft.com/kb/951016

— Джон Гомер

@JohnHomer - см. Мой комментарий в вашем ответе. Я изменю свой ответ как возможный, но также укажу и оставлю отзыв, если вы уверены, что статья КБ относится и к проблемам с диском локального сервера, как описано в ОП.

— TheCleaner

-1

Лучший способ - изменить ключ реестра в

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

Убедитесь, что установлено значение 0 для отключения
Вам нужно перезагрузить компьютер, чтобы он вступил в силу.
Интерфейс может отображать его как отключенный при включенном реестре

— Бен
источник

Ключи политики не должны устанавливаться вручную. Они используются управлением групповой политикой для хранения настроек. Дополнительная информация: technet.microsoft.com/en-us/library/cc962657.aspx

— Джон Гомер