Дело не в файле hosts — он ломает общие ресурсы, доступ к которым осуществляется через имя хоста, отличное от «настоящего» имени сервера. Ваш результат нормальный, так как это буквально вся цель объекта групповой политики.
Рассматриваемый объект групповой политики очень похож на применение TLS SNI на некоторых веб-серверах: клиент заявляет: «Я здесь, чтобы поговорить с сервером SRV01.EXAMPLE.COM», и если сервер не распознает это имя как один из виртуальных хостов он служит, он полностью отвергает клиента. Итак, здесь, если клиент заявляет, что хочет поговорить с одним из ваших псевдонимов /etc/hosts, но сервер не знает псевдоним, он отклоняет клиента.
Kerberos уже имеет встроенную подобную реализацию (поэтому вам необходимо зарегистрировать имена участников-служб для псевдонимов, используя setspn), но GPO делает его более строгим и распространяет ту же защиту и на NTLM.
(Как уже упоминалось на странице Docs, это должно предотвратить ретрансляционные атаки NTLM, когда злонамеренный сервер A принимает аутентификацию NTLM, а затем пересылает точно такие же пакеты NTLM на реальный сервер B — атака будет предотвращена, поскольку сервер B см. «Я хочу поговорить с сервером А» от клиента.)
Это является по-прежнему можно использовать псевдонимы хостов, но для этого требуется постоянно увеличивающееся количество ручек реестра. Официальный метод заключается в использовании netdom имя_компьютера REALHOST /add:THEALIAS как в этот пост TechNet, и я нашел сообщения в блогах, в которых утверждается, что достаточно сделать псевдонимы пригодными для использования даже со строгой проверкой SPN, но на самом деле кажется, что это нет вполне достаточно — есть по крайней мере одно, если не два значения реестра, которые он забывает трогать.
NETDOM-регистры Керберос SPN для псевдонима в AD, что позволяет получать для них билеты Kerberos, аналогично ручному вводу этих двух команд:
setspn -S HOST/THEALIAS REALHOST$
setspn -S HOST/thealias.example.com REALHOST$
Это необходимо для Kerberos, и нет никакого оправдания тому, чтобы не использовать Kerberos в среде AD, поэтому независимо от того, решите ли вы использовать NETDOM или будете делать это вручную, вам все равно следует зарегистрировать псевдонимы SPN.
(Технически SMB использует участников «cifs/», но в AD они неявно присутствуют всякий раз, когда регистрируется имя участника-службы «host/».)
Затем NETDOM добавляет псевдоним в два места реестра сервера, в результате чего сервер регистрирует свои дополнительные имена в AD DNS, а также объявляет их через браузер NetBIOS:
Дорожка: HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Имя: Альтернативные имена компьютеров
Тип: REG_MULTI_SZ
Данные: {thealias.example.com}
Дорожка: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Имя: Необязательные имена
Тип: REG_MULTI_SZ
Данные: {ТЕАЛИИ}
Похоже, они не влияют на аутентификацию (даже Kerberos), поэтому я считаю, что оба они совершенно необязательны, если вы используете /etc/hosts или создаете записи CNAME вручную в DNS.
Еще один параметр, который NETDOM не создать, но я нашел необходимым для доступа к псевдонимам изнутри самого сервера:
- Дорожка:
HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Имя: BackConnectionHostNames
Тип: REG_MULTI_SZ
Данные: {thealias.example.com}
Этот нужен только для «петлевых» соединений, поэтому, возможно, в целом не обязательно, но, по крайней мере, в моем случае сервер сделал необходимо подключиться к собственному псевдониму, поэтому настройка была обязательной.
Наконец, я обнаружил, что функция «Проверка целевого имени участника-службы» свой собственный список разрешенных имен, которые необходимо обновить вручную — в противном случае псевдонимы будут отклонены из-за строгой проверки SPN даже при наличии всех вышеперечисленных настроек:
- Дорожка:
HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Имя: Срвалловедсервернамес
Тип: REG_MULTI_SZ
Данные: {ТЕАЛИИ, thealias.example.com}
Вы захотите указать оба коротких имени и Полные доменные имена каждого псевдонима — из моих экспериментов перечисление одного не подразумевает автоматически другого.
С зарегистрированными именами участников-служб Kerberos и Срвалловедсервернамес установленное значение реестра, псевдонимы должны, наконец, работать правильно даже при строгой проверке цели.
