none
RMS Superuser RRS feed

  • Вопрос

  •  

    Такой вопрос. После того как была создана и настроена группа в AD для суперюзеров. Туда был добавлен тестовый пользователь для проверки функционала. После того как был потверждён функционал работоспособности. Пользователь был удалён из AD. Но как оказалось своих прав он не лишился, причём и на вновь создаваемые документы. Как решить проблему удаления пользователя из группы SuperUser,?
    25 августа 2008 г. 8:29

Ответы

  •  Spartak97 написано:
    Просто из базы данных конфигурации ключи пользователя не удаляются автоматически и в целях актуализации использования пользовательских лицензий и для того чтобы база не росла постоянно. Нужно проделывать процедуры по её очистки от всех атрибутов пользователя удалённого из RMS-сервиса. (например в случаи увольнения сотрудника)

    Вы правы ключи пользователей не удаляются автоматически, база конфигурации разрастается и отчеты о выданных сертификатах приводят некорректную информацию, включающую неисопльзуемые RAC-сертификаты.
    Средств автоматической очистки нет, придется Вам выполнять эту процедуру вручную. Инструкция приведена здесь:
    Deleting User Accounts in RMS Configuration Database
    9 сентября 2008 г. 8:16

Все ответы

  • Источник Вашей проблемы - это механизм кэширования информации о членстве в группах. По умолчанию, служба RMS запрашивает иформацию о членстве в группах Active Directory у серверов, выполняющих роль глобального каталога (Global Catalog, GC). Для того, чтобы снизить нагрузку на эти серверы (представьте, что будет с контроллерами домена в достаточно большой корпоративной сети, если RMS-серверы будут обращаться к ним раз в секунду) служба RMS по умолчанию кэширует информацию членстве в группах в специально предназначенную для этого базу данных DRMS_Directory_... Вследствие этого изменение членства в группах AD могут не оказывать влияние на функционирование службы RMS до того момента, пока не будет очищен этот кэш. По умолчанию, членство в группах кэшируется на 720 минут (12 часов)
    Параметрами механизма кэширования можно управлять (вплоть до полного отключения кэширования) посредством правки системного реестра и настройки параметров таблицы DRMS_ClusterPolicies базы данных DRMS_Configuration.
    Вот пример файла реестра, полностью отключающего кэширование RMS (можно сохранить данный текст в файл типа reg и выполнить этот файл):

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\1.0\DirectoryServices]
    "MinGc"=dword:00000000
    "MaxGc"=dword:00000000
    "PrincipalCacheMax"=dword:00000000
    "PrincipalCacheExpireMinutes"=dword:00000000
    "GroupIDCacheMax"=dword:00000000
    "GroupIDCacheExpireMinutes"=dword:00000000
    "GroupMembershipCacheMax"=dword:00000000
    "GroupMembershipCacheExpireMinutes"=dword:00000000
    "ContactMembersofGroupCacheMax"=dword:00000000
    "ContactMembersofGroupCacheExpireMinutes"=dword:00000000


    Чтобы отключить кэширование в БД DRMS_Directory необходимо подключиться к БД DRMS_Config_...и в таблице DRMS_ClusterPolicies изменить значение параметра UseDirectoryServicesCacheDatabase на 0 (ноль).


    После выполнения обеих операций необходимо выполнить команду iisreset.


    25 августа 2008 г. 10:01
  • В том и запара что предварительно, специально для тестирования кеширование было отключено. Скорей всего надо попробывать подождать 12 часов до обновления кеша. И если кеш обновится и SuperUser утратить свой функционал. Получится что я криво кеш отключилSmile))))))))))

     

     

     

    Лан тода подождём до завтра

    25 августа 2008 г. 11:59
  • Необходимо отключать кэш и в реестре и в конфигурационной БД. И обязательно перезапускать службу IIS. Лучше вообще сервер перезагрузить после всех этих операций, чтобы наверняка
    25 августа 2008 г. 12:30
  • Завтра увидим когда полюбому произойдёт обновление кеша. тода и отпишусь здесь

    25 августа 2008 г. 13:03
  • Ну вообщем ничего не изменилось хотя учётной записи пользователя в группе SuperUser нет. Sad(((((((((((

    26 августа 2008 г. 4:24
  • В таком случае Вам необходимо ответить на следующие вопросы:
    1) Какого типа группа AD, ассоциированная с группой Super Users (Security Global / Security Universal)?
    2) Какой функциональный уровень Вашего домена и леса AD?
    3) Документы защищались вручную или при помощи шаблонов политики назначения прав?

    Чтобы тотально отключить кэширование не только членства в группах, но и права доступа к документу, необходимо помимо отключения кэша членства в группах в реестре и БД конфигурации RMS сделать следующее:
    1) При назначении прав на документ группе пользователей тип этой группы должен быть Security Universal.
    2) При защите документа вручную необходимо отметить пункт "Require a connection to verify user's permissions".
    26 августа 2008 г. 7:10
  •  Spartak97 написано:

    Ну вообщем ничего не изменилось хотя учётной записи пользователя в группе SuperUser нет. (((((((((((


    По умолчанию все RMS-приложения пакета Microsoft Office 2003/2007 получают Use License на документ у RMS-сервера и кэшируют эту лицензию в профиле пользователя. Соотвественно, пока она есть в профиле пользователя, запрос к RMS-серверу производиться не будет. Это поведение по умолчанию, причем локальная лицензия на использование действительна в течении 365 дней. Чтобы избежать подобной ситуации необходимо при защите документов включать требование проверки прав пользователя при каждом обращении к защищенному документу (см. мой пост). Это же требование можно выставить в шаблонах политики назначения прав.
    26 августа 2008 г. 7:15
  • Вообщем по прошествии двух суток как пользователь был удалён и группы SuperUser он потерял свои права. Вот так вотSmile

    28 августа 2008 г. 13:06
  • Инструкции для полного отключения кэширования я привел в своем предыдущем сообщении. Но это подействует только на впервые открываемые документы. У тех же пользователей, которые уже получили однажды доступ к защищенному документу (как Ваш бывший член группы Super Users), необходимо принудительно удалить все файлы начинающиеся c CLC-... в профиле пользователя (для Vista - %LocalAppData%\Microsoft\DRM). Эти файлы есть Client Licensor Certificates, которые позволяют пользователю открывать защищённые документы без повторного обращения к RMS-серверу. То есть пока у Вашего бывшего Super User существует в профиле CLC для открываемых им документов, он будет иметь к ним доступ с правами, которыми он обладал в момент открытия (читай, в момент пребывания в группе Super Users).
    29 августа 2008 г. 6:23
  • Можете провести эксперимент с другим членом группы Super Users, предварительно выполнив все мои рекомендации и очистив директорию %LocalAppData%\Microsoft\DRM от CLC-сертификатов.
    29 августа 2008 г. 6:25
  • Ничего подобного поскольку CLC отвечает за то что бы автономно защищать документ. Кстати в Office 2003 по умолчанию защищает всегда автономно. а вот за использование отвечает EUL. EUL предоставляет право использовать документ в соответствии с правами предоставленные авторомSmile

    29 августа 2008 г. 7:30
  • Вы правы, я перепутал CLC и UL (EUL). И на старуху, как говорится, бывает проруха. И Вы совершенно верно описали механизм автономной защиты документов. Но если в моих предыдущих сообщениях заменить CLC на EUL, получиться именно то, что я хотел Вам сказать. Правда файлы EUL начинаются не CLC, конечно же .
    В Windows Vista все Use Licenses представляют собой файлы с префиксом EUL в директории
    %USERPROFILE%\AppData\Local\Microsoft\DRM.
    В Windows XP все Use Licenses представляют собой файлы с префиксом EUL в директории %USERPROFILE%\Local Settings\Application Data\Microsoft\DRM.
    1 сентября 2008 г. 7:22
  • Ладно с проблемой разобрался. Спасибо

    1 сентября 2008 г. 7:29
  • Рад был помочь . И всё таки, если располагаете временем, проведите небольшой эксперимент, дабы раз и навсегда разобраться с этим механизмов кеширования и автономного досутпа к защищённому контенту.
    1 сентября 2008 г. 7:51
  • Вот в чём прикол. Что всё-равно после удаления всех лицензий и уже давнишнего исключения пользователя из группы суперюзер он всё-равно получает полный доступ к открываемым ранее документам

    2 сентября 2008 г. 11:45
  • Насколько я помню, Вы сообщили, что по истечении двух суток этот пользователь потерял права на доступ к документам. Это не так? Если да, то опишите пожалуйста детальную последовательность Ваших действий и ответьте на вопросы, которые я задавал в начале обсуждения (касаемо типа группы).
    3 сентября 2008 г. 12:12
  • Да пользователь потерял права SuperUser на доступ к вновь создаваемым документам. Однако сохранил права SuperUser на открываемые ранее документы когда он ещё являлся членом группы SuperUser.

    3 сентября 2008 г. 12:27
  •  

    Пользователь получал доступ даже когда были удалены все лицензии на использование(EUL) с его хранилища лицензий.

     

     

    В таком случае Вам необходимо ответить на следующие вопросы:
    1) Какого типа группа AD, ассоциированная с группой Super Users (Security Global / Security Universal)?
    2) Какой функциональный уровень Вашего домена и леса AD?
    3) Документы защищались вручную или при помощи шаблонов политики назначения прав

    Ответы:

    1) Security Uneversal.

    2) Вопрос не понятен.

    3) Документы защищались как вручную так и с помощью шаблонов

    3 сентября 2008 г. 12:31
  • кстати нет группа superuser   -------  distribution Universal

     

    3 сентября 2008 г. 12:35
  •  Spartak97 написано:

    2) Какой функциональный уровень Вашего домена и леса AD?
    Ответы:

    2) Вопрос не понятен.

    4 сентября 2008 г. 6:55
  • Мне кажется, основная ошибка, в том что я описываю механизм кэширования, относящийся к использованию групп в шаблонах назначения прав и ручной защите документа. Механизм Super Users немного отличается от приведенного мною выше.

    При защите документа члены группы AD, ассоциированной с группой Super Users, добавляются в Publish License в качестве авторов документа. А автор документа может получить доступ к документу не совершая запрос к RMS-серверу. Это объясняет потерю пользователем прав на вновь защищаемые документы (после обновления или отключения механизма кэширования членства в группах) и оставшиеся права на ранее защищенные документы (в качестве автора этих документов).

    Так что, смею полагать, что единственный вариант корректного исключения пользователя из группы Super Users - это исключение пользователя из группы AD (лучше в дополнение отключить кэширование членства в группах), а также отзыв RAC-сертификата этого пользователя (Revocation Policy).

    Попробуйте отозвать RAC-сертификат этого пользователя.

    4 сентября 2008 г. 7:07
  • Нет ну это понятно что если удалить или заблокировать RAC пользователя то он потеряет свою функциональность. Ну неужели в MS не предумали более коректного способа лишать пользователя привелегии SuperUser,?

     

    4 сентября 2008 г. 10:38
  • На самом деле добавлять пользователя в группу Super Users нужно более чем осторожно. Обычно эта группа используется сотрудниками службы безопасности в компании. И исключение из этой группы производится только в момент увольнения сотрудника. А в момент увольнения сотрудника необходимо как можно скорее отозвать его RAC-сертификат.

    Собираюсь лично провести подобный эксперимент с членами группы Super Users, но смогу это сделать только на следующее неделе. О результатах сообщу.

    4 сентября 2008 г. 11:06
  • Вообщем там ситуация такая. При добавлении пользователя в группу SuperUser, при открытии документа он получает лицензию на использование которая хранится в самом документе и действительна по умолчанию 7 лет. Из этого следует что единственным способом лишить его использование ранее открытых документов только удаление его из AD и физическое удаление с его пользовательской станции всех его сертификатов и лицензий из папки DRM.

    4 сентября 2008 г. 13:34
  •  Spartak97 написано:

    Вообщем там ситуация такая. При добавлении пользователя в группу SuperUser, при открытии документа он получает лицензию на использование которая хранится в самом документе и действительна по умолчанию 7 лет. Из этого следует что единственным способом лишить его использование ранее открытых документов только удаление его из AD и физическое удаление с его пользовательской станции всех его сертификатов и лицензий из папки DRM.


    Ну зачем так кардинально подходить к решению. Удалять учетную запись из AD не обязательно, тем более это очень болезненный процесс. Можно просто отозвать RAC-сертификат пользователя в консоли администрирования RMS-сервера и удалить RAC-сертификат (файл GIC в директории %USERPROFILE%\Local Settings\Application Data\Microsoft\DRM) на всех машинах. При попытке открытия документа пользователем в режиме автора RMS-клиент в любом случае будет искать локальный RAC-сертификат пользователя. Если сертификат отсутствует или повреждён RMS-клиент сделает запрос RMS-серверу. Запрос окончится неудачей так как данный RAC находится в списке отозванных в конфигурации RMS-сервера.
    5 сентября 2008 г. 9:22
  • Ну мне кажется что намного удобней если учётную запись пользователя просто заблокировать в группе безопасности RMS-сервиса (группа куда по умолчанию должны входить все пользователи сервиса для обращения к серверам RMS). Чем блокировать в консоли администрирования. поскольку там множество ньюансов возникает:

    Необходимо исключить сертификат учетной записи управления правами на всех зарегистрированных подчиненных серверах на веб-узле администрирования КАЖДОГО сервера

    8 сентября 2008 г. 4:57
  •  Spartak97 написано:

    Ну мне кажется что намного удобней если учётную запись пользователя просто заблокировать в группе безопасности RMS-сервиса (группа куда по умолчанию должны входить все пользователи сервиса для обращения к серверам RMS).

    Тогда этот пользователь вообще не сможет воспользоваться службой RMS, а это в большинсмотве случаев не допустимо.

     Spartak97 написано:
    Чем блокировать в консоли администрирования. поскольку там множество ньюансов возникает:

    Необходимо исключить сертификат учетной записи управления правами на всех зарегистрированных подчиненных серверах на веб-узле администрирования КАЖДОГО сервера


    А у Вас что более двух RMS-серверов в организации?
    8 сентября 2008 г. 10:51
  •  

    Ну вообще их два в составе одного кластера.
    9 сентября 2008 г. 4:53
  • И в чем проблема на двух серверах отозвать RAC-сертификат пользователя RMS?
    9 сентября 2008 г. 6:48
  • Да нет проблемы то вообщем нет никакой. Щас встала другая проблема? Есть ли скрипт который обращался бы в базу данных конфигурации и удалял все следы пользователя от туда? В случаи если например пользователь был удалён из сервиса

    9 сентября 2008 г. 6:53
  •  

    Для ведения базы данных конфигурации можно запустить сохраненную процедуру, которая удаляет ключ пользователя в соответствии с его идентификатором безопасности (SID) при каждом удалении учетной записи, связанной с пользователем, из Active Directory. Можно также периодически запускать сценарий, который удаляет любые ключи пользователя из базы данных конфигурации, если связанные с ними идентификаторы безопасности уже не существуют в Active Directory.

     

     

    Вот что то вроде такой процедуры которая описана выше

    9 сентября 2008 г. 7:01
  • Не встречал информации по подобному скрипту. Честно говоря, не совсем понимаю, к чему Вам такие мытарства. Для исключения пользователя из организации RMS предназначены процедуры отзыва и исключения RAC-сертификатов пользователей.
    9 сентября 2008 г. 7:47
  • Просто из базы данных конфигурации ключи пользователя не удаляются автоматически и в целях актуализации использования пользовательских лицензий и для того чтобы база не росла постоянно. Нужно проделывать процедуры по её очистки от всех атрибутов пользователя удалённого из RMS-сервиса. (например в случаи увольнения сотрудника)

     

    9 сентября 2008 г. 7:58
  •  Spartak97 написано:
    Просто из базы данных конфигурации ключи пользователя не удаляются автоматически и в целях актуализации использования пользовательских лицензий и для того чтобы база не росла постоянно. Нужно проделывать процедуры по её очистки от всех атрибутов пользователя удалённого из RMS-сервиса. (например в случаи увольнения сотрудника)

    Вы правы ключи пользователей не удаляются автоматически, база конфигурации разрастается и отчеты о выданных сертификатах приводят некорректную информацию, включающую неисопльзуемые RAC-сертификаты.
    Средств автоматической очистки нет, придется Вам выполнять эту процедуру вручную. Инструкция приведена здесь:
    Deleting User Accounts in RMS Configuration Database
    9 сентября 2008 г. 8:16