none
503 ошибка AD FS adfs/services/trust RRS feed

  • Вопрос

  • Здравствуйте!

    Помогите, пожалуйста, первый раз столкнулись с AD FS. Настроили интеграцию с внешним приложением(application.domain.com), в "Partner Identity Provider" приложения указали https://adfs.domain.com/adfs/services/trust. При переходе на application.domain.com корректно редиректит на наш сервер, но после ввода учётных данных идёт ответ со стороны "application": The server encountered an error processing the request. The exception message is 'The partner identity provider http://adfs.domain.ru/adfs/services/trust is not configured.'. See server logs for more details.

    Подскажите, пожалуйста, где может быть заминка? Как диагностировать проблему? При попытке перехода на http://adfs.domain.ru/adfs/services/trust выдаёт ошибку 503, в логах глухо. Заранее спасибо за помощь!

    21 сентября 2017 г. 15:30

Ответы

  •  http://adfs.domain.com/adfs/services/trust - это строка идентификации (URI) вашего ADFS, а не адрес(URL), по нему ничего не публикуется, а эта строка передаётся во всяческих сообщениях в качестве идентификатора ADFS, в данном случае - как Identity Provider (он же Claim Provider в терминологии ADFS) .

    Что там у вас не так сконфигурировано, я, конечно, не скажу - ошибка возникает уже в приложении. Раз управление доходит до приложения, то точки подключения (endpoint) сконфигурированы, скорее всего, правильно. Неправильно может быть указаны идентификатор ADFS в приложении - что-либо, кроме  http://adfs.domain.com/adfs/services/trust. Неправильно могут быть сконфигурированы (на обоих сторонах - и в Relying Party Trust в ADFS и в приложении) сертификаты: token-signing и encryption(если смотреть со стороны AD FS в свойствах Relying party trust) он же token-decrypting (на стороне приложения). Неправильно могут быть сконфигурированы правила преобразования утверждений (claims) - как на стороне ADFS, особенно если там не настроено по умолчанию Permit Access for All users, так и на стороне приложения (особо обратить внимание на утверждение для Identity - у него разные форматы бывают).

    Лучше всего, конечно, было бы найти в логах приложения (искать надо именно там), что именно ему не нравится, но если найти не получается, то надо аккуратно посмотреть всё перечисленное выше - может, найдёте причину.


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


    22 сентября 2017 г. 10:11
  • Вряд ли. Те сертификаты, о которых я говорил - они вообще не связаны с сертификатом сайта (с ним связан только Service Communication certificate, который в федеративном доверии, вроде как, напрямую не участвует (по крайней мере, в настройках его нет). По умолчанию там ADFS использует самоподписанные сертификаты - там, где он их сам устанавливает - или сертификаты, которые предоставляет приложение. Насколько я помню (боюсь ошибиться) token-signing - это сертификат, принадлежащий ADFS (Claim provider), а encryption/decryption - приложению (Relying party).


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

    23 сентября 2017 г. 0:15

Все ответы

  • Или подскажите, пожалуйста, возможно я что-то недопонимаю. На стороне "application" прописан Parner Identity Provider: http://adfs.domain.com/adfs/services/trust для организации SSO с помощью saml 2.0. При переходе на адрес сервиса, он редиректит на страницу аутентификации adfs, аутентификация проходит корректно, дальше идёт редирект обратно на страницу входа в сервис с удостоверением и вылетает ошибка, что http://adfs.domain.com/adfs/services/trust не сконфигурирован. Как диагностировать проблему? Может не тот endpoint прописан? Я не вижу его в списке endpoints и по netsh не вижу что конкретно этот адрес как-то опубликован. Помогите, пожалуйста, на что взглянуть? Метадата корректно открывается, страница аутентификации тоже, аутентифицирует в АД корректно. Спасибо заранее!
    22 сентября 2017 г. 6:33
  •  http://adfs.domain.com/adfs/services/trust - это строка идентификации (URI) вашего ADFS, а не адрес(URL), по нему ничего не публикуется, а эта строка передаётся во всяческих сообщениях в качестве идентификатора ADFS, в данном случае - как Identity Provider (он же Claim Provider в терминологии ADFS) .

    Что там у вас не так сконфигурировано, я, конечно, не скажу - ошибка возникает уже в приложении. Раз управление доходит до приложения, то точки подключения (endpoint) сконфигурированы, скорее всего, правильно. Неправильно может быть указаны идентификатор ADFS в приложении - что-либо, кроме  http://adfs.domain.com/adfs/services/trust. Неправильно могут быть сконфигурированы (на обоих сторонах - и в Relying Party Trust в ADFS и в приложении) сертификаты: token-signing и encryption(если смотреть со стороны AD FS в свойствах Relying party trust) он же token-decrypting (на стороне приложения). Неправильно могут быть сконфигурированы правила преобразования утверждений (claims) - как на стороне ADFS, особенно если там не настроено по умолчанию Permit Access for All users, так и на стороне приложения (особо обратить внимание на утверждение для Identity - у него разные форматы бывают).

    Лучше всего, конечно, было бы найти в логах приложения (искать надо именно там), что именно ему не нравится, но если найти не получается, то надо аккуратно посмотреть всё перечисленное выше - может, найдёте причину.


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


    22 сентября 2017 г. 10:11
  • Доброго вечера!

    Спасибо большое за ответ! По поводу сертификатов - на стороне adfs везде используется wildcard на *.domain.com. Возможно в этом ошибка? Спасибо!

    22 сентября 2017 г. 20:32
  • Вряд ли. Те сертификаты, о которых я говорил - они вообще не связаны с сертификатом сайта (с ним связан только Service Communication certificate, который в федеративном доверии, вроде как, напрямую не участвует (по крайней мере, в настройках его нет). По умолчанию там ADFS использует самоподписанные сертификаты - там, где он их сам устанавливает - или сертификаты, которые предоставляет приложение. Насколько я помню (боюсь ошибиться) token-signing - это сертификат, принадлежащий ADFS (Claim provider), а encryption/decryption - приложению (Relying party).


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

    23 сентября 2017 г. 0:15