Статус: Новичок
Группы: Участники
Зарегистрирован: 04.07.2018(UTC) Сообщений: 4 Откуда: Чебоксары Сказал(а) «Спасибо»: 1 раз
|
Всем привет. Если кто то сталкивался с такой проблемой, подскажите как решить. Суть вот в чём. При открытии и просмотре свойств сертификатов очень долгие висы. Компы на которых такое происходит входят в домен. Стоит отрубить сетку и всё начинает летать. Сертификаты и их свойства отзываются мгновенно. Тестил разными способами и в крипто про и в ie и через оснастку работы с сертификатами.
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,390 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 37 раз Поблагодарили: 714 раз в 619 постах
|
Посмотрите procmon'ом сетевые запросы. |
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 04.07.2018(UTC) Сообщений: 4 Откуда: Чебоксары Сказал(а) «Спасибо»: 1 раз
|
Хорошо, попробую. А вообще не в курсе на контроллере домена есть какая то проверка корректности сертификатов? И воообще можно как то отключить эту сетевую проверку? Спасибо.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 04.07.2018(UTC) Сообщений: 4 Откуда: Чебоксары Сказал(а) «Спасибо»: 1 раз
|
Запустил procmon, настроил фильтр на mmc.exe, запустил certmgr.mmc, открыл только сетевую активность, по нулям, открытие списка сертификатов из личного (2 всего) 2 минуты, открытие свойства одного из сертификатов - 1.15 минуты, переход по вкладкам сертификата (общие, состав, путь сертификации) тоже около 20 секунд. Что за ерунда. И это при отсутствии сетевых обращений. Зато стоило выдернуть сетку из компа, все стало работать мгновенно... Вся проблема в том, что если пользователи подписывают документы ЭЦП, им приходиться ждать минут по 5, пока откроется список сертификатов из хранилища...
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 395 раз в 366 постах
|
Автор: Игорь67 Хорошо, попробую. А вообще не в курсе на контроллере домена есть какая то проверка корректности сертификатов? И воообще можно как то отключить эту сетевую проверку? Спасибо. По симптомам похоже что зачем-то ищется какой-то компьютер (контроллер домена? например, в домене может быть свой УЦ, сертификаты которого разворачиватся через групповую политику) и не находится (либо отказывает в подключении несколько раз). Наверно не нужно ограничивать фильтр на mmc.exe, так как соединение может идти от какой-то из системных служб (групповая политика?). Ну и то что компьютер не находится это тоже проблема - я бы еще и WireShark помониторил сеть на проблемном компьютере на предмет ошибок разрешения и нахождения. Ничего с контроллером домена не делали перед появлением тормозов? Хорошо бы провести диагностику проблем на контроллере - что никакие роли не ведут на неподключенные к сети компьютеры и записи DNS для домена в норме. Посмотрите какие IP для контроллера домена возвращаются из DNS, не вылетел ли компьютер на котором тормоза из домена?
У меня контроллер домена плохо находится при подключении клиентов удаленного доступа из-за что в диапазон локальной сети с учетом маски попадает адрес сервера удаленного доступа, развернутого на контроллере домена - при этом он регистрируется в DNS и компьютеры локальной сети получают 2 адреса - правильный 192.168.x.2 и неправильный 192.168.x.106. Из-за специфики DNS при возврате нескольких адресов обращения делятся пополам и половина компьютеров пытается соединиться по неправильному адресу.
Соответственно, некоторые компьютеры пропускают срок замены пароля учетной записи компьютера. Потом снова получают правильный адрес, но контроллер им отказывает в подключении из-за неверного пароля и групповая политика не срабатывает.
Отредактировано пользователем 23 августа 2018 г. 8:12:55(UTC)
| Причина: Не указана
|
1 пользователь поблагодарил two_oceans за этот пост.
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 04.07.2018(UTC) Сообщений: 4 Откуда: Чебоксары Сказал(а) «Спасибо»: 1 раз
|
Всем спасибо за варианты решения проблемки!!! Начал копать начиная с сервака (стоит Server 2012 поднят AD ну и DNS сервер разумеется) В качестве DHCP сервера выступает роутер МикроТик(192.168.0.2), и в качестве DNS сервера на клиентах в настройках сетевого интерфейса был указан (ДУРОДОМ, спасибо предыдущему сисадмину) ОН ЖЕ!!! Т.е. и внешнюю переадресацию доменных имен и локальных выполнял роутер и доменные адреса в локальной сети просто не транслировались в ip-ники. Решение оказалось простым проосто правильно настроил на серваке и роутере DNS сервер. На всех клиентах в сетевом интерфейсе прописал в качестве основного DNS сервера ip своего сервера и убрал альтернативные. ВСЁ, Больше проблемы нет, всё просто летает!!!
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 395 раз в 366 постах
|
Рад что помогло. Теоретически такую ситуацию (роутер как главный DNS, сервер домена как дополнительный) можно решить при помощи условной пересылки (если конечно прошивка конкретного роутера такую функцию поддерживает). Полагаю МикроТики должны поддерживать.
На роутере настроить пересылку запросов по определенным доменам на локальный сервер. После настройки условной пересылки не будет необходимости менять адрес DNS на локальный сервер. При нахождении адреса с доменом локальной сети запрос будет пересылаться от роутера к локальному серверу, который разрешит локальный домен корректно. А если адрес других доменов - запрос от роутера направится интернет-провайдеру и также разрешится корректно. В этом случае на сервер попадают только запросы с локальными адресами и нагрузка на сервер меньше. При работах на локальном сервере отвалятся только локальные адреса, что частично можно скомпенсировать настройкой роутера. Этот вариант я хочу применить у себя, но пока МикроТика нет.
Вариант 2: поднять DHCP на локальном сервере и указать в нем DNS локального сервера (тогда не надо бегать по всем клиентам прописывая вручную DNS), а DHCP роутера переключить в режим направления запросов к локальному серверу (этот вариант преимущественно нужен если есть беспроводной сегмент сети) или вообще отключить (если все проводное - 2 DHCP будут конфликтовать). В этом случае запрос DNS будет сначала приходить на локальный сервер и локальные адреса разрешатся там, а все остальные пойдут через роутер к интернет-провайдеру. В этом случае нагрузка на сервер будет больше, так как на него придут вообще все запросы DNS. Также интернет будет недоступен при технических работах на сервере. У нас сейчас такой вариант и любые работы как острый нож для пользователей.
Вариант 3: наоборот сделать все записи DNS для домена на роутере (большинство "домашних" роутеров на это неспособны, но с МикроТиком можно попробовать) - если у роутера получают адреса все клиенты (или большинство), то надо только правильно настроить формирование DNS записей о них (добавление к имени узла суффикса локального домена) и добавить ВСЕ нужные записи о контроллере домена (у которого как правило адрес статический и потому он не попадает в DHCP клиенты роутера). Тут надо заменить что записей о контроллере домена достаточно много, не только запись A, но и куча записей SRV, важно перенести ВСЕ. В этом случае можно будет погасить DHCP и DNS на сервере и соответственно обеспечить корректную работу DNS даже если на сервере технические работы.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close