Кратък преглед

При опит за влизане в продукти, услуги или мобилни приложения на Adobe с Federated ID (SSO) се получава едно от следните съобщения за грешка:

След успешно конфигуриране на SSO в Администраторската конзола на Adobe, уверете се, че сте отбелязали Изтегляне на метаданни и сте записали в компютъра си файла с метаданни SAML XML.Вашият доставчик на самоличност изисква този файл, за да разреши влизане с еднократно удостоверяване.Трябва да импортирате правилно конфигурационните данни от XML файла във вашия доставчик на самоличност (IdP). Това е необходимо за SAML интеграцията с вашия IdP и ще гарантира, че данните са конфигурирани правилно.

По-долу са дадени някои често срещани проблеми с конфигурирането:

  • Сертификат е във формат, различен от PEM.
  • Сертификат, който има разширение, различно от .cer. .pem и .cert, няма да работи.
  • Сертификатът е криптиран.
  • Сертификатът е в едноредов формат. Изисква се многоредов.
  • Проверката за анулирани сертификати е включена (не се поддържа в момента).
  • Доставчикът на самоличност в SAML се различава от този, който е посочен в администраторската конзола (например при грешка в изписването, липсват букви – написано е http вместо https).

Ако имате въпроси за това как да използвате файла с метаданни SAML XML, за да конфигурирате вашия IdP (доставчик на самоличност), обърнете се директно към вашия доставчик на самоличност за инструкции, които може да са различни за различните IdP.

Ето някои примери за конкретни IdP (списъкът не е изчерпателен – става за всеки IdP, съвместим със SAML 2):

Okta: Вземете ръчно необходимата информация от XML файл, като я въведете в правилните UI полета, за да конфигурирате правилно данните.

Ping Federate: Качете XML файл или въведете данните в правилните UI полета.

Microsoft ADFS: Вашият сертификат трябва да бъде в PEM формат, но за ADFS по подразбиране е зададен DER формат. Можете да конвертирате сертификата, като използвате командата openssl, която е налична в OS X, Windows и Linux и се задава, както следва:

openssl x509 -in certificate.cer -out certificate.pem -outform PEM

След като изпълните горната стъпка, преименувайте сертификата и му сложете разширение .cer.

Също така се уверете, че се използва правилният сертификат. Ако имате повече от един сертификат; той трябва да бъде същият, с който ще бъдат подписвани заявките. (Например, ако заявките се подписват със сертификат "за подписване с код", тогава това е сертификатът, който трябва да се използва.) Проверката за анулирани сертификати трябва да е изключена.

Ако сте конфигурирали вашия IdP по най-добрия начин, който знаете, опитайте едно или повече от следните неща, в зависимост от получената грешка.

Връзка за изтегляне на метаданни

Основни положения при отстраняване на проблеми

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

  • На потребителя е зададена конфигурация на продукт с право на използване.
  • Собственото име на потребителя, фамилното име и имейл адресът се изпращат в SAML точно както са посочени в таблото на организацията, и присъстват в с правилни етикети.
  • Проверете всички записи в администраторската конзола и при вашия доставчик на самоличност за правописни или синтактични грешки.
  • Настолното приложение на Creative Cloud е актуализирано до последната си версия.
  • Потребителят влиза на правилното място (настолно приложение на CC, приложение на CC или adobe.com)

Грешка "Възникна грешка" с бутона с надпис "Опитайте отново"

Възникна грешка – ОПИТАЙТЕ ОТНОВО

Тази грешка обикновено се случва след успешно удостоверяване на потребителя и когато Okta успешно препрати отговора за удостоверяване в Adobe.

В Администраторската конзола на Adobe проверете следното:

В раздел „Самоличност“:

  • Уверете се, че свързаният домейн е бил активиран.

В раздел „Продукти“:

  • Уверете се, че потребителят е свързан към правилния псевдоним на продукт и в домейна, който сте обявили за конфигуриране като Federated ID.
  • Уверете се, че псевдонимът на продукта има зададени правилни права за използване.

В раздел „Потребители“:

  • Уверете се, че потребителското име на потребителя е под формата на пълен имейл адрес.

Грешка при влизане: „Достъпът е отказан“

Грешка „Достъпът е отказан“

Възможни причини за тази грешка:

  • Собственото име, фамилното име или имейл адресът, които са изпратени в SAML потвърждението, не съответстват на информацията въведена в административната конзола.
  • Потребителят не е свързан с правилния продукт или продуктът не е свързан с правилно право на използване.
  • Потребителското име в SAML се появява като нещо различно от имейл адрес. Всички потребители трябва да са в домейна, който сте заявили в процеса на конфигуриране.
  • Вашият SSO клиент използва Javascript като част от процеса на влизане, а вие се опитвате да влезете в клиент, който не поддържа Javascript (като например Creative Cloud Packager).

Как да решите проблема:

  • Проверете конфигурацията в таблото на потребителя: информацията за потребителя и конфигурацията на продукта.
  • Изпълнете SAML Тrace и проверете дали изпратената информация съвпада с тази от таблото, а след коригирайте несъответствията.

Грешка „В момента е влязъл друг потребител“

Грешката „В момента е влязъл друг потребител“ възниква, когато атрибутите, изпратени в SAML потвърждението, не съвпадат с имейл адреса, който е използван за стартиране на процеса на влизане.

Проверете атрибутите в SAML потвърждението и се уверете, че те отговарят точно на идентификатора, който потребителят се опитва да използва, като също така съвпадат точно с информацията от администраторската конзола.

Грешка "Неуспешно обаждане като принципал на системата" или "Неуспешно създаване на потребител"

Грешката "Неуспешно обаждане като принципал на системата" (последвана от произволен код) или "Неуспешно създаване на потребител" показва проблем с атрибутите на SAML. Уверете се, че имената на атрибутите използват правилен клавиатурен регистър (големите и малките букви в името имат значение): FirstName, LastName, Email. Например, ако завършите атрибута с "email" вместо "Email", може да предизвикате тези грешки.

Тези грешки също така могат да възникнат, ако SAML потвърждението не съдържа имейл адреса на потребителя в Тема > елемент NameId (когато използвате SAML Tracer, този елемент трябва да е във формат EmailAddress, като действителният имейл трябва да се представи като текст).  

Ако имате нужда от помощ от Adobe, моля включете SAML проследяване.

 

Грешка "В SAML отговора издателят не съответства на издателя, който е конфигуриран като доставчик на самоличност"

IDP издателят в SAML потвърждението е различен от този, който е конфигуриран във входящия SAML файл. Погледнете за правописни грешки (като например смяната на https с http). При проверка на низа на IDP издателя в SAML системата на клиента трябва да търсите ТОЧНО съвпадение на низа, който той е дал. Този проблем се появява понякога, защото наклонената черта в края липсва.

Ако имате нужда от помощ за тази грешка, представете SAML следата и стойностите, които сте въвели в таблото на Adobe.

Грешка "Електронният подпис в SAML отговора не отговаря на сертификата на доставчика на самоличност"

Файлът на сертификата най-вероятно е некоректен и трябва да бъде качен отново. Този проблем обикновено се случва, след като е направена промяна и администраторът посочва файл на неправилен сертификат.  Също така проверете типа на формата (трябва да бъде PEM формат за ADFS).

Грешка "Текущият час е преди часовия диапазон, посочен в условията на потвърждението"

Windows:

Или коригирайте системния часовник, или коригирайте стойността на времевото отместване.

Настройка на времето на системата:

Проверете системния часовник с тази команда:

w32tm /query /status

Можете да коригирате системния часовник на Windows Server със следната команда:

w32tm /resync

Ако системният часовник е настроен правилно, може да се наложи да създадете толеранс за разликата между IDP и системата, която той удостоверява.

Отместване на часовника

Започнете със задаване на допустимо отместване от 2 минути. Проверете дали можете да се свържете и след това или увеличете, или намалете стойността, в зависимост от резултата. Намерете подробна информация в базата знания на Microsoft

Казано накратко, от PowerShell можете да изпълните следните команди:

Get-ADFSRelyingPartyTrust –identifier “urn:party:sso”  #Само за да видите какви са били първоначалните стойности
Set-ADFSRelyingPartyTrust –TargetIdentifier “urn:party:sso” –NotBeforeSkew 2  #Задаване на отместване от 2 минути

където "urn:party:sso" е един от идентификаторите за вашето лице

Забележка: Можете да използвате Get-ADFSRelyingPartyTrust cmdlet без параметри, за да получите всички надеждни обекти за лицето.

Системи, базирани на UNIX:

Уверете се, че системният часовник е настроен правилно, например със следната команда:

ntpdate -u pool.ntp.org

Получателят, който е посочен в SubjectConfirmation, не съвпадна с идентификационен номер на нашия доставчик на услуги

Проверете атрибутите, тъй като те трябва да съвпадат точно (големите и малките букви са от значение) с: FirstName, LastName, Email. Това съобщение за грешка може да означава, че в някой от атрибутите са използвани грешно главни или малки букви, като например "email" вместо "Email."  Също така проверете стойността за получателя – тя трябва да сочи към ACS низа.

ACS низ

Грешка 401, неоторизирани идентификационни данни

Тази грешка се появява, когато приложението не поддържа федерирано влизане, и трябва да влезете с вашия Adobe ID. Framemaker, RoboHelp и Captivate са примери за приложения с това изискване.

Грешка "Неуспешно влизане с входящ SAML файл: SAML отговорът не съдържа потвърждения"

Проверете работния процес за влизане. Ако имате достъп до страницата за влизане от друга машина или мрежа, но не и вътрешно, проблемът може да бъде в низ на блокиращ агент.  Също така изпълнете SAML проследяване и потвърдете, че собственото име, фамилното име и потребителското име (зададено като правилно форматиран имейл адрес) са в SAML темата.

Грешка 400, неправилна заявка / Грешка "Статусът на SAML заявката сочи, че тя не е била успешна" / Неуспешна проверка на SAML сертифицирането

Грешка 400, неправилна заявка

Проверете дали е било изпратено правилно SAML потвърждение:

  • Проверете дали доставчикът на самоличност предава следните атрибути (малките и големите букви имат значение) в SAML потвърждението: FirstName, LastName, Email. Ако тези атрибути не са конфигурирани в IdP, за да бъдат изпратени като част от конфигурацията на SAML 2.0 Connector, удостоверяване няма да работи.
  • В темата няма елемент NameID. Проверете дали елементът „Тема“ съдържа елемент NameId. Той трябва да съвпада с атрибута Email, който би трябвало да бъде имейл адреса на потребителя, който искате да удостоверите.
  • Правописни грешки – особено лесно се допуска замяната на https с http.
  • Проверете дали е осигурен правилният сертификат. Доставчиците на самоличност (IDP) трябва да бъде конфигурирани така, че да използват некомпресирани SAML заявки/отговори. Протоколът с входящ SAML файл за Okta работи само с некомпресирани настройки (а не с компресирани).

Помощна програма като SAML Tracer за Firefox може да помогне за разкомпресирането на потвърждението и показването му за проверка. Ако поискате помощ от Adobe, ще бъдете попитани за този файл. 

Следващият работен пример може да ви помогне за правилното форматиране SAML потвърждението:

Изтегляне

С Microsoft ADFS:

  1. Всеки акаунт в Active Directory трябва да има имейл адрес, отбелязан в Active Directory, за да се влиза успешно в системата (Регистър на събитията: SAML отговорът не съдържа елемент NameId в потвърждението). Проверете първо това.
  2. Отидете на таблото
  3. Щракнете върху раздела „Самоличност“ и изберете домейн.
  4. Щракнете върху „Редактиране на конфигурацията“.
  5. Открийте „IDP обвързване“. Превключете на HTTP-POST и след това запишете. 
  6. Тествайте отново влизането.
  7. Ако то работи, но предпочитате предишната настройка, просто се върнете към HTTP-REDIRECT и качете отново метаданните в ADFS.

С други IdP:

  1. Възникването на грешка 400 означава, че едно иначе успешно влизане е било отхвърлено от вашия IdP.
  2. Проверете регистрационните файлове на вашия IdP, за да разберете защо се появява тази грешка.
  3. Коригирайте проблема и опитайте отново.

Конфигуриране на Microsoft ADFS

Вижте постъпковите указания за конфигуриране на Microsoft ADFS.

Ако Mac клиент има празен прозорец в Creative Cloud, уверете се, че потребителският агент "Creative Cloud" е надежден.

Конфигуриране на Microsoft Azure

Вижте постъпковите указания за конфигуриране на Microsoft Azure.

Конфигуриране на OneLogin

Вижте постъпковите указания за конфигуриране на OneLogin.

Конфигуриране на Okta

Вижте постъпковите указания за конфигуриране на Okta.

Този материал е лицензиран под лиценз Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported  Публикациите в Twitter™ и Facebook не попадат под клаузите на Creative Commons.

Правни бележки   |   Правила за онлайн поверителност