Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
amiga505
Зарегистрирован: 19.01.2006 Сообщения: 85
|
Добавлено: Ср Янв 31 2007 19:36 Заголовок сообщения: Проблема с входом в домен |
|
|
доброго времени суток, уважаемые гуру!
во вверенной мне сети начали твориться странные вещи. собственно тревожит один из серверов. сервер как сервер - ничего серьезного, Windows 2003 Standard SP1 R2, входит в домен, на сервере крутится standby Оракла. недавно было замечено, что на сервер невозможно зайти ремоут десктопом с использованием логина/пароля пользователя АД. локальным администратором (консоль) пускает, а вот при попытке зайти даже домен админом выдает "Не удалось войти в систему из-за следующей ошибки: Отказано в доступе". установить, когда именно и почему началось подобное безобразие не удалось.
во время исследования проблемы в журнале были обнаружены события:
ID:1058
Windows не удалось получить доступ к файлу GPT.INI для объекта групповой политики CN={......},CN=Policies,CN=System,DC=xxx,DC=yyy,DC=zz. Этот файл должен находиться в <\\...\Policies\{...}\gpt.ini>. (Отказано в доступе. ). Обработка групповой политики прекращена.
ID: 1030
Не удалось запросить данный список объектов групповой политики. Проверьте в журнале событий наличие сообщений, описывающих причины сбоя.
при гуглении был найден, в частности, следующий топик http://forum.citforum.ru/viewtopic.php?t=46932&highlight=%CE%F2%EA%E0%E7%E0%ED%EE+++%E4%EE%F1%F2%F3%EF%E5 и прочитана рекомендованная статья на Майкрософте. Насколько я понял, информация в данной статье применима для до-SP1 систем. Я попробовал сделать на проблемном сервере dfsutil /PurgeMupCache - не помогло.
едем дальше - читаю eventid.net
Цитата: | The event was occurring in combination with EventID 1030 from source Userenv and was referencing a GPO that existed on the PDC but not on the other site DC, despite this GPO being created the night before. I manually copied the GPO from the PDC Sysvol folder to the DC’s Sysvol folder. The clients were then able to process GPO updates again.The event was occurring in combination with EventID 1030 from source Userenv and was referencing a GPO that existed on the PDC but not on the other site DC, despite this GPO being created the night before. I manually copied the GPO from the PDC Sysvol folder to the DC’s Sysvol folder. The clients were then able to process GPO updates again. |
проверил - действительно, одна из политик не реплицировалась на один из контроллеров домена. перенес мануально. не помогло - те же грабли.
прочитал статью Майкрософта "Обзор проблем, возникающих из-за отсутствия административных общих папок", проверил шары - все на месте, DSF работает. с DNS все в порядке. все пингуется и резолвится.
к концу дня, окончательно зайдя в тупик, решил попробовать "метод удара ломом в пах" - вывести машину из домена и ввести опять. вывел успешно, убил запись о машине на контроллере. пытаюсь ввести -грабли. на этот раз "При присоединении к домену произошла следующая ошибка: отказано в доступе". я так понимаю эти сообщения суть разные проявления одной проблемы. помогите, друзья, совсем не знаю, что уж и думать. групповые политики никто не трогал, но я бегло просмотрел на всякий случай - вроде все на месте. хотя тут я могу ошибаться. из интересных симптомов можно еще отметить следующее: пытаемся с проблемного сервера зайти на контроллер домена - \\fs01, получаем запрос на пользователя/пароль (что уже странно, так как с других серверов-членов домена на ощедоступные шары этого контроллера заходим без проблем), вводим заведомо правильные данные и получаем сообщение, что ввели неправильное имя пользователя и пароль. еще момент - уже после выведения из домена - если ввести неверные данные (пользователь/пароль), система скажет "Имя пользователя и пароль не опознаны", а не отказано в доступе. вот так |
|
Вернуться к началу |
|
|
bvvtver
Зарегистрирован: 31.01.2007 Сообщения: 122 Откуда: MSK
|
Добавлено: Ср Янв 31 2007 19:57 Заголовок сообщения: |
|
|
http://support.microsoft.com/kb/314494/ru
Здесь есть пара советов. Следует обратить внимание на
Цитата: |
Примечание. Для подключения к общему ресурсу \\Имя_домена_Active Directory\Sysvol необходим клиент DFS.
Примечание. Кроме того, данная проблема может возникать, если группа «Все» была лишена разрешений NTFS на доступ к корневому каталогу. Если группа «Все» действительно не имеет таких прав, присвойте этой группе права на чтение и выполнение только для корневого каталога.
|
Редактирую...
Виноват!! Это для XP. Но пост не удаляю. Может пригодится |
|
Вернуться к началу |
|
|
amiga505
Зарегистрирован: 19.01.2006 Сообщения: 85
|
Добавлено: Ср Янв 31 2007 20:16 Заголовок сообщения: |
|
|
Рапортую:
- DFS работает, параметра DisableDFS не присутствовало, насколько я знаю по-умолчанию должно работать (значение 0)
- права на корень такие же, как и у других не проблемных серверов, а именно - особые разрешения. пробовал явно указывать чтение и выполнение - не помогло. |
|
Вернуться к началу |
|
|
amiga505
Зарегистрирован: 19.01.2006 Сообщения: 85
|
Добавлено: Ср Янв 31 2007 20:21 Заголовок сообщения: |
|
|
ну особые разрешения - это как раз чтение и выполнение только для этой папки (корня) |
|
Вернуться к началу |
|
|
bvvtver
Зарегистрирован: 31.01.2007 Сообщения: 122 Откуда: MSK
|
Добавлено: Ср Янв 31 2007 20:31 Заголовок сообщения: |
|
|
Цитата: | \\fs01, получаем запрос на пользователя/пароль (что уже странно, так как с других серверов-членов домена на ощедоступные шары этого контроллера заходим без проблем), вводим заведомо правильные данные и получаем сообщение, что ввели неправильное имя пользователя и пароль. еще момент - уже после выведения из домена - если ввести неверные данные (пользователь/пароль), система скажет "Имя пользователя и пароль не опознаны", а не отказано в доступе. вот так |
Логин вводится в формате domain\user
? |
|
Вернуться к началу |
|
|
kin
Зарегистрирован: 07.06.2006 Сообщения: 79
|
Добавлено: Ср Янв 31 2007 20:53 Заголовок сообщения: |
|
|
Может чем поможет...
У меня была такая же беда (в смысле ошибка таже самая"...Windows не удалось получить доступ к файлу GPT.INI для объекта групповой политики CN={......},CN=Policies,CN=System,DC=xxx,DC=yyy,DC=zz. Этот файл должен находиться в <\\...\Policies\{...}\gpt.ini>. (Отказано в доступе. ). Обработка групповой политики прекращена.") попутно проскакивало сообщение о невозможности зарегистрировать имя в DNS, причем выполнение ipconfig/registerdns тоже не проходило.
Дело было в следующем, по какой-то, одному ПК известно какой причине, он не мог обновить IP адрес от DHCP-сервера (ID предупреждения 1003). Получалось что-то, физически он в домене, логически - нет.
После ручного освобождения аренды и перезагрузки процесс пошел...
можно еще покопаться в DNS (по-моему есть смысл...) и службах.... |
|
Вернуться к началу |
|
|
amiga505
Зарегистрирован: 19.01.2006 Сообщения: 85
|
Добавлено: Чт Фев 01 2007 10:47 Заголовок сообщения: |
|
|
2bvvtver: да, логин вводится в формате domain\user
2kin: в ДНС и службах копался - в службах как по мне все, что должно работать - работает. в ДНС сервер присутствует, ipconfig /flushdns ipconfig /registerindns проходит, но на ситуацию не влияет. в DHCP у сервера резервирование, обновление параметров ip проходит успешно - так что дело и не в этом, похоже. что ж это за зад такой... |
|
Вернуться к началу |
|
|
amiga505
Зарегистрирован: 19.01.2006 Сообщения: 85
|
Добавлено: Чт Фев 01 2007 13:02 Заголовок сообщения: |
|
|
фантастика. не входит в домен и все тут. отказано в доступе. и ничего в логах ни на самом проблемном сервере, ни на контроллерах домена. |
|
Вернуться к началу |
|
|
amiga505
Зарегистрирован: 19.01.2006 Сообщения: 85
|
Добавлено: Чт Фев 01 2007 18:31 Заголовок сообщения: |
|
|
починил.
на мысль натолкнула следующая статья: http://support.microsoft.com/kb/839499, которая, в свою очередь, была найдена при разборе сведений от dcdiag на контроллере домена. проблема оказалась в несогласованности настроек политик на контроллере и проблемном сервере, а именно политик:
локальные политики на контроллере:
- Microsoft network server: Digitally sign communications (always). Включено
- Microsoft network server: Digitally sign communications (if client agrees). Включено
локальные политики на проблемном сервере:
- Microsoft network client: Digitally sign communications (always). Отключено
- Microsoft network client: Digitally sign communications (if client agrees). Отключено
так что проблема оказалась-таки в политиках. но вот почему такое произошло, мне пока не понятно. буду разбираться. |
|
Вернуться к началу |
|
|
|