AD и VIPNET Client - не работают групповые политики

[PrAW]

Рабочие станции в защищенной сети, контроллер домена в открытой сети, в итоге при запуске групповые политики не подтягиваются.

В итоге от источника NETLOGON при каждом запуске ошибки в логах:

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

Подозреваю, это происходит по причине того, что в момент запуска доменных служб и прочей групповой политики VipNet еще не разрешил подключение.

Есть какие-то методы обхода?
VipNet Client 4.3, Windows 7x64
 

 

[basid]

Разрешить сохранение пароля в реестре, перезагрузиться, ввести и сохранить пароль пользователя.

[PrAW]

28 минут назад, basid сказал:

Разрешить сохранение пароля в реестре, перезагрузиться, ввести и сохранить пароль пользователя.

Такое уже сделал, включен автовход в Vipnet, запрашивается только пароль учетки от Windows. Ситуация по всей локалке, не единичный комп.
В правилах открытой сети в клиенте все исходящие в сторону локалки и групповых адресов разрешены.

После запуска всё работает нормально, тот же gpupdate.exe успешно подтягивает, проблема на этапе включения.

[zero]

 

4 часа назад, PrAW сказал:

VipNet Client 4.3

 А можно поподробнее с номером билда?

Возможно не резолвится доменное имя DC. Вообще рекомендуется контроллер домена затуннелировать координатором, как и dns-сервера. В документации глава называется: "Использование DNS-серверов на контроллерах домена"

[PrAW]

VipNet Client 4.3 (2.42428)

Туннелировать не получится - мы обособленное подразделение, координатор далеко (за пределами локалки, пинг больше 50мс). Пробрасывать канал туда-обратно для проброса сервера - как-то не очень.

На данный момент у меня в руках только конфигурирование локальных клиентов и управление локальными серверами в открытой сети.

[zero]

Без схемы сети с указанием где проблемные клиенты, где DC, где dns-сервера, обслуживающие сеть и журнала ip-пакетов с любого проблемного узла трудно понять в чём может быть дело.

  Координатор не туннелирует Ваши dns случайно?

[PrAW]

Вот схема сети, журнал пакетов в каком виде нужен?

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

[zero]

54 минуты назад, PrAW сказал:

журнал пакетов в каком виде нужен?

Вы сами посмотрите, нет ли там блокированных пакетов к dns и DC.

[veselov-pv]

Добрый день. Как-то удалось решить данную ошибку?

[azz]

Данная проблема решается(если dns и DC не в туннеле за координатором) либо включением portfast на сетевом оборудовании(на cisco, например) либо использование кэширования учетных данных для входа пользователя в систему.

[PrAW]

 

15 часов назад, veselov-pv сказал:

Добрый день. Как-то удалось решить данную ошибку?

Нет, так и не устраняется.

При свежем запуске смотрю журнал блокированных пакетов:

1. UDP 239.255.255.250:1900 - служба SSDP
2. UDP 224.0.0.252:5355 - Link-Local Multicast Name Resolution
этих событий несколько. Больше заблокированного нет.

12 часов назад, azz сказал:

Данная проблема решается(если dns и DC не в туннеле за координатором), либо включением portfast на сетевом оборудовании(на cisco, например) либо использование кэширования учетных данных для входа пользователя в систему.

DNS, DC в локалке, но не в защищенной сети. Хотя уже экспериментирую - BDC попробовал загнать в защищенную сеть, на DNS повысил приоритеты для него, чтобы его запрашивали в первую очередь - тоже не помогло.

Такое ощущение, что в момент запуска критичной для групповых политик сетевой службы vipnet client всё еще не загрузил правила, но уже блокирует. В принципе, ситуация с portfast может напоминать текущее положение вещей.

К сожалению, часть пользователей сидят в локалке через IP телефоны (транк, два влана - голосовой и пользовательский на каждом порту, через CDP), так что portfast тут не поможет, попробую RPVST.

Опять же, во втором филиале обходятся без IP телефонии, а проблемы те же.

[PrAW]

Я еще лучше спрошу - а есть ли вообще те, у кого Vipnet защищает сеть и у кого нет проблем с NETLOGON / GROUP POLICY и в принципе с AD???

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

8:11:03 Событие 12 Kernel-General (включение)

8:11:22 Служба "Служба профилей пользователей" перешла в состояние Работает.

8:11:22 Служба "Клиент групповой политики" перешла в состояние Работает.
8:11:22 Служба "Служба интерфейса сохранения сети" перешла в состояние Работает.
8:11:22 Служба "Модуль поддержки NetBIOS через TCP/IP" перешла в состояние Работает.
8:11:23 Служба "DHCP-клиент" перешла в состояние Работает.
8:11:23 Служба "DNS-клиент" перешла в состояние Работает.
8:11:23 Служба "Сервис регистрации пользователя ViPNet" перешла в состояние Работает. ( настроено сохранение пароля, автовход. )
8:11:24 Служба "Брандмауэр Windows" перешла в состояние Работает.
8:11:24 Служба "Рабочая станция" перешла в состояние Работает.
8:11:24 Служба "Сетевой вход в систему" перешла в состояние Работает.
8:11:24 Служба "ViPNet Основные сервисы Контроля Приложений." перешла в состояние Работает.
8:11:31 Служба "ViPNet NAT Proxy" перешла в состояние Работает.

8:11:33 Служба "ViPNet Система обновления" перешла в состояние Работает.
8:11:33 Служба "ViPNet Сервер передачи данных." перешла в состояние Работает.

8:11:35 Служба "ViPNet Служба аутентификации пользователя Контроля Приложений." перешла в состояние Работает.

 

и дальше пошло:

 

8:11:36 Событие 1014 DNS-Client

Разрешение имен для имени _ldap._tcp.Default-First-Site._sites.dc._msdcs.***.local истекло после отсутствия ответа от настроенных серверов DNS.

8:11:38 Событие 5719 NETLOGON
Компьютер не может установить безопасный сеанс связи с контроллером домена **** по следующей причине: 
Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть. 
Это может затруднить проверку подлинности. Убедитесь, что компьютер подключен к сети. Если ошибка повторится, обратитесь к администратору домена.  

8:12:31 Событие 1129 GroupPolicy
Ошибка при обработке групповой политики из-за отсутствия сетевого подключения к контроллеру домена. Это может быть временным явлением. Будет создано сообщение об успехе после того, как компьютер удастся подключить к контроллеру домена и групповая политика будет обработана успешно. Если в течение нескольких часов это сообщение не появляется, обратитесь к системному администратору.
Дополнительные сведения 
Если данный компьютер является контроллером указанного домена, он устанавливает безопасный сеанс связи с эмулятором основного контроллера этого домена. В противном случае компьютер устанавливает безопасный сеанс связи с произвольным контроллером данного домена.

 

При этом DNS резолвится с запущенного полностью компьютера вполне нормально:

nslookup -type=srv _ldap._tcp.Default-First-Site._sites.dc._msdcs.***.local
╤хЁтхЁ:  pdc.***.local
Address:  192.168.1.11

_ldap._tcp.Default-First-Site._sites.dc._msdcs.***.local      SRV service location:
          priority       = 1
          weight         = 10
          port           = 389
          svr hostname   = pdc.***.local
pdc.***.local internet address = 192.168.1.10
 

Я уже просто не совсем понимаю, в каком месте зарыта собака. При загрузке без установленного випнета, тот же Windows 7, что и у остальных юзеров  - вполне успешно и радостно всё стартует, отрабатываются login скрипты AD и т.д.

[azz]

Вам поможет одна из двух вещей, о которых написал выше. Можете больше не копать дальше.

[Fedos]

Баг исправлен в более старшей сборке. Протестировано на 4.3.2.46794.