По советам уважаемых хабрачитателей я несколько изменю формат своих публикаций по ASA. Сюда буду писать самое интересное, не утомляя подробным описанием. Полную статью «ASA. Перехватывающая аутентификация» читайте в нашем свежеиспеченном блоге
А здесь я расскажу, как используя ASA, напрямую аутентифицироваться в AD
На МСЭ часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. На ASA такая проверка называется «перехватывающая аутентификация» (cut-through proxy).
Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting).
Примечание: в английском слове authentication нет слога «фи», который появился в русском «аутентификация» скорее всего из-за созвучия слову «идентификация». Причем, в нашем могучем языке есть и «аутентичность». Без всякого «фи» :) Не попадитесь!
Аутентификация.
Отвечает на вопрос «есть ли такой пользователь». Поиск этого пользователя может производиться как в локальной (LOCAL) базе данных, так и во внешних (TACACS+, RADIUS, AD по протоколу LDAP).
Настройка сервера LDAP подразумевает указание учетной записи пользователя из AD, с которой ASA будет входить в LDAP, тип сервера, «корень» поиска и т.д.
Пример:
После того, как настроены сервера, самое время определить, какой трафик нам интересно проверять и не пропускать без аутентификации. На ASA за это отвечает…конечно список доступа, где строчками permit указывается такой трафик. Сам список доступа для аутентификации применяется командой
При этом будут проверяться пакеты, поступающие на вход указанного интерфейса.
Например, хотим проверить весь трафик из локальной сети 10.1.1.0/24 (за интерфейсом inside), идущий во все сети, кроме 172.16.1.0/24:
А как же спросить у пользователя его логин/пароль? Ведь не может же какой-нибудь пинг инициировать запрос?
Перехватить сессию и спросить логин и пароль ASA может по протоколам http/https, ftp, telnet. Если же необходимо аутентифицировать другой трафик, то надо сделать 2 телодвижения: пойти куда-нибудь за ASA по одному из указанных протоколов, ввести свои логин/пароль либо в броузере либо в telnet либо в ftp окошке. Надо учитывать, что такой трафик обязательно должен быть указан в списке доступа для интересного трафика.
Например, мы хотим, чтобы пользователь мог пойти по telnet или http на хост 1.1.1.1 и его бы спросили логин и пароль. Тогда этот трафик обязательно должен попадать в список доступа. Вот такой не подойдет, т.к. по telnet работать не будет:
Если данные верны, ASA пропустит ваш трафик. Но только на указанное время. По умолчанию таймауты, скажем так, странные: 5 минут абсолютного времени, таймаут неактивности не отслеживается. Поменять их не только можно, но и нужно:
Пример:
Таким образом, с аутентификацией все просто: если более ничего не указывать, то пользователю, а вернее, ip-адресу его компьютера, будет можно все.
Гораздо более интересный момент – авторизация, то есть ограничение прав пользователя.
Для авторизации по LDAP нам нужен «костыль» — специальная конструкция, которая сопоставит атрибуту LDAP атрибут RADIUS, который поймет ASA. Такая конструкция называется
Пример. Сопоставим атрибуту ipPhone базы AD атрибут IETF-Radius-Filter-Id (список доступа). И опишем, что если в указанном атрибуте мы получим слово «BUHG», то на пользователя применим список доступа BUH, который уже написан на ASA:
Важно: если в указанном атрибуте мы ничего не получили, мы его игнорируем, а если получили слово, не описанное в значениях для данного атрибута, то доступ будет запрещен. Таким образом, администратор AD может влиять на права доступа. Например, может перекрыть интернет неугодному пользователю, не прикасаясь к ASA:)
Осталось только применить этот список атрибутов в конкретном сервере LDAP
Пример:
Приятного авторизования, дорогие хабрачитатели-цисколюбы :)
ЗЫ Я сам: «На нормальных ОС это делается половиной команды» :) Так что поможем админам «ненормальных» :)
А здесь я расскажу, как используя 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
Приятного авторизования, дорогие хабрачитатели-цисколюбы :)
ЗЫ Я сам: «На нормальных ОС это делается половиной команды» :) Так что поможем админам «ненормальных» :)
