Проблемы безопасных каналов

.

Каждый компьютер, присоединяемый к домену (клиентская рабочая станция, сервер или DC), требует подключения к DC для обеспечения выполнения обязательных требований по обслуживанию в домене AD. Для рабочих станций и серверов необходимо подключение к DC того домена, которому они принадлежат, а также к DC доменов-доверителей. DC одного домена должны иметь связь с DC доменов-доверителей и доверенных доменов. Кэшированные значения, определяющие междоменные соединения, описываются термином «безопасный канал домена». Существует два типа безопасных каналов: между членом домена и DC этого же домена; между DC домена-доверителя и DC доверенного домена.

Значение безопасных каналов

Почему нужно заботиться об исправности безопасного канала? Дело в том, что все службы, связанные с доменом, в той или иной степени используют безопасный канал. Нет доступа к групповой политике? Недоступен сетевой ресурс? Не удается зарегистрироваться в домене? Во всех этих случаях следует проверить работу безопасного канала. Конечно, подобные неисправности могут быть вызваны и другими причинами, но лишь немногие из них сложнее в диагностике и более широко распространены, чем проблемы безопасного канала.

Для чего нужен безопасный канал? Напрашивается ответ: «для всего, что связано с доменом». Все службы, связанные с доменом, должны иметь возможность обнаружения DC для отправки запроса. Это верно как для члена домена (например, рабочей станции или рядового сервера), так и для DC. Обеспечение доступности эффективно реагирующего DC — функция безопасного канала. Если с сервером нельзя связаться и отправить запрос, то службы не работают.

В частности, пользователь, подключающийся к сайту SharePoint, настроенному на работу с Kerberos, должен запросить билет Kerberos, предъявляемый серверу SharePoint для авторизации. Компьютер пользователя просматривает кэшированные данные о безопасном канале домена (кэш, обслуживаемый службой NetLogon), определяя целевой DC для отправки запроса на билет Kerberos. Если по какой-либо причине DC не отвечает, то запрос на билет не формируется, и аутентификация с использованием Kerberos при подключении к SharePoint не работает. В зависимости от архитектуры SharePoint, результатом может быть отказ в доступе к сайту – и все из-за проблемы безопасного канала.

Рассмотрим типовой мультидоменный сценарий. Предположим, что пользователь из домена A регистрируется в системе на компьютере B в домене B. Регистрация пользователя обрабатывается в соответствии с групповой политикой, и на DC домена А по протоколу LDAP посылается запрос с тем, чтобы определить, какая политика применима к пользователю А. Как компьютер B, принадлежащий домену B, узнает, куда отправлять сетевой трафик, чтобы выяснить применяемую политику домена А? Это возможно благодаря тому, что сведения о сетевом расположении домена и DC постоянно обновляются. Актуальность информации поддерживается службой NetLogon на каждом компьютере, присоединенном к домену Windows. NetLogon постоянно формирует список доступных DC и доменов (при наличии отношений доверия). На экране 1 приведен фрагмент журнала отладки NetLogon, иллюстрирующий этот непрерывный процесс. Вы можете просмотреть журнал отладки NetLogon на своем компьютере, следуя инструкциям, приведенным в статье Microsoft «Enabling debug logging for the NetLogon service» (http://support.microsoft.com/kb/109626).

Экран 1. Фрагмент журнала отладки NetLogon

На верхнем уровне проблемы безопасного канала могут быть сведены к неполадкам сетевого подключения. Если проблемы с подключением носят перемежающийся характер, то все службы работают тогда, когда работает сеть. Постоянные проблемы подключения порождают ситуацию неисправного безопасного канала, что, в свою очередь, приводит к несовпадению общего секрета между компьютером и AD, в результате чего компьютер перестает быть доверенным. Совокупный эффект заключается в том, что никто не может войти в домен и получить доступ к доменным ресурсам.

На клиентском компьютере или рядовом сервере неисправность безопасного канала негативно отражается на аутентификации доступа к сетевым и прочим службам. На DC это может препятствовать репликации AD и вызывать препятствия для входа в систему и доступа, если проблема остается нерешенной.

Выявление проблемы безопасного канала

Лучший способ обнаружить проблему безопасного канала – задействовать функцию I_NetLogonControl2. I_NetlogonControl2 – это одна из функций, используемых службой NetLogon (она есть на любом компьютере с Windows любой версии) для поддержания сведений о доступных доменах и DC.

В распоряжении администратора есть три простых инструмента для вызова этой функции и быстрого получения информации о возможности подключения к определенному домену и DC: NLTest, PowerShell и WMI.

NLTest.exe. Утилита NLTest.exe была выпущена в комплекте средств поддержки Windows 2000 и Windows Server 2003 и включена по умолчанию в большинство более новых версий Windows. Параметр sc_verify вызывает I_NetlogonControl2, и вам остается указать проблемный домен.

C:>nltest /sc_verify:americas
Flags: b0 HAS_IP HAS_TIMESERV
Trusted DC Name \DD3-AM-DC-03.americas.fabrikam.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfully

Если проблема безопасного канала не исчезает, то есть если общий секрет на компьютере не совпадает с общим секретом в AD для этого компьютера, исправить ошибку поможет параметр sc_reset.

PowerShell. В PowerShell 2.0 добавлена команда PowerShell Test-ComputerSecureChannel, которая также вызывает I_NetLogonControl2, но обеспечивает минимум информации, возвращая ответ True, если безопасный канал домена исправен, а DC доступен, либо, в противном случае, ответ False.

PS C:> Test-ComputerSecureChannel
True

Подобно NLTest.exe, команда Test-ComputerSecureChannel может применяться и для исправления ошибки с использованием ключа Repair.

WMI. С помощью класса win32_ntdomain инструментарий управления Windows (WMI) позволяет запросить все домены, о которых знает компьютер. WMI полезен в случаях, когда на тестируемом компьютере нельзя рассчитывать на средства PowerShell. Заметим, что в приведенном ниже примере (где Win32_NTDomain вызывается через команду PowerShell Get-WMIObject с использованием псевдонима GWMI) в качестве ответа возвращается только локальный домен, но может быть возвращен любой домен, связанный с локальным доменом отношениями доверия.

PS C:> gwmi win32_ntdomain
ClientSiteName: TX
DcSiteName: TX
Description: AMERICAS
DnsForestName: americas.fabrikam.com
DomainControllerAddress: \
DomainControllerName: \DD3-AM-DC-03
DomainName: AMERICAS
Roles:
Status: OK

Заметим, что состояние OK в этом примере соответствует ответу True или False, возвращаемому командой Test-ComputerSecureChannel, и указывает на работоспособность или неработоспособность безопасного канала.

Устранение проблемы безопасного канала

Пользователям, обращающимся в службу поддержки Microsoft, высылается дополнительный пакет сбора данных. Вместо собственной команды PowerShell Test-ComputerSecureChannel в пакете используется WMI-класс Win32_NTDomain (вызываемый из PowerShell), что позволяет запускать тест даже на более старых операционных системах, таких как Windows XP и Windows 2003. Для иллюстрации применения теста ниже приведены два примера сценариев, которые можно самостоятельно запустить в окне PowerShell, см. листинг 1 и листинг 2.

В первом примере выполняется сбор информации о безопасном канале текущего домена, а также основных сведений о лесе. На экране 2 приведены результаты.

Экран 2. Результаты работы первого сценария

Для выявления любой проблемы создается тест как сценарий PowerShell (файл. ps1), а к возвращаемому состоянию добавляется условный оператор ‘if’. Можно также указать имя домена, как показано в примере, показанном в Листинге 2.

В практике диагностики Microsoft этот сценарий превращен в простую функцию, которую можно использовать повторно.

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

PowerShell
Get-Date >> $OutputFileName
$ComputerName = Get-WmiObject -Class Win32_ComputerSystem
$OutputFileName = Join-Path $Pwd.Path ($ComputerName.Name + «_Secure Channels.txt»)
$domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
«This computers domain information is:» >> $OutputFileName
$domain >> $OutputFileName
«This computers secure channel information is:» >> $OutputFileName
gwmi Win32_NTDomain >> $OutputFileName

PowerShell
$Domain = «americas»
function SecureChannelCheck
{
#Function to give a simple «good» or «bad» result for secure channel health.
#Accepts a flat domain name--not entire FQDN--as input.
#To run as a script, not a function, just replace $DomainName with $env:userdomain.
param ($DomainName)
$v = «select * from win32_ntdomain where domainname = '» + $DomainName + «'»
$v2 = get-wmiobject -query $v
if ($v2.Status -eq «OK")
{Write-Host»The domain secure channel is OK.«}
elseif (($v2 -eq $null) -or ($v2 -ne»OK«))
{Write-Host»The domain secure channel has problems."}
}
SecureChannelCheck($Domain)