none
Security-Kerberos 4 RRS feed

  • Вопрос

  • На некоторых серверах Windows Server 2012 (а также и на Windows Server 2008) стал замечать, что регистрируется такая ошибка.

    Источник: Security-Kerberos

    ID: 4

    Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера pc-mak1$. Использовалось конечное имя cifs/PC-DRIVERS3.sfh.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (SFH.LOCAL) отличен от домена клиента (SFH.LOCAL), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

    Ошибка регистрируется на сервере, который сам не образается ни к pc-makl1, ни к pc-drivers3.

    В чем может быть проблема?

    9 марта 2016 г. 12:13

Ответы

  • Для резервного копирования используется Veritas Backup Exec 15.0.3.

    А ответ на команды setspn (запускал на контроллере домена) такой:

    C:\Users\Administrator>setspn -L pc-mak1.sfh.local
    FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
    нием 0x00000525
    Не удалось найти учетную запись pc-mak1.sfh.local

    C:\Users\Administrator>setspn -L pc-drivers3.sfh.local
    FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
    нием 0x00000525
    Не удалось найти учетную запись pc-drivers3.sfh.local

    Setspn принимает в качестве параметра имя компьютера, а не его FQDN. Поэтому команда должна быть:

    setspn -L pc-mak1

    и т.п. 

    BackupExec ЕМНИП может быть настроен так, чтобы искать в сети компьютеры, куда он бы поставил своего агента. Подробностей сейчас не помню - давно им не пользовался.


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


    • Изменено M.V.V. _ 17 марта 2016 г. 12:10
    • Помечено в качестве ответа MikAndr 23 марта 2016 г. 8:13
    17 марта 2016 г. 12:07

Все ответы

  • тут рекомендуют удалить учётную запись компьютера, если она не используется.
    9 марта 2016 г. 12:34
    Модератор
  • В чем может быть проблема?

    Проблема, скорее всего, в том, что имя PC-DRIVERS3.sfh.local разрешается в IP-адрес сервера PC-mak1. Почему это происходит и что с этим делать- смотреть содержимое зоны DNS и удалить ненужные записи. А почему и зачем сервер, на котором зафиксирована ошибка, у вас таки обращается к pc-drivers3.sfh.local  по протоколу  SMB, то это вам надо разбираться отдельно.


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

    9 марта 2016 г. 12:52
  • Все учетные записи компьютеров используются в сети.
    10 марта 2016 г. 8:52
  • Посмотрели записи DNS. Нет никакого наложения в адресации.

    10 марта 2016 г. 8:56
  • В файл hosts ещё загляните на всякий случай.


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

    10 марта 2016 г. 11:43
  • Файлы hosts у нас не используются.

    11 марта 2016 г. 7:57
  • В чем может быть проблема?

    SPNы неправильно настроены, удали из свойств компьютера PC-DRIVERS3.sfh.local в AD из атрибута servicePrincipalName строчку  cifs/PC-DRIVERS3.sfh.local, можно через команду

    setspn -D cifs/PC-DRIVERS3.sfh.local PC-DRIVERS3

    но лучше понять как прописываются SPN и как работает Kerberos, пример на основе Sharepoint

    15 марта 2016 г. 12:06
  • Пожалуйста, не надо неправильных советов

    Во-первых,  cifs/PC-DRIVERS3.sfh.local - это вполне правильно настроенный SPN для компьютера PC-DRIVERS3 с работающей службой файлового сервера (а в Windows  она работает почти всегда). Во-вторых, конкретного этого SPN у учётной записи компьютера может просто не быть - в этом случае будет использовано отображение на обобщённую запись с классом службы HOST: HOST/PC-DRIVERS3.sfh.local

    Но вот одну мысль, которую я забыл проверить, вы мне напомнили правильно: надо посмотреть, кому в домене назначен SPN cifs/PC-DRIVERS3.sfh.local  - командами

    setspn -Q cifs/PC-DRIVERS3.sfh.local

    setspn -Q HOST/PC-DRIVERS3.sfh.local

    Если это - не PC-DRIVERS3, то надо разобраться - зачем и почему.


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

    15 марта 2016 г. 12:33
  • Вроде бы ответ правильный:

    C:\Users\Administrator>setspn -Q cifs/PC-DRIVERS3.sfh.local
    Проверка домена DC=sfh,DC=local

    Такое SPN не найдено.

    C:\Users\Administrator>setspn -Q HOST/PC-DRIVERS3.sfh.local
    Проверка домена DC=sfh,DC=local
    CN=PC-DRIVERS3,OU=Computers,OU=Отдельные пользователи,DC=sfh,DC=local
            HOST/PC-DRIVERS3
            HOST/pc-drivers3.sfh.local

    Найдено существующее SPN.

    Соответствует доменной учетной записи компьютера.

    Вообще я такие ошибки отмечаю на сервере резервного копирования. Только на нем нет заданий резервного копирования этих рабочих станций. И еще, сами имена рабочих станций меняются от сообщения к сообщению. Например, два последних сообщения об ошибке:

    Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера pc-litvishko3$. Использовалось целевое имя cifs/PC-LITVISHKO2.sfh.local. Это означает, что целевому серверу не удалось расшифровать билет, предоставленный клиентом. Это возможно, когда целевое SPN-имя зарегистрировано на учетную запись, отличную от учетной записи, используемой конечной службой. Убедитесь, что целевое SPN-имя зарегистрировано только на учетную запись, используемую сервером. Эта ошибка также может возникать, если пароль целевой службы отличается от пароля, заданного для нее в центре распространения ключей Kerberos. Убедитесь, что пароли в службе на сервере и в центре распространения ключей совпадают. Если имя сервера задано не полностью и конечный домен (SFH.LOCAL) отличается от домена клиента (SFH.LOCAL), проверьте эти два домена на наличие учетных записей серверов с одинаковыми именами или используйте для идентификации сервера полное имя.

    Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера pc-semenovmv1$. Использовалось целевое имя cifs/PC-ELEFERENKO2.sfh.local. Это означает, что целевому серверу не удалось расшифровать билет, предоставленный клиентом. Это возможно, когда целевое SPN-имя зарегистрировано на учетную запись, отличную от учетной записи, используемой конечной службой. Убедитесь, что целевое SPN-имя зарегистрировано только на учетную запись, используемую сервером. Эта ошибка также может возникать, если пароль целевой службы отличается от пароля, заданного для нее в центре распространения ключей Kerberos. Убедитесь, что пароли в службе на сервере и в центре распространения ключей совпадают. Если имя сервера задано не полностью и конечный домен (SFH.LOCAL) отличается от домена клиента (SFH.LOCAL), проверьте эти два домена на наличие учетных записей серверов с одинаковыми именами или используйте для идентификации сервера полное имя.

    Мне не понятно, почему эти ошибки регистрирует сервер, который не обращается к этим компьютерам.

    15 марта 2016 г. 13:31
  • Да, ответ правильный.

    Все признаки говорят за то, что у вас на сервере резервного копирования время от времени возникает ошибка разрешения имён, возможно - из-за того, что после изменения IP-адресов компьютеров старые записи A некоторое время остаются активными.

    А почему у вас сервер резервного копирования обращается к этим компьютерам - это надо разбираться отдельно. Обычно этим занимаются программы инвентаризации клиентов (такие, как SCCM), корпоративные антивирусы и т.п. программы, взаимодействующие со своими агентами на клиентах.

    Программа резервного копирования тоже может этим заниматься - например, если она настроена на автоматическую установку своих клиентов на рабочие станции.


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

    15 марта 2016 г. 13:44
  • Но вот одну мысль, которую я забыл проверить, вы мне напомнили правильно: надо посмотреть, кому в домене назначен SPN cifs/PC-DRIVERS3.sfh.local  - командами

    setspn -Q cifs/PC-DRIVERS3.sfh.local

    setspn -Q HOST/PC-DRIVERS3.sfh.local

    Поэтому и даю не правильные советы, нужно знать что за служба/приложение использует этот SPN

    Какое ПО используется для резервного копирования? посмотреть что прописано на этой учетной записи

    setspn -L xxx.sfh.local

    15 марта 2016 г. 13:50
  • Ну, со службой, которая использует этот SPN для поиска сервера, всё совершенно ясно: это - редиректор, служба "Рабочая станция"(lanmanworkstation) и связанные с ней драйверы клиентской части протокола SMB.

    SPN, назначенные учётной записи, под которой выполняется служба резервного копирования, несущественны, и их вообще может не быть - для клиента они необязательны, для идентификации он вполне может использовать User Principal Name.

    Но мысль найти ту службу, которая пытается обращаться к клиентским компьютерам по SMB - она правильная.


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

    15 марта 2016 г. 14:43
  • Для резервного копирования используется Veritas Backup Exec 15.0.3.

    А ответ на команды setspn (запускал на контроллере домена) такой:

    C:\Users\Administrator>setspn -L pc-mak1.sfh.local
    FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
    нием 0x00000525
    Не удалось найти учетную запись pc-mak1.sfh.local

    C:\Users\Administrator>setspn -L pc-drivers3.sfh.local
    FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
    нием 0x00000525
    Не удалось найти учетную запись pc-drivers3.sfh.local

    16 марта 2016 г. 13:09
  • а эти учетки в домене включены?
    17 марта 2016 г. 4:39
  • Для резервного копирования используется Veritas Backup Exec 15.0.3.

    А ответ на команды setspn (запускал на контроллере домена) такой:

    C:\Users\Administrator>setspn -L pc-mak1.sfh.local
    FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
    нием 0x00000525
    Не удалось найти учетную запись pc-mak1.sfh.local

    C:\Users\Administrator>setspn -L pc-drivers3.sfh.local
    FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
    нием 0x00000525
    Не удалось найти учетную запись pc-drivers3.sfh.local

    Setspn принимает в качестве параметра имя компьютера, а не его FQDN. Поэтому команда должна быть:

    setspn -L pc-mak1

    и т.п. 

    BackupExec ЕМНИП может быть настроен так, чтобы искать в сети компьютеры, куда он бы поставил своего агента. Подробностей сейчас не помню - давно им не пользовался.


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


    • Изменено M.V.V. _ 17 марта 2016 г. 12:10
    • Помечено в качестве ответа MikAndr 23 марта 2016 г. 8:13
    17 марта 2016 г. 12:07
  • Да, действительно дело было в Backup Exec. После того как отменил автоопрос по сети в Backup Exec ошибка перестала появляться.

    23 марта 2016 г. 8:13
  • Я часто вижу аналогичную ошибку на узлах кластера.

    Источник: Security-Kerberos

    ID: 4

    Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера smt06$. Использовалось целевое имя HTTP/cls-smt01.moscow.smt.com. Это означает, что целевому серверу не удалось расшифровать билет, предоставленный клиентом. Это возможно, когда целевое SPN-имя зарегистрировано на учетную запись, отличную от учетной записи, используемой конечной службой. Убедитесь, что целевое SPN-имя зарегистрировано только на учетную запись, используемую сервером. Эта ошибка также может возникать, если пароль целевой службы отличается от пароля, заданного для нее в центре распространения ключей Kerberos. Убедитесь, что пароли в службе на сервере и в центре распространения ключей совпадают. Если имя сервера задано не полностью и конечный домен (MOSCOW.SMT.COM) отличается от домена клиента (MOSCOW.SMT.COM), проверьте эти два домена на наличие учетных записей серверов с одинаковыми именами или используйте для идентификации сервера полное имя.

    Причем в данном случае smt06 - это узел кластера cls-smt01. А саму ошибку я вижу на другом узле кластера.



    • Изменено MikAndr 19 июля 2018 г. 8:51
    19 июля 2018 г. 8:46