Поставленная задача: настроить удаленный доступ в корпоративную сеть компании для сотрудников с различными правами доступов. В наличии имеется 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