Sign in with Microsoft
Sign in or create an account.

Продовжити виправлення неполадок для перевірки потенційних проблем з покладається виробників.

Продовжити додаткових перевірок покладається виробників.

Продовжити, виправлення неполадок, щоб перевірити сертифікат SSL.

Продовжити, виправлення неполадок, щоб перевірити проксі-сервер-довірчий зв'язок між проксі-сервера веб-застосунку та AD FS.

Зв'язування, можуть конфліктувати з AD FS прив'язування сертифікат на порт 443.

Проблеми, що користувач зіткнутися з єдиного входу?

Ця проблема може виникнути, AD FS сторінка входу або на боці застосунку.

Ця проблема виникає, AD FS входу на сторінці, з'являється на "помилка", "HTTP 503 Служба недоступна" або інші повідомлення про помилку. URL-адресу сторінки, помилка показує, AD FS ім'я служби, наприклад fs.contoso.com.

Якщо проблема виникає, на стороні застосунку, URL-адресу сторінки, помилка показує, IP-адресу або ім'я сайту цільовий служби.

Коли виникає ця проблема?

Ця проблема вплинути на всіх користувачів?

Користувач має доступ будь-який покладається сторони?

Чи виникає ця проблема з Azure AD сценарію?

Користувач має доступ будь-який покладається сторони?

Маркер сертифікат підпису нещодавно оновлено AD FS, перевірте, якщо новий сертифікат зареєстрована об'єднання партнером. У випадку, якщо AD FS використовує маркер дешифрування сертифікат, який також оновлюється нещодавно у, те ж саме перевірте також. Щоб перевірити, якщо поточний маркер AD FS цифрового підпису, сертифікат на AD FS, відповідає на об'єднання партнера, виконайте такі дії:

  1. Отримання поточних маркер цифрового підпису сертифікат на AD FS, запустіть таку команду:
    Get-ADFSCertificate -CertificateType token-signing

  2. У списку сертифікатів, що повертається, знайти один з IsPrimary = TRUEі занотуйте на відбиток.

  3. Отримайте відбиток, поточний маркера цифрового підпису, сертифікат на об'єднання партнера. Власник програми, необхідно надати вам.

  4. Порівняння, відбитків пальців два сертифікатів .

Те ж саме перевірки, якщо AD FS використовує новий маркер дешифрування сертифікатів, крім того, що команди для отримання маркер дешифрування сертифікат на AD FS наступним чином:
Get-ADFSCertificate -CertificateType token-decrypting

Якщо маркерів сертифіката або маркер розшифрування сертифікат власним підписом, AutoCertificateRollover активовано за промовчанням на цих сертифікатів, і AD FS керує сертифікати автоматичного відновлення, якщо до закінчення терміну дії.

Щоб визначити, якщо ви користуєтеся, сертифікати із власним підписом, виконайте такі дії:

  1. Виконайте таку команду:
    Get-ADFSCerticate -CertificateType "token-signing"
    Get-ADFSCertificate

  2. Перевірте сертифікат атрибутів.
    Якщо тему та постачальника атрибути обидва, які починаються з "CN = ADFS підписання,...", сертифікат власним підписом і керований AutoCertRollover.

Підтвердження, якщо поновити сертифікати автоматично, виконайте такі дії:

  1. Виконайте таку команду:
    Get-ADFSProperties | FL AutoCertificateRollover
    Get-ADFSProperties

  2. Перевірте AutoCertificateRollover атрибут.

    • Якщо AutoCertificateRollover = TRUE, AD FS автоматично створює новий сертифікатів (за 30 днів до закінчення терміну дії, за промовчанням) і встановлює їх як основний сертифікатів (за 25 днів до закінчення терміну дії).

    • Якщо AutoCertificateRollover = FALSE, слід замінити вручну сертифікати.

Чи відповідає на до-відбитків пальців?

Щоб перевірити, чи невідповідності, виконайте такі дії:

  1. Визначити алгоритм використовується покладається сторона, запустіть таку команду: Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

    Можливих значень. SHA1 або SHA256 .

  2. Зверніться до власника на застосування алгоритм використовується на стороні застосунку.

  3. Переконайтеся, що якщо два алгоритмів відповідає.

Існує невідповідність?

Користувач отримати до несподіваних NTLM рядка або запит на автентифікацію на основі форм?

Користувач отримати неочікувані рядка, для декількох факторів автентифікації? Чи користувач повторно отримати запрошення?

Чи виникає ця проблема з Azure AD сценарію?

Запит на автентифікацію, що надсилаються до Azure AD, містять рядок = параметр входу?

Подайте запит на запити перевірки параметрів WAUTH і RequestedAuthNContext може мати методи автентифікації, який зазначено. Це параметр запит, установлюючи на запит на автентифікацію, несподіване?

Для виправлення неполадок, скористайтеся наведеними нижче способами.

Перевірте стан користувача, оболонки Windows PowerShell або інтерфейсу користувача. Якщо користувач вимкнуто, щоб користувач.

Перевірка стану користувача з оболонки Windows PowerShell

  1. Увійдіть до будь-якого контролерів доменів.

  2. Відкрийте оболонку Windows PowerShell.

  3. Перевірка стану користувача, запустіть таку команду:
    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    Get-ADUser

Перевірка стану користувача в інтерфейсі користувача

  1. Увійдіть до будь-якого контролерів доменів.

  2. Відкрийте консоль керування Active Directory – користувачі й комп'ютери .

  3. Користувачі вузла, користувача у правій області вікна, клацніть правою кнопкою миші та виберіть пункт Властивості.

  4. Клацніть вкладку обліковий запис .

  5. У розділі Параметри облікового запису, перевірте, якщо обліковий запис вимкнуто перевіряється.
    The "Account is disabled" option under Account options

  6. Якщо є можливість, зніміть його.

Вирішується проблема?

Якщо будь-які властивості користувача, оновлення, у службі Active Directory, призводить до зміни в метаданих об'єкту користувача. Перевірте метаданих об'єкту користувача, щоб дізнатися, які властивості нещодавно було оновлено. Виявлено зміни, переконайтеся, що вони є зареєстрована, пов'язані з ними послуги. Щоб перевірити, чи було, якщо властивість зміни користувача, виконайте такі дії:

  1. Увійдіть до контролера домену.

  2. Відкрийте оболонку Windows PowerShell.

  3. Отримання метаданих об'єкта користувача, запустіть таку команду:
    repadmin /showobjmeta <destination DC> "user DN"

    Приклад команди є:
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. У метаданих, перегляньте стовпець дати/часу для кожного атрибута ключ для внесення змін. У наступному прикладі атрибут userPrincipleName триває, нові дати інші атрибути, ніж представляє внесення змін до об'єкта метаданих користувача.
    repadmin show user metadata

Вирішується проблема?

В середовищі AD FS кількох лісів, необхідна двосторонній лісу довіри між лісі, де розгортання AD FS і до лісу, які використовують для перевірки автентичності, розгортання AD FS. Щоб переконатися, що якщо довіри між лісами працює належним чином, виконайте такі дії:

  1. Увійдіть до контролера домену в лісі, де розгортання AD FS.

  2. Консоль керування за відкриття в Active Directory домени та довіру .

  3. В на консоль керуваннядомену, який містить безпеки, який потрібно перевірити, клацніть правою кнопкою миші та виберіть пункт Властивості.

  4. Відкрийте вкладку довіри .

  5. У розділі доменів надійним цього домену (вихідний довіри) або доменів, що довіряєте цього домену (вхідний довіри)клацніть безпеки, щоб перевірити і виберіть пункт Властивості.

  6. Натисніть кнопку, перевірити.
    Виберіть один із параметрів у діалоговому вікні Служби доменів Active Directory .

    • Якщо ні, рекомендовано після повторного ті ж дії, взаємне домену.

    • Якщо так, передбачають до облікових даних для адміністратора домену двосторонню угоду. Потрібно виконати таку саму процедуру для домену, що двосторонню угоду.

Active Directory Domain Services

  • Вирішується проблема?

Дамп маркерів застосунок є корисним, під час налагодження проблеми до об'єднання служби підтримки користувачів, а також підтвердження користувача стверджують, що правила. Це не є офіційне рішення, але добре незалежні налагодження рішення, який рекомендовано для виправлення неполадок.

Перш ніж використовувати дамп маркерів застосунку, вам потрібно:

  1. Отримати інформацію покладається виробників застосунок, який потрібно відкрити. Якщо у автентифікація OAuth здійснюється, зверніться по OAuth клієнта інформацію, а також.

  2. Настроювання, дамп маркерів застосунку.

Отримати інформацію про OAuth і покладається партії

Якщо використовується звичайних покладається сторона, виконайте наведені нижче дії:

  1. Відкрийте на сервері AD FS оболонки Windows PowerShell варіант Запуск із правами адміністратора .

  2. Додайте до AD FS 2.0 компонент для оболонки Windows PowerShell, запустіть таку команду:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Отримання інформації покладається виробників, запустіть таку команду:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Отримати інформацію OAuth клієнта, запустіть таку команду:
    $client = Get-AdfsClient ClientName

Якщо використовується функція застосунку групи у Windows Server 2016, виконайте наведені нижче дії.

  1. Відкрийте на сервері AD FS оболонки Windows PowerShell варіант Запуск із правами адміністратора .

  2. Отримання інформації покладається виробників, запустіть таку команду:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Відомості, Якщо клієнт OAuth спільних, отримати клієнт за допомогою такої команди:
    $client = Get-AdfsNativeClientApplication ClientName

    Відомості, Якщо клієнт OAuth конфіденційну інформацію, отримати клієнт за допомогою такої команди:
    $client = Get-AdfsServerApplication ClientName

Настроювання дамп маркерів застосунку

Настроювання дамп маркерів застосунку, виконайте такі команди, у вікні Windows PowerShell:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Продовжено такі. Наприкінці кожного способу див. Якщо проблему вирішено. Якщо ні, скористайтеся іншим способом.

У цьому методі запуску, отримавши на політика дані і потім використовувати дамп маркерів застосунок для діагностики політики, щоб побачити, якщо користувач атаки.

Докладно політики

$rp. Правила авторизації покладається виробників показує, IssuanceAuthorizationRules.

У Windows Server 2016 і пізніших версій можна використовувати $rp. AccessControlPolicyName Настроювання автентифікації та авторизації політики. Якщо $rp. AccessControlPolicyName, має значення, доступ до політику в місці, яке керує політику авторизації. У такому випадку $rp. IssuanceAuthorizationRules не вказано. За допомогою $rp. ResultantPolicy, щоб знайти відомості про політику керування доступом.

Якщо $rp. ResultantPolicy не має відомості про політику, подивіться на фактичні вимоги правил. Для отримання претензії правила, виконайте такі дії:

  1. Значення політики керування доступом $null, запустіть таку команду:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null

  2. Отримання інформації покладається виробників, запустіть таку команду:
    $rp = Get-AdfsRelyingPartyTrust RPName

  3. Check $rp.IssuanceAuthorizationRulesі$rp. AdditionalAuthenticationRules.

Діагностика політику авторизації за допомогою маркерів дамп застосунку

  1. Вибір дамп маркерів політики автентифікації, тим самим, як учасник покладається в іншому випадку.

  2. Потрібно відкрити одну з наведених нижче посилань, залежно від того, в політиці автентифікації користувача.

    • WS-Fed:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML-P:https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Форс-декількох факторів автентифікації:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  3. Увійдіть на сторінці входу.

Що ви отримуєте, – це набір вимог користувача. Дізнатися, чи потрібні додаткові дії в політику авторизації, який явно забороняє користувача на основі цих вимог.

Вирішується проблема?

  1. Настроювання претензії правила, у програмі дамп маркерів тим самим претензії правила в іншому випадку покладається сторони.

  2. Настроювання дамп маркерів політики автентифікації, тим самим, як учасник покладається в іншому випадку.

  3. Потрібно відкрити одну з наведених нижче посилань, залежно від того, в політиці автентифікації користувача.

    • WS-Fed:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML-P:https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Форс-декількох факторів автентифікації:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Увійдіть на сторінці входу.

, Це набір вимог, покладається виробників буде отримати для користувача. Якщо будь-які вимоги відсутні або неочікувана, подивіться політика видавання, щоб з'ясувати причину.

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

Вирішується проблема?

Правила авторизації перевірити, чи пристрій вимоги, переконайтеся, якщо будь-якої з цих вимог для пристрою відсутні у списку вимоги, які можна отримати від дампа маркерів застосунку. Відсутній тверджень, може блокувати пристрій автентифікації. Щоб претензії дамп маркерів застосунку, виконайте в розділі " використання дамп маркерів застосунок для діагностики політику авторизації " у спосіб, Перевірте політику авторизації користувача було впливу .

Нижче наведено вимоги пристрою. Правила авторизації може використовувати деякі з них.

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser

  • http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown

  • http://schemas.microsoft.com/2014/02/deviceusagetime

  • http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant

  • http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Якщо відсутні претензій, виконайте в настроїти локальний умовного доступу з використанням зареєстровані на пристрої , щоб переконатися, що середовища інсталяції, для пристрою автентифікації.

Якщо всі вимоги, див. Якщо значення претензії дамп маркерів застосунку, відповідає значення, потрібен дозвіл політики.

Вирішується проблема?

Для виправлення неполадок, скористайтеся наведеними нижче способами. Наприкінці кожного способу див. Якщо проблему вирішено. Якщо ні, скористайтеся іншим способом.

Якщо користувач намагається увійти в систему Azure AD, їх буде перенаправлено AD FS автентифікації, для федеративного домену. Один із можливих причин не вдалося увійти є, що користувач не ще не синхронізується Azure AD. Може з'явитися цикл з Azure AD-AD FS, після першого автентифікації спроба AD FS. Щоб визначити, чи користувач синхронізується Azure AD, виконайте такі дії:

  1. Завантажити і встановити модуль Azure AD PowerShell для оболонки Windows PowerShell.

  2. Відкрийте оболонку Windows PowerShell, режим "Запуск із правами адміністратора".

  3. Ініціювати з'єднання Azure AD, запустіть таку команду:
    Connect-MsolService

  4. Глобальний адміністратор-облікових даних забезпечити підключення.

  5. Отримати список користувачів в Azure AD, запустіть таку команду:
    Get-MsolUser

  6. Переконайтеся, що якщо користувач є у списку.

Якщо користувач немає у списку, синхронізація, користувач Azure AD.

Вирішується проблема?

Azure AD вимагає immutableID, UPN користувача, для автентифікації користувача.

Примітка. immutableID також називають sourceAnchor в таких засобів:

  • Azure AD-синхронізації

  • Синхронізації для azure Active Directory (DirSync)

Адміністратори можуть використовувати Azure AD-підключення для керування AD FS безпеки з Azure AD. Якщо ви не управління безпеки, за допомогою Azure AD-підключення, ми рекомендуємо, щоб ви тому, завантаження, Azure AD для підключення. Стверджують, що azure AD для підключення дає можливість автоматичного керування правилами, залежно від параметри синхронізації.

Щоб перевірити, чи це твердження правила immutableID і UPN в AD FS відповідає те, що Azure AD використовує, виконайте такі дії:

  1. Отримати sourceAnchor і UPN Azure AD-підключення.

    1. Відкрити Azure AD-підключення.

    2. Виберіть режим, поточну конфігурацію.
      Azure AD Connect -View current configuration

    3. На сторінці Огляд, ваше рішення занотуйте значення Джерело ПРИВ'ЯЗКИ і Ім'я учасника-користувача.
      Azure AD Connect -Review your solution

  2. V-erify значення immutableID (sourceAnchor) і UPN у відповідний стверджують, правила, які налаштовано на сервері AD FS.

    1. Відкрийте на сервері AD FS AD FS консоль керування.

    2. Натисніть кнопку, виробників, спираючись на довіри.

    3. Клацніть правою кнопкою миші на покладається виробників довіри з Azure AD і натисніть кнопку Редагування претензії видавання політики .

    4. Відкрийте претензії правило незмінний Ідентифікатор і UPN.

    5. Переконайтеся, що якщо змінні, які надсилають запит на значення immutableID та УПН такі ж, як і ті, у програмі Azure AD-підключення.
      Issue UPN and ImmutableID

    6. Якщо значення, скористайтеся одним із наведених нижче способів.

      • AD FS керує Azure AD-підключення, скидання покладається виробників довіри через Azure AD-підключення.

      • Якщо AD FS не керує Azure AD-підключення, виправити, претензії правильно атрибути.
         

Вирішується проблема?

Інформація буде в подальші дії.

 

Якщо використовується звичайних покладається сторона, виконайте наведені нижче дії:

  1. На основному сервері AD FS відкрийте оболонку Windows PowerShell, режим Запуск із правами адміністратора .

  2. Додайте до AD FS 2.0 компонент для оболонки Windows PowerShell, запустіть таку команду:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Отримання інформації покладається виробників, запустіть таку команду:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Отримати інформацію OAuth клієнта, запустіть таку команду:
    $client = Get-AdfsClient ClientName

Якщо використовується функція застосунку групи у Windows Server 2016, виконайте наведені нижче дії.

  1. На основному сервері AD FS відкрийте оболонку Windows PowerShell, режим Запуск із правами адміністратора .

  2. Отримання інформації покладається виробників, запустіть таку команду:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Якщо клієнт OAuth спільних, отримати інформацію клієнта, запустіть таку команду:
    $client = Get-AdfsNativeClientApplication ClientName

    Якщо клієнт конфіденційними, отримати інформацію клієнта, запустіть таку команду:
    $client = Get-AdfsServerApplication ClientName

Тепер перейдіть до наведених нижче способів для виправлення неполадок.

Покладається виробників, ідентифікатор ID клієнта та перенаправлення URI має бути надано власник застосунок і клієнта. Проте ще може бути через невідповідність між надає власника і те, що встановлено AD FS. Наприклад, невідповідності можуть бути спричинені помилка. Перевірте, якщо настройки надаються власника збіг ті, що настроєно в AD FS. Дії, описані в попередній сторінці ви отримаєте налаштування в AD FS за допомогою PowerShell.

Параметри, які надаються власник

Параметри, налаштовані на AD FS

Покладатися на виробників ID

$rp.Identifier

Покладатися переспрямування для виробників URI

Префікс або підстановки збіг з

  • $rp. WSFedEndpoint, WS-Fed покладається сторона

  • $rp. SamlEndpoints, SAML покладається сторона

Ідентифікатор клієнта

$client.ClientId

Переспрямування для клієнта URI

Відповідність префікс $client. RedirectUri

Якщо елементи в таблиці, крім того, перевірте, якщо ці параметри, що відповідає те, що вони з'являються в AD FS надіслано запит на автентифікацію, і те, що встановлено AD FS. Спробуйте, відтворення проблеми під час захоплення трасування програми Fiddler на запит на автентифікацію, що надсилає застосунок для AD FS. Перевірте параметри запиту зробити такі перевірки, залежно від типу запиту.

OAuth запитів

Запит про OAuth подібних до наведених нижче:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Перевірте, якщо параметри запиту, відповідає налаштування в AD FS.

Запит параметрів.

Параметри, налаштовані на AD FS

client_id

$client.ClientId

redirect_uri

Префікс збіг з @client_RedirectUri

Параметр "ресурси" має являють собою дійсний покладається партії AD FS. Отримати інформацію покладається виробників, виконавши одну з таких дій.

  • Якщо використовується звичайних покладається сторона, виконайте таку команду:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"

  • , Якщо використовується функція застосунку групи у Windows Server 2016, виконайте таку команду:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed запитів

WS-Fed запит подібних до наведених нижче:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Перевірте, якщо параметри запиту, відповідає налаштування в AD FS.

Запит параметрів.

Параметри, налаштовані на AD FS

wtrealm

$rp.Identifier

wreply

Префікс відповідність або $rp, з використанням знаків підстановки. WSFedEndpoint

SAML запити.

Запит SAML подібних до наведених нижче:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Декодувати значення параметра SAMLRequest, за допомогою параметр "З DeflatedSAML" в майстрі Fiddler текст. Декодувати значення подібних до наведених нижче:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Виконайте такі перевірки в межах декодувати значення.

  • Перевірки, якщо хост ім'я значення, призначення відповідає ім'я хоста AD FS.

  • Перевірки, якщо значення постачальник відповідає$rp.Identifier.

Додаткові примітки для SAML

  • $rp. SamlEndpoints: Показує, усі види SAML, кінцеві точки. AD FS відповідь буде надіслано відповідні URL-адреси, налаштувати кінцеві точки. SAML-кінцева можна використовувати перенаправлення, повідомлення або артефактів прив'язки повідомлення. AD FS можна налаштувати всі ці URL-адреси.

  • $rp. SignedSamlRequestsRequired: Якщо значення, SAML запит надіслано з покладається виробників вимогам для підписування. Параметри "SigAlg" і "Підпис" необхідно запит.

  • $rp. RequestSigningCertificate: Це підпису сертифікат, який використовується для створення підпис SAML запит. Переконайтеся, що сертифікат дійсний і зверніться до власника застосунку, відповідно до сертифіката.

Вирішується проблема?

Якщо$rp.EncryptClaimsповернення "Увімкнено", залежить від виробника шифрування увімкнуто. AD FS використовує сертифікат шифрування вимоги. Виконайте такі перевірки.

  • $rp. EncryptionCertificate: Ця команда використовується для отримання сертифіката та перевірити, чи дійсний.

  • $rp. EncryptionCertificateRevocationCheck: Ця команда використовується для перевірки, сертифікат на відповідність анулювання, перевірте вимоги.

Вирішується проблема?

Якщо сертифікат невідповідностей, переконайтеся, що те, що використовують партнери нових сертифікатів. Сертифікати входить об'єднання метаданих, опубліковані сервер AD FS.

Примітка. Партнери, зверніться до всі ваші ресурсів організації або облікового запису організації партнерів представлені у вашому AD FS покладається довіри для виробників і вимог постачальником довіри.

Партнери можуть отримати доступ до об'єднання метаданих

Якщо партнери можуть отримати доступ до об'єднання метадані, зверніться до партнерів для використання нових сертифікатів.

Партнери не вдається отримати доступ до об'єднання метаданих

У такому випадку необхідно вручну надіслати партнери відкритих ключів нових сертифікатів. Щоб це зробити, виконайте такі дії:

  1. Експорт відкритих ключів, .cert файли або файли. p7b містять ланцюгів весь сертифіката.

  2. Надіслати відкритих ключів партнерами.

  3. Запитайте партнерів для використання нових сертифікатів.

Вирішується проблема?

  1. Відкрийте консоль керування AD FS.

  2. Цільовий покладається виробників, клацніть правою кнопкою миші та виберіть Властивості.

  3. На вкладці " Додатково ", виберіть алгоритм, відповідно, потрібен застосунок.
    Relying party trust-Hash algorithm

Вирішується проблема ?

  1. На сервері AD FS дамп видавання перетворення правила, за допомогою такої команди:
    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules

  2. Знайдіть правило, яке проблеми NameIdentifier вимоги. Якщо такі правила, не існує, пропустіть цей крок.
    Ось приклад правила:

    c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

    Повідомлення NameIdentifier формат у такий синтаксис:
    Properties["Property-type-URI"] = "ValueURI"

    Нижче наведені можливі форматів. Перший формат, за замовчуванням.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  3. Запитайте власника застосунку NameIdentifier формат потрібних.

  4. Переконайтеся, що якщо два формати NameIdentifier відповідає.

  5. Якщо у форматах, не збігаються, налаштування, NameIdentifier-стверджують, що має формат, який програми потрібні. Щоб це зробити, виконайте такі дії:

    1. Відкрийте консоль керування AD FS.

    2. Виберіть, Залежить від виробника довіривиберіть відповідну об'єднання партнера та виберіть Тверджень видавання редагування політики в області дії .

    3. Існує проблема NameIdentifier претензії або оновити існуюче правило правило додати нові правила. Виберіть Ім'я посвідчення для вхідних стверджують, що типі вкажіть потрібний формат програми потрібні.
      Configure claim rule

Вирішується проблема?

Зверніть увагу: можна також використовувати програми Fiddler для виправлення неполадок. Ідея в тому ж.

Дамп маркерів застосунок є корисним, під час налагодження проблеми до об'єднання служби підтримки користувачів, а також підтвердження користувача стверджують, що правила. Це не є офіційне рішення, але добре незалежні налагодження рішення, який рекомендовано для виправлення неполадок. За допомогою маркерів дамп застосунку, виконайте такі дії:

  1. Налаштувати скинути маркерів програму, за допомогою наступних команд:
    $authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"https://dumptoken.azurewebsites.net/default.aspx"
    $samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
    Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

  2. Реплікація покладається виробників конфігурації в іншому випадку копію правил оформлення від сторони, що покладається на DumpToken. Для цього, виконайте таку команду:
    Set-ADFSRelyingPartyTrust -TargetName "urn:dumptoken" -IssuanceTransformRules (Get-ADFSRelyingPartyTrust -Name <”your_SrcRP_Name”>).IssuanceTransformRules

  3. Потрібно відкрити одну з наведених нижче посилань, залежно від того, в політиці автентифікації користувача.

    • WS-Fed:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML:https://<Ferderation Instance>/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Форс-декількох факторів автентифікації:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Отримайте претензій, мають увійти в систему на сторінці перевірки автентичності користувача.

  5. У файл дампа маркерів виводу розширення Raw маркерів XML-розділ і потім перегляньте атрибут твердження наступні рядки з перевірки , щоб побачити, якщо вони відповідають, що налаштовано політика видавання претензії :

    • SAML:NameIdentifier: відображає NameIdentifier форматі.

    • SAML:AttributeStatement: це показує, що кожну пару тип/стверджують, для маркера.

    • SAML:AuthenticationStatement: це показує, що метод автентифікації та автентифікації миттєвого.

Вирішується проблема?

За допомогою IdpInititatedSignOn сторінки, щоб перевірити, якщо служба AD FS запущений і функціональні можливості автентифікації працює належним чином. Щоб відкрити сторінку IdpInitiatedSignOn, виконайте такі дії:

  1. Увімкнути IdpInitiatedSignOn сторінку, запустивши наведену нижче команду на сервері AD FS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. На комп'ютері, у внутрішній мережі, відвідайте сторінку:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. На сторінці входу, введіть правильні облікові дані користувача, який дійсний.

Чи Вхід виконано?

Щоб виправити цю неполадку, перевірте, на такі компоненти та послуги.

Доступ до AD FS потрібно вказати безпосередньо до одного з серверів AD FS або балансування навантаження, перед AD FS-серверів. Виконайте такі перевірки.

  • Ping ім'я служби об'єднання (наприклад, fs.contoso.com). Переконайтеся, що якщо IP-адресу, яку ви отримуєте розпізнає AD FS-серверів або балансування навантаження AD FS-серверів.

  • Перевірити, чи є запис "A" об'єднання служби на DNS-сервера. До запису, потрібно вказати AD FS-серверів або балансування навантаження AD FS-серверів.

Вирішується проблема?

  • Перевірки, якщо брандмауер блокує трафіку між:

    • Сервер AD FS і балансування навантаження.

    • У WAP (проксі-застосунок веб) сервер і балансування навантаження, при використанні WAP.

  • Якщо активовано тест пам'яті на балансування навантаження, перевірте наступне:

    • , Якщо ви використовуєте Windows Server 2012 R2, переконайтеся, що на Пакет поновлення серпня 2014 установлено.

    • Переконайтеся, що якщо порт 80 увімкнуто брандмауер на WAP-серверів і AD FS серверів.

    • Переконайтеся, що-тест пам'яті встановлено порт 80 і кінцевої точки/adfs/тест пам'яті.

Вирішується проблема?

  1. На сервері AD FS, відкрийте диспетчер серверів.

  2. У Server Manager, виберіть у меню Знаряддя > служби.

  3. Перевірити, чи станСлужб Федерації Active Directoryпрацює.

Вирішується проблема?

AD FS передбачає різні кінці різними функціями та сценарії. Не всі кінці ввімкнуто за промовчанням. Щоб перевірити стан кінцеві точки, виконайте такі дії:

  1. На сервері AD FS, відкрийте консоль керування AD FS.

  2. Розгорніть служби > кінцеві точки.

  3. Знайдіть кінцеві точки і переконайтеся, що якщо на статус ввімкнуто увімкнено стовпця.
    ADFS Endpoints status

Вирішується проблема?

Корпорація Майкрософт рекомендує, що використання Azure AD підключення, яка полегшує керування SSL-сертифікат.

Azure AD для підключення встановлюється у вашому середовищі?

Якщо інстальовано Azure AD для підключення, переконайтеся, що використовувати для керування та оновлення сертифікати SSL.

Вирішується проблема?

Сертифікат SSL, має відповідати наступним вимогам:

  • Сертифікат, з центру сертифікації довірені кореневі.
    AD FS вимагає, що є сертифікати SSL довірений кореневий центр сертифікації. AD FS доступ з до комп'ютерів, не входить до домену, рекомендовано використовувати SSL-сертифікат із довірений кореневий центр сертифікації, як DigiCert VeriSign тощо. Якщо протокол SSL сертифікат центру сертифікації довірені кореневі, можна зіпсувати SSL повідомлення.

  • Теми ім'я сертифіката припустима.
    Об'єднання ім'я служби, а не ім'я сервера AD FS або інше ім'я, має відповідати назві теми. Щоб отримати об'єднання ім'я служби, виконайте таку команду, на основному сервері AD FS:
    Get-AdfsProperties | select hostname

  • Не відкликання сертифіката.
    Перевіряти відкликання сертифікатів. Якщо це сертифікат, підключення SSL не можна вважати надійною і буде заблоковано клієнти.

Сертифікат SSL, відповідає даним умовам?

Щоб вирішити проблему, отримати кваліфікований сертифікат SSL повідомлення.

Проблему вирішено після використання кваліфікований сертифікат SSL?

Перевірте наступні конфігурації сертифіката SSL.

Необхідно інсталювати сертифікат SSL до особистого сховища на локальному комп'ютері, на кожному сервері ферми об'єднання. Щоб інсталювати сертифікат, двічі клацніть на. Файл PFX сертифікат і дотримуйтесь майстра.

Щоб перевірити, чи інстальовано сертифікат на правильному місці, виконайте такі дії:

  1. Список сертифікатів, які перебувають у сховищі особистих , на локальному комп'ютері, запустіть таку команду:
    dir Cert:\LocalMachine\My

  2. Перевірте, чи сертифікат у списку.

Вирішується проблема?

Отримайте сертифікат, який використовується для SSL повідомлення з відбиток і переконайтеся, що якщо на відбиток збігається з очікуваним сертифікат-відбиток.

Для отримання на Відбиток сертифіката, який використовується, виконайте таку команду, у Windows PowerShell:

Get-AdfsSslCertificate

Якщо це не так сертифіката встановити правильний сертифікат, за допомогою такої команди:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Вирішується проблема?

Сертифікат SSL, потрібно встановити як служба зв'язку сертифікат AD FS фермі. Це не відбудеться автоматично. Щоб перевірити, чи правильно сертифікат встановлено, виконайте такі дії:

  1. На консолі керування AD FS розгорніть вузол служба > сертифікати.

  2. Переконайтеся, що сертифікат до списку служби зв'язку чи очікується сертифіката.

Якщо у списку сертифікат неправильний, правильний сертифікат і потім надайте, AD FS служби, дозвіл на читання сертифікат. Щоб це зробити, виконайте такі дії:

  1. Набір правильний сертифікат:

    1. Сертифікати, клацніть правою кнопкою миші та виберіть Установити сертифікат служби зв'язку.

    2. Виберіть правильний сертифікат.

  2. Перевірте, якщо служба AD FS дозвіл на читання сертифікат:

    1. Додайте оснастка сертифікатів на локальному комп'ютері обліковий запис для консолі керування Microsoft (MMC).

    2. Розгорніть сертифікатів (на локальному комп'ютері) > особистих > сертифікати.

    3. Сертифікат SSL, клацніть правою кнопкою миші, виберіть Усі завдання > Керування приватних розділів.

    4. Переконайтеся, що якщо adfssrv буде в списку групи та користувачів із дозвіл на читання .

  3. Якщо adfssrv немає у списку, надання AD FS служби, дозвіл на читання сертифікат:

    1. Інсталяція, виберіть розташування, клацніть сервер і натисніть кнопку OK.

    2. У групі, Введіть імена об'єктів, щоб вибрати, введіть в nt service\adfssrv, клацніть Перевірити імената натисніть кнопку OK.
      Якщо ви використовуєте AD FS зі служби реєстрації пристрою (DRS), введіть nt service\drs .

    3. Надано дозвіл на читання та натисніть кнопку OK.

Вирішується проблема?

DRS налаштовано AD FS?

Якщо ви налаштували AD FS DRS, переконайтеся, що SSL сертифікат правильно настроєно для RDS. Наприклад, якщо є два УПН-суфіксів contoso.com і fabrikam.com, сертифікат має бути enterpriseregistration.contoso.com і enterpriseregistration.fabrikma.com як додаткових імен суб'єкта (без).

Щоб перевірити, чи сертифікат SSL, має правильний SANs, виконайте такі дії:

  1. Список усіх УПН суфіксів, які використовуються в організації, запустіть таку команду:
    Get-AdfsDeviceRegistratrionUpnSuffix

  2. Перевірте, якщо сертифікат SSL необхідні SANs настроєно.

Сертифікат SSL є DRS правильні імена, як SANs?

Щоб вирішити цю проблему, отримати новий SSL сертифікат, який правильно SANs для DRS та призначити йому SSL сертифікат для AD FS.

Вирішується проблема?

Перевірте, якщо встановлено правильно SSL сертифікат на всіх серверах, WAP

  1. Переконайтеся, що інстальовано протокол SSL-сертифіката у сховищі особистих локального комп'ютера на кожному WAP-сервері.

  2. Отримання сертифіката SSL, які використовуються WAP, запустіть таку команду:
    Get-WebApplicationProxySslCertificate

  3. Якщо сертифікат SSL не так, встановити правильний сертифікат SSL, запустіть таку команду:
    Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint

Перевірте сертифікат прив'язки та їх оновлення, якщо необхідно

Для підтримки не з НДВ випадки, адміністратори, можна вказати резервна прив'язки. Окрім стандартних federationservicename:443, обов'язковими знайдіть резервна прив'язки під такі ідентифікатори в застосунку.

  • {5d89a20c-beab-4389-9447-324788eb944a}
    Це Ідентифікатор застосунку, щоб AD FS.

  • {f955c070-e044-456c-ac00-e9e4275b3f04}
    Це для проксі-сервера веб-застосунку, код застосунку.

Наприклад, якщо сертифікат SSL для резервна прив'язки, як 0.0.0.0:443, переконайтеся, що зв'язування оновлено відповідним чином під час оновлення сертифіката SSL.

Вирішується проблема?

  1. На сервері AD FS, відкрийте диспетчер серверів.

  2. У Server Manager, виберіть у меню Знаряддя > служби.

  3. Перевірити, чи станСлужб Федерації Active Directoryпрацює.

Вирішується проблема?

За допомогою IdpInititatedSignOn сторінки, щоб швидко перевірити, якщо служба AD FS ввімкнута та працює і функціональні можливості автентифікації працює належним чином. Щоб відкрити сторінку IdpInitiatedSignOn, виконайте такі дії:

  1. Увімкнути IdpInitiatedSignOn сторінку, запустивши наведену нижче команду на сервері AD FS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. На комп'ютері, яка не належить до мережі, відвідайте сторінку:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. На сторінці входу, введіть правильні облікові дані користувача, який дійсний.

Чи Вхід виконано?

Щоб виправити цю неполадку, перевірте, на такі компоненти та послуги.

Доступ до AD FS потрібно вказати безпосередньо до одного з серверів WAP (проксі-застосунок веб) або балансування навантаження, перед WAP-серверів. Виконайте такі перевірки.

  • Ping ім'я служби об'єднання (наприклад, fs.contoso.com). Перевірте, чи IP-адресу, яку вирішує Ping одного WAP-сервера або балансування навантаження WAP-серверів.

  • Перевірити, чи є запис "A" об'єднання служби на DNS-сервера. До запису, потрібно вказати WAP-серверів або балансування навантаження WAP-серверів.

Якщо WAP не реалізовано у вашому сценарії для доступ, перевірте Якщоccessing AD FS точки відновлення безпосередньо до одного з серверів AD FS або балансування навантаження, перед серверів AD FS:

  • Ping ім'я служби об'єднання (наприклад, fs.contoso.com). Переконайтеся, що якщо IP-адресу, яку ви отримуєте розпізнає AD FS-серверів або балансування навантаження AD FS-серверів.

  • Перевірте, чи є запис "A" об'єднання служби на DNS-сервера. До запису, потрібно вказати AD FS-серверів або балансування навантаження AD FS-серверів.

Вирішується проблема?

  • Перевірки, якщо брандмауер блокує трафіку між:

    • Сервер AD FS і балансування навантаження.

    • У WAP (проксі-застосунок веб) сервер і балансування навантаження, при використанні WAP.

  • , Якщо активовано тест пам'яті на балансування навантаження, перевірте наступне:

    • , Якщо ви використовуєте Windows Server 2012 R2, переконайтеся, що на Пакет поновлення серпня 2014 установлено.

    • Переконайтеся, що якщо порт 80 увімкнуто брандмауер на WAP-сервер і AD FS серверів.

    • Переконайтеся, що-тест пам'яті, що встановлено порт 80 і /adfs/probe-кінцевої точки.

Вирішується проблема?

  1. Перевірте, чи вхідний трафік через TCP-порт 443 увімкнуто.

    • tвін брандмауера між веб-застосунок проксі-сервер і об'єднання серверну ферму.

    • брандмауер між клієнтами та веб-застосунок проксі-сервер.

  2. Перевірте, чи увімкнуто вхідний трафік через TCP-порт 49443 брандмауер між клієнтами та веб-застосунок проксі-сервер, за таких умов:

    • Автентифікація TLS клієнта, використовуючи x. 509 сертифікат увімкнуто.

    • Використовується AD FS Windows Server 2012 R2.

      Примітка. Конфігурація не є обов'язковим брандмауер на веб-застосунок проксі-сервер і об'єднання-серверів.

Вирішується проблема?

 

Вирішується проблема?

AD FS передбачає різні кінці різними функціями та сценарії. Не всі кінці ввімкнуто за промовчанням. Щоб перевірити, що до того кінцевої точки ввімкнуто проксі-сервер, виконайте такі дії:

  1. На сервері AD FS, відкрийте консоль керування AD FS.

  2. Розгорніть служби > кінцеві точки.

  3. Знайдіть кінцевої точки і перевірте, чи увімкнуто стан Проксі-сервера з підтримкою стовпця.
    ADFS endpoints proxy status

 

Вирішується проблема?

Примітка Відомості на цій сторінці, застосовується до AD FS-2012 R2 та пізніших версій.

Якщо у веб-застосунку проксі-сервера (WAP) розгортання проксі-довірчий зв'язок має бути встановлено WAP-сервер і сервер AD FS. Перевірте, якщо встановлено проксі-довірчий зв'язок, або починається не на підвищенням часу.

Довідкова інформація

Проксі-сервер-довірчий зв'язок, є сертифікат клієнта, на основі. Після запуску майстра після інсталяції проксі-сервера веб-застосунку, майстер, створює власним підписом клієнтський сертифікат, що за допомогою облікових даних, зазначений у вікні майстра. Потім майстер вставки сертифікат до бази даних конфігурації AD FS та додано до сховища сертифікатів AdfsTrustedDevices на сервері AD FS.

Будь-які SSL зв'язку HTTP. sys використовує такий порядок пріоритетів для SSL сертифікат прив'язки, відповідно до сертифіката:

Пріоритет

Ім'я

Параметри

Опис

1

IP

IP:port

Точне IP і Port відповідність

2

СНАЙ

Hostname:port

Точне hostname відповідність (підключення потрібно вказати НДВ)

3

CCS

Порт

Виклик у-сховище сертифікатів

4

IPv6 підстановки

Порт

IPv6-знаків підстановки (підключення має бути IPv6)

5

IP-підстановки

Порт

IP-знаків підстановки (підключення може бути IPv4 або IPv6)

AD FS 2012 R2 і пізніше, незалежно від інформаційних служб Інтернету (IIS) та працює як служба на http. sys. -hostname:port SSL сертифікат прив'язки, які використовуються AD FS. Під час автентифікації сертифікат клієнта AD FS, надсилає список довірених сертифікатів (CTL) на основі сертифікати у сховищі AdfsTrustedDevices. Якщо є SSL сертифікат зв'язування для сервера AD FS, використовує IP:port або CTL магазину не AdfsTrustedDevices, проксі-сервер, довірчих відносин може не встановлено.

Отримайте прив'язки сертифіката SSL для AD FS

На сервері AD FS, виконайте таку команду в оболонці Windows PowerShell:
netsh http show sslcert

У списку прив'язки, що повертається знайдіть з 5d89a20c-beab-4389-9447-324788eb944a, Ідентифікатор застосунку. Ось приклад контролерам прив'язки. Зверніть увагу, жирний частин.

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Виправлення неполадок

Автоматичне розпізнавання, проблеми з проксі-довірчий зв'язок, запустіть наведений нижче сценарій. На основі Виявлено проблему, виконайте дії відповідно в кінці сторінки.

param

(

  [switch]$syncproxytrustcerts

)

function checkhttpsyscertbindings()

{

Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")

$httpsslcertoutput = netsh http show sslcert

$adfsservicefqdn = (Get-AdfsProperties).HostName

$i = 1

$certbindingissuedetected = $false

While($i -lt $httpsslcertoutput.count)

{

        $ipport = $false

        $hostnameport = $false

        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }

        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }

        # Check for IP specific certificate bindings

        if ( ( $ipport -eq $true ) )

        {

            $httpsslcertoutput[$i]

            $ipbindingparsed = $httpsslcertoutput[$i].split(":")

            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )

            {

                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning

                $certbindingissuedetected = $true

            }

            $i = $i + 14

            continue

        }

        # check that CTL Store is set for ADFS service binding

        elseif ( $hostnameport -eq $true )

        {

            $httpsslcertoutput[$i]

            $ipbindingparsed = $httpsslcertoutput[$i].split(":")

            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )

            {

                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"

                $certbindingissuedetected = $true

            }

        $i = $i + 14

        continue

        }

    $i++

}

If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }

}

function checkadfstrusteddevicesstore()

{

# check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store

Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"

$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}

If ( $certlist.count -gt 0 )

{

    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"

    $certlist | Format-List Subject

}

Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }

}

function checkproxytrustcerts

{

    Param ([bool]$repair=$false)

    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")

    $doc = new-object Xml

    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")

    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString

    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"

    $cli = new-object System.Data.SqlClient.SqlConnection

    $cli.ConnectionString = $connString

    $cmd = new-object System.Data.SqlClient.SqlCommand

    $cmd.CommandText = $command

    $cmd.Connection = $cli

    $cli.Open()

    $configString = $cmd.ExecuteScalar()

    $configXml = new-object XML

    $configXml.LoadXml($configString)

    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2

    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices

    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")

    $store.open("MaxAllowed")

    $atLeastOneMismatch = $false

    $badCerts = @()

    foreach($rawCert in $rawCerts)

    {   

        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')

        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)

        $now = Get-Date

        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))

        {

            $certThumbprint = $cert.Thumbprint

         $certSubject = $cert.Subject

         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue

         if ($ctlMatch -eq $null)

         {

       $atLeastOneMismatch = $true

          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"

       if ($repair -eq $true)

       {

        write-Warning "Attempting to repair"

        $store.Add($cert)

        Write-Warning "Repair successful"

       }

                else

                {

                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")

                }

         }

        }

    }

    $store.Close()

    if ($atLeastOneMismatch -eq $false)

    {

     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")

    }

}

checkhttpsyscertbindings

checkadfstrusteddevicesstore

checkproxytrustcerts($syncproxytrustcerts)

Write-Host; Write-Host("All checks completed.")

Що таке, що Виявлено проблему?

Зв'язування IP:port триває, високий пріоритет. Якщо в IP:port зв'язування прив'язки AD FS SSL-сертифікат, HTTP. sys завжди використовує сертифікат для прив'язки у зв'язку з SSL. Щоб вирішити цю проблему, скористайтеся наведеними нижче способами.

Спосіб 1: Видалення, IP:port зв'язування

Зауважте, що IP:port зв'язування може стати знову після того, як його видалено. Наприклад, застосунок настроєно за допомогою цього IP:port, Прив'язка може автоматично відновити на наступному запуску служби.

Спосіб 2: Іншу IP-адресу для використання AD FS SSL зв'язку

Якщо IP:port зв'язування, усунення ADFS служба повне доменне ім'я, до іншої IP-адреси не використовується в будь-який прив'язки. Таким чином, HTTP. sys Hostname:port зв'язування для використання протоколу SSL зв'язку.

Спосіб 3: Set-AdfsTrustedDevices як CTL чекає IP:port зв'язування

Це останнім засобом, якщо не вдається скористатися методами, вище. Але краще зрозуміти такі умови, що перед зміненням CTL, зберігання за промовчанням для AdfsTrustedDevices:

  • Є причини, the IP:port зв'язування.

  • Якщо зв'язування залежить від CTL зберігання, для перевірки автентичності для сертифіката клієнта за промовчанням.

Вирішується проблема?

Якщо інстальовано Azure AD-підключення, використовувати сад, підключіть CTL сховища ім'я для AdfsTrustedDevices для прив'язки сертифіката SSL, на всіх серверах з AD FS. Azure AD-підключення не встановлено, повторно створити AD FS сертифікат прив'язки, запустивши наведену нижче команду на всіх серверах з AD FS.
Set-AdfsSslCertificate -Thumbprint Thumbprint

Вирішується проблема?

Якщо сховище сертифікатів, де лише сертифікати із власним підписом зазвичай буде існувати CA випущено сертифікат, CTL, які створюються в магазині буде містити лише випущено сертифікат CA. AdfsTrustedDevices сховища сертифікатів, є магазин, який повинен мати лише сертифікати із власним підписом. Цих сертифікатів є:

  • MS-організації доступу: Власним підписом сертифікат для об'єднання сертифікати-видавець на робочому місці.

  • ADFS проксі довіряти: Сертифікатів для кожного веб-застосунок проксі-сервера.

AdfsTrustedDevices certificates

Таким чином, видаліть усі сертифікати, CA, випущені з AdfsTrustedDevices сховища сертифікатів.

Вирішується проблема?

Під час встановлення проксі-сервер довірчий зв'язок із серверів AD FS записування до бази даних конфігурації AD FS та додати до сховища сертифікатів AdfsTrustedDevices на сервері AD FS сертифікат клієнта. Для розгортання ферми з AD FS сертифікат клієнта, як очікується, буде синхронізовано з інших серверів AD FS. Якщо синхронізації, не відбувається з якихось причин, довірчий зв'язок проксі-сервер працює тільки довіри, було створено із сервером AD FS, але не з інших серверів AD FS.

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

Спосіб 1

Інсталюйте оновлення, описані у KB 2964735 на всіх серверах з AD FS. Після інсталяції оновлення синхронізації сертифіката клієнта очікується автоматичну.

Спосіб 2

Запуск сценарію з-syncproxytrustcerts перехід на синхронізацію вручну клієнта сертифікати до сховища сертифікатів AdfsTrustedDevices AD FS бази даних конфігурації. Сценарій, слід запускати на всіх серверах AD FS ферми.

Зверніть увагу, що це не постійне рішення, оскільки Клієнтські сертифікати, буде оновлено на постійній основі.

Вирішується проблема?

Перевірте, чи часу "або" часовий пояс невідповідності. Якщо час не в зоні, але не відповідає часу, проксі-сервер, довірчих відносин також не буде створений.

Вирішується проблема?

Якщо SSL припинення, відбувається на пристрої мережі між AD FS сервери та WAP-сервер, зв'язок між AD FS і WAP буде розірвати через те, що повідомлення на основі сертифікат клієнта.

Вимкнення SSL припинення на мережні пристрої AD FS та WAP-серверах.

Вирішується проблема?

Перевірте Windows інтегровану автентифікацію. параметри у браузері клієнта, AD FS настройки та автентифікація запит параметрів.

Перевірте браузер клієнта користувача

Перевірте настройки Властивості браузера.

  • На вкладці " Додатково " переконайтеся, що, Увімкнути інтегрована автентифікація Windows параметр увімкнуто.

  • Після безпеки > Локальна інтрамережа > сайти > Додатково, переконайтеся, що AD FS URL-адресу веб-сайти до списку.

  • Нижче безпеки > Локальна інтрамережа > інший, переконайтеся, що вибрано параметр автоматичного входу до системи, лише в зоні Інтранету .

Якщо ви використовуєте Firefox, Chrome або Safari, переконайтеся, що ввімкнено відповідний параметри цих браузерів.

Перевірте настройки AD FS

Перевірте настройки WindowsIntegratedFallback

  1. Відкрийте оболонку Windows PowerShell запустити як адміністратор варіант.

  2. Отримайте політика глобального автентифікації, запустіть таку команду:
    Get-ADFSGlobalAuthenticationPolicy

  3. Перевірте значення атрибута WindowsIntegratedFallbackEnbaled.

Якщо значення True, автентифікацію на основі форм, як очікується. Це означає, що на запит на автентифікацію, що відбудеться у браузері, який не підтримує у Windows інтегровану автентифікацію. Див. наступний розділ про те, як отримати підтримки браузера.

Якщо значення False, слід очікувати інтегрованої автентифікації в ОС Windows.

Перевірте настройки WIASupportedUsersAgents

  1. Отримати Перелік підтримуваних клієнтських, запустіть таку команду:
    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  2. Перегляньте список рядок агента користувача, який команда повертає.

Перевірте, чи рядок агента користувача, браузера у списку. Якщо ні, додайте рядок агента користувача, виконавши наведені нижче дії:

  1. Перейдіть до http://useragentstring.com/ , виявлення та відображається рядок агента користувача, браузера.

  2. Отримати Перелік підтримуваних клієнтських, запустіть таку команду:
    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  3. Додайте рядок агента користувача, браузера, запустіть таку команду:
    $wiaStrings = $wiaStrings+"NewUAString"
    Наприклад:$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"

  4. Оновлення WIASupportedUserAgents настройку за допомогою такої команди:
    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

Перевірте параметри запит на автентифікацію

Перевірте, якщо запит автентифікації визначає автентифікацію на основі форм, як метод автентифікації

  1. Якщо запит автентифікації WS-об'єднання запит, перевірки, якщо запит містить wauth = urn: Оазис: імена: змісту: SAML:1.0:am:password.

  2. Якщо SAML запит на запит на автентифікацію, перевірте, якщо запит містить samlp:AuthnContextClassRef елемент зі значенням urn: Оазис: імена: змісту: SAML:2.0:ac:classes:Password.

Щоб отримати додаткові відомості див. Огляд автентифікації обробники AD FS- сторінок для входу в.

Перевірте, чи застосунок Microsoft Online Services для служби Office 365

Якщо застосунок, який потрібно отримати доступ до служби Microsoft Online Services, що виникають очікується керує вхідний запит на автентифікацію і . Роботи застосунків власник , щоб змінити поведінку.

Якщо застосунок Microsoft Online Services, що виникають може, керує на PromptLoginBehavior налаштування надійного область об'єкта. Цей параметр визначає чи Azure AD орендарів надсилання термінових = увійти в AD FS. Для встановлення на PromptLoginBehavior настройкувиконайте наведені в цих дії:

  1. Відкрийте оболонку Windows PowerShell, режим "Запуск із правами адміністратора".

  2. Отримайте параметр об'єднання існуючого домену, запустіть таку команду:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  3. Встановіть параметр PromptLoginBehavior, запустіть таку команду:
    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>

    Значення параметра PromptLoginBehavior є:

    1. TranslateToFreshPasswordAuth: Azure AD надсилає wauth і wfresh AD FS, відмінний від того, = входу. Це призводить до на запит на автентифікацію, для використання автентифікації на основі форм.

    2. NativeSupport: параметр входу запитувати = надсилається як AD FS.

    3. Вимкнуто: нічого не надсилаються до AD FS.

Щоб дізнатися більше про команди Set-MSOLDomainFederationSettings, див. запит на об'єднання служб Active Directory = входу параметра підтримки.

Вирішується проблема?

Декількох факторів автентифікацію ввімкнуто в серверів AD FS у покладається учасника, або у на автентифікацію, запит параметр. Перевірте конфігурацію, щоб побачити, якщо вони правильно встановлено. Якщо у кількох факторів автентифікації очікується але ви'повторно неодноразово запит на його, перевірте, покладається виробників видавання правила, щоб побачити, якщо вимоги для декількох факторів автентифікації передаються через застосунку.

Щоб отримати додаткові відомості про автентифікацію на кількох факторів в AD FS див. у наступних статтях:

Перевірка параметрів конфігурації на сервер AD FS і покладається партії

Для перевірки параметрів конфігурації на сервер AD FS, перевірки, правила глобального додаткові автентифікації. Для перевірки параметрів конфігурації на покладається виробників, перевірки, додаткові автентифікації правила покладається виробників довіри.

  1. Для перевірки параметрів конфігурації на сервер AD FS, виконайте таку команду, у вікні Windows PowerShell.
    Get-ADFSAdditionalAuthenticationRule

    Щоб перевірити конфігурацію на покладається виробників, виконайте таку команду:
    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules

    Примітка. Якщо команди не дав нічого, правила додаткові автентифікації не настроєно. Пропустіть цей крок.

  2. Дотримуватися претензії правило, значення, настроєні.

Переконайтеся, що якщо включено автентифікацію на кількох факторів претензії правило набору

Набір правил претензії входять такі розділи:

  • Умова заяви:C:[Type=…,Value=…]

  • Твердження проблема:=> issue (Type=…,Value=…)

Якщо проблема твердження, містить такі вимоги, вказано автентифікацію на кількох факторів.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Ось приклади, які потребують автентифікації в кількох факторів можна використовувати для пристроїв, реєстрація не на робочому місці, так і для мережі екстранет відповідно:

  • c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

  • c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Перевірити покладається правила оформлення партії

Якщо користувач отримує повторно запити на автентифікацію на кількох факторів після того, як вони виконувати першим автентифікації, цілком можливо, що відповідь виробників не проходить через декількох факторів автентифікації вимоги до програми. Щоб перевірити автентифікації вимоги, що передаються через, виконайте такі дії:

  1. У Windows PowerShell, виконайте таку команду:
    Get-ADFSRelyingPartyTrust -TargetName ClaimApp

  2. Дотримуватися правила встановлення визначено в IssuanceAuthorizationRules або IssuanceAuthorizationRulesFile атрибутів.

Набір правил, повинен містити такі правила випуск проходити крізь претензії декількох факторів автентифікації:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==” http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)

Перевірте параметр запит на автентифікацію

Перевірте, якщо запит автентифікації вказує на кількох факторів автентифікації як метод автентифікації

  • Якщо запит автентифікації WS-об'єднання запит, перевірки, якщо запит містить wauth = http://schemas.microsoft.com/claims/multipleauthn.

  • Якщо SAML запит на запит на автентифікацію, перевірте, якщо запит містить samlp:AuthnContextClassRef елемент зі значенням http://schemas.microsoft.com/claims/multipleauthn.

Щоб отримати додаткові відомості див. Огляд автентифікації обробники AD FS- сторінок для входу в.

Перевірте, чи застосунок Microsoft Online Services для служби Office 365

Якщо застосунок, який потрібно отримати доступ до служби Microsoft Online Services для служби Office 365, перевірте налаштування об'єднання SupportsMFA домену.

  1. Отримайте поточні настройки об'єднання SupportsMFA домену, запустіть таку команду:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  2. Якщо параметр SupportsMFA FALSE, встановіть для нього значення TRUE, запустивши таку команду:
    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE

Вирішується проблема?

Вимкнути можливість запитувати = входу, запустіть таку команду:
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Після виконання цієї команди Office 365 програми не буде включено запитувати = параметр входу кожного запиту на автентифікацію.

Вирішується проблема?

Змінити параметр запит використовувати метод автентифікації, очікування.

Вирішується проблема?

Якщо це єдиний вхід вимкнуто, увімкніть її.

Вирішується проблема?

Вітаємо! Єдиний вхід проблему вирішено.

Ми, на жаль, що проблема не зникне. Ми будемо вдячні, якщо заливка опитування з детальний опис вашої проблеми.

Що робити цей посібник?

Усуває єдиного входу (SSO), проблеми з Active Directory (AD FS) об'єднання служби.

Що це за?

Адміністратори, які допомагають діагностувати, єдиного входу проблеми для користувачів, що їх.

Як працює?

Ми почнемо з проханням проблеми, які стикаються користувачі. Потім буде направлено через ряд виправлення неполадок, які стосуються вашої ситуації.

Приблизний час завершення:

30-45 хвилин.

Потрібна додаткова довідка?

Отримуйте нові функції раніше за інших
Приєднатися до Microsoft оцінювачів

Ця інформація корисна?

Наскільки ви задоволені якістю мови?
Що вплинуло на ваші враження?

Дякуємо за відгук!

×