Archive for the ‘ На форумах Technet ’ Category

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

Свежий поучительный случай с русского форума 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 отключена), а потому в целом возникает загадочная и сбивающая системного администратора с толку картина, что к одним ресурсам доступ после переноса учётных записей и групп сохраняется, а к другим (к которым он предоставляется через те же группы) — нет.

Реклама

О переименовании контроллера домена обратно

Любят наши люди стабильность. Даже когда не слишком получается. Вот очередной случай с форума Microsoft Technet. Жил в некой маленькой конторке домен (в смысле — единственный контроллер домена) с именем SERVER на Windows Server 2003. Жил — не тужил, но вот настало время ему апгрейдиться. То ли потому что Windows Server 2003 уже давно как производителем с поддержки снята, то ли ещё по какой причине — это мне неведомо.
Админ тамошний, не долго думая, поднял второй контроллер — DC2 — на новой современной(почти) Windows 2012, а старый контроллер понизил. Затем, ради этой самой стабильности — чтобы не утруждать себя перенастройкой приложений — дал админ новому контроллеру IP старого и переименовал его в старое имя — SERVER — через свойства системы. И тут что-то пошло не так: сначала при переименовании Windows сообщила, что такое имя уже существует, а после перезагрузки стал недоступным домен, не получилось открыть консоль «AD Users and Computers»… Ну, такой факт, что резервной копии, чтобы вернуть всё взад, у этого админа не было, даже и упоминать не стоит: так всегда бывает в подобных случаях у подобных админов. Короче — печаль.
Читать далее

Новые возможности — новые проблемы: разрешение имён в Windows

Не секрет, что с течением времени появлением новых версий Windows расширяются возможности настройки подсистемы разрешения имён(resolver) в этой ОС. Становится возможным штатным образом делать такие вещи, которые раньше требовали хитрой настройки, если вообще были возможны. Но эти новые возможности несут в себе и потенциал новых проблем, вызванных неправильной их настройкой. И проблемы эти не так то просто обнаружить традиционными инструментами, к которым администраторы привыкли за долгие годы работы. Недавно я как раз занимался обсуждением на русском форуме Technet темы, которая служит хорошей иллюстрацией такого положения дел.

Дело обстояло следующим образом. У автора темы внезапно сервер-член домена (под управлением Windows Server 2012 R2) перестал находить контроллер домена через DNS. В журнале событий при этом имелась соответствующая случаю диагностика в виде довольно часто возникающих предупреждений с Event ID 1014 и источником Microsoft Windows DNS Client: «Разрешение имен для имени _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs… истекло после отсутствия ответа от настроенных серверов DNS», а также — ряда других событий,  в частности — сообщений о проблеме обработки групповой политики из-за невозможности найти контроллер домена. Читать далее

Публикация Sharepoint на нестандартном порту.

Сегодня встретил на форуме Techent cообщение с такой вот проблемой, касающейся публикации Sharepoint (для справки: автор заменил в URL реальное имя своего домена на слово domen):

Добрый день. Проблема с публикацией SP в интернет.
Задал адрес в альтернативном доступе для Интернет указал как http://sp.domen.ru
На шлюзе (Kerio Control) опубликовал по порту 8855 натом на внутренний адрес и порт 80.
При заходе спрашивает логин-пароль, а далее дико дико тупит. Через раз вываливается в 504 тайм аут. Это если заходить на адрес http://sp.domen.ru:8855/sites/sitename
через раз показывает в итоге сам сайт кое как подгружая страницу, но работать на сайте не получается, ибо как сказал выше постоянно 504 gateway time out.
Что ему нужно? )

Естественно, Sharepoint нужно, прежде всего, чтобы в сопоставлениях альтернативного доступа был указан внешний URL для выделенной под внешней доступ зоны (у автора вопроса это, как выяснилось позже — зона Интернет), содержащий этот самый нестандартный порт 8855. Но и это не всё. Когда я посоветовал автору вопроса добавить во внешний URL зоны Интернет номер порта, он ответил, что он это пробовал, но эффекта это не дало.
После моей просьбы показать настройку сопоставлений альтернативного доступа была получена следующая картинка (с замазанным именем реального домена)

sharepoint-publication

Конечно, предпочтительным вариантом показать сопоставления было получить выдачу команды Get-SPAlternateURL в Powershell (с текстом работать удобнее), но для понимания, кто виноват и что делать, этой картинки достаточно.
На картинке мы видим, что для зоны Интернет назначено единственное (создаваемое по умолчанию) сопоставление внешнего имени (http://sp.domen.ru:8855) самого на себя. Но так как у автора вопроса в реальности подключение на порт 8855 на шлюзе перенаправляется на порт 80 сервера Sharepoint, а не 8855, то это сопоставление не работает. Поэтому подключение извне воспринимается как относящееся к зоне По умолчанию, и в страницах ответа возвращаются URL, соответствующие зоне По умолчанию, но не зоне Интернет.
Чтобы сопоставление заработало, нужно добавить правильный внутренний URL (по которому перенаправляется запрос на шлюзе) в список внутренних URL для зоны Интернет.

Для этого на странице, скриншот который приведен выше, надо перейти по ссылке «Добавить внутренние URL-адреса».  На открывшейся странице в строке ввода «Добавить внутренний URL» следует написать для нашего случая http://sp.domen.ru. А в общем случае там нужно указать URL с именем хоста из внешнего имени (в нашем случае это sp.domen.ru), но с портом внутреннего сервера, на который реально перенаправляются внешние запросы (в нашем случае это — порт HTTP по умолчанию). А в  списке зон  ниже на этой странице нужно выбрать зону Интернет.
При такой настройке Sharepoint будет (в нашем случае) понимать, что если он получил запрос на 80-й порт с именем хоста sp.domen.ru (это имя передаётся в заголовке запроса HTTP), то все URL ссылок в ответе (на картинки, на ссылки для перехода и пр.) должны начинаться с внешнего URL зоны для внешнего доступа — http://sp.domen.ru:8855

После такой настройки публикация Sharepoint ожидаемо заработала.

PS Как сообщил автор, в данном случае публикация была чисто с целью протестировать саму возможность публикации. Ну, а для работы, конечно, в целях безопасности публиковать Sharepoint нужно исключительно по протоколу HTTPS. Но это уже другая история.

 

Чистьте Active Directory!

Я уже писал ранее о том, как не удалённый вовремя из Active Directory  вышедший из строя контроллер домена может мешать её работе. И вот, форумы русского Technet принесли ещё один пример того, как не вычищенные вовремя из Active Directory следы «мёртового» контроллера домена могут мешать нормальному функционированию. Автор вопроса на форумах наткнулся на ситуацию, когда он не может добавить в домен новую рабочую станцию. При этом, в журнале событий фиксировалось событие с кодом 16651 от источника Microsoft-Windows-Directory-Services-SAM , говорящее об исчерпании пула относительных идентификаторов (RID) и о проблеме получения нового пула. Однако, автор вопроса уверял, что контроллер — владелец роли RID Master работоспособен. Дополнительный опрос и диагностика показали следующую картину: у автора вопроса физически был ровно один контроллер домена, который являлся владельцем всех ролей FSMO, но в базе данных Active Directory остались записи для другого, неработоспособного контроллера домена, и тесты dcdiag сообщали о совершенно естественных проблемах репликации с этим, физически отсутствующим контроллером. И именно это послужило источником проблемы. Дело в том, что владелец роли FSMO (при настройках по умолчанию) после запуска не начинает функционировать в качестве такового до тех пор, пока он не проведёт начальную синхронизацию раздела каталога, с которым связана соответствующая роль FSMO, с каким-либо другим контроллером домена, на котором есть копия этого раздела. Сделано это из соображений безопасности — чтобы случайно включенный в сеть бывший владелец роли, у которого роль была принудительно изъята и передана другому контроллеру, не нарушил функционирование Active Directory. Поэтому у автора, хотя роль RID master и была перенесена на функционирующий контроллер, этот контроллер не начал выполнять функции RID master, потому что не мог провести начальную синхронизацию, о необходимости которой говорило наличие в AD другого контроллера домена. После удаления из AD записей о неработоспособном контроллере, когда  необходимость в начальной синхронизации отпала, проблема была решена — новый пул RID был получен и рабочая станция была успешно добавлена. Мораль всей этой истории такова — не оставляйте в AD следы вывденных из эксплуатации контроллеров доменов: они могут помешать работе.