Назад | Перейти на главную страницу

Почему удаление группы ВСЕ не позволяет администраторам домена получить доступ к диску?

Это связано с этим вопросом:

Группе администраторов домена отказано в доступе к диску d:

У меня есть рядовой сервер в совершенно новой лабораторной среде AD.


    Everyone - Special Permissions - This folder only
      Traverse folder / execute file
      List folder / read data
      Read attributes
      Read extended attributes

    CREATOR OWNER - Special Permissions - Subfolders and files only
      Full Control

    SYSTEM - This folder, subfolders and files
      Full Control

    Administrators - This folder, subfolders and files
      Full Control

В приведенном выше ACL пользователь домена ADMIN01 может войти в систему и получить доступ к D: диск, создавать папки и файлы и все хорошо.

Если я удалю Everyone разрешение от корня этого диска, а затем не встроенные пользователи, которые являются членами Domain Admins (например. ADMIN01) группа больше не может получить доступ к диску. Домен Administrator аккаунт в порядке.

Локальная машина Administrator и Domain Admin У учетной записи «Администратор» по-прежнему есть полный доступ к диску, но любой «обычный» пользователь, добавленный в Domain Admins отказано в доступе.

Это происходит независимо от того, создал ли я том и удалил ли Everyone разрешение, зарегистрированное как локальный компьютер Administrator или выполняю ли я это в системе как Domain Admin Учетная запись «Администратор».

Как упоминалось в моем предыдущем вопросе, обходной путь заключается в отключении «Контроль учетных записей пользователей: запускать всех администраторов в режиме утверждения администратором» политика либо локально на рядовом сервере, либо через объект групповой политики домена.

Почему удаление Everyone счет от D:ACL вызывает эту проблему для не встроенных пользователей, которым предоставлено членство в Domain Admins?

Также почему эти типы не встроенных Domain Admin пользователям было предложено повысить свои разрешения, а не просто запретить доступ к диску?

Я сам это заметил. Что происходит, так это то, что UAC срабатывает, потому что вы используете членство «локальных администраторов» для получения доступа к диску, и это именно то, что отслеживает UAC.

Для файловых серверов я лично рекомендую никогда не использовать группу «Администраторы» для предоставления разрешений пользователям.

Попробуйте следующее: создайте группу AD под названием «FileServerAdmins» или что-то еще, добавьте в нее своего пользователя (или группу администраторов домена). Предоставьте этой группе доступ к диску D с теми же разрешениями, что и существующей группе администраторов.

Вы должны заметить, что даже после удаления разрешения «Все» любые члены группы «FileServerAdmins» по-прежнему должны иметь доступ к диску, не получая приглашения UAC.

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

Похоже, я не одинок с этой проблемой. Проблема, похоже, заключается в том, что не встроенные пользователи, которые Domain Admins не совсем полный шиллинг, когда дело доходит до UAC, и, похоже, к ним относятся «специально»:

Windows Server 2008 R2 и UAC

Проблема с разрешениями UAC и администраторов домена в Windows 2008 - Часть 1

Проблема с разрешениями UAC и администраторов домена или карман, полный криптонита - Часть 2

Ключевой абзац последней ссылки объясняет:

В принципе, [не встроенные пользователи, которые - (добавлены мной)] Администраторы домена, в отличие от ВСЕХ ДРУГИХ ПОЛЬЗОВАТЕЛЕЙ, получают два токена. У них есть токен полного доступа (как и у всех) и второй токен доступа, называемый отфильтрованным токеном доступа. У этого отфильтрованного токена доступа удалены административные полномочия. Explorer.exe (то есть корень всего) запускается с отфильтрованным токеном доступа, и, таким образом, все запускается с ним.

Думайте об этом как о RUNAS наоборот. Вместо того, чтобы быть администратором домена, вы получаете статус пиона. По сути, это криптонит.