ИТ-Инфраструктура / Использование стандарта IEEE 802.1x в сети передачи данных

802.1x — это стандарт, который используется для аутентификации и авторизации пользователей и рабочих станций в сети передачи данных. Благодаря стандарту 802.1x можно предоставить пользователям права доступа к корпоративной сети и ее сервисам в зависимости от группы или занимаемой должности, которой принадлежит тот или иной пользователь. Так, подключившись к беспроводной сети или к сетевой розетке в любом месте корпоративной сети, пользователь будет автоматически помещен в тот VLAN, который предопределен политиками группы, к которой привязана учетная запись пользователя или его рабочей станции в AD. К данному VLAN будет привязан соответствующий список доступа ACL (статический, либо динамический, в зависимости от прав пользователя) для контроля доступа к корпоративным сервисам. Кроме списков доступа, к VLAN можно привязать политики QoS для контроля полосы пропускания.

Я по большей части специалист по Cisco и хочу рассказать об одной из многих моделей функционирования IEEE 802.1x в сети передачи данных, построенной на оборудовании Cisco Systems.

Для того, чтобы реализовать данную модель потребуется минимальный набор следующих компонентов:

• коммутатор, который будет выступать в роли аутентификатора;
• сервер аутентификации (RADIUS сервер);
• DHCP сервер;
• суппликант (клиент) 802.1x на рабочей станции пользователя;

Для расширенного функционала не лишними окажутся:

• сервер хранения учетных данных пользователей (AD, Samba и пр.);
• серверы сертификатов.

Родной клиент 802.1x присутствует во многих операционных системах, таких как Windows XP/Vista/7/CE/Mobile, Linux, Solaris, Apple OS X, и др. Но, как показывает практика, зоопарк операционных систем, под управлением которых работают пользовательские рабочие станции, а следовательно и обилие встроенных разношерстных суппликантов в них не облегчает, а наоборот в несколько раз усложняет внедрение и дальнейшее использование стандарта 802.1x в компании. Чтобы облегчить свою учесть, желательно использовать унифицированный сторонний клиент, который вам больше понравится, такой, который бы работал под всеми ОС, которые установлены на рабочих станциях ваших пользователей.

Я бы не стал рекомендовать к использованию бесплатные суппликанты, которые распространяются в сети, т.к. на практике они оказались не достаточно функциональны. Что касается клиента Cisco Secure Services Client, предлагаемого компанией Cisco Systems, то он, к сожалению, более не поддерживается, о чем говорит цитата с их официального сайта: «Cisco announces the end-of-sale and end-of life dates for the Cisco Secure Services Client. The last day to order the affected product(s) is January 27, 2012». От себя добавлю, что мне очень понравился Juniper Networks Odyssey Access Client, используя который можно преднастроить его как вам угодно, создать файл инсталляционного пакета MSI и централизованно развернуть на пользовательских рабочих станциях.

Для демонстрации работы стандарта IEEE 802.1x, далее приведу диаграмму процесса авторизации в упрощенном виде, где цифрами указан номер шага:

В наше время сложно представить компанию, информационная инфраструктура которой не была бы управляемой. Под управляемой инфраструктурой я понимаю доменную сеть. При использовании стандарта 802.1x в доменной среде необходимо учитывать один нюанс — нельзя проводить авторизацию в сети передачи данных только по учетной записи пользователя! Все дело в том, что при загрузке, прежде чем вывести окно авторизации пользователя, рабочая станция должна пройти несколько этапов:

1. Получить IP адрес;
2. Определить сайт и контроллер домена;
3. Установить безопасный туннель до AD, используя протоколы LDAP, SMB;
4. Авторизоваться в домене, используя учетную запись рабочей станции по протоколу Kerberos;
5. Загрузить GPO;
6. Запустить скрипты, предписанные GPO на рабочую станцию.

Всего это не случиться, если проводить авторизацию только по учетной записи пользователя. А причина проста, неавторизованная рабочая станция при загрузке не будет допущена к сети передачи данных, все протоколы кроме EAPoL, которые обычно используются для нормального функционирования, будут заблокированы до момента авторизации. Следовательно, если до момента логина пользователя, станция не была авторизована в сети, групповые политики к ней применены не будут. Если вы работаете в доменной среде, обязательно нужно в первую очередь авторизовать в сети рабочую станцию, чтобы она прошла через все вышеперечисленные этапы. Что делать после авторизации рабочей станции решать уже вам, но есть два варранта:

1. Оставить как есть;
2. Провести дополнительную авторизацию по учетным данным пользователя.

Допустим вы решили сперва авторизовать рабочую станцию, а затем пользователя по его учетным данным в AD. С одной стороны подход правильный, но с другой возникают следующие проблемы:

1. Если вы используете быструю оптимизацию процедуры регистрации (Fast Logon Optimization), тогда групповые политики и скрипты не успеют примениться на рабочей станции до того, как пользователь будет авторизован и перемещен в другой VLAN с последующей сменой IP адреса.
2. Если вы отключили Fast Logon Optimization, тогда может случиться такая неприятная ситуация, когда групповых политик и скриптов достаточно много, а пользователь на столько быстр, что успел ввести свои учетные данные и попасть в свой VLAN со сменой IP адреса, тогда процесс корректного включения рабочей станции будет прерван.
3. Если вы используете авторизацию по учетным данным пользователя, то не исключены проблемы с удаленным подключением к рабочей станции администратором. Возможна смена VLAN, а с ним и IP адреса при подключении другого пользователя.

Самым беспроигрышным и безопасным вариантом будет авторизация рабочей станции в сети по сертификату без авторизации пользователя. Конечно, это не значит, что нужно навсегда отказаться от авторизации пользователя. Просто для этого необходимо подойти к процессу авторизации несколько с другой стороны – если до этого мы говорили про процедуру смены VLAN (динамический VLAN) в качестве основного разделителя прав пользователей, то в данном случае нам поможет динамический список доступа. В результате, вместо смены VLAN и IP адреса, изменятся правила ACL конкретного VLAN в соответствии с правами доступа конкретного пользователя. К сожалению, такая функция доступна не везде, но, по крайней мере, она есть на сервере контроля доступа ACS версии 5.2.

Кстати говоря, здесь я хотел бы рассмотреть некоторые логические элементы взаимосвязи между сервером контроля доступа ACS, он же Cisco Access Control Server, он же RADIUS сервер, и хранилищем учетных данных, например, Active Directory. На сервере ACS устанавливаются взаимоотношения с AD по типу:

Группа объектов ACS = Группе объектов AD

Права доступа для объектов конкретной группы устанавливаются на ACS. Логика работы получается следующая:

1. Приходит запрос на проверку авторизационных данных;
2. ACS обращается к серверу AD с вопросом кто это такой и в какой группе AD он находится;
3. AD сообщает что это такой-то объект и он находится у меня в такой-то группе;
4. ACS сопоставляет имя группы AD и локально-созданную группу с политиками доступа на ACS, которой она соответствует;
5. Если соответствие найдено, ACS сообщает коммутатору, какие правила доступа применить на порт согласно заданным критериями безопасности на ACS для этой группы.

Если соответствие не найдено или сервер AD сообщил, что авторизационные данные недействительны, коммутатор помещает порт в гостевой VLAN.

Теперь, когда с порядком авторизации стало более или менее понятно, необходимо предусмотреть нештатные ситуации:

1. Не включен клиент 802.1x. В том случае, когда клиент не активен, рабочая станция не может идентифицировать себя, она автоматически помещается в гостевой VLAN с ограниченным доступом к сети передачи данных. Процесс выполнения данной функции представлен на рисунке:

2. Клиент 802.1x включен, но настроен неверно. В том случае, когда клиент не может корректно идентифицировать себя, рабочая станция автоматически помещается в гостевой VLAN с ограниченным доступом. Процесс выполнения данной функции представлен на рисунке:

3. RADIUS сервер недоступен. Для повышения отказоустойчивости в случае выхода из строя сервера аутентификации, рабочая станция помещается в Failover VLAN с минимально необходимыми для выполнения работы правами доступа к сети передачи данных:

Здесь же отмечу, что с определением недоступности сервера RADIUS компания Cisco Systems дала маху, а именно, по истечении deadtime таймера, коммутатор считает мертвый сервер RADIUS живым и, если он настроен, то запускает процесс переавторизации всех пользователей, подключенных к нему. Не трудно представить, как начинает «колбасить» пользователей, когда их заставили пройти авторизацию заново, в то время как сервер RADIUS до сих пор мертв, хотя коммутатор считает его живым. В итоге рабочие станции не могут авторизоваться вообще ни в одном VLAN-е, они остаются подвешенными в воздухе, отрезанными от сети, они не могут попасть ни в гостевой VLAN ни в Failover VLAN.
Данная ошибка официально признана Cisco, ее описание можно найти на их сайте:

"CSCir00551 — Misleading radius debug message
Description
Symptom:
The "%RADIUS-4-RADIUS_ALIVE: RADIUS server 172.27.66.89:2295,2296 has returned."
is a little misleading. It is not saying that the server has returned, in the
sense of being heard from. It is only saying that RADIUS has marked the server
as being alive because the deadtime timer has expired, and RADIUS is willing to
re-send messages to this server again.
Conditions:
None
Workaround:
None"

Подвержены данной ошибке все операционные системы коммутаторов, вплоть до самых последних версий, которые мне удалось проверить. Кроме того все они перечислены в списке affected ОС на официальном сайте Cisco. Почему до сих пор не исправили эту ошибку, остается только загадкой.

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

Здесь же остановимся на настройке только коммутаторов. Настройки будут различаться в зависимости от новизны IOS.

Старый IOS

Для настройки связи с сервером RADIUS необходимы следующие команды:

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
radius-server host 192.168.20.20 auth-port 1645 acct-port 1646 key SecretSharedKey123
radius-server source-ports 1645-1646
radius-server dead-criteria time 5 tries 4
dot1x system-auth-control

Для настройки отдельного порта, используются следующие команды:

1. Общие команды:

interface GigabitEthernet1/0/1
switchport mode access
dot1x pae authenticator
dot1x port-control auto
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
end

2. Гостевой VLAN:

interface GigabitEthernet1/0/1
dot1x guest-vlan 1 //гостевой VLAN
dot1x auth-fail vlan 1 //auth-fail VLAN
dot1x auth-fail max-attempts 2
end

3. Failover VLAN:

interface GigabitEthernet1/0/1
dot1x critical
dot1x critical vlan 150 //failover VLAN
end

Все вместе:

interface GigabitEthernet1/0/1
switchport mode access
dot1x critical
dot1x pae authenticator
dot1x port-control auto
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout reauth-period server
dot1x timeout tx-period 5
dot1x reauthentication
dot1x guest-vlan 1 //гостевой VLAN
dot1x auth-fail vlan 1 //auth-fail VLAN
dot1x auth-fail max-attempts 2
dot1x critical vlan 150 //failover VLAN
spanning-tree portfast
end

Новый IOS

Для настройки связи с сервером RADIUS необходимы следующие команды:

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
radius-server dead-criteria time 5 tries 4
radius-server deadtime 30
radius-server host 192.168.20.20 key SecretSharedKey123
dot1x system-auth-control

Для настройки отдельного порта, используются следующие команды:

1. Общие команды:

interface GigabitEthernet1/0/1
switchport mode access
authentication port-control auto
authentication violation protect
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
end


2. Гостевой VLAN:

authentication event fail action authorize vlan 1
authentication event no-response action authorize vlan 1

3. Failover VLAN:
authentication event server dead action authorize vlan 150

Все вместе:
interface GigabitEthernet0/2
switchport mode access
authentication event fail action authorize vlan 1
authentication event server dead action authorize vlan 150
authentication event no-response action authorize vlan 1
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation protect
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
end

В заключение, хочу отметить, что рассказывать про принципы работы стандарта 802.1x можно намного дольше, больше и глубже. В данном материале я постарался изложить самые основные, элементарные принципы работы с данным стандартом. В свое время мне бы подобный материал очень пригодился как отправная точка для его будущего изучения.

Автор: stillevil