none
Sharepoint и Аутентификация kerberos

    Вопрос

  • Коллеги день добрый, подскажите что можно проверить?

    Есть ферма Sharepoint\ есть лес в нем сайты Питер Москва Киев Ульяновск

    Аутентификация  kerberos отрабатывает отлично у пользователей Питера, а вот у пользователей  Остальных сайтов постоянно запрашивает логин и пароль.

    Куда можно посмотреть подскажите? что бы понять в чем  трабл?


    • Изменено Dedman2k3 16 мая 2017 г. 10:01

Все ответы

  • Прежде всего, включите протоколирование Kerberos на Sharepoint - может, что увидите сразу. Смотреть надо в журнале событий Система. Заодно полезно посмотреть этот же журнал на предмет ошибок Kerberos на том контроллере домена, с которым работают пользователи (на контроллерах домена протоколирование Kerberos включено по умолчанию).

    Далее.

    Про лес и сайты - это понятно. Но для аутентификации важнее логическая структура AD - домены. Домен у вас один на все площадки, или у них свои домены?

    Если один на все площадки, то проверяйте репликацию между всеми контроллерами домена.

    Если доменов несколько, то нужно проверить, что пользователям доступны контроллеры всех доменов по пути аутентификации (т.е. по цепочке отношений доверия в лесу). Полезным будет посмотреть (например, командой klist.exe) наличие в кэше у пользователя билетов TGT на все промежуточные контроллеры после попытки обращения к Sharepoint. Имеет смысл проверить журналы событий на этих контроллерах на предмет ошибок Kerberos.


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


    • Изменено M.V.V. _ 16 мая 2017 г. 11:28
  • Прежде всего, включите протоколирование Kerberos на Sharepoint - может, что увидите сразу. Смотреть надо в журнале событий Система. Заодно полезно посмотреть этот же журнал на предмет ошибок Kerberos на том контроллере домена, с которым работают пользователи (на контроллерах домена протоколирование Kerberos включено по умолчанию).

    Далее.

    Про лес и сайты - это понятно. Но для аутентификации важнее логическая структура AD - домены. Домен у вас один на все площадки, или у них свои домены?

    Если один на все площадки, то проверяйте репликацию между всеми контроллерами домена.

    Если доменов несколько, то нужно проверить, что пользователям доступны контроллеры всех доменов по пути аутентификации (т.е. по цепочке отношений доверия в лесу). Полезным будет посмотреть (например, командой klist.exe) наличие в кэше у пользователя билетов TGT на все промежуточные контроллеры после попытки обращения к Sharepoint. Имеет смысл проверить журналы событий на этих контроллерах на предмет ошибок Kerberos.


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


    Большое спасибо за совет, буду сегодня шустрить проверять, по результатам отпишусь, что в итоге нашел.
  • есть вот такая ошибка на самом сервере WFE . видимо когда пытаюсь с сервера WFE запустить ЦА( ЦА находиться на sp01) ну и т.к. на сервере  WFE  не пускает не под каким логином и паролем в ЦА\ выдает вот такую ошибку.. не совсем понятно что с ней делать 

    Получено сообщение об ошибке Kerberos:
     в сеансе входа в систему домен.RU\sp01$
     Время клиента: 
     Время сервера: 14:30:3.0000 5/16/2017 Z
     Код ошибки: 0x19 KDC_ERR_PREAUTH_REQUIRED
     Расширенная ошибка: 
     Область клиента: 
     Имя клиента: 
     Область сервера: домен.ru
     Имя сервера: krbtgt/домен.ru
     Имя целевого объекта: krbtgt/домен.ru@домен.ru
     Текст ошибки: 
     Файл: e
     Строка: d3f
     Данные ошибки в данных записи.

    а ниже еще вот такая ошибка

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


    • Изменено Dedman2k3 16 мая 2017 г. 14:36
  • Прежде всего, включите протоколирование Kerberos на Sharepoint - может, что увидите сразу. Смотреть надо в журнале событий Система. Заодно полезно посмотреть этот же журнал на предмет ошибок Kerberos на том контроллере домена, с которым работают пользователи (на контроллерах домена протоколирование Kerberos включено по умолчанию).



    на WFE  включил протоколирование kerberos постоянные ошибки:

    Получено сообщение об ошибке Kerberos:
     в сеансе входа в систему domen.RU\sp01$
     Время клиента: 
     Время сервера: 8:0:3.0000 5/17/2017 Z
     Код ошибки: 0x19 KDC_ERR_PREAUTH_REQUIRED
     Расширенная ошибка: 
     Область клиента: 
     Имя клиента: 
     Область сервера: domen.ru
     Имя сервера: krbtgt/domen.ru
     Имя целевого объекта: krbtgt/domen.ru@domen.ru
     Текст ошибки: 
     Файл: e
     Строка: d3f
     Данные ошибки в данных записи.

    Получено сообщение об ошибке Kerberos:
     в сеансе входа в систему 
     Время клиента: 
     Время сервера: 8:0:0.0000 5/17/2017 Z
     Код ошибки: 0x1b Unknown Error
     Расширенная ошибка: 
     Область клиента: 
     Имя клиента: 
     Область сервера: domen.RU
     Имя сервера: spsearch
     Имя целевого объекта: spsearch@domen.RU
     Текст ошибки: 
     Файл: 9
     Строка: 12c5
     Данные ошибки в данных записи.

    на контроллерах домена нету вообще ошибок, подобных тоже.

    Далее.

    Про лес и сайты - это понятно. Но для аутентификации важнее логическая структура AD - домены. Домен у вас один на все площадки, или у них свои домены?

     домен один.


    • Изменено Dedman2k3 17 мая 2017 г. 8:18
  • Возможно, имеют место проблемы из-за MTU на каналах связи, меньших, чем стандартные 1500 для Ethernet.

    Можно попробовать (хотя бы - для диагностики) принудительно заставить Kerberos работать только по TCP

    PS Померить MTU можно с помощью команды ping -f -l размер_пакета адрес.места.назначения : ищите максимальный размер_пакета, при котором ping ещё проходит. Для стандартного MTU для Ethernet размер_пакета =1472 (28 байт съедает заголовок).


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

  • Возможно, имеют место проблемы из-за MTU на каналах связи, меньших, чем стандартные 1500 для Ethernet.

    Можно попробовать (хотя бы - для диагностики) принудительно заставить Kerberos работать только по TCP

    PS Померить MTU можно с помощью команды ping -f -l размер_пакета адрес.места.назначения : ищите максимальный размер_пакета, при котором ping ещё проходит. Для стандартного MTU для Ethernet размер_пакета =1472 (28 байт съедает заголовок).


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

    cделал так на пользовательском пк включил логировнаие kerberos и принудительно работать через tcp

    нечего кроме ошибки не нашел(

    Получено сообщение об ошибке домен:
     в сеансе входа в систему домен\полльзователь
     Время клиента: 
     Время сервера: 8:56:44.0000 5/18/2017 Z
     Код ошибки: 0x19 KDC_ERR_PREAUTH_REQUIRED
     Расширенная ошибка: 
     Область клиента: 
     Имя клиента: 
     Область сервера: домен
     Имя сервера: krbtgt/домен
     Имя целевого объекта: krbtgt/домен@домен
     Текст ошибки: 
     Файл: e
     Строка: d39
     Данные ошибки в данных записи.
  • Это может даже не быть ошибкой: в некоторых случаях клиент Kerberos начинает запрос TGT для без предварительной аутентификации, на что ему KDC (т.е. контроллер домена) возвращает ошибку с требованием аутентификации и дальше всё работает нормально.

    Смотрите на клиенте (посредством klist), получает ли он билет Kerberos для службы Sharepoint при обращении к этому серверу.

     

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


  • Смотрите на клиенте (посредством klist), получает ли он билет Kerberos для службы Sharepoint при обращении к этому серверу.

     

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

    ок, значит зашел на машину в московском офисе, там где не работает аутентификация

    сделал klist purge

    потому прописал klist, выдал Кешированные билетов 0

    Запустил IE, ввел в адресную строку имя портала, у меня сразу запросил логин и пароль, нажал отмена, после снова в командной строке ввел klist пишет:

    текущим идетификатором входа является 0:0x4097be6

    Кешированные билеты : 0

    Ок, думаю я. нету нечего т.к. не работает, беру машину питерскую там где работает аутентификация.

    пишу также в начале klist purge.

    открываю браузер ввожу имя портала, аутентификация проходит успешно все ок.

    ввожу в командной строке klist пишет:

    Кешированные билеты : 0

    не совсем понятно почему и в том и  в другом случае 0

    куда дальше копать?

  • По поводу Kerberos - копать в сторону того, используется ли он у вас вообще при аутентификации на Sharepoint. Например, в событиях аудита успешных попыток входа на этот сервер посмотреть используемый протокол аутентификации. Потому как у вас были выше сообщения, намекавшие на неверную настройку SPN, что препятствует использованию Kerberos.

    А по поводу запросов пароля (совсем забыл про это, посыпаю голову пеплом) - смотреть настройки безопасности IE: там по умолчанию ЕМНИП стоит автоматический вход (т.е. без запроса пароля) только в пределах местной интрасети, а сайт в другой подсети обычно в неё не попадает. Используемый протокол аутентификации на это поведение IE не влияет.


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

  • По поводу Kerberos - копать в сторону того, используется ли он у вас вообще при аутентификации на Sharepoint. Например, в событиях аудита успешных попыток входа на этот сервер посмотреть используемый протокол аутентификации. Потому как у вас были выше сообщения, намекавшие на неверную настройку SPN, что препятствует использованию Kerberos.

    хмм возможно вы правы, я что то где то упустил..

    вот лог из журнала безопасности аудит успеха на WFE сервере взят,  это когда питреской тачке пользователь аутентифировался на портале автоматически лог показывает через kerberos:

    Вход с учетной записью выполнен успешно.

    Субъект:
    ИД безопасности: NULL SID
    Имя учетной записи: -
    Домен учетной записи: -
    Код входа: 0x0

    Тип входа: 3

    Уровень олицетворения: Олицетворение

    Новый вход:
    ИД безопасности: домен\temp2
    Имя учетной записи: temp2
    Домен учетной записи: домен
    Код входа: 0x5B7348E
    GUID входа: {24670dde-adf0-babb-93b8-8f3f11bedea3}

    Сведения о процессе:
    Идентификатор процесса: 0x0
    Имя процесса: -

    Сведения о сети:
    Имя рабочей станции:
    Сетевой адрес источника: 192.168.2.217
    Порт источника: 55339

    Сведения о проверке подлинности:
    Процесс входа: Kerberos
    Пакет проверки подлинности: Kerberos
    Промежуточные службы: -
    Имя пакета (только NTLM): -
    Длина ключа: 0

    Данное событие возникает при создании сеанса входа. Оно создается в системе, вход в которую выполнен.

    Поля "Субъект" указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба "Сервер", или локальный процесс, такой как Winlogon.exe или Services.exe.

    В поле "Тип входа" указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).

    Поля "Новый вход" указывают на учетную запись, для которой создан новый сеанс входа, то есть на учетную запись, с которой выполнен вход.

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

    Поле "Уровень олицетворения" задает допустимую степень олицетворения для процессов в данном сеансе входа в систему.

    Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
    - GUID входа - это уникальный идентификатор, который позволяет сопоставить данное событие с событием KDC.
    - В поле "Промежуточные службы" указано, какие промежуточные службы участвовали в данном запросе на вход.
    - Поле "Имя пакета" указывает на подпротокол, использованный с протоколами NTLM.
    - Поле "Длина ключа" содержит длину созданного ключа сеанса. Это поле может иметь значение "0", если ключ сеанса не запрашивался.

    в шарике на веб приложении kerberos выбран:

    setspn на учетку из под которой работает веб-приложение портала прописан

    далее в iis kerberos настроен на сервере WFE:

    А по поводу запросов пароля (совсем забыл про это, посыпаю голову пеплом) - смотреть настройки безопасности IE: там по умолчанию ЕМНИП стоит автоматический вход (т.е. без запроса пароля) только в пределах местной интрасети, а сайт в другой подсети обычно в неё не попадает. Используемый протокол аутентификации на это поведение IE не влияет.

    хмм поу молчанию на всех пк в домене стоит:

    получается, что то то похожее что вы описали.. просто у нас на питерском ADсайте  допустим 1 подсети до 25 подсети, логинется автоматически на портал, а вот на ADсайте московском там с 26 подсети по 80 и в этих подсетях как раз так не работает... 


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

    порекомедуйте пожалуйста как можно выяснить почему не работает kerberos ??  что я забыл...

    • Изменено Dedman2k3 20 мая 2017 г. 17:41