Заметка о том, как однажды легла авторизация на всех службах с авторизацией ADFS.

В респонсе -

 "type": "organization/saml-diagnostics#invalid-signature",
  "title": "The signature of response or assertion was invalid.",
  "status": 400,
  "instance": "/federations/bpfrhbh3m4f0tug16kd7",
  "request-id": "910ec7ea-75bc-4662-a212-37c3e4358a78"

В консоле ADFS все сертификаты выглядели валидно и даже помечены как primary (первичными

После авторизации на Exchange стало ещё интереснее

Ключевое сообщение в URI

https://mail.domain/owa/auth/errorfe.aspx?msg=WrongAudienceUriOrBadSigningCert

Тут уж перезапуск служб ADFS не поможет.

Начали смотреть - заказчик по тихому сам сменил.

В логах ADFS

Служба AD FS установила, что все сертификаты службы имеют соответствующие права доступа, предоставленные учетной записи службы AD FS.

Не стоит полагаться на статус.

Дело в том, что 2 сертификата для расшифрофки подписи token-decrypting и подписи маркера token-signing с установкой как первичный - не нами заказчиком не были нормально импортированы а помечены первичными.

Но в нашем случае требуется восстановить работоспособность ASAP

А выбор старого, ещё действующего сертификата как Primary недоступен.

При добавлении нового получаем warning

Идем в консоль PowerShell и выполняем

Set-ADFSProperties -AutoCertificateRollover $false

После переключаем сертификаты в консоле ADFS для расшифрофки подписи token-decrypting и подписи маркера token-signing как первичными

Теперь есть время нормально импортировать "новые" сертификаты.

Импортируем в личное хранилище итд. Далее план действий понятен. Открываем Obtain and Configure TS and TD Certificates for AD FS
 
Об этом расскажет мой коллега в другой статье.