Pull to refresh

ASA. Настройка перехватывающей аутентификации через AD и LDAP

Reading time 4 min
Views 18K
По советам уважаемых хабрачитателей я несколько изменю формат своих публикаций по ASA. Сюда буду писать самое интересное, не утомляя подробным описанием. Полную статью «ASA. Перехватывающая аутентификация» читайте в нашем свежеиспеченном блоге

А здесь я расскажу, как используя ASA, напрямую аутентифицироваться в AD

На МСЭ часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. На ASA такая проверка называется «перехватывающая аутентификация» (cut-through proxy).

Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting).

Примечание: в английском слове authentication нет слога «фи», который появился в русском «аутентификация» скорее всего из-за созвучия слову «идентификация». Причем, в нашем могучем языке есть и «аутентичность». Без всякого «фи» :) Не попадитесь!

Аутентификация.
Отвечает на вопрос «есть ли такой пользователь». Поиск этого пользователя может производиться как в локальной (LOCAL) базе данных, так и во внешних (TACACS+, RADIUS, AD по протоколу LDAP).


Настройка сервера LDAP подразумевает указание учетной записи пользователя из AD, с которой ASA будет входить в LDAP, тип сервера, «корень» поиска и т.д.

aaa-server {SERVERNAME} protocol ldap
aaa-server {SERVERNAME} ({interface}) host {IP_SERVER}
 ldap-base-dn {корневой уровень}
 ldap-scope {subtree|onelevel}
 ldap-naming-attribute {передаваемый атрибут}
 ldap-login-dn {имя пользователя ASA}
 ldap-login-password {пароль на пользователя ASA}
 server-type {Microsoft|Novell|OpenLDAP|sun|auto}

Пример:
aaa-server AD (dmz) host 172.16.1.100
 ldap-base-dn ou=Employers, dc=anticisco, dc=ru
 ldap-scope subtree
 ldap-naming-attribute sAMAccountName
 ldap-login-dn cn=ASA, cn=users, dc=anticisco, dc=ru
 ldap-login-password ASALDAPPASS
 server-type microsoft

После того, как настроены сервера, самое время определить, какой трафик нам интересно проверять и не пропускать без аутентификации. На ASA за это отвечает…конечно список доступа, где строчками permit указывается такой трафик. Сам список доступа для аутентификации применяется командой

aaa authentication match {AUTHACL} {interface} {SERVERNAME}

При этом будут проверяться пакеты, поступающие на вход указанного интерфейса.

Например, хотим проверить весь трафик из локальной сети 10.1.1.0/24 (за интерфейсом inside), идущий во все сети, кроме 172.16.1.0/24:
access-list AUTH deny ip 10.1.1.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list AUTH permit ip 10.1.1.0 255.255.255.0 any
aaa authentication match AUTH inside RAD

А как же спросить у пользователя его логин/пароль? Ведь не может же какой-нибудь пинг инициировать запрос?
Перехватить сессию и спросить логин и пароль ASA может по протоколам http/https, ftp, telnet. Если же необходимо аутентифицировать другой трафик, то надо сделать 2 телодвижения: пойти куда-нибудь за ASA по одному из указанных протоколов, ввести свои логин/пароль либо в броузере либо в telnet либо в ftp окошке. Надо учитывать, что такой трафик обязательно должен быть указан в списке доступа для интересного трафика.

Например, мы хотим, чтобы пользователь мог пойти по telnet или http на хост 1.1.1.1 и его бы спросили логин и пароль. Тогда этот трафик обязательно должен попадать в список доступа. Вот такой не подойдет, т.к. по telnet работать не будет:
access-list AUTH permit tcp any any eq 80
access-list AUTH permit udp any any

Если данные верны, ASA пропустит ваш трафик. Но только на указанное время. По умолчанию таймауты, скажем так, странные: 5 минут абсолютного времени, таймаут неактивности не отслеживается. Поменять их не только можно, но и нужно:

timeout uauth {HH:MM:SS} {absolute|inactivity}

Пример:
timeout uauth 0:15:0 inactivity
timeout uauth 20:00:00 absolute

Таким образом, с аутентификацией все просто: если более ничего не указывать, то пользователю, а вернее, ip-адресу его компьютера, будет можно все.

Гораздо более интересный момент – авторизация, то есть ограничение прав пользователя.

Для авторизации по LDAP нам нужен «костыль» — специальная конструкция, которая сопоставит атрибуту LDAP атрибут RADIUS, который поймет ASA. Такая конструкция называется

ldap attribute-map {MAPNAME}
 map-name {LDAPATTRIBUTE} {RADUISATTRIBUTE}
 map-value {LDAPATTRIBUTE} {SENDNAME} {TRANSLATENAME}

Пример. Сопоставим атрибуту ipPhone базы AD атрибут IETF-Radius-Filter-Id (список доступа). И опишем, что если в указанном атрибуте мы получим слово «BUHG», то на пользователя применим список доступа BUH, который уже написан на ASA:
ldap attribute-map AD
 map-name ipPhone IETF-Radius-Filter-Id
 map-value ipPhone BUHG BUH

Важно: если в указанном атрибуте мы ничего не получили, мы его игнорируем, а если получили слово, не описанное в значениях для данного атрибута, то доступ будет запрещен. Таким образом, администратор AD может влиять на права доступа. Например, может перекрыть интернет неугодному пользователю, не прикасаясь к ASA:)

Осталось только применить этот список атрибутов в конкретном сервере LDAP

aaa-server {SERVERNAME} ({interface}) host {IP_SERVER}
 ldap-attribute-map {MAPNAME}

Пример:
aaa-server AD (dmz) host 172.16.1.100
 ldap-attribute-map AD

Приятного авторизования, дорогие хабрачитатели-цисколюбы :)

ЗЫ Я сам: «На нормальных ОС это делается половиной команды» :) Так что поможем админам «ненормальных» :)
Tags:
Hubs:
+6
Comments 3
Comments Comments 3

Articles