ACS (Access Control Server) позволяет обеспечить централизованную аутентификацию, упрощает управление пользователями и безопасностью.
ACS особенно полезен при большом количестве устройств. Теперь не нужно на каждой железке хранить одни и те же учетные записи, все они хранятся в едином хранилище.
С Cisco Secure ACS мы можем управлять и администрировать доступом пользователей на Cisco IOS, устройствах VPN, ASA, WiFi решения и т.д.
В данной статье рассматривается применение ACS 5 для административного доступа к консоли маршрутизатора/коммутатора, а также для регулирования доступа пользователей по VPN.

ACS 5 - это очередное поколение и имеет существенные отличия от предыдущих версий ACS 4.x. Впрочем все стало гораздо более удобно и интуитивно понятно по сравнению с предыдущей версией.
В отличие от 4.х пятая версия выполнена на платформе Linux. ACS можно прибрести в виде Appliance, а также можно и установить на виртуальной машине.

Установка ACS 5

Дистрибутив:
http://rutracker.org/forum/viewtopic.php?t=3455387

Описание как создавать Вирт машину под ACS 5.0:
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_sys...

При настройке виртуалки выбираем:
Linux, Other linux, 32 bit
При первой загрузке нужно ввести setup
Далее будет диалог

Выставляем пароль. Этот пароль будет использоваться для входа в командную строку. Синтаксис командной строки даже попытались сделать похожим на IOS. Здесь выставляются такие параметры как IP адрес, DNS, Time zone, ntp server

После установки можно зайти на Web-морду ACS:
https://ip_address

Система первым делом спросит лицензию, впрочем есть и способы отучения от жадности.

Установка патчей

Патч из себя представляет файл FILE.tar.gpg
Его нужно разместить на ftp-сервере, затем выполнить шаги:
1) ssh login или с консоли
2)#conf t
3)#repository rep1
4)#url ftp://x.x.x.x/folder
5)#user USERNAME password plain PASSWODR
6)#exit
7)#exit
8)#acs path install FILE.tar.gpg repository rep1

Крайне рекомендуется ставить самый последний патч который найдёте.
ACS 5.x "голый", без патчей, - крайне глючен.
И наоборот: если вы наблюдаете какой-то глюк (особенно если это лечится ребутом) - начните с установки последнего патча.

Для перехода с 5.2 на 5.3:
1) Скачиваем ACS_5.3.0.40.tar.gz
2) application upgrade ACS_5.3.0.40.tar.gz rep1
Процесс может занять продолжительное время, его статус можно посмотреть:
Monitoring Configuration > System Operations > Data Upgrade Status.

После апгрейда можно проверить:
show application version acs
show application status acs

Кстати может иногда понадобиться останавливать и стартовать ACS из консоли:
acs/admin# acs stop
acs/admin# acs start

Для нормальной работы также нужно проверить наличие настроек и добавить если таковых нет:
ip domain-name baug.local
ip name-server 10.5.14.7
clock timezone Europe/Moscow
ntp server 10.5.14.95
Данные настройки вводятся через консоль.

Web-морда ACS

После установки мы можем заходить на Web-интерфейс ACS:
https://acs_address

Но тут сразу стоит отметить что далеко не под каждым браузером и не любой версии можно нормально работать.
Страница может не отображать какие то элементы, а может и полностью перекоситься.
Перед работой нужно четко понять с какими браузерами совместима ваша версия ACS.
Наберите в гуле: cisco acs 5.4 Supported Browsers

Supported Browsers

You can access the ACS 5.4 administrative user interface using the following web clients and browsers:

MAC OS
– Mozilla Firefox version 3.x
– Mozilla Firefox version 10.x

Windows 7
– Internet Explorer version 8.x
– Internet Explorer version 9.x
– Mozilla Firefox version 3.x
– Mozilla Firefox version 8.x

Windows XP
– Internet Explorer version 8.x
– Mozilla Firefox version 8.x
– Mozilla Firefox version 9.x
– Mozilla Firefox version 10.x

The above mentioned browsers are supported only with one of the following cipher suits:
– –TLS_RSA_WITH_AES_256_CBC_SHA
– –TLS_RSA_WITH_AES_128_CBC_SHA
– –RSA_WITH_3DES_EDE_CBC_SHA

FirefoxPortable_8.0.1_Russian.paf.exe
http://sourceforge.net/projects/portableapps/files/Mozilla%20Firefox,%20...

Настройка административного доступа + доступ к VPN в IOS с использованием ACS 5

Network Device Groups

В отличие от предыдущих версий, ACS 5 основан на политиках. Это подобно access-lists, политики - это список правил, которые обрабатываются в порядке нумерации.
Политикам характерно правило "first-match", т.е. если условия какого-либо правила удовлетворяют запросу, то это правило активируется, а ниже стоящие правила уже не проверяются.

С точки зрения ACS любой маршрутизатор, коммутатор, VPN концентратор, WiFi controller и другое устройство, настроенное на работу с ACS называется AAA client

Network Device Groups (NDG) позволяют логически группировать AAA clients
Например мы можем группировать устройства по физическому расположению (Location), по типу устройства (Device Type) или создать свою NDG.
Затем мы можем применить политики к NDG.

Если к примеру пользователь пытается зайти на маршрутизатор, то он делает запрос на ACS. В ACS определяет в какой NDG находится AAA client и затем применяет к девайсу соответствющую его группе политику. Таким образом мы можем применить одну и ту же политику к нескольким AAA clients

Группы NDG могут иметь иерархическую структуру. Если политика применяется на NDG, то она применится также и на дочерние NDG
AAA Client может находиться в нескольких NDG одновременно.

Создадим пару NDG для маршрутизаторов и коммутаторов:
Network Resources > Network Device Groups > Device Type - Create

AAA Clients

Следующим шагом нужно создать AAA Client.
Network Resources > Network Devices and AAA Clients - Create
Нам нужно ввести Имя устройства и его IP адрес.

Также как видно здесь активирован TACACS.

В двух словах для работы сервисов AAA (Authentication Authorisation Accounting) с сервером ACS могут использоваться два протокола - RADIUS и TACACS+. По сути с помощью этих протоколов AAA client общается с сервером ACS. TACACS+ является cisco - проприетарным, а RADIUS открытым стандартом.
TACACS+ в определённом смысле более продвинут: например он полностью шифрует свои пакеты, в то время как RADIUS шифрует лишь пароли.
У RADIUS же бесспорный плюс - это его открытость и поддержка множеством производителей.

Для управления доступом к командной строке рекомендуется использовать TACACS+, т.к. он поддерживает различные примочки типа Command Authorization и тд. А для доступа к VPN или к WIFI рекомендуется RADIUS, т.к. это открытый стандарт.

Итак для Административного доступа мы активировали TACACS и также ввели пароль shared secret. Пароль на этой странице должен совпадать с пароле в настройке TACACS со стороны маршрутизатора.

Для доступа по VPN для маршрутизатора, выполняющего роль VPN-концентратора нужно также активировать и RADIUS:

Identity group

В ACS мы можем создавать пользователей (internal user).
Пользователь может входить в Identity Group. Правило политики может использовать Identity Group, тем самым влияя на все пользователей этой группы.
Для создания группы идем:
Users and Identity Stores > Identity Groups - Create
При создании группы нужно ввести только ее имя.
Создадим две группы:
Admin - Для административного доступа к устройствам
WebVPN_access - для доступа к Web VPN

Добавление пользователей

Users and Identity Stores > Internal Identity Stores > Users - Create

Вообще ACS может работать не только со своими пользователями, но и к примеру с пользователями из Active Directory, поэтому Internal Identity Stores означает именно внутреннюю БД пользователей на борту самого ACS
При создании пользователя мы вводим его имя, пароль и его группу, enable password используется для административного входа, если необходимо вводить enable.

Создадим несколько пользователей в разных группах:

Создание политик

Итак, мы сделали все необходимое, чтобы можно было создавать собственно сами политики, регулирующие доступ.
Как уже было сказано, политики представляют собой список правил, которые обрабатываются в порядке нумерации.
В ACS есть возможность сделать несколько разных списков правил, например для Device Administration и для Wireless network access, эти списки называются access services.

Access service - это есть некая административная единица, которая в свою очередь в себя включает собственно политики.
Service selection rules - определяют в каких случаях какой Access service будет выбран.

По умолчанию созданы два Access service:
- Default Device Admin
- Default network access

Если мы заглянем в Service Selection Rules, то увидим что Default network access будет выбран если используется протокол Radius, а Default Device Admin - если используется протокол Tacacs.

Для наших целей этого достаточно.
Default Device Admin мы будем использовать для Device Administration
А Default network access нам пригодится для регулирования доступа пользователей по VPN.

Вернемся к Access Service. В нем располагаются политики. Политики бывают двух видов:

Identity - Политики Identity определяют из каких источников пользователь будет идентифицирован. Источники могут быть разными: это может быть внутренняя БД ACS или Internal Identity Store, внешняя база Active Directory и т.д. Политики Identity идентифицируют пользователя или определяют кто он и откуда.

Тут может быть либо Single result selection либо Rule based result selection, для наших задач оставим Single
В Default Device Admin - Identity мы оставим в качестве источника Internal Users

Authorization - эти политики производят Авторизацию пользователя или определяют кому какие права дать.
Здесь мы создадим политику, дающую доступ членам группы Admin. А в дефолной последней политике мы сделаем Result Deny.

Итак что у нас получилось в итоге:
Service selection rules отдают запросы по Radius на access service Default Network Access, а по TACACS на Default Device Admin.
В Default Device Admin Identity лезет в локальную БД, а Authorization проверяет пользователя на членство в группе Admin, и при положительном результате возвращает "Permit Access".

Настройка маршрутизатора для Device Administration

Для Device Administration нам нужно сделать так, что при попытке входа в консоль маршрутизатор обращался на ACS по протоколу TACACS.

aaa group server tacacs+ tac_acs
server 10.5.14.249
ip tacacs source-interface Vlan1
! создается группа tac_acs, использующая протокол TACACS для обращения к серверу с IP и с определенным IP адресом источника.
! IP адрес источника должен совпадать с IP адресом нами ранее созданного AAA Client, т.е. нужно выбрать интерфейс на котором висит IP 10.5.11.1

aaa authentication login cons_login group tac_acs local
! Запись cons_login определяет порядок обработки логина, т.е. первым делом идет обращение на группу tac_acs, если же тот окажется недоступным, то будет проверять локальная база пользователей
aaa accounting exec default start-stop group tac_acs
aaa accounting commands 0 default stop-only group tac_acs
aaa accounting commands 1 default stop-only group tac_acs
aaa accounting commands 15 default stop-only group tac_acs
! Данные записи включают учет времени регистрации и лог введенных пользователем команд. Лог отдается в группу tac_acs.

tacacs-server host 10.5.14.249 key local_pass
tacacs-server directed-request
! создается серевер TACACS, тут важен его IP, и особенно Key, он должен совпадать с тем что мы ввели в свойствах AAA клиента в разделе shared secret.

line vty 0 4
login authentication cons_login
line vty 5 15
login authentication cons_login
! Терминальные линии настраиваются на запрос на запись cons_login

Собственно все готово.
Можно вводить команды. Единственное, для проверки не закрывайте окно в котором ввели команды. Откройте другое окно терминала и проверьте пустит или нет. Если что-то пойдет не так, в первом окне всегда можно будет отменить введенные команды.
Либо используйте test aaa group (см. раздел Проверка)

Все команды одним блоком:

aaa group server tacacs+ tac_acs
 server 10.5.14.249
 ip tacacs source-interface Vlan1

aaa authentication login cons_login group tac_acs local
aaa accounting exec default start-stop group tac_acs
aaa accounting commands 0 default stop-only group tac_acs
aaa accounting commands 1 default stop-only group tac_acs
aaa accounting commands 15 default stop-only group tac_acs

tacacs-server host 10.5.14.249 key baug_local
tacacs-server directed-request

line vty 0 4
 login authentication cons_login

line vty 5 15
 login authentication cons_login

Те же команды в "новом стиле". Это также рабочая и рекомендуемая конструкция.

aaa group server tacacs+ tac_acs
 server name acs01
 ip tacacs source-interface Vlan1

aaa authentication login cons_login group tac_acs local
aaa accounting exec default start-stop group tac_acs
aaa accounting commands 0 default stop-only group tac_acs
aaa accounting commands 1 default stop-only group tac_acs
aaa accounting commands 15 default stop-only group tac_acs

tacacs-server directed-request
tacacs server acs01
 address ipv4 10.5.14.249
 key key_local

line vty 0 4
 login authentication cons_login

line vty 5 15
 login authentication cons_login

11.08.2015 Еще вариант внедрения с авторизацией

Пожалуй самая универсальная версия.

! Включаем AAA
aaa new-model
!
! Добавляем локального админа
! Он будет использоваться в случае недоступности сервера ACS:
username adm_user privilege 15 secret vH74_dfj83L
!
! Добавляем сервера ACS, а также ключ для доступа к серверам
tacacs-server directed-request
tacacs server acs01
 address ipv4 192.168.110.46
 key my_key
tacacs server acs02
 address ipv4 192.168.110.47
 key my_key
!
! Добавляем группу серверов ACS
aaa group server tacacs+ tac_acs
 server name acs01
 server name acs02
 ip tacacs source-interface Port-channel1.180
!
! Настраиваем default method list, предназначенный для authentication.
! default method list будет использоваться для аутентификации сессий
! SSH, Telnet, VTY, AUX, Console в случае если в свойствах этой сессии не указан
! другой method list.
! login - означает что method list используется для логина.
! default - то что он дефолтный
! local - первый метод аутентификации через local БД
! enable - второй метод аутентификации с использованием пароля enable (имя пользователя не важно)
aaa authentication login default local enable
!
! Следующий method list является custom authentication method list, и предназначен для 
! аутентификации в vty.
! Здесь method tac_acs есть обращение к группе серверов созданным нами ранее
aaa authentication login authen_cons_login group tac_acs local
!
! Настроим method list для автормзации. 
aaa authorization exec author_cons_login group tac_acs local
!
! Следующая конструкция предназначена для включения Accounting.
! 1 и 15 означает уровни privelege на которых будет происходить accounting.
! Также отметим, что accounting возможен только при работе с сервером ACS
aaa accounting commands 1 default start-stop group tac_acs
aaa accounting commands 15 default start-stop group tac_acs
!
! Вешаем правила на линии vty
line vty 0 4
 login authentication authen_cons_login
 authorization exec author_cons_login
!
line vty 5 15
 login authentication authen_cons_login
 authorization exec author_cons_login

Безусловно, для работы с ACS должен быть настроен и сам сервер ACS.
Без сервера ACS данная конфигурация также будет функционировать, при этом аутентификация будет происходить по локальной БД, в которой а нас находится единственный пользователь adm_user с максимальным уровнем privilege 15.

Проверка

Сперва всегда проверяйте доступность сервера от маршрутизатора. Сервер ACS должен пинговаться.

Очень удобное средство - это тестирование AAA, например:
test aaa group tac_acs admin cisco123 legacy

Посмотреть ошибки наиболее информативно и интуитивно понятно в самом ACS:
Monitoring and Reports -> Launch Monitoring & Report Viewer
Reports -> Catalog -> AAA protocol -> TACACS Authentication -> Today

Также можно включить Debug и на маршрутизаторе:
debug aaa authorization
debug tacacs
debug tacacs packet

В процессе проверки пригодится команда для отображения залогиненных юзеров:
show users

Настройка авторизации через сервер ACS

Аутентификация - это определение кем является пользователь.
Авторизация - это процесс отдачи определенных прав этому пользователю

Авторизация может понадобиться например в случае когда необходимо дать возможность определенным лицам выполнять некоторые команды, но не являясь полноценным администратором.
Тема делегирования доступа обсуждается в статье Делегирование прав доступа к консоли или Role-Based Access Control (RBAC)

Разрешим определенному пользователю менять IP адрес маршрутизатора:
(1) На маршрутизаторе создаем Custom Privilege level
privilege interface level 8 ip address
privilege interface level 8 ip
privilege configure level 8 interface
privilege exec level 8 configure terminal
privilege exec level 8 configure

(2) Для включения авторизации добавляем следующие строки:
aaa authorization exec auth_cons_login group tac_acs local

line vty 0 4
access-class 23 in
exec-timeout 480 0
privilege level 15
password 7 1544525D52737A
authorization exec auth_cons_login
login authentication cons_login
transport input telnet ssh

(3) На ACS добавляем группу Monitor

(4) Добавляем пользователя viewer и включаем его в группу Monitor

(5) Access policies > Access Services > Default device Admin > Athorization
Для создания нового правила нажимаем Create
В разделе Identity Group выставляем группу Monitor

На той же странице в разделе Results по умолчанию стоит значение Permit access, нажмем кнопку Select .
Откроется окно доступных значений. По умолчанию там есть только Permit Access и Deny Access. Нажмем Create:

Во вкладке Common tasks выставляем уровень 8

Таким образом общий вид правил получится следующий:

Теперь, если мы попытаемся зайти под пользователем Viewer, получится следующее:

Включение поддержки AD

Мы настроили административный доступ с использованием пользователей во внутренней базе ACS.
Можно конечно ввести всех пользователей в сам ACS, но гораздо практичней использовать уже существующие их учетки в базе AD.
Для этого нам необходимо произвести подключение к AD.
По сравнению с ACS4.x, в пятой версии подключение к AD существенно упростилось.
Нужно зайти на страницу:
Users and Identity Stores > External Identity Stores > Active Directory
Вбить имя домена FQDN, а также имя и пароль Админа этого домена. Все остальное система сделает сама.
Тут же можно протестировать подключение. Для того чтобы домен нормально нашелся, нужно выставить AD-шный DNS сервер в настройке ip name-server х.х.х.х

Если Connectivity Status покажет CONNECTED, то можно переходить к следующему этапу.

В домене также создадим группу с именем SSL_VPN_Users, далее идем:
Users and Identity Stores > External Identity Stores > Active Directory
И добавляем эту группу. Теперь эта группа будет доступна для работы политик.

Identity Store Sequences

Для того чтобы при аутентификации производилось поочередное обращение к нескольким базам, необходимо настроить Identity Store Sequences:
Users and Identity Stores > Identity Store Sequences
В нашем случае будет полезным проверять локальную БД Internal Users, а затем AD, которую мы только что подключили.

Внизу не забудьте выбрать Continue to next identity store in the sequence

Настройка политик для доступа к VPN

Access Policies > Access Services > Default Network Access > Identity
Выбираем созданную Identity Store Sequence Local-AD

Теперь идем в авторизацию:
Access Policies > Access Services > Default Network Access > Authorization

Здесь можно создать три правила:

Первые два - разрешают доступ пользователям из локальных групп, третье из доменной.

Настройка на маршрутизаторе Web VPN

Настройки AAA
aaa authentication login vpn_ls group rad_acs local
aaa group server radius rad_acs
server 10.5.14.249
ip radius source-interface GigabitEthernet0/1
radius-server host 10.5.14.249 key 0 baug_local
radius-server directed-request

Настройки Web VPN
Подробнее об WebVPN можно прочитать в статье: Web VPN: подключение отовсюду

webvpn gateway gateway_1
ip address 87.237.40.108 port 443
ssl trustpoint WEBVPN
inservice
!
webvpn install svc flash:/webvpn/anyconnect-dart-win-2.5.2019-k9.pkg sequence 1
!
webvpn install svc flash:/webvpn/anyconnect-linux-2.5.3055-k9.pkg sequence 2
!
webvpn context SSL
secondary-color white
title-color #669999
text-color black
ssl authenticate verify all
!
acl "ssl_vpn_acl"
!
!
policy group policy_1
functions svc-enabled
svc address-pool "webvpn_pool" netmask 255.255.252.0
svc keep-client-installed
svc split include 10.5.0.0 255.255.0.0
virtual-template 1
default-group-policy policy_1
aaa authentication list vpn_ls
gateway gateway_1
inservice

Настройка архивирования конфигурации Backup

Архивирование возможно с использованием разных протоколов. Мы рассмотрим настройку архивирования по FTP.
Предположим что FTP у нас поднято на Windows, тогда по умолчанию корневая директория будет C:\Inetpub\ftproot
Создадим там папку: C:\Inetpub\ftproot\ACSBACKUP

Создадим Software Repository
System Administration > Software Repositories > Create

Создадим Scheduled Backups
System Administration > Scheduled Backups > Create

Собственно все, на сервер FTP теперь будут падать файлы бэкапа.

Настройка репликации

Настроенный бэкап есть необходимое требование к любой инсталляции ACS, но также рекомендацией является развертывание нескольких серверов ACS, поскольку это резко повысит общую надёжность системы в целом.

Принцип работы нескольких серверов следующий: в кластере есть один Primary server, все остальные сервера будут Secondary servers. Все изменения конфигурации производятся на Primary server, и далее изменения реплицируются на Secondary servers. Между серверами существуют лишь коммуникации Primary-Secondary, и не существует Secondary-Secondary.

Установка Secondary Server

Аналогично устанавливаем второй сервер, используя другое имя и IP адрес.
Активируем лицензию на нём. При этом номер лицензии должен быть другой, иначе сервера не подружатся.

Идём на ACS02
System Administration > Operations > Local Operations > Deployment Operations

Вбиваем
Primary Instance - адрес первого acs01
Admin Username - админ ACS (тот под которым заходим на web-морду)
Admin Password
Жмём на кнопку Register to Primary
Сервисы ACS02 рестартанут.

Теперь на веб мордах серверов мы будем видеть из роли, те. primary или secondary:

Все действия теперь нужно делать только из веб морды Primary.

Также посмотреть статус можно здесь:
System Administration > Operations > Local Operations > Deployment Operations
Тут же от Secondary можно сделать Request to force a full replication update for this Secondary Instance.

Статус самой репликации можно посмотреть:
System Administration > Operations > Distributed System Management

Если используется аутентификация через AD, нужно добавить второй нод в домен.
Делается аналогично, из веб морды второго сервера:

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

aaa group server tacacs+ tac_acs
 server name acs01
 server name acs02
 ip tacacs source-interface Port-channel1.181
!
aaa group server radius rad_acs
 server name acs01
 server name acs02
 ip radius source-interface Port-channel1.181

aaa authentication login cons_login group tac_acs local
aaa authentication login ezvpn_authen_ls group rad_acs local
aaa authorization network ezvpn_author_ls local 
aaa accounting exec default start-stop group tac_acs
aaa accounting commands 0 default stop-only group tac_acs
aaa accounting commands 1 default stop-only group tac_acs
aaa accounting commands 15 default stop-only group tac_acs

tacacs-server directed-request
tacacs server acs01
 address ipv4 192.168.10.46
 key ost_local
tacacs server acs02
 address ipv4 192.168.10.47
 key ost_local

radius-server directed-request
!
radius server acs01
 address ipv4 192.168.10.46 auth-port 1645 acct-port 1646
 key ost_local
!
radius server acs02
 address ipv4 192.168.10.47 auth-port 1645 acct-port 1646
 key ost_local

line vty 0 4
 access-class 23 in
 exec-timeout 480 0
 privilege level 15
 login authentication cons_login
 transport input all
line vty 5 15
 access-class 23 in
 exec-timeout 480 0
 privilege level 15
 login authentication cons_login
 transport input all

ACS + WLC

Рассмотрим теперь как подружить ACS и WiFi.
Зачем это нужно? В подавляющем большинстве случаев подключения к WiFi выполняется с использованием WPA2 + Preshared key. Т.е. на WLAN выставляется ключ, который необходимо знать для подключения к сети. Понятно, что с точки зрения безопасности это не лучший вариант.
Давайте сделаем небольшой шаг в строну безопасности, и настроим авторизацию по доменным учеткам.

Немного теории
Для аутентификации клиента был разработан протокол EAP, или Extensible Authentication Protocol.
EAP инкапсулирует usernames, passwords, certificates, tokens, one-time password (OTPs), которые клиент отсылает для аутентификации.
EAP стал общим стандартом, но EAP - это протокол второго уровня.

EAP over LAN (802.1X) - это модификация протокола EAP, позволяющая выполнять аутентификацию в сети LAN.
При этом взаимодействие происходит следующим образом:
- Клиент подключается к сети (например Wifi), контроллер запрашивает имя и пароль.
- Клиент упаковывает это в EAP Frame и отдаёт контроллеру.
- Поскольку EAP протокол 2-го уровня, контроллер упаковывает всё это в протокол RADIUS, и отправляет на сервер ACS, где собственно и происходит Authentication.

Начнем настройку:
Создадим NDG для WLC.
Network Resources > Network Device Groups > Device Type - Create

Добавляем наш контроллер WLC как AAA Client.
Здесь нужно запомнить какой пароль мы ввели для RADIUS.
Также, обратите внимание, мы добавили этот девайс в созданную нами группу NDG: Network Device Groups, WLC.
Network Resources > Network Devices and AAA Clients > New

Добавляем группу Identity Group в ACS.
В эту группу можно будет добавить локальным пользователей, для доступа в WiFi:
Users and Identity Stores > Identity Groups > New

Теперь настроим доступ на ACS.
В Identity настроим источники БД, где будет проверяться юзера:
Access Policies > Access Services > Default Network Access > Identity
Здесь мы выберем созданную нами ранее Local-AD, которая сначала идёт во внутреннюю БД ACS, а затем в AD.

Предоставляем сам доступ:
Access Policies > Access Services > Default Network Access > Authorization
Здесь мы создали два правила:
Rule-3 разрешает доступ для Internal Users, состоящих во внутренней группе wifi_access
Rule-1 разрешает доступ для доменных юзеров состяощих также в определённой группе
Также здесь выставлено NDG, дающее право выходить только через устройство WLC.
Обратите внимание, что правило Default выставлено на deny access:

Настройки WLC

1. Настройка RADIUS Authentication
   Логинимся на WLC и идём в настройки RADIUS:
   SECURITY > AAA > RADIUS > Authentication > New
   Здесь мы вбиваем IP адрес нашего сервера ACS, а также Secret, который мы вводили в настройках RADIUS со стороны ACS.
   
2. Настройка RADIUS Authentication Accounting
   SECURITY > AAA > RADIUS > Accounting > New
   Всё аналогично:
   
3. Создаём WLAN, и настраиваем его для работы с 802.1X:
   Выставляем имя WLAN, VLAN, а также видимость.
   WLANs > Edit
   

   Выставляем настройки Security Layer2.
   WLANs > Edit the SSID > Security
   

   Привязываем сервер RADIUS к данному WLAN:
   

4. Собственно всё. Теперь клиент будет спрашивать метод EAP, и нужно будет выбрать:
   - PEAP (EAP-MSCHAPv2)
   - Доменные имя и пароль, причем имя указывать без домена.
   Дальнейшее нужно смотреть в логах ACS.
   Изначально рекомендуется упростить политику доступа, начать с аутентификации в локальной базе, и затем постепенно усложнять.
   

Настройка статического IP для клиентов anyconnect
cisco asa anyconnect acs static ip

Сохранил замечательную статью.
122378-ip_assignment_using_an_external_server_on_acs_5.pdf