Налаштування ASA AnyConnect VPN разом з IPI Enterprise Server через SAML
IPI Enterprise Server – Налаштування ASA AnyConnect VPN разом з IPI Enterprise Server через SAML
Вступ
У цьому документі описано, як налаштувати мову розмітки Security Assertion Markup Language (SAML) із зосередженням на Adaptive Security Appliance (ASA) AnyConnect через IPI Enterprise Server.
Сервер IPI Enterprise Server (IES) підтримує стандарт SAML 2.0 (Security Assertion Markup Language) для автентифікації користувачів.
IES — це IdP (Identity Provider), який увімкне SSO для всіх веб-додатків (SP, Service Provider), що підтримують SAML.
Оскільки IES підтримує безпарольну авторизацію FIDO2, постачальники послуг автоматично отримують можливість авторизуватися за допомогою апаратних ключів безпеки без необхідності створювати та вводити паролі
Передумови
Вимоги
Корпорація Cisco рекомендує вам мати знання з наступних тем:
Базові знання про RA VPN і налаштування у ASA.
Базові знання про SAML та Microsoft Active Directory.
Базові знання про AnyConnect Licenses (APEX або VPN-Only).
Компоненти для використання
Інформація в цьому документі базується на таких версіях програмного та апаратного забезпечення:
IPI Enterprise Server версії 3.9 і вище
Microsoft Active Directory.
Cisco ASA 9.7 і вище та Anyconnect 4.6 і вище
Working AnyConnect VPN profile
Інформація в цьому документі була створена з пристроїв у спеціальному лабораторному середовищі. Усі пристрої, використані в цьому документі, починалися з очищеної конфігурації (за замовчуванням). Якщо ваша мережа активна, переконайтеся, що ви розумієте потенційний вплив будь-якої команди. Ви також можете зіставляти користувачів із певними ролями програми на основі правил, які ви визначаєте у своїх налаштуваннях у Active Directory, Cisco ASA та Anyconnect.
Додаткова інформація
ІSAML — це структура на основі XML для обміну даними автентифікації та авторизації між доменами безпеки. Це створює коло довіри між користувачем, постачальником послуг (Service Provider, SP) і постачальником ідентифікаційної інформації (Identity Provider, IdP), що дозволяє користувачеві входити в декілька служб одночасно. Сервер IPI Enterprise Server легко інтегрується з пристроєм Cisco ASA VPN, щоб забезпечити додатковий захист для входу Cisco AnyConnect VPN.
Компоненти SAML
Метадані: це документ на основі XML, який забезпечує безпечну транзакцію між IdP і SP. Це дозволяє IdP і SP укладати угоди.
Ролі, які підтримуються пристроями (IdP, SP)
Пристрій може підтримувати більше ніж одну роль і може містити значення як для SP, так і для IdP. Під полем EntityDescriptor знаходиться IDPSSODescriptor, якщо міститься інформація для Single Sign-On IdP, або SPSSODescriptor, якщо міститься інформація для Single Sign-On SP. Це важливо, оскільки для успішного налаштування SAML потрібні правильні значення з відповідних розділів.
Entity ID - це поле є унікальним ідентифікатором для SP або IdP. Один пристрій може мати кілька служб і використовувати різні ідентифікатори об’єктів, щоб їх розрізняти. Наприклад, ASA має різні ідентифікатори об’єктів для різних тунельних груп, які потребують автентифікації. IdP, який автентифікує кожну тунельну групу, має окремі записи ідентифікатора об’єкта для кожної тунельної групи, щоб точно ідентифікувати ці служби.
URL-адреси служби: вони визначають URL-адресу служби SAML, яку надає SP або IdP. Для IdP це найчастіше служба єдиного виходу (Single Logout Service )з системи та служба єдиного входу (Single Sign-On Service). Для постачальників послуг це, як правило, Assertion Consumer Service і Single Logout Service.
URL-адреса служби єдиного входу (Single Sign-On Service URL) - буде знайдена в метаданих IdP, використовуючи SP для перенаправлення користувача до IdP для автентифікації. Якщо це значення налаштовано неправильно, IdP не отримує або не може успішно обробити запит на автентифікацію, надісланий SP.
URL-адреса Assertion Consumer Service, знайдена в метаданих SP, використовується IdP для перенаправлення користувача назад до SP і надання інформації про спробу автентифікації користувача. Якщо це налаштовано неправильно, SP не отримує твердження (відповідь) або не може успішно його обробити.
URL-адресу служби єдиного виходу (Single Logout Service URL) можна знайти як у SP, так і в IdP. Він використовується для полегшення виходу з усіх служб SSO з SP і є необов’язковим для ASA. Коли URL-адреса служби SLO (Single Logout Service) з метаданих IdP налаштована на SP і коли користувач виходить із служби на SP, SP надсилає запит IdP. Після того, як IdP успішно вийшов із служб користувача, він перенаправляє користувача назад до SP за допомогою URL-адреси служби SLO, знайденої в метаданих SP.
Прив’язки SAML для URL-адрес служби: Прив’язки (Binding) – це метод, який SP використовує для передачі інформації до IdP і навпаки для послуг. Це включає перенаправлення HTTP, HTTP POST і Artifact. Кожен метод має свій спосіб передачі даних. Метод прив’язки, який підтримує служба, включено до визначення цієї служби. Наприклад:
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" ="https://saml.example.com/simplesaml/saml2/idp/SSOService.php"/ >
ASA не підтримує прив’язку артефакту. ASA завжди використовує метод HTTP Redirect для запитів автентифікації SAML, тому важливо вибрати URL-адресу служби SSO, яка використовує прив’язку HTTP Redirect, щоб IdP очікував цього.
Сертифікати для операцій підпису та шифрування (Signature and Encryption operations)
Щоб забезпечити конфіденційність і цілісність повідомлень, що надсилаються між SP та IdP, SAML включає можливість шифрувати та підписувати дані. Сертифікат, який використовується для шифрування та/або підпису даних, можна включити в метадані, щоб одержувач міг перевірити повідомлення SAML і переконатися, що воно надходить з очікуваного джерела. Сертифікати, які використовуються для підпису та шифрування, можна знайти в метаданих у розділах KeyDescriptor use="signing" і KeyDescriptor use="encryption", відповідно, і потім X509Certificate. ASA не підтримує шифрування повідомлень SAML.
Діаграма мережі
Налаштування IES як IdP
Крок 1. Налаштуйте Identity Provider
Ідентифікатори (IdP) та постачальники послуг (SP) повинні обмінюватися сертифікатами публічних ключів, адресами для запитів та іншими параметрами для встановлення згоди між ними.
Для роботи протоколу SAML необхідний сертифікат у форматі «.pfx». Його можна створити, наприклад, за допомогою програми OpenSSL або за допомогою наявного сертифіката. Файл сертифіката необхідно скопіювати на сервер IES (наприклад, директорію з бінарними файлами та налаштуваннями.
Увійдіть на сервер IES, потім перейдіть до Налаштування -> Параметри -> SAML.
Потім натисніть кнопку Налаштувати IdP:
Виберіть файл .pfx і введіть пароль для нього. Також необхідно вибрати відповідний алгоритм підпису:
Алгоритм підпису - a signature algorithm. Він має відповідати алгоритму, за яким було встановлено сертифікат pfx. Можливі варіанти: SHA1, SHA256, SHA384, SHA512.
Крок 2. Отримайте файл метаданих IES
На тій же сторінці (Налаштування -> Параметри -> SAML), після встановлення сертифіката .pfx, ви можете:
· Переглянути метадані · Завантажити метадані · Завантажити публічний сертифікат публічного ключа
Метадані — це файл XML, який містить усю необхідну інформацію про налаштування IdP і сертифікат відкритого ключа. ASA дозволяє імпортувати метадані IdP під час налаштування SAML, що спрощує налаштування. Ви також можете завантажити окремий сертифікат, якщо це необхідно, або переглянути всі метадані на екрані.
Для наступних кроків вам потрібно завантажити файл метаданих і файли сертифікатів.
Налаштування ASA для SAML через CLI
Крок 1. Створіть Точку довіри (Trustpoint ) і імпортуйте сертифікат SAML
# config t
# crypto ca trustpoint IES-SAML
revocation-check none
no id-usage
enrollment terminal
no ca-check
# crypto ca authenticate IES-SAML
-----BEGIN CERTIFICATE-----
…
IES IdP Certificate Text you downloaded on the previous step.
…
-----END CERTIFICATE-----
# quit
Крок 2. Забезпечення SAML IdP
# webvpn
# saml idp https://example.ipi.com/
# url sign-in https://example.ipi.com/Saml/Login
# url sign-out https://example.ipi.com/Saml/Logout
# trustpoint idp IES-SAML - [IdP Trustpoint]
# trustpoint sp ASA-EXTERNAL-CERT - [SP Trustpoint]
# no force re-authentication
# no signature
# base-url https://asa.example.com
Крок 3. Застосування SAML Authentication до VPN Tunnel Configuration
# tunnel-group TUNNEL-GROUP-NAME webvpn-attributes
saml identity-provider https://example.ipi.com/
authentication saml
# end
# write memory
Крок 4. Отримання файлу SAML ASA Metadata FIle
Запустіть наступну команду:
# show saml metadata TUNNEL-GROUP-NAME
Далі скопіюйте текст метаданих у файл xml і збережіть його.
Примітка. Якщо ви вносите зміни в конфігурацію IdP, вам потрібно видалити конфігурацію постачальника ідентифікаційної інформації saml із Tunnel Group і повторно застосувати її, щоб зміни набули чинності.
Додавання Service Provider (SP) до сервера IES
Увійдіть на сервер IES, потім перейдіть до Налаштування -> Параметри -> SAML. Потім натисніть кнопку Додати постачальника послуг.
У наступній формі ви можете додати файл метаданих або заповнити всі параметри вручну:
Емітент - Entity ID який вказано в FortiMail
Ствердження споживчої служби - ACS URL який вказано в FortiMail
Публічний сертифікат x509 - Certificate який вказано в FortiMail
NameID формат - Email
NameID значення - Електронна пошт
Емітмент - унікальне ім’я SP, яке потрібно скопіювати з налаштувань SP або отримати з файлу метаданих.
Ствердження споживчої служби - адреса входу на стороні постачальника послуг. Переспрямування здійснюється на цю адресу після успішного входу через службу IdP.
Служба єдиного виходу - адреса для виходу з облікового запису. Якщо ви виходите з IdP, ця URL-адреса відкривається в циклі для всіх SP.
Публічний сертифікат x509 - публічний сертифікат постачальника послуг (Service Provider).
NameID формат - формат поля, яке ідентифікує користувача.
NameID значення - вибір поля, де можна взяти ідентифікатор користувача.
Оскільки IdP і SP можуть використовувати різні ідентифікатори для користувачів, необхідний механізм зіставлення цих ідентифікаторів для встановлення однозначної відповідності між користувачами в обох службах. Ідентифікатором користувача (логіном) у IES є його електронна адреса, хоча в інших системах це може бути щось інше (наприклад, комбінація імені та прізвища користувача).
Якщо ваша конфігурація ASA та AD приймає електронну пошту як ідентифікатор користувача, вам потрібно встановити:
NameID формат - Email NameID значення- Електронна пошта
Якщо конфігурація ASA та AD не приймає електронну пошту як ідентифікатор користувача, потрібно встановити формат, який ви використовуєте, у полі NameID формат та значення «Зовнішній ідентифікатор» у полі NameID значення. Потім потрібно заповнити поле «Зовнішній ідентифікатор» для кожного співробітника.
Для цього натисніть Співробітники -> Виберіть співробітника -> Деталі -> розділ Єдиний вхід -> Налаштування -> поле "Зовнішній ідентифікатор".
Після заповнення та збереження всіх налаштувань ви можете перевірити інтеграцію, увійшовши до Service Provider. Ви повинні бути перенаправлені на сторінку автентифікації IES, де вам потрібно буде ввести ваше ім’я користувача (електронну адресу) і пройти перевірку ключа безпеки.
Остаточна перевірка
Крок 1. Увімкнення SSO для користувача на сервері IES
Співробітники не можуть увійти на сервер IES використовувати службу SSO за замовчуванням, вони повинні мати дозвіл адміністратора. Виберіть співробітника та натисніть кнопку Змінити. Потім у розділі Єдиний вхід натисніть кнопку Увімкнути систему єдиного входу на сторінці, що відкриється, щоб надати дозвіл.
Примітка: Співробітник повинен мати дійсну електронну адресу та відповідний ключ безпеки для активації послуги SSO.
Служба SSO вмикається автоматично та не може бути відключена від всіх адміністраторів на сервері IES.
Якщо зовнішній ідентифікатор використовується як значення NameID, ви також повинні заповнити це поле. Відкрийте Співробітники -> оберіть співробітника -> Єдиний вхід -> натисніть Редагувати -> відредагуйте поле Зовнішній ідентифікатор.
Примітка: Деякі постачальники послуг (SP) можуть не підтримувати цю функцію.
Крок 2. Увійдіть до веб-служби за допомогою SAML
Підключіться до своєї адреси URL VPN і виберіть один із варіантів входу у вікні IPI Enterprise Server, а потім увійдіть за допомогою своїх облікових даних:
Програма AnyConnect підключена:
Загальні питання
Невідповідність ідентифікатора об’єкта (Entity ID)
Приклад налагодження:
[SAML] consume_assertion: Ідентифікатор провайдера невідомий #LassoServer. Щоб зареєструвати провайдер #LassoServer об'єкт, ви повинні використовувати методи lasso_server_add_provider() або lasso_server_add_provider_from_buffer().
Проблема: Загалом означає, що команда saml idp [entityID] у конфігурації webvpn ASA не відповідає ідентифікатору об’єкта IdP, знайденому в метаданих IdP.
Solution: Check the entity ID of the IdP’s metadata file and change the saml idp [entity id] command to match this.
Вирішення: перевірте ID у файлі метаданих IdP і змініть команду saml idp [entity id] об’єкта відповідно до цього.
Невідповідність часу
Приклад налагодження:
[SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout: 0
[SAML] consume_assertion: assertion is expired or not valid
Проблема 1. Час ASA не синхронізується з часом IdP.
Вирішення 1. Налаштуйте ASA з тим самим сервером NTP, який використовується IdP.
Проблема 2. Твердження (Accretions) недійсне між вказаним часом.
Вирішення 2. Змініть значення часу очікування (timeout), налаштоване на ASA.
Використано неправильний сертифікат підпису для Identity Provider (IdP Signing Certificate)
Приклад налагодження:
[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match
[SAML] consume_assertion: Профіль не може перевірити підпис у повідомленні.
Проблема: ASA не може перевірити повідомлення, підписане IdP, або немає підпису для перевірки ASA.
Рішення: перевірте сертифікат підпису IdP, встановлений на ASA, щоб переконатися, що він відповідає тому, що надсилає IdP. Якщо це підтверджено, переконайтеся, що підпис включено у відповідь SAML.
Недійсна аудиторія твердження (Assertion Audience)
Приклад налагодження:
[SAML] consume_assertion: аудиторія твердження недійсна
Проблема: IdP визначає неправильну аудиторію.
Вирішення: Виправте Audience configuration на IdP. Цей параметр повинен відповідати ASA Entity ID.
Неправильна URL-адреса для Assertion Consumer Service
Приклад налагодження: Неможливо отримати будь-яке налагодження після надсилання початкового запиту автентифікації. Користувач може ввести облікові дані в IdP, але IdP не перенаправляє дані до ASA.
Проблема: Неправильно налаштовано URL-адресу IdP для Assertion Consumer Service.
Рішення: перевірте базову URL-адресу в налаштуваннях та переконайтеся, що вона правильна. Перевірте метадані ASA, щоб переконатися, що URL-адреса для Assertion Consumer Service правильна. Перевірте відповідність цієї адреси для обох сервісів: ASA та IdP. Адреса повинна збігатися для обох сервісів.
Зміни конфігурації SAML не набувають чинності
Приклад: після того, як URL-адресу Єдиного входу (SSO) змінено, сертифікат SP, SAML продовжує працювати за попередніми налаштуваннями.
Problem: ASA needs to regenerate it's metadata when there is a configuration change that affects it. It does not do this automatically. Проблема: ASA має згенерувати заново свої метадані, коли відбувається зміна конфігурації, яка впливає на це. Регенерація відбувається автоматично.
Рішення: після внесення змін у відповідній тунельній групі видаліть і повторно застосуйте команду saml idp [entity-id].
Виправлення несправностей
Більшість усунення несправностей SAML пов'язані з неправильною конфігурацією, яку можна виявити під час перевірки налаштувань SAML або запуску налагодження debug Webvpn saml 255. Це можна використовувати для усунення більшості проблем, однак у випадках, коли це налагодження не надає корисної інформації, можна запустити додаткові налагодження:
debug webvpn saml 255
debug webvpn 255
debug webvpn session 255
debug webvpn request 255
Last updated
