У меня есть Windows Server 2003, работающий как файловый сервер. Он содержит множество общих папок с различными разрешениями. Поле 2003 не является хостом контроллера домена / Active Directory; Active Directory работает на сервере вне нашего контроля, но мы считаем, что это Server 2008 R2.
Я обнаружил, что сохранение входа в систему Windows Server 2003 через протокол удаленного рабочего стола (RDP) приводит к тому, что разрешения безопасности в проводнике Windows устаревают, как будто сервер кэширует разрешения, которые были там ранее.
Действия по воспроизведению:
Перейдите на диск с общими дисками в проводнике Windows, например Z:
Выберите общую папку, щелкните правой кнопкой мыши и выберите «Свойства», затем щелкните вкладку «Безопасность».
Обратите внимание на имеющиеся разрешения.
Выйдите из сеанса RDP и подключитесь снова.
Повторите шаги 2 - 3.
Обратите внимание, что разрешения не совпадают.
Я на 100% уверен, что никакие другие пользователи или администраторы не изменяют разрешения. Разрешения для общих папок изменяются ТОЛЬКО одним администратором, вошедшим в это поле. Нажатие «F5» («Обновить») в проводнике Windows не обновляет разрешения. Это заставляет администратора полагать, что существуют другие разрешения для папок, чем фактические, действующие разрешения, которые видят клиенты.
Самым сложным является то, что клиенты (конечные пользователи), подключающиеся к общим папкам, могут видеть фактические разрешения. Например, если пользователю фактически отказано в доступе к папке, кэшированное разрешение, предоставляющее ему доступ, может отображаться на сервере, но клиент не сможет получить доступ к папке. Однако изменение разрешений не будет отображаться на сервере, пока администратор не выйдет из системы, а затем снова не войдет в систему.
Есть ли способ заставить систему автоматически обновлять разрешения вместо их кеширования или сделать это вручную? Это ошибка, устраняемая с помощью пакета обновления, или это особенность проекта?
В случае, если пользователь «кэширован» и кажется добавленным в список настраиваемых разрешений для папки, поведение является наиболее странным: вы можете изменить разрешения для пользователя, например от полного доступа до отказа во всех разрешениях и обратно, при этом операционная система не сообщает об ошибках. Но внесение этих изменений и нажатие кнопки Применить приведет к нет видимого эффекта клиенту, и когда вы снова войдете на сервер после выхода из системы, пользователь вообще не появится в списке пользователей с настраиваемыми разрешениями!
Мммм. Предполагая, как Zoredache указывает, что вы говорите о списках DAC файловой системы NTFS, тогда проблема почти наверняка не связана с вашим контроллером домена.
Когда вы устанавливаете разрешения в файловой системе, сервер помечает объект файловой системы идентификатором безопасности субъекта безопасности, которому вы предоставляете разрешение. Если вы используете локальную учетную запись пользователя / локальную группу, то SID будет специфичным для сервера. Однако в модели домена вы можете ссылаться на глобальную доменную группу или локальную группу домена, и в этом случае SID участника безопасности на основе домена будет привязан к объекту файловой системы.
Кроме того, передовая практика по-прежнему диктует, что вы должны использовать локальные группы в файловой системе с глобальными / локальными доменными группами в этих локальных группах. Это теоретически сокращает поиск SID между серверами и DC / GC.
После того, как тег SID был применен, он будет по-прежнему сохраняться, даже если DC / GC отключен или недоступен; вам просто будет представлен неразрешенный SID.
Итак, предложения:
Я (мы?) Ждем больше информации ...