Ошибка взаимной проверки подлинности пароль сервера на контроллере домена устарел

Господа Хорошие, прошу о помощи, зашел в тупик, рву на себе волосы.

На windows server 2008R2 настроил web-dav. Создал самозаверенный сертификат на сервере и установил его на клиенте, чтобы пустить соединение через https. Первые 2 дня все функционировала хорошо. Сейчас же, при обращении к сетевому диску получаю сообщение: «Ошибка взаимной проверки подлинности. Пароль сервера на контроллере домена устарел».

Если переподключить сетевой диск или перезагрузить службу «веб-клиент» минуты 2 работает и потом снова ошибка. Через браузер подключение работает стабильно все время, но цель использования web-dav исключительно как сетевой диск.

На клиенте в журналах ничего, на сервере: «Причина ошибки: Неизвестное имя пользователя или неверный пароль. Состояние: 0xc000006d»

О системе: Домена нет. Active Directory нет. Подключаюсь из интернета через проброшенный порт.

Проблема уже сниться — ничего не могу придумать.

У нас есть существующая установка WebDAV с Apache mod_dav, который размещался на диске WebDAV по защищенному URL-адресу SSL с выданным CA сертификатом и базовой аутентификацией. MacOSX и Windows <10 могут подключаться в течение ряда лет.

За исключением одной машины, новые машины Windows 10 не могут подключиться к этому серверу WebDAV. При попытке сопоставить сетевой диск дважды запрашиваются учетные данные базовой аутентификации, а затем появляется следующая ошибка:

The mapped network drive could not be created because the following error
has occurred:

Mutual Authentication failed: The server's password is out of date at
the domain controller.

Более конкретно, когда кнопка «Готово» нажата в диалоговом окне «Подключить сетевой диск», запрашивается имя пользователя и пароль — это диалоговое окно отображается перед попыткой любого подключения к серверу WebDAV. Введено правильное имя пользователя и пароль, и в этот момент возникает примерно 6-секундная задержка, когда отображается диалоговое окно с сообщением «Попытка подключения». После этой задержки на сервер WebDAV поступает один запрос, который выглядит следующим образом:

PROPFIND /shared HTTP/1.1
Host: 127.0.0.1:8022
User-Agent: Microsoft-WebDAV-MiniRedir/10.0.10586
translate: f
X-Forwarded-For: xx.xx.xx.xx
X-Forwarded-Host: x.x.x
X-Forwarded-Server: x.x.x
Connection: Keep-Alive

Приведенный выше запрос не содержит заголовков аутентификации, поэтому сервер WebDAV отвечает, как и ожидалось, следующим образом:

HTTP/1.1 401 Unauthorized
Date: Wed, 13 Jan 2016 14:18:10 GMT
Server: Apache/2.4.12 (Unix)
WWW-Authenticate: Basic realm="Xxx Xx"
Content-Length: 381
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

[content]

Сразу после получения этого ответа диалоговое окно «Подключить сетевой диск» снова запрашивает имя пользователя и пароль. Ввод того же имени пользователя и пароля вызывает задержку примерно в 6 секунд, после чего появляется сообщение «Ошибка взаимной аутентификации» без каких-либо попыток связаться с сервером WebDAV.

Некоторые заметки:

• Контроллер домена отсутствует, это простой защищенный сервер WebDAV, защищенный Basic Auth и SSL.

• Одна машина с Windows 10 работает нормально, мы не знаем, что особенного в этой машине, и все новые машины с Windows 10 выходят из строя.

• Мы попытались изменить значение HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services WebClient Parameters BasicAuthLevel на 2, и это не имело никакого значения (как и ожидалось, исходное значение было 1, и мы используем сертификат, выданный ЦС SSL).

Кто-нибудь сталкивался с этой проблемой раньше?

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

Домен хранит текущий пароль компьютера, а также предыдущий, на всякий случай 🙂 . Если пароль изменится дважды, то компьютер, использующий старый пароль, не сможет пройти проверку подлинности в домене и установить безопасное соединение. Рассинхронизация паролей может произойти по разным причинам, например компьютер был восстановлен из резервной копии, на нем была произведена переустановка ОС или он просто был долгое время выключен. В результате при попытке входа в домен нам будет выдано сообщение о том, что не удается установить доверительные отношения с доменом.

Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.

Способ первый

Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учетной записью и заново вводим его в домен.

Примечание. Кое где встречаются рекомендации удалить компьютер из домена и заново завести. Это тоже работает, однако при этом компьютер получает новый SID и теряет членство в группах, что может привести к непредсказуемым последствиям.

Способ этот довольно громоздкий и небыстрый, т.к. требует перезагрузки, однако работает в 100% случаев.

Способ второй

Заходим на компьютер, которому требуется сбросить пароль, открываем командную консоль обязательно от имени администратора и вводим команду:

Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*

где SRV1 — контролер домена, Administrator — административная учетная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.

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

Что интересно, в рекомендациях  по использованию и в справке написано, что команду Netdom Resetpwd можно использовать только для сброса пароля на контролере домена, другие варианты использования не поддерживаются. Однако это не так, и команда также успешно сбрасывает пароль на рядовых серверах и рабочих станциях.

Еще с помощью Netdom можно проверить наличие безопасного соединения с доменом:

Netdom Verify WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*

Или сбросить учетную запись компьютера:

Netdom Reset WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*

где WKS1 — рабочая станция, которой сбрасываем учетку.

Способ достаточно быстрый и действенный, однако есть одно но: по умолчанию утилита Netdom есть только на серверах с установленной ролью  Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удаленного администрирования Remote Server Administration Tools (RSAT).

Способ третий

Еще одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:

Nltest /query — проверить безопасное соединение с доменом;

Nltest /sc_reset:Contoso.com — сбросить учетную запись компьютера в домене;

Nltest /sc_change_pwd:Contoso.com — изменить пароль компьютера.

Самый быстрый и доступный способ, ведь утилита Nltest по умолчению есть на любой рабочей станции или сервере. Однако, в отличие от Netdom, в которой предусмотрен ввод учетных данных, Nltest работает в контексте запустившего ее пользователя. Соответственно, зайдя на компьютер под локальной учетной записью и попытавшись выполнить команду можем получить ошибку доступа.

Способ четвертый

PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищенного канала — True или False.

Для сброса учетной записи компьютера и защищенного канала можно использовать такую команду:

Test-ComputerSecureChannel -Server SRV1 -Credential ContosoAdministrator -Repair

где SRV1 — контролер домена (указывать не обязательно).

Для сброса пароля также можно также воспользоваться такой командой:

Reset-ComputerMachineChannel -Server SRV1 -Credential ContosoAdministrator

Способ быстрый и удобный, не требующий перезагрузки. Но и здесь есть свои особенности. Ключ -Credential впервые появился  в PowerShell 3.0. Без этого параметра командлет, запущенный из под локального пользователя, выдает ошибку доступа. Получается что данный метод можно использовать только на  Windows 8 и Server 2012, ведь для остальных ОС PowerShell 3.0 пока недоступен.

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

Изменение параметров смены пароля компьютера

Смена пароля в домене происходит следующим образом:

Каждые 30 дней рабочая станция отправляет ближайшему контролеру домена запрос на изменение пароля учетной записи компьютера. Контролер принимает запрос, пароль изменяется, а затем изменения передаются на все контролеры в домене при следующей репликации.

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

Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:

Disable machine account password change — отключает на локальной машине запрос на изменение пароля;

Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;

Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.

Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе HKLMSYSTEMCurrentControlSetServicesNetlogonParameters есть два параметра :

 DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.

MaximumPasswordAge — определяет максимальный срок действия пароля компьютера в днях. При желании можно задать более 1 миллиона дней !!!

И в разделе HKLMSYSTEMCurrentControlSetServicesNetlogonParameters, только у контролеров домена, параметр:

RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.

Вот вроде и все про доверительные отношения. Как видите, доверие в домене — штука тонкая, так что старайтесь его не терять.

для выдачи сертификатов используется stand-alone центр сертификации не входящий в домен

если запрашиваешь хэндл и инициализируешь контекст на клиенте с параметрами

ULONG MessageAttributes = ISC_REQ_MUTUAL_AUTH | ISC_REQ_USE_SUPPLIED_CREDS;

SCHANNEL_CRED cred;
cred.dwFlags = SCH_CRED_NO_SERVERNAME_CHECK | SCH_CRED_NO_DEFAULT_CREDS |
SCH_CRED_AUTO_CRED_VALIDATION (или SCH_CRED_MANUAL_CRED_VALIDATION) | SCH_CRED_REVOCATION_CHECK_CHAIN;

(переменные передаются в соответствующие параметры апишных ф-й)

то при втором вызове InitializeSecurityContext выдается ошибка 1397
Ошибка взаимной проверки подлинности. Пароль сервера на контроллере домена устарел.

если же добавляется один флаг в эту переменную

ULONG MessageAttributes = ISC_REQ_MUTUAL_AUTH | ISC_REQ_USE_SUPPLIED_CREDS |
ISC_REQ_MANUAL_CRED_VALIDATION;

то при первом вызове InitializeSecurityContext выдается ошибка 1
Неверная функция

в чем проблемы? что я не учел?

дополнение:

на сервере я использую флаги

cred.dwFlags = SCH_CRED_NO_SYSTEM_MAPPER | SCH_CRED_REVOCATION_CHECK_CHAIN;

серверный и клиентский сертификаты я беру из хранилища MY

и сервер и клиент (тестовые консольные приложения) запущены на одном компьютере, входящем в домен (ЦС как я и сказал в домен не входит, но является доверенным для данного компа)

установил

ULONG MessageAttributes = ISC_REQ_USE_SUPPLIED_CREDS;

заработало

то ли неверные комбинации задавал, то ли документация по флагам неполная

но с ISC_REQ_MUTUAL_AUTH не работает