SSO-аутентификация (SAML, OIDC, Kerberos)

В данной инструкции представлено описание процесса настройки Single Sign-On аутентификации по протоколам SAML и OIDC, а также SSO-аутентификации по протоколу Kerberos в Microsoft Active Directory.

Документ предназначен для использования администраторами организации.

Архитектура и описание системы — в документе представлена информация о сервисах Мессенджер и ВКС, обеспечивающих функциональность SSO-аутентификации, а также расположение log-файлов данных сервисов. Не является частью публичной документации, обратитесь к представителю VK Tech, чтобы ознакомиться с документом.

Клиентские платформы в рамках запроса аутентификации должны поддерживать аутентификацию через внешнего провайдера аутентификации, в результате которой сервер отдаст ответ, содержащий email и atoken (ключ, необходимый для инициализации сессии и получения идентификатора сессии — aimsid), используемые далее при старте сессии мессенджера.

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

Внешний провайдер аутентификации (Identity Provider) — провайдер осуществляющий аутентификацию и поддерживающий протоколы аутентификации SAML и OpenID Connect. Провайдером является SAML IDP или OIDC Authentication server.

В процессе аутентификации пользователя сервер Мессенджер и ВКС перенаправляет пользователя на провайдера аутентификации. Клиент переходит по указанным redirect'ам, пользователь вводит аутентификационные данные. Далее клиент начинает новую сессию мессенджера и пользуется идентификатором сессии (aimsid) во всех запросах. При отзыве access_token'а aimsid инвалидируется.

На клиентских приложениях aimsid хранится во внутреннем хранилище ОС в зашифрованном виде (за исключением web-версии), в соответствии с таблицей:

По окончании процесса аутентификации все управление токенами и взаимодействие с провайдером аутентификации осуществляется на стороне сервера Мессенджер и ВКС.

Хранением, обновлением, проверкой токенов занимается сервис Tokeeper. Сервис хранит данные, используя БД Tarantool. БД Tarantool отслеживает токены, период жизни которых истек, и автоматически удаляет их из базы.

Настройка взаимодействия «клиент — сервер Мессенджер и ВКС» представлена в разделе Шаг 1. Настройка подсистемы авторизации сервера Мессенджера.

Настройка взаимодействия «сервер Мессенджер и ВКС — Identity Provider» представлена в Шагах 2-5.

Ограничения Keycloak

Сервис Keycloak не взаимодействует с внешним провайдером аутентификации после авторизации. Соответственно, не сможет инвалидировать свою сессию при инвалидации сессии пользователя на внешнем провайдере аутентификации.

Однако, если инвалидировать сессию пользователя в сервисе Keycloak, клиент Мессенджер и ВКС разлогинит пользователя.

Одновременная работа с несколькими провайдерами аутентификации

SSO аутентификация поддерживает аутентификацию через несколько провайдеров.

Выбор нужного провайдера осуществляется на основе useragent'а, переданного параметром в начале процесса аутентификации. Процесс настройки провайдеров представлен ниже.

Secure Browser

• Для iOS — ASWebAuthenticationSession.

• Для Android — Android Custom Tab.

• Для Web — Window.open.

• Для Desktop — открытие в стандартном браузере.

1. Клиент из файла myteam-config.json получает auth-url для аутентификации (см. описание в разделе).

2. Сервер Мессенджер и ВКС составляет запрос в Identity Provider на /auth endpoint и перенаправляет на него клиента.

3. Пользователь (в secure browser) вводит аутентификационные данные:

   • если пользователем уже вошел в Систему, сработает SSO, и пользователю ничего вводить не потребуется;
   • в случае ошибки логина/пароля — об этом пользователю сообщит Identity Provider внутри secure_browser в окне логина («Invalid username or password») и предложит ввести логин/пароль повторно.

4. Identity Provider перенаправляет на указанный сервером redirect_uri, находящийся на сервере.

5. Сервер Мессенджер и ВКС обрабатывает redirect от Identity Provider:

   • в параметрах запроса получает:
     • state;
     • code.

6. Сервер Мессенджер и ВКС составляет и отправляет запрос в Identity Provider на /token endpoint:

   • в ответ получает необходимые токены и периоды их жизни (access_token, refresh_token, id_token и т.д.)
   • сохраняет их, если еще нет токенов для этого пользователя в хранилище сервера.

7. Сервер Мессенджер и ВКС завершает действия, необходимые для аутентификации, и осуществляет редирект на переданный redirect_uri, в параметрах передавая результат:

   • code:
     • 20000 – успех;
     • 50000 - server error.
   • reason — передается в случае ошибки;
   • atoken;
   • email;
   • host_time.

1. Клиент из файла myteam-config.json получает auth-url для аутентификации (см. описание в разделе).

2. Сервер Мессенджер и ВКС составляет запрос в Identity Provider на /auth endpoint и перенаправляет на него клиента.

3. Пользователь (в secure browser) вводит аутентификационные данные:

   • если пользователем уже вошел в Систему, сработает SSO, и пользователю ничего вводить не потребуется;
   • в случае ошибки логина/пароля — об этом пользователю сообщит Identity Provider внутри secure_browser в окне логина («Invalid username or password») и предложит ввести логин/пароль повторно.

4. Identity Provider перенаправляет на указанный сервером redirect_uri, находящийся на сервере.

5. Сервер Мессенджер и ВКС обрабатывает redirect от Identity Provider:

   • в параметрах запроса получает:
     • state;
     • code.

6. Сервер Мессенджер и ВКС завершает действия, необходимые для аутентификации, и осуществляет редирект на переданный redirect_uri, в параметрах передавая результат:

   • code:
     • 20000 – успех;
     • 50000 - server error.
   • reason — передается в случае ошибки;
   • atoken;
   • email;
   • host_time.

Необходимые шаги для включения SSO аутентификации представлены ниже:

1. Перейти в веб-интерфейс сервиса Keycloak:

   • открыть доступ для домена mridme.<DOMAIN> и перейти в браузере на https://mridme.<DOMAIN>

   или

   • пробросить локальный порт на сервер:

    
   ssh -L 8080:keycloak-http.keycloak.svc.cluster.local:80 centos@<server>

   и перейти в браузере http://127.0.0.1:8080/auth

2. Логин: admin

   Пароль: пароль необходимо получить в службе технической поддержки

3. Перейти Manage → Clients → выбрать nomailcli → вкладка Settings → установить значения для полей:

   • Valid redirect URIs — https://u.<DOMAIN_EXAMPLE.COM>/api/v87/rapi/auth/oidc/submitCode, где <DOMAIN_EXAMPLE.COM> — ваш домен;

   • Client authentication — On:

     

   • Вкладка Advanced → Advanced Settings → поле Proof Key for Code Exchange Code Challenge Method → указать S256:

     

   • Вкладка Credentials → поле Client Authenticator → указать Client Id and Secret:

     

4. Необязательные параметры:

   • Перейти Realm settings → вкладка Tokens: можно указать время жизни различных токенов (на весь realm):

     

   • Перейти Clients → выбрать nomailcli → вкладка Advanced → Advanced Settings:

     можно указать время жизни access_token:

     

5. Проставить поведение при первом логине:

   • Перейти Configure → вкладка Identity providers → выбрать провайдера → в поле First login flow указать «first broker login»:

     

Ниже представлено добавление провайдера аутентификации при использовании протокола OIDC. Если Вы используете протокол SAML, перейдите к разделу Протокол SAML.

1. Проверить доступность адреса mridme.<DOMAIN>.

2. Создать и настроить провайдера аутентификации:

   Перейти Identity Providers → выбрать необходимый протокол:

    
   ![vk-teams-sso-auth-for-admins-10](/ru/assets/sso-auth-for-admins/images/vk-teams-sso-auth-for-admins-10.png)

3. Указать следующие значения полей:

   • Alias — задать Alias провайдера;

   • Display name — задать имя провайдера:

   • Use discovery endpoint — Off;

   • Authorization URL — запросить у администратора Authentication server;

   • Token URL — запросить у администратора Authentication server;

   • Logout URL — запросить у администратора Authentication server;

   • User Info URL — запросить у администратора Authentication server;

   • Issuer — запросить у администратора Authentication server:

     

   • Validate Signatures — On;

   • Use JWKS URL — On;

   • JWKS URL — запросить у администратора Authentication server;

   • Client authentication — Client secret sent as post;

   • Client ID — запросить у администратора Authentication server;

   • Client Secret — запросить у администратора Authentication server:

     

   • Перетащить файл в поле Import config from file

     или

   • В поле Import config from file нажать Browse → выбрать файл :

     

4. Нажать Save.

Ниже представлено добавление провайдера аутентификации при использовании протокола SAML. Если Вы используете протокол OIDC, перейдите к разделу Шаг 3. Регистрация провайдеров аутентификации в сервисах Мессенджер и ВКС.

1. Проверить доступность адреса mridme.<DOMAIN>.

2. Создать и настроить провайдера аутентификации:

   Перейти Identity Providers → выбрать необходимый протокол:

   

3. Указать следующие значения полей:

   • Alias — задать Alias провайдера;

   • Display name — задать имя провайдера;

   • Use entity descriptor — Off:

     

   • Single Sign-On service URL — запросить у администратора IDP-сервера;

   • Single logout service URL — запросить у администратора IDP-сервера;

   • NameID policy format — Unspecified;

   • HTTP-POST binding response — On;

   • HTTP-POST binding for AuthnRequest — On;

   • HTTP-POST binding logout — On:

     

   • Allowed clock skew — 30:

     

   • Перетащить файл в поле Import config from file

   или

   • В поле Import config from file нажать Browse → выбрать файл :

   

4. Нажать Save.

Провайдеры регистрируются в сервисе Stdb. Оттуда информацию о них получают сервисы Front и Tokeeper.

SSO аутентификация поддерживает аутентификацию через несколько провайдеров.

Возможна поддержка нескольких провайдеров в двух форматах:

Вариант 1. Сервис Keycloak подключается к провайдеру аутентификации в режиме посредника, все взаимодействие с провайдером лежит на сервисе Keycloak.

Настроить выбор провайдера для различных вариантов подключения:

• Подключиться к сервису Stdb:

   
  rlwrap nc stdb.vkteams.svc.cluster.local. 4020

• Далее добавить таблицу с данными провайдеров:

   
  stdb_table_add idp_configurations issuer@string addr@string client_id@string scope@string client_secret@string platforms_and_auth_extra_params@string need_register_user@string# для версий до 25.2stdb_row_add idp_configurations KK https://di.<DOMAIN_EXAMPLE.COM>/auth/realms/myteam/.well-known/openid-configuration nomailcli openid use_secrets_luke '{ "web": "di_idp_hint=<Alias_1>", "desktop": "di_idp_hint=<Alias_2>", "default": "di_idp_hint=<Alias_3>" }' false# Если поле default пусто и нет алиасовstdb_row_add idp_configurations KK https://di.<DOMAIN_EXAMPLE.COM>/auth/realms/myteam/.well-known/openid-configuration nomailcli openid use_secrets_luke '{ "default": "" }' false# для версии 25.2 и вышеstdb_row_add idp_configurations KK https://kc.<DOMAIN_EXAMPLE.COM>/auth/realms/myteam/.well-known/openid-configuration nomailcli openid use_secrets_luke '{ "web": "kc_idp_hint=<Alias_1>", "desktop": "kc_idp_hint=<Alias_2>", "default": "kc_idp_hint=<Alias_3>" }' false

  где <Alias_1>, <Alias_2>, <Alias_3> — значение поля Alias для провайдеров в Keycloak (см. Шаг 2. Добавление провайдера аутентификации).

Для разграничения платформ используется поле platforms_and_auth_extra_params таблицы сервиса Stdb. Уточнения значения этого поля:

• default — переходим на базовую страницу авторизации сервиса Keycloak.

• di_idp_hint или kc_idp_hint=<Alias провайдера в настройках Keycloak>.

Доступные платформы:

• Web;
• Android;
• Desktop;
• IOS.

Вариант 2. Отдельная регистрация каждого провайдера: в таблицу каждый провайдер добавляется новой строкой.

1. Добавьте в конфигурационный файл /usr/local/nginx-im/html/myteam/myteam-config.json указанное содержимое:

    
   "oauth-authorization": {  "enabled": true,  "config": {  "auth-url": "https://u.<DOMAIN_EXAMPLE.COM>/api/v87/rapi/auth/oidc/authorize"  }},

2. Для инсталляции на одну виртуальную машину выполните команду:

    
   HELMWAVE_USE_LOCAL_REPO_CACHE=true hwup -t godmod

   Для кластерной инсталляции:

    
   HELMWAVE_USE_LOCAL_REPO_CACHE=true HELMWAVE_ENV_NAME=cluster hwup -t godmod

3. Перезапустите под в технологическое окно (может приводить к сбою в новых подключениях):

    
   kubectl delete pods -n vkteams -l app=myteam-admin

Необходимо настроить по три mapper’a для каждого провайдера — email, lastName и firstName.

1. Перейти Identity Providers → выбрать провайдера → вкладка Mappers → нажать Add mapper:

   

2. Указать следующие значения полей:

   • Name — задать имя mapper’a;

   • Sync mode override — Inherit;

   • Mapper type — Attribute Importer;

   • Claim — маска для поиска атрибута в токене (запросить у администратора IDP-сервера);

   • User Attribute Name — прописать один из вариантов — email; lastName или firstName:

     

3. Нажать Save.

4. Повторить шаги 1-4 для создания остальных двух mappers.

На контроллере домена необходимо зарегистрировать учетную запись.

В разделе Account ввести в поле User logon name HTTP/<почтовый домен>.

В окне Account options внутри того же раздела отметьте чекбосы:

• User cannot change password.
• Password never expires.
• This account supports Kerberos AES 128 bit encryption.
• This account supports Kerberos AES 256 bit encryption.
• Do not require Kerberos preauthentication.

Затем в разделе управления групповыми политиками перейдите к настройке политики Configure encryption types allowed for Kerberos.

Во вкладке Security Policy Setting отметьте следующие политики:

• RC4_HMAC_MD5.
• AES128_HMAC_SHA1.
• AES256_HMAC_SHA1.

В зависимости от выбранного типа шифрования — RC4-HMAC-NT или AES128-SHA1, AES256-SHA1 — выполните шаги, представленные ниже:

При использовании шифрования RC4-HMAC-NT

1. Получить параметр msDS-KeyVersionNumber:

    
   Get-ADUser -Identity i.ivanov -Properties msDS-KeyVersionNumber

   msDS-KeyVersionNumber — атрибут объекта учетной записи в Active Directory, который указывает версию ключа, используемого для шифрования данных, связанных с этой учетной записью. Аналогично kvno_number в Kerberos, но специфично для Active Directory.

2. На Windows Server сгенерировать файл .keytab для Kerberos аутентификации в Active Directory:

    
   ktpass -princ HTTP/computer.contoso.com@CONTOSO.COM -mapuser CONTOSO\keycloak -out mcs.keytab -crypto ALL -ptype KRB5_NT_PRINCIPAL /pass "SomePassword" -kvno kvno_number

   где:

   • -princ —FQDN сервера Keycloak в формате HTTP/computer.contoso.com@CONTOSO.COM для организации связи между сервисом Keycloak и Active Directory

   • -mapuser — пользователь, для которого регистрируется SPN и генерируется файл .keytab;

   • -pass — пароль пользователя;

   • -crypto — тип шифрования. Чтобы сгенерировать файл .keytab, поддерживающий все способы шифрования, укажите для ключа -crypto значение ALL;

   • -ptype — тип принципала;

   • -out — имя создаваемого файла .keytab.

   • kvno — номер версии ключа для идентификации версии ключа шифрования, используемого для защиты данных. kvno_number должен быть равен следующему значению: msDS-KeyVersionNumber + 1

3. Проверить значение параметра msDS-KeyVersionNumber, он должен быть равен значению kvno_number из предыдущей команды.

4. Дополнительно включить шифрование RC4-HMAC-NT в контейнере с Keycloak (оно автоматически отключается, так как считается слабым):

   • создать файл через любой текстовый редактор (название указать любое, в примере использовано название файла allow-weak) со следующим содержимым:

      
     [libdefaults] allow_weak_crypto = true permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac arcfour-hmac

   • создать ConfigMap на основе файла, созданного на предыдущем шаге:

      
     kubectl create configmap krb5-week-conf --from-file=allow-weak --namespace=keycloak

   • чтобы отредактировать deployments выполните команду:

      
     kubectl -n keycloak edit deployments

   • добавить строки в секции volumeMounts: и volumes:

      
     spec:  template:    spec:      containers:         volumeMounts:         - mountPath: /etc/krb5.conf.d/          name: krb5-week-conf        volumes:         - configMap:          defaultMode: 420          name: krb5-week-conf        name: krb5-week-conf

При использование шифрования AES128-SHA1, AES256-SHA1

1. При использовании шифрования AES128-SHA1, AES256-SHA1 необходимы настройки для пользователей в Active Directory. В свойствах учетных записей пользователей необходимо установить поддержку типов шифрования AES128-SHA1, AES256-SHA1 — либо через групповые политики, либо вручную.

   

2. Получить параметр msDS-KeyVersionNumber:

    
   Get-ADUser -Identity i.ivanov -Properties msDS-KeyVersionNumber

   msDS-KeyVersionNumber — атрибут объекта учетной записи в Active Directory, который указывает версию ключа, используемого для шифрования данных, связанных с этой учетной записью. Аналогично kvno_number в Kerberos, но специфично для Active Directory.

3. На Windows Server сгенерировать файл .keytab для Kerberos аутентификации в Active Directory :

    
   ktpass -princ HTTP/computer.contoso.com@CONTOSO.COM -mapuser CONTOSO\keycloak -out mcs.keytab -crypto ALL -ptype KRB5_NT_PRINCIPAL /pass "SomePassword" -kvno kvno_number

   где:

   • -princ —FQDN сервера Keycloak в формате HTTP/computer.contoso.com@CONTOSO.COM для организации связи между сервисом Keycloak и Active Directory

   • -mapuser — пользователь, для которого регистрируется SPN и генерируется файл .keytab;

   • -pass — пароль пользователя;

   • -crypto — тип шифрования. Чтобы сгенерировать файл .keytab, поддерживающий все способы шифрования, укажите для ключа -crypto значение ALL;

   • -ptype — тип принципала;

   • -out — имя создаваемого файла .keytab.

4. Создать секрет из файла .keytab и прокинуть его внутрь контейнера с Keycloak:

    
   kubectl -n keycloak create secret generic keycloak-keytab --from-file=mcs_new.keytab --dry-run=client -o yaml | kubectl apply -f -

5. Проверить наличие нового .keytab файла и сравнить kvno с актуальным:

    
   klist -kteK /path/to/keytab

   Если внутри пода неактуальный kvno (устаревший .keytab), то перезапустите под и повторите проверку. Внутри пода команда klist по умолчанию недоступна, чтобы получить файл из пода выполните команду:

    
   kubectl cp -n keycloak keycloak-7d7d67fd79-lvckt:/path/to/keytab/in/pod /path/to/keytab/on/machine

Перейдите в веб-интерфейс сервиса Keycloak и выполните все действия из раздела Шаг 1. Настройка подсистемы авторизации сервера Мессенджер и ВКС.

1. Перейти в раздел Configure → User federation → нажать на кнопку Add Ldap providers:

   

2. Установить следующие значения полей:

   • Vendor — Active Directory:

   • Connection URL – IP-адрес контроллера домена Active Directory.

     При использовании защищенного соединения, указать протокол ldaps и сделать активными переключатели:

     • Enable StartTLS – On;
     • Connection pooling – On.

     Для проверки настроенного соединения нажать на кнопку Test connection. При успешном соединении получаем сообщение «Successfully connected to LDAP».

   • Указать Bind DN и пароль пользователя, от имени которого планируется подключаться к Active Directory.

     Для проверки подключения к Active Directory нажать на кнопку Test authentication. При успешном соединении получаем сообщение «Successfully connected to LDAP».

     

3. Определите в каком параметре передается username. Пример команды:

    
   ldapsearch -x -D "CN=Administrator,CN=Users,DC=contoso,DC=com" -H ldap://<AD IP> -b "CN=Users,DC=contoso,DC=com" -W

4. Если username передается не в параметре cn, то необходимо обновить информацию в разделе User Federation → LDAP → Mappers → username, поле LDAP Attribute:

   

5. В блоке с настройками поиска и обновления LDAP указать следующие значения полей:

   • Edit mode — READ_ONLY;
   • UsersDN — атрибут distinguishedName из Active Directory;
   • Username LDAP attribute — cn или параметр определенный выше. Достаточно часто это параметр sAMAccountName.
   • RDN LDAP attribute — cn;
   • UUID LDAP attribute — objectGUID;
   • User object classes — person, organizationalPerson, user;
   • User LDAP filter — опциональный фильтр, который указывает, из какой группы в Active Directory брать пользователей;
   • Search scope — Subtree для сквозного поиска пользователей согласно фильтру в поле User LDAP filter.

   

6. В блоке с настройками синхронизации указать следующие значения полей:

   • Import users — On;

   • Sync Registrations — On;

   • Periodic full sync — On;

   • Full sync period — указать период синхронизации в секундах;

   • Periodic changed users sync — On;

   • Changed users sync period — указать период синхронизации в секундах.

   

7. В блоке с настройками Kerberos указать следующие значения полей:

   • Allow Kerberos authentication — On;
   • Kerberos realm — заглавными буквами указать наименование домена, настроенного на шаге 2;
   • Server principal — указать SPN, указанный при создании файла .keytab (см. шаг 1);
   • Key tab — указать путь до файла .keytab;
   • Debug – On (опционально).

   

8. Нажать на кнопку Save.

9. Если в атрибуте cn приходит значение, отличное от username почтового адреса (без домена), нужно настроить маппинг поля username на тот атрибут, в котором приходит значение username.

Для этого в только что созданном провайдере - можно найти в User federation → ldap:

• на вкладке Mappers открыть "username"
• в поле "LDAP Attribute" указать название атрибута, в котором приходит username
• нажать на кнопку Save.

Далее в настройке из п. 3, в блоке с настройками поиска и обновления LDAP, в поле Username LDAP attribute также указать название атрибута, в котором приходит username.

Описание представлено в разделе.

Описание представлено в разделе.

1. Нажать Win + R, ввести inetcpl.cpl и нажать ОК.

2. Перейти на вкладку Security → нажать Trusted sites → нажать на кнопку Sites:

   

3. Добавить:

   • https://<vkteams_domain>
   • https://*.<vkteams_domain>
   

4. Нажать на кнопку Custom level… и установить переключатель Automatic login with current user name and password:

   

5. Нажать на кнопку ОК, чтобы сохранить изменения.

Изменить реестр HKEY_LOCAL_MACHINE/SOFTWARE/Policies/Google/Chrome.

Установить:

• AuthNegotiateDelegateWhitelist: *.<VKTeams_DOMAIN>,< VKTeams_DOMAIN >

• AuthServerWhitelist: *.<VKTeams_DOMAIN>,< VKTeams_DOMAIN >

• AuthNegotiateDelegateAllowlist: *.<VKTeams_DOMAIN>,< VKTeams_DOMAIN >

• AuthServerAllowlist: *.<VKTeams_DOMAIN>,< VKTeams_DOMAIN >

Отключите блокировку всплывающих окон в браузере.

Проверьте, что в сервисе Stdb верно прописано поле addr в idp_configurations.

В логах сервиса Keycloak: «Failed to make identity provider oauth callback: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target».

Проверьте, что у сервиса Keycloak есть все сертификаты.

Появляется при попытке входа по SSO при включении SSO-аутентификации через сервис Keycloak версии 24.9.5.

Проблема связана с эндпоинтом di.<vkt_domain>/auth/realms/myteam/. Сервис Front идет по url-адресу и попадает на Nginx (API Gateway), на котором нет этого домена.

Окружение

Версия: 24.9, 24.11.

Операционные системы: CentOS, РЕД ОС, РЕД ОС (Сертифицированная версия).

Тип инсталляции: 1 виртуальная машина, кластерная инсталляция, DMZ.

Решение

Из файла /etc/coredns/conf.d/main_domains.hosts удалите строку di.{$COREDNS_EXTERNAL_DOMAIN} и перезапустите CoreDNS командой:

 
systemctl restart coredns

В случаях, когда в инсталляциях с SSO используются самоподписанные сертификаты, в логах сервиса Front может появиться ошибка:

 
E FRONT: Couldn't get IDP infromation from discovery_url. status: SslPeerVerificationFailed, reason: SSL peer certificate or SSH remote key was not OK (./core/src//openid_connect/idp_settings.cc:134)

Проблема возникает из-за того, что сервис Front не может проверить самоподписанный сертификат.

Окружение

Версия: 24.9, 24.11.

Операционные системы: CentOS, РЕД ОС, РЕД ОС (Сертифицированная версия).

Тип инсталляции: 1 виртуальная машина, кластерная инсталляция, DMZ.

Решение

1. Установите на хостовую ОС все необходимые корневые сертификаты.

2. Проверьте в файле на ВМ usr/local/etc/k8s/helmwave/projects/front/values/front.yml версию, указанную в строке:

    
   .tag: &tag "<version>"

3. Скачайте файл:

   • Версия 24.9
   • Версия 24.11

4. Укажите в скачанном файле ту же версию, что в файле из шага 2.

5. Перенесите скачанный файл в /usr/local/etc/k8s/helmwave/projects/front/values/front.yml.

6. Выполните команду:

   Для инсталляций на одну виртуальную машину версии 24.9:

    
   premsetup.py --install -m helmwave`

   Для кластерных инсталляций версий 24.9 и 24.11, а также для инсталляций на одну виртуальную машину версии 24.11:

    
   im_deployer --helmwave --update --hw-once --hw-project front

   На кластерных инсталляциях команду нужно выполнить на любой из первых трех нод (a1, b1, a2).

Проблема может возникнуть из-за того, что Java Keycloak не может прочитать keytab-файл:

1. Необходимо исправить deployments Keycloak, добавив следующие данные:

    
   volumeMounts:- mountPath: /mnt/keytab-writablename: keytab-tmpvolumes:- emptyDir: {}name: keytab-tmp

2. Перезапустите под.

3. Переместите keytab в папку /mnt/keytab-writable:

    
   kubectl cp mcs_new.keytab keycloak-pod:/mnt/keytab-writable/mcs_test.keytab -n keycloak

4. Измените путь до keytab в веб-интерфейсе Keycloak.

Проверьте, что из пода доступен контроллер домена. Например:

 
nc -zv dc01.contoso.com 88

Если команда завершается ошибкой, то необходимо добавить в deployments Keycloak, в секцию spec.template.spec следующие строчки:

 
hostAliases:  - ip: "айпи"    hostnames:      - "dc01.contoso.com"

1. Создайте на машине с Keycloak файл krb5.conf. Пример содержимого:

    
   [libdefaults]        default_realm = CONTOSO.COM        kdc_timesync = 1        ccache_type = 4        forwardable = true        proxiable = true        isInitiator=false        fcc-mit-ticketflags = true        allow_weak_crypto = true        default_tkt_enctypes = aes256-cts-hmac-sha1-96        default_tgs_enctypes = aes256-cts-hmac-sha1-96        permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac arcfour-hmac[realms]        CONTOSO.COM = {                kdc = dc01.CONTOSO.COM                admin_server = dc01.CONTOSO.COM        }[domain_realm]        .contoso.com = CONTOSO.COM        contoso.com = CONTOSO.COM

2. Выполните команду, указав путь до файла krb5.conf:

    
   kubectl create configmap krb5-conf --from-file=krb5.conf=/<путь до файла>/krb5.conf -n keycloak

3. Обновите deployments:

    
   kubectl -n keycloak describe deployments

   И вставьте:

    
   volumeMounts:- mountPath: /etc/krb5.confname: krb5subPath: krb5.confvolumes:- configMap:defaultMode: 420name: krb5-confname: krb5

Технический писатель: Белова Ирина