Enterprise Server 3.15 в настоящее время доступен в качестве кандидата на выпуск.

Устранение неполадок с проверкой подлинности SAML

Если вы используете единый вход SAML и пользователи не могут пройти проверку подлинности для доступа к GitHub, можно устранить проблему.

В этой статье

Сведения о проблемах с проверкой подлинности SAML

GitHub Enterprise Server регистрирует сообщения об ошибках проверки подлинности SAML в systemd journal logs для github-unicorn контейнера. Ответы можно просмотреть в этот журнал, а также настроить более подробное ведение журнала.

Дополнительные сведения о требованиях к ответу SAML см. в разделе "Справочник по конфигурации SAML".

Настройка отладки SAML

Вы можете настроить GitHub Enterprise Server для записи подробных журналов отладки для каждой попытки проверки подлинности SAML. Возможно, вы сможете устранить неполадки неудачных попыток проверки подлинности с помощью этих дополнительных выходных данных.

Warning

  • Включайте отладку SAML только на время и отключайте ее сразу после завершения устранения неполадок. Если вы оставьте возможность отладки включено, размер logs увеличивает гораздо быстрее, чем обычно, что может негативно повлиять на производительность GitHub Enterprise Server.
  • Проверьте новые параметры проверки подлинности для ваш экземпляр GitHub Enterprise Server в промежуточной среде перед применением параметров в рабочей среде. Дополнительные сведения см. в разделе Настройка промежуточного экземпляра.

  1. В правом верхнем углу GitHub Enterprise Serverщелкните фото профиля, а затем выберите параметры Enterprise.

    Снимок экрана: раскрывающееся меню, которое отображается при щелчке фото профиля на GitHub Enterprise Server. Параметр "Параметры предприятия" выделен в темно-оранжевый контур.

  2. В левой части страницы на боковой панели учетной записи предприятия щелкните Политики.

  3. В разделе Политики, нажмите кнопку "Параметры".

  4. В разделе "Отладка SAML" нажмите раскрывающийся список и выберите Включено.

  5. Попытайтесь войти в ваш экземпляр GitHub Enterprise Server с помощью поставщика удостоверений SAML.

  6. Просмотрите выходные данные отладки в systemd journal for github-unicorn на ваш экземпляр GitHub Enterprise Server. Дополнительные сведения см. в разделе "Сведения о системных журналах".

  7. Завершив устранение неполадок, откройте раскрывающийся список и выберите Отключено.

Декодирование ответов

Некоторые выходные данные в systemd journal for github-unicorn могут быть закодированы в кодировке Base64. Вы можете получить доступ к административной оболочке и использовать служебную base64 программу для ваш экземпляр GitHub Enterprise Server, чтобы декодировать эти ответы. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

Чтобы декодировать выходные данные, выполните следующую команду, заменив ENCODED_OUTPUT кодированными выходными данными из журнала.

base64 --decode ENCODED_OUTPUT

Ошибка: "Другой пользователь уже владеет этой учетной записью"

Когда пользователь впервые входит в ваш экземпляр GitHub Enterprise Server с проверкой подлинности SAML, GitHub Enterprise Server создает учетную запись пользователя в экземпляре и сопоставляет SAML NameID и nameid-format учетную запись.

При повторном входе пользователя GitHub Enterprise Server сравнивает учетную запись NameID и nameid-format сопоставляет ответ поставщика удостоверений. NameID nameid-format Если ответ поставщика удостоверений больше не соответствует значениям, которые GitHub Enterprise Server ожидает пользователя, вход завершится ошибкой. Пользователь увидит следующее сообщение.

Другой пользователь уже владеет этой учетной записью. Попросите администратора проверить журнал аутентификации.

Сообщение обычно указывает, что имя пользователя или адрес электронной почты были изменены у поставщика удостоверений. Убедитесь, что NameID учетная nameid-format запись пользователя на GitHub Enterprise Server соответствует идентификатору пользователя NameID и nameid-format вашему idP. Дополнительные сведения см. в разделе Обновление SAML NameID пользователя.

Ошибка: "Получатель в ответе SAML пустой или недопустимый"

Recipient Если URL-адрес ACS не соответствует ваш экземпляр GitHub Enterprise Server, одно из следующих двух сообщений об ошибках появится в журнале проверки подлинности при попытке пользователя пройти проверку подлинности.

Recipient in the SAML response must not be blank.

Recipient in the SAML response was not valid.

Убедитесь, что для Recipient поставщика удостоверений задано значение полного URL-адреса ACS для ваш экземпляр GitHub Enterprise Server. Например, https://ghe.corp.example.com/saml/consume.

Ошибка: "Ответ SAML не подписан или изменен"

Если поставщик удостоверений не подписал ответ SAML или подпись не соответствует содержимому, в журнале проверки подлинности появится следующее сообщение об ошибке.

SAML Response is not signed or has been modified.

Убедитесь, что вы настроили подписанные утверждения для приложения GitHub Enterprise Server у поставщика удостоверений.

Ошибка: "Аудитория недопустима" или "Утверждение не найдено"

Если в ответе поставщика удостоверений отсутствует или неверное значение Audience, в журнале проверки подлинности появится следующее сообщение об ошибке.

Audience is invalid. Audience attribute does not match https://YOUR-INSTANCE-URL

Убедитесь, что для поставщика удостоверений EntityId задано значение Audience ваш экземпляр GitHub Enterprise Server, которое является полным URL-адресом экземпляра. Например, https://ghe.corp.example.com.

Ошибка: "Текущее время раньше, чем указано в условии NotBefore"

Такая ошибка может возникать при слишком большом расхождении текущего времени у поставщика удостоверений и в GitHub Enterprise Server, что иногда случается с локальными поставщиками удостоверений.

Чтобы предотвратить возникновение таких проблем, мы рекомендуем назначить для вашего устройства тот же источник сетевого протокола времени (NTP), который использует поставщик удостоверений. При возникновении этой ошибки убедитесь, что время на вашем устройстве правильно синхронизируется с NTP-сервером. Команду в административной оболочке можно использовать chronyc для немедленной синхронизации времени. Дополнительные сведения см. в разделе "Настройка синхронизации времени".

Если в качестве поставщика удостоверений вы используете ADFS, также установите значение 1 минута в ADFS в параметре NotBeforeSkew для GitHub. Если NotBeforeSkew имеет значение 0, то проблемы с проверкой подлинности будут возникать даже при очень небольших различиях во времени, даже в несколько миллисекунд.