Поставленная задача: настроить удаленный доступ в корпоративную сеть компании для сотрудников с различными правами доступов. В наличии имеется Cisco ASA 5510 с лицензией на достаточное кол-во пользователей AnyConnect.
Чтобы всё было максимально безопасно, а в дальнейшем легко обслуживалось, я решил настроить авторизацию по LDAP + выдавать каждому сотруднику сертификат и записывать его на USB-Token.
Подразумеваю, что у вас уже поднят и работает AD+CA
Таким образом всю задачу можно разделить на этапы:
1. Настройка проверки сертификатов, выданных корпоративным Certificate Authority (в дальнейшем CA),
2. Настройка авторизации пользователей через LDAP
3. Настройка AnyConnect
4. Разграничение прав доступа пользователей
1. Начнем с настройки проверки пользовательских сертификатов
Чтобы ASA могла посчитать сертификат валидным, ей самой нужен валидный сертификат. Можно настроить ASA чтобы она сама могла запросить сертификат у CA через NDES, но у меня, по какой-то причине, так и не взлетело. Поэтому есть способ, что называется, «в лоб» — запросить сертификат вручную через web-интерфейс CA.
Перед запросом сертификата ASA необходимо прописать FQDN и домен:
раздел, в котором это делается, видно в самом верху скриншота, далее будет так же
Подойдет сертификат Web-сервера, шаблон которого уже имеется в CA, но с небольшим изменением — нужно включить возможность экспортировать закрытый ключ. Я клонировал шаблон запроса сертификата и изменил параметры в нём (в дефолтном нет возможности что-то изменить):
Далее идем в веб-интерфейс CA и запрашиваем сертификат для ASA, не забыв отметить ключ как экспортируемый:
После запроса сертификата, устанавливаем его себе на ПК.
Установленный сертификат необходимо экспортировать с закрытым ключом в файл. Для этого заходим в оснастку управления сертификатами certmgr.msc в раздел с личными сертификатами:
Включите все сертификаты цепочки в экспортируемый файл, таким образом, мы включим в него корневой сертификат CA:
В следующем шаге придумываем пароль на сертификат и сохраняем файл.
Теперь нужно этот самый сертификат импортировать на ASA:
И если вы сделали все правильно, то сертификат успешно установится после нажатия «Add Certificate». При этом у вас появиться и Identity и CA Certificate.
На этом этапе ASA уже может авторизовывать пользователей с валидными сертификатами, которые выданы этим же CA, но пока не будет проверять отозван сертификат или нет — это нужно исправить. Иначе как-то не безопасно.
Выбираем корневой сертификат в разделе CA Certificates и редактируем:
В моём случае, я забираю Certificate Revocation List (CRL) по HTTP ссылке, которая содержится в Identity сертификате. Что важно — в ссылке указано доменное имя CA — т.е. на ASA нужно указать адреса DNS серверов и интерфейс с которого сервера доступны:
На скриншотах ниже основные настройки. На первом скриншоте есть опция «Consider certificate valid if revocation information cannot be retrieved», если её включить и ASA по какой-то причине не получит CRL то авторизация всё равно будет происходить. В моём случае, если CRL не получена, подключение не происходит.
Способы получения ссылок на CRL настраиваются на этой вкладке. Также, можно указать вручную:
Способы получения CRL:
Со стороны ASA настройка завершена, осталось убедиться что CA вообще публикует CRL. Необходимые параметры в свойствах CA:
На скришноте ниже определяются способы публикации CRL:
В свойствах Revoked certificates указываем переодичность публикации:
Публикуем CRL, и пробуем принудительно получить её на ASA:
Если всё настроено верно то всё получиться:
2. Можно приступить к настройке LDAP авторизации
В разделе AAA Server Groups добавляем новую группу:
Добавляем сервера в созданную группу:
Тонкости настроек:
Base DN — имя вашего домена. Например, синтаксис для домена my.corp такой: DC=my,DC=corp
Naming Attribute — sAMAccountName для серверов Microsoft, гугл подсказал.
Login DN — учетка в домене, обладающая админскими правами. Например, учетка Cisco в группе Users в домене my.corp : CN=Cisco,CN=Users,DC=my,DC=corp
Если у вас есть резервный DC, аналогично добавьте и его.
Проверить, работает ли авторизация, можно кнопкой «Test» и введя реквизиты любой доменной учетки:
Если реквизиты введены верно и LPAD настроен корректно, авторизация пройдет успешно:
3. Настраиваем AnyConnect
При включении функционала AnyConnect ASA попросит указать файл с клиентским софтом, это обязательно, без него просто не работает. Соответственно, рекомендую залить и указать сразу для всех операционок.
Включаем AnyConncet и выбираем интерфейсы, на которых будем принимать подключения. Так же, я отключил web-портал и запретил выбирать профайл вручную:
Настройки идентичны для двух дефотных профилей DefaultWEBVPNGroup и DefaultRAGroup. На что обратить внимание:
Можно сделать так, чтобы логин пользователя сам «подтягивался» из выданного ему сертификата и пользователь не смог бы его как-то изменить. В противном случае, остается возможность имея чужой сертификат войти со своей учеткой. У меня получилось адекватно забрать только Common Name (CN), поэтому важно чтобы в AD у пользователя CN совпадал с его доменным логином, иначе на этапе авторизации в LDAP подтянется неподходящий логин.
При такой настройке окно авторизации будет выглядеть так:
Переходим в GroupPolicies и меняем параметры в выбранной нами групповой политике на свой вкус. У меня всего одна — дефолтная.
ВАЖНО! Дефолтная GroupPolicy распространяется на всё. И если у вас имеется IPSec то ему для работы нужен ikev1/v2. Также, для AnyConnect можно создать новую полиси.
И настроил Split Tunneling — по сути разделение маршрутов. Если оставить как есть, то при подключении к AnyConnect весь траффик пользователя будет туннелироваться к нам.
В моем случае, туннелируются только те сети и хосты, к которым я разрешаю доступ. Весь прочий траффик пользователя ходит без изменений.
В ACL со списком сетей будет туннелироваться то что разрешено:
На этом базовая настройка AnyConnect завершена, но при такой настройке все пользователи равны в правах, что не всегда хорошо.
4. Настраиваем фильтры на основе группы в AD
Создаем в AD необходимое количество групп в AD.
На ASA создаем для каждой группы свой ACL и каждый из них настраиваем как нужно. Сильно акцентировать внимание на фильтрах не буду.
Настраиваем автоматический выбор фильтра на основании группы AD. Делается это в разделе Dynamic Access Policies
Например, у меня есть группа AnyConnectLAN, пользователи в ней имею доступ только в локальную сеть офиса. Настройки на её примере:
Аналогично настраиваем все прочие группы и фильтры.
Что интересно — если пользователь состоит сразу в нескольких группах, то ему применяться сразу несколько фильтров для этих групп.
Стоит обратить внимание, что есть дефолтная Dynamic Access Policy — DfltAccessPolicy, которая по умолчанию разрешает подключение без групп. Т.е. мы назначим фильтры тем пользователям, которые состоят в группах, а у которых групп вообще нет — будет полный доступ. Так не годится, меняем её настройки:
Теперь пользователи без групп не смогут подключиться и очень удобно изменять права доступа для пользователя — достаточно поменять группу в AD.
На этом настройка завершена и в результате мы имеем:
- Двухфакторную авторизацию — пользователь должен иметь валидный сертификат и ввести свой доменный пароль
- Разграничение прав доступа по VPN на основе группы в AD