Sharepoint Server 2013 и группы Active Directory


Чем проще ситуация, тем иной раз дольше соображаешь, как с ней справиться. Вот на днях нужно было настроить доступ к ресурсу на Sharepoint Server 2013 для пользователей, которые внесены в группу Active Directory. Вообще для Sharepoint предоставление доступа на основе групп AD рекомендуется при большом количестве пользователей: это увеличивает производительность. После настройки доступа и проверки, что он работает, прошло какое-то время, и от пользователей пришла жалоба: «Нет доступа». Выясняется странная ситуация: у части пользователей доступ есть, у части пользователей доступа нет. Причём все они в группе AD присутствуют.

Это самая неприятная ситуация, когда что-то не работает частично. Куда проще, когда вообще не работает: значит где-то что-то отвалилось или не настроено. А вот при частичном отказе – всё настроено и найти место, которое периодически создаёт проблему (может проблем даже несколько сразу – наложенные проблемы), всегда намного сложнее.

Добавил тестового пользователя в группу – доступа нет. Появилась гипотеза, что доступ есть у тех пользователей, которые были в группе давно, и доступа нет у вновь добавленных пользователей. Это помогло найти рекомендации по уменьшению времени жизни claim based дескриптора безопасности. Именно claim based, потому что в Sharepoint Server 2013 это используется как основной и рекомендуемый режим.


$mysts = Get-SPSecurityTokenServiceConfig

# Ставим для теста 5 минут

$mysts.WindowsTokenLifetime = (New-TimeSpan -Minutes 5)

###$mysts.FormsTokenLifetime = (New-TimeSpan -Minutes 5)

# Подгоняем второй параметр

$mysts.LogonTokenCacheExpirationWindow = (New-TimeSpan -Minutes 2)

# Применяем новые значения

$mysts.Update()

# Перезапуск IIS на всех серверах

iisreset

В моему удивлению проблема сохранилась: тестовый вновь добавленный пользователь не получил доступ ни через 5 минут, ни через 15, ни после IISRESET, ни даже после перезагрузки.

Появились сомнения в правильности гипотезы и пути исправления проблемы. Но после нарезания нескольких «кругов» и поиска корня проблемы в других местах (репликация профилей и групп из AD, обновление SID пользователя с помощью stsadm –o migrateuser –oldlogin DOMAIN\user –newlogin DOMAIN\user –ignoresidhistory), пришлось вернуться на эту дорогу снова.

И тут обнаружился ещё один параметр связанный с временем жизни дескриптора безопасности, только на этот раз дескриптора безопасности не claim based, а самого Windows: оказывается Sharepoint кэширует эти дескрипторы, включая членство в группах. Этот параметр настраивается для фермы Sharepoint с помощью утилиты spsadm


# Для теста выставляем свойство в 5 минут

stsadm -o setproperty   -propertyname token-timeout -propertyvalue 5

# Перезапуск IIS на всех серверах

iisreset

После этого тестовый пользователь получил доступ – проблема была решена.

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

 

Полезные ссылки:

SharePoint 2013 Claim Expiration and AD Sync

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: