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

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

След успешно конфигуриране на SSO в Adobe Admin Console, уверете се, че сте отбелязали Изтегляне на метаданни и сте записали в компютъра си файла с метаданни 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 Admin Console проверете следното:

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

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

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

  • Уверете се, че потребителят е свързан към правилния псевдоним на продукт и в домейна, който сте обявили за конфигуриране като 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).

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

IdP сървър, базиран на Windows:

1. Уверете се, че системният часовник е синхронизиран със сървър за точно време

Проверете точността на системния часовник спрямо вашия времеви сървър с тази команда; Стойността "Фаза на отклонение/Phase Offset" трябва да бъде малка част от секундата:

w32tm /query /status /verbose

Можете да предизвикате незабавна повторна синхронизация на системния часовник със сървър за време със следната команда:

w32tm /resync

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

2. Увеличете допустимата разлика в системния часовник между сървъри

От прозорец на Powershell с администраторски права задайте допустимата стойност за отклонение да е 2 минути. Проверете дали можете да се влезете в системата и след това или увеличете, или намалете стойността, в зависимост от резултата.

Определете текущата настройка за отклонение във времето за релевантната довереност на проверяващата страна със следната команда:

Get-ADFSRelyingPartyTrust | Format-List -property Identifier,Name,NotBeforeSkew

Довереността на проверяващата страна се идентифицира чрез URL адреса, показан в полето „Идентификатор/Identifier" на изхода на предходната команда за тази конкретна конфигурация. Този URL адрес се вижда и в помощната програма за управление на ADFS в прозореца за свойства на релевантната довереност на проверяващата страна в таб "Идентификатори" в полето „Довереност на проверяващата страна ", както е показано на екрана по-долу.

Задайте отклонението на време да е 2 минути със следната команда, като заместите съответно адреса на идентификатора:

Set-ADFSRelyingPartyTrust –TargetIdentifier 'https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx' –NotBeforeSkew 2  

relying_party_identifier

IdP сървър, базиран на UNIX

Уверете се, че системният часовник е настроен правилно или с помощта на ntpd услугата, или ръчно с командата ntpdate от root shell или със sudo, както е показано по-долу (имайте предвид, че ако времето бъде изместено с повече от 0,5 секунди, промяната няма да се отрази веднага, а системният часовник ще бъде коригиран постепенно). Уверете се, че и часовата зона е зададена правилно.

# ntpdate -u pool.ntp.org

Бележка:

Това сработва при доставчици на самоличност като Shibboleth.

Получателят, който е посочен в 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.

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

Вижте поетапните указания за конфигуриране на Centrify.

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

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