none
Репликация контроллеров, после долгого отсутствия связи RRS feed

  • Вопрос

  • Добрый день,

    Описание ситуации: в организации с множеством домен контроллеров, с одной из площадок пропала связь. С периода 18.07.2014 - по нынешнее время, репликация с двумя контроллерами домена не происходила. Сейчас, связь восстановлена, в журналах репликации возникли ошибки. Репликация осуществляется с использованием DFS.

    Ошибки:

    В журнале репликации DFS:

    Служба репликации DFS обнаружила ошибку в подключении к партнеру для группы репликации Domain System Volume. 

    Дополнительные сведения: 
    Ошибка: 1825 (Ошибка в пакете безопасности.) 
    Идентификатор подключения: F29C3738-AF90-4CE8-BFC0-48C1B36A5819 
    Идентификатор группы репликации: 72D953C6-FD0A-4DA0-8D91-2C0B144E45A1

    В системном журнале:

    Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера SERVERNAME$. Использовалось конечное имя DNS\SERVERNAME$. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен отличен от домена клиента, проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

    Такая ошибка возникает при попытке получить доступ к любому сетевому ресурсу проблемных серверов.

    Время хранения удаленных объектов AD установлен по умолчанию 180 дней.

    Решения не нашел, может кто то сталкивался с подобными обстоятельствами. Не хотелось бы, понижать роли контроллеров домена на проблемных серверах и разворачивать их снова. Ведь будут утрачены объекты созданные за этот период, их относительно всего домена не много, но они есть.

    Прошу помогите, какие рекомендации Microsoft на этот счет. Заранее благодарен.


    15 октября 2014 г. 9:54

Ответы

  • Здесь смотрели? 

    Версия серверов какая?


    Я не волшебник, я только учусь MCTS Мнения, высказанные здесь, являются отражение моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий Мой Блог http://rutechnet.azurewebsites.net

    • Помечено в качестве ответа Denis.Pasternak 15 октября 2014 г. 16:36
    15 октября 2014 г. 10:33
    Модератор
  • Хочу попробовать сбросить пароль машины

    http://networkadminkb.com/KB/a268/how-to-reset-domain-controller-computer-account.aspx

    о результатах отпишусь вечером


    • Изменено Denis.Pasternak 15 октября 2014 г. 11:49
    • Помечено в качестве ответа Denis.Pasternak 15 октября 2014 г. 16:35
    15 октября 2014 г. 11:47
  • Добрый день.

    Посмотрите похожую на вашу тему 

    В кратце

    (Цитирую)

    Есть 2 способа решения

    1.Радикальный

    Суть радикального метода состоит в том чтобы принудительно понизить в роли контроллер домена командой dcpromo /forceremoval
    Данная команда принудительно выполнит понижение в роли контроллера домена до уровня рядового сервера. После понижения роли выполняется  удаление всех ссылок в домене на этот контроллер. Далее производится  включение сервера в состав домена, и выполнение обратного процесса, т.е. повышение сервера до уровня контроллера домена.

    2.Не радикальный

    Не радикальный способ состоит в том, чтобы возобновить процесс репликации между контроллерами без каких либо радикальных действий по удалению ролей и т.д. Процесс восстановления репликации между контроллерами домена хорошо описан в разделе Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)


    Я не волшебник, я только учусь MCTS Мнения, высказанные здесь, являются отражение моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий Мой Блог http://rutechnet.azurewebsites.net

    IMHO это - не тот случай: время жизни захороненных объектов с момента обрыва репликации ещё не истекло. Ошибка KRB_AP_ERR_MODIFIED может иметь три источника: пароль компьютера, запомненный на нём самом, не совпадает с его паролем на КД, где получен билет, разрешение имен даёт адрес не того сервера и SPN сервера принадлежит другому хосту.

    Наиболее вероятен в данном случае первый вариант, т.к. пароль КД площадки должен был более двух раз меняться на нём самом (пароль меняется раз в месяц), а другие КД хранят всего две копии пароля - текущий и предыдущий. В этом случае можно обойтись без принудительного понижения, а просто сбрось пароль контроллера домена площадки.

    Процедура сброса пароля КД описана в статье 837513 MS KB (см. раздел "Method 6")

    Но оба остальных варианта тоже можно проверить (особенно, если сброс пароля не помог) - и что имя КД и его записи SRV разрешаются в нужный IP (командами ping, nltest /dnsgetdc) , и что SPN назначен правильно (проверяется командой setspn -L).

    PS Процедура сброса пароля в той статье, ссылка на которую в вашем предыдущем посте - та же самая, что и в MS KB, с тем же успехом можете руководствоваться ей.


    Слава России!


    • Изменено M.V.V. _ 15 октября 2014 г. 12:32
    • Помечено в качестве ответа Denis.Pasternak 15 октября 2014 г. 16:35
    15 октября 2014 г. 12:30
  • В вашем случае нужно остановить KDC на обоих контроллерах на площадке. По умолчанию при входе вы проходите проверку подлинности на КД в своём сайте, то есть, при остановленной KDC на самом КД - на втором КД, а он содержит старые, неактуальные пароли учетных записей серверов центрального офиса.

    PS Я бы вообще не запускал KDC на проблемных КД до момента успешной межсайтовой репликации.


    Слава России!


    • Изменено M.V.V. _ 15 октября 2014 г. 13:40
    • Помечено в качестве ответа Denis.Pasternak 15 октября 2014 г. 16:35
    15 октября 2014 г. 13:37

Все ответы

  •  Результат repadmin /showrepl - такая ошибка, относительно всех серверов :

      SITE\SERVER через  RPC
            DSA - GUID объекта: 5f01bea8-b74b-4876-b475-be712a191431
            Последняя попытка @ 2014-10-15 13:00:35 завершена с ошибкой, результат -
    2146893022 (0x80090322):
                Главное конечное имя неверно.
            7579 последовательных ошибок.
            Последний успех @ 2014-07-28 14:15:41.

           SITE\SERVER через  RPC
            DSA - GUID объекта: 436c1016-4363-47b5-a34d-2e5b3e2b0038
            Последняя попытка @ 2014-10-15 13:00:35 завершена с ошибкой, результат 5
     (0x5):
                Отказано в доступе.
            7579 последовательных ошибок.
            Последний успех @ 2014-07-28 14:15:42.

           SITE\SERVER через  RPC
            DSA - GUID объекта: b677e990-f7cb-4daf-8f87-16602bc119e0
            Последняя попытка @ 2014-10-15 13:00:35 завершена с ошибкой, результат -
    2146893022 (0x80090322):
                Главное конечное имя неверно.
            7579 последовательных ошибок.
            Последний успех @ 2014-07-28 14:15:43.

           SITE\SERVER через  RPC
            DSA - GUID объекта: 5afbb9b1-7558-4f97-b941-84e1845b48ce
            Последняя попытка @ 2014-10-15 13:00:35 завершена с ошибкой, результат -
    2146893022 (0x80090322):
                Главное конечное имя неверно.
            7579 последовательных ошибок.
            Последний успех @ 2014-07-28 14:15:43.

        
    15 октября 2014 г. 10:16
  • 2.Не радикальный

    Не радикальный способ состоит в том, чтобы возобновить процесс репликации между контроллерами без каких либо радикальных действий по удалению ролей и т.д. Процесс восстановления репликации между контроллерами домена хорошо описан в разделе Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)


    Я не волшебник, я только учусь MCTS Мнения, высказанные здесь, являются отражение моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий Мой Блог http://rutechnet.azurewebsites.net

    Благодарю, на сколько я понимаю не радикальный метод заключается в принудительной репликации и скорее всего привет к удалению не существующих объектов. Беспокоит сохранность объектов или быть может перенос объектов со старого контроллера, с последующим восстановление на  "вновь созданной контроллере" :) если такое возможно.

    15 октября 2014 г. 10:34
  • Здесь смотрели? 

    Версия серверов какая?


    Я не волшебник, я только учусь MCTS Мнения, высказанные здесь, являются отражение моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий Мой Блог http://rutechnet.azurewebsites.net

    Версия операционных систем Windows 2008 R2, режим работы леса 2008
    15 октября 2014 г. 10:35
  • Хочу попробовать сбросить пароль машины

    http://networkadminkb.com/KB/a268/how-to-reset-domain-controller-computer-account.aspx

    о результатах отпишусь вечером


    • Изменено Denis.Pasternak 15 октября 2014 г. 11:49
    • Помечено в качестве ответа Denis.Pasternak 15 октября 2014 г. 16:35
    15 октября 2014 г. 11:47
  • Добрый день.

    Посмотрите похожую на вашу тему 

    В кратце

    (Цитирую)

    Есть 2 способа решения

    1.Радикальный

    Суть радикального метода состоит в том чтобы принудительно понизить в роли контроллер домена командой dcpromo /forceremoval
    Данная команда принудительно выполнит понижение в роли контроллера домена до уровня рядового сервера. После понижения роли выполняется  удаление всех ссылок в домене на этот контроллер. Далее производится  включение сервера в состав домена, и выполнение обратного процесса, т.е. повышение сервера до уровня контроллера домена.

    2.Не радикальный

    Не радикальный способ состоит в том, чтобы возобновить процесс репликации между контроллерами без каких либо радикальных действий по удалению ролей и т.д. Процесс восстановления репликации между контроллерами домена хорошо описан в разделе Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)


    Я не волшебник, я только учусь MCTS Мнения, высказанные здесь, являются отражение моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий Мой Блог http://rutechnet.azurewebsites.net

    IMHO это - не тот случай: время жизни захороненных объектов с момента обрыва репликации ещё не истекло. Ошибка KRB_AP_ERR_MODIFIED может иметь три источника: пароль компьютера, запомненный на нём самом, не совпадает с его паролем на КД, где получен билет, разрешение имен даёт адрес не того сервера и SPN сервера принадлежит другому хосту.

    Наиболее вероятен в данном случае первый вариант, т.к. пароль КД площадки должен был более двух раз меняться на нём самом (пароль меняется раз в месяц), а другие КД хранят всего две копии пароля - текущий и предыдущий. В этом случае можно обойтись без принудительного понижения, а просто сбрось пароль контроллера домена площадки.

    Процедура сброса пароля КД описана в статье 837513 MS KB (см. раздел "Method 6")

    Но оба остальных варианта тоже можно проверить (особенно, если сброс пароля не помог) - и что имя КД и его записи SRV разрешаются в нужный IP (командами ping, nltest /dnsgetdc) , и что SPN назначен правильно (проверяется командой setspn -L).

    PS Процедура сброса пароля в той статье, ссылка на которую в вашем предыдущем посте - та же самая, что и в MS KB, с тем же успехом можете руководствоваться ей.


    Слава России!


    • Изменено M.V.V. _ 15 октября 2014 г. 12:32
    • Помечено в качестве ответа Denis.Pasternak 15 октября 2014 г. 16:35
    15 октября 2014 г. 12:30
  • Хочу попробовать сбросить пароль машины

    http://networkadminkb.com/KB/a268/how-to-reset-domain-controller-computer-account.aspx

    о результатах отпишусь вечером


    netdom resetpwd /s:имя_рабочего_контроллера /ud:домен\администратор_домена /pd:пароль

    Не удалось сбросить пароль учетной записи локального компьютера.

    Вход в систему не произведен: конечная учетная запись указана неверно.

    Не удалось выполнить команду.

    Если выполняю команду и в качестве сервера указываю, второй сервер этого же сайта (который давно не реплицировался, на одной площадке). То команда выполняется успешно.

    Если указать в качестве сервера IP адрес, рабочего сервера с запущенной службой KDC - то команда выполняется успешно.

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

    НО если обратиться по IP, - пускает без потребности ввода логина или пароля.



    15 октября 2014 г. 13:04
  • В вашем случае нужно остановить KDC на обоих контроллерах на площадке. По умолчанию при входе вы проходите проверку подлинности на КД в своём сайте, то есть, при остановленной KDC на самом КД - на втором КД, а он содержит старые, неактуальные пароли учетных записей серверов центрального офиса.

    PS Я бы вообще не запускал KDC на проблемных КД до момента успешной межсайтовой репликации.


    Слава России!


    • Изменено M.V.V. _ 15 октября 2014 г. 13:40
    • Помечено в качестве ответа Denis.Pasternak 15 октября 2014 г. 16:35
    15 октября 2014 г. 13:37
  • В вашем случае нужно остановить KDC на обоих контроллерах на площадке. По умолчанию при входе вы проходите проверку подлинности на КД в своём сайте, то есть, при остановленной KDC на самом КД - на втором КД, а он содержит старые, неактуальные пароли учетных записей серверов центрального офиса.

    PS Я бы вообще не запускал KDC на проблемных КД до момента успешной межсайтовой репликации.


    Слава России!


    Ух, спасибо! Откуда вы только знаете, все :) посмотрю, что реплицируется

    Спасибо, Вам M.V.V и Вам Антон.

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


    15 октября 2014 г. 15:37