Блог

Мы находимся в процессе отключения NTLM в нашей среде как для входящего, так и для исходящего трафика через объект групповой политики. В ходе нашего лабораторного тестирования мы столкнулись со следующим при блокировке входящего NTLM на удаленном хосте:

1. Отправка RDP на удаленный хост с входящим NTLM, заблокированным через кросс-лес, породила сообщение об ошибке CredSSP.
2. Установка исправления Oracle для шифрования как смягченного, так и уязвимого в качестве обходного пути не сработала.
3. Отключение NLA на удаленном хосте в качестве обходного пути позволит использовать RDP между лесами
4. Я попытался применить «Разрешить делегирование новых учетных данных» с помощью политики на удаленном хосте, но он все еще получает ошибку CredSSP
5. Я также попытался настроить политику на удаленном хосте для использования SSL для «Требуется использование определенного уровня безопасности для удаленных подключений (RDP)», и я все равно получил ту же ошибку CredSSP.
6. Что сработало, так это то, что если я попытаюсь выполнить RDP из того же леса на удаленный хост, это позволит подключиться, и я могу подтвердить, что он использует Kerberos для RDP вместо NTLM.
7. Еще одно наблюдение состоит в том, что после того, как на удаленном хосте сработал тот же RDP леса, теперь будет работать соединение RDP между лесами на удаленном хосте с заблокированным входящим NTLM.

Кто-нибудь сталкивался с чем-то подобным раньше? Если да, то нашел ли кто-нибудь решение для RDP между лесами для работы на удаленном хосте с заблокированным входящим NTLM без необходимости предварительной аутентификации на удаленном хосте в том же лесу?

Encryption Oracle Remediation Ошибка является отвлекающим маневром, поскольку в ней используется тот же код ошибки, что и в NTLM is not available ошибке. Если вы не исправили ошибку в течение 3 лет, это, скорее всего, никогда не будет проблемой исправления шифрования Oracle. На самом деле просто он попытался вернуться к NTLM, а политика сказала «нет».

По всей вероятности, проблема в том, что клиент не может найти контроллер домена или связаться с ним для выполнения NLA.

Клиент должен сначала найти домен пользователя (домен А). Оттуда он проверяет подлинность их пароля. Затем он просит получить билет в автомат. Машина не находится в домене пользователя, поэтому она создает реферальный билет туда, где, по ее мнению, находится машина (домен B).

Реферал возвращается клиенту, и клиент пытается найти DC, куда должен направляться реферал (домен B). Клиент отправляет ссылку на домен B и запрашивает билет в автомат. Контроллер домена либо находит машину и выдает для нее билет, либо говорит, что не знает, и предлагает ссылку на другой домен (домен C), и вы повторяете попытку, либо просто не удается сказать, что машина не найдена.

Все это происходит с точки зрения клиента, а не с точки зрения целевой машины. Это происходит еще до того, как клиент отправит сообщение на целевую машину (ish). Вот почему отключение NLA, по-видимому, решает проблему.

Таким образом, есть несколько причин, по которым это происходит:

1. Вы использовали IP-адрес-это прямой сценарий NTLM. Kerberos по умолчанию не использует IP-адреса. Вы можете включить его, но он не будет масштабироваться.
2. Клиент не может взаимодействовать с контроллером домена в домене пользователя (домен A). Проблема с сетью, клиенту нужна прямая связь с контроллером домена, плюс DNS.
3. Клиент не может обмениваться данными a с DC в домене целевой машины (домен B). Все еще проблема с сетью, клиенту нужна прямая связь с контроллером домена, плюс DNS.
4. Вы не указываете правильное полное имя, и контроллер домена пользователя не может понять, к какому лесу он должен относиться. Вы можете включить порядок поиска в лесу, и это, возможно, поможет, или вы можете ввести полное имя машины.

Это не исчерпывающий список, но это наиболее распространенные причины.

Рекомендации:

https://syfuhs.net/windows-and-domain-trusts

https://syfuhs.net/how-authentication-works-when-you-use-remote-desktop