Доверие бывает излишним.

Свежий поучительный случай с русского форума MS TechNet.

Системный администратор  переносит с помощью ADMT объекты из, видимо, исторически сложившегося отдельного домена/леса (назовём его, как и автор поста на форуме, source.ru) в поддомен основного леса (назовём лес target.ru, а домен — branch.target.ru). Между отдельным и основным лесами существует отношение межлесного доверия.

Пользователей и группы он уже перенёс, а вот ресурсы — файловый и терминальный серверы — ещё нет. И чтобы дать пользователям, перенесённым в новый поддомен, возможность работы с ресурсами, оставшимися в старом, администратор, как полагается, перенёс их с сохранением SID пользователей/групп из старого домена в SIDHistory. А также — настроил внешнее отношение доверия домена source.ru домену branch.target.ru и отключил на этом отношении фильтрацию SID.

Однако, вопреки его ожиданиям, перенесённые пользователи не получили доступ к общим папкам файл-сервера через сохранённые в SIDHistory SID старого домена. Администратор предположил, что проблема может быть в фильтрации SID на межлесном отношении доверия. Но так как он не понимал, какое отношение имеет фильтрация SID на межлесном доверии к аутентификации при наличии прямого внешнего доверия, то он обратился с вопросом на форум: правильно ли он предположил причину.

Причиной действительно оказалась фильтрация SID на межлесном доверии. Но вот ответ на вопрос, почему — он, на мой взгляд, весьма поучителен. Вкратце, ответ заключается в том, что внешнее отношение доверия не совсем полноценно: оно не допускает аутентификацию по протоколу Kerberos (а только по протоколу NTLM).

Рассказываю, что там произошло, более подробно. Как известно, при доступе к общим папкам другого сервера в сети используется согласование протокола доступа (Negotiate), при котором предпочтительным является выбор протокола аутентификации Kerberos. Именно этот протокол выбирается, если есть возможность его использовать, а протокол NTLM используется только когда нет возможности использовать Kerberos. В данном случае, благодаря наличию межлесного доверия, использовать Kerberos можно: компьютеры в лесу target.ru могут узнать из AD своего леса, что доступ к ресурсам, полные имена DNS (FQDN) которых имеют суффикс source.ru, осуществляется через межлесное доверие между корнем леса клиента (target.ru) и корнем леса source.ru.

Поэтому клиент из домена branch.target.ru запрашивает у контроллера своего домена билет доступа к службе выдачи билетов (TGT)  корневого домена леса target.ru, а с помощью этого TGT у контроллера корневого домена леса target.ru — TGT для корневого домена леса source.ru. Т.к. внутри леса какая-либо фильтрация SID отсутствует, то оба эти TGT содержат (в поле PAC) SID, принадлежащие домену source.ru, из атрибута SIDHistory.

Далее клиент (который, как мы помним, находится в домене branch.target.ru) запрашивает у контроллера домена source.ru билет на доступ к файл-серверу, используя TGT, полученный от контроллера корневого домена своего леса. И вот на этом этапе контроллер домена source.ru исключает из билета службы SID, принадлежащие домену source.ru — потому что видит, что TGT получен для отношения доверия, для которого SIDHistory запрещена. И клиент (перенесённый из домена source.ru) в результате получает билет доступа к службе файл-сервера, в котором нет SID из атрибута SIDHistory, принадлежавших исходному пользователю/группам из домена source.ru. В результате, учётная запись клиента не получает разрешений для доступа к общим папкам, которые она имела до переноса.

Лечится это просто: разрешением использования SIDHistory для межлесного отношения доверия. Делается это всё той же командой netdom, что и для внешнего отношени доверия, только ключ другой — не /quarantine:NO, а /EnableSIDHistory:YES :

netdom trust source.ru  /domain:target.ru /EnableSIDHistory:YES

Поучительным же моментом является то, что в данном случае внешнее отношение доверия создавать было совсем не нужно. Более того, его наличие маскирует проблему, когда для аутентификации по тем или иным причинам используется NTLM: для NTLM используется аутентифкация через внешнее отношение доверия (на котором фильтрация SID отключена), а потому в целом возникает загадочная и сбивающая системного администратора с толку картина, что к одним ресурсам доступ после переноса учётных записей и групп сохраняется, а к другим (к которым он предоставляется через те же группы) — нет.

Реклама
  1. No trackbacks yet.

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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