Context directory agent настройка

Installation and Configuration Guide for Context Directory Agent, Release 1.0

Book Title

Installation and Configuration Guide for Context Directory Agent, Release 1.0

Chapter Title

Context Directory Agent Overview

View with Adobe Reader on a variety of devices

View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone


Chapter: Context Directory Agent Overview

Context Directory Agent Overview

Unlike traditional security mechanisms, Cisco’s security gateways such as ASA-CX, WSA, ASA and the Cloud-based CWS service, provide security to networks based on the context of the entity requiring access. While traditional network and content security gateways used to rely on the entity’s IP Address only to determine if it should pass the security gateway or not, today’s Cisco products allow to take into account much additional information, and make decisions based on the complete context of the network entity, such as the user currently using it, what operating system it uses, what location is it in, and so on. Security administrators write policies using reference to this context, and when network traffic hits the security gateway, it needs to check what is the context of the originating (and sometimes, also the destined) IP Address.

Cisco Context Directory Agent (CDA) is a mechanism that maps IP Addresses to usernames in order to allow security gateways to understand which user is using which IP Address in the network, so those security gateways can now make decisions based on those users (or the groups to which the users belong to).

CDA runs on a Cisco Linux machine; monitors in real time a collection of Active Directory domain controller (DC) machines for authentication-related events that generally indicate user logins; learns, analyzes, and caches mappings of IP Addresses and user identities in its database; and makes the latest mappings available to its consumer devices.

Starting with patch 2, CDA can now receive information from Cisco Identity Services Engine (ISE) and Cisco Secure Access Control Server (ACS) machines about 802.1x network logins, in order to map users that do not directly login into Active Directory. CDA acts as a syslog server, receiving syslog messages from ISE and ACS, and populates the mapping table using network login information derived from ISE and ACS.

Consumer devices, such as the Cisco Adaptive Security Appliance (ASA) and the Cisco IronPort Web Security Appliance (WSA), interact with the CDA using the RADIUS protocol in order to obtain the latest set of IP-to-user-identity mappings, in any one of the following ways:

For both the on-demand and full-download methods, the request from the consumer device can be specially tagged to indicate that it also includes a registration regarding any subsequent updates.

For example, when a consumer device requests a basic on-demand query, CDA responds with the specific mapping that might have been found in its cache, and does not send any further updates about that mapping. On the other hand, if the on-demand query also includes a registration, the initial response from CDA is the same as before and if, at a later point in time, that specific mapping undergoes a change, then CDA proactively notifies the requesting consumer device (as well as any other consumer devices that have registered for notification) about the change in that specific mapping.

Similarly, when a consumer device requests a basic full download, CDA transfers a snapshot of the session data containing all of the mappings currently found in its cache, and does not send any further updates. On the other hand, if the request is to register for replication, then the initial response from CDA is the same as before. At a later point in time, if the set of mappings undergoes any sort of change (new mappings added or certain mappings changed and so on), then CDA proactively notifies the requesting consumer device (as well as any other consumer devices that have registered for replication) about these changes, relative to the snapshot that was previously sent.

The IP-to-user-identity mappings that are discovered, maintained, and provided by CDA can include not only IPv4 addresses, but also IPv6 addresses.

CDA can send logs to one or more syslog servers.

CDA continues to function if any of the Active Directory domain controllers or the consumer devices have failed. It obtains information from other domain controllers. However, there is no failover for CDA. CDA internally contains a “watchdog” functionality that continuously monitors the Linux processes internal to it, automatically restarting them if it detects that they have crashed. While there is no failover for CDA in itself, the solution as a whole does support failover, controlled by the consumer devices, using their capability to configure a primary and secondary CDA (similar to primary and secondary RADIUS server), and failover to the secondary server in case the primary is unresponsive. It should be noted that primary and secondary CDAs are completely unaware of each other, and do not exchange any state information.

Читайте также:  Настройка мышки на планшете

Functional Overview

Figure 1-1 represents a simplified view of the CDA solution. In this example, a user logs in from a computer and generates web traffic by requesting access to a server. The consumer device intercepts the web traffic and sends a RADIUS request to CDA asking for the user who logged into the computer. CDA, which has been maintaining the latest set of IP-to-user-identity mappings, sends the user information to the consumer device. The consumer device uses the user identity information to determine whether or not to grant access to the end user.

In this example, CDA learns about the user either from the authentication that occurred in the domain controller, or by the authentication performed by ISE that grants network access to the user. The advantage of integrating CDA with ISE is to allow CDA to provide user information from authentication identity servers, which are different than Active Directory servers.

In case ASA is deployed in the network as a VPN concentrator, CDA accepts mapping update events in addition to the login events received from the Active Directory.

Figure 1-1 CDA Architecture

The CDA is responsible for:

CDA interacts with the following components in a network:

Consumer Device

Consumer devices are responsible for actively retrieving (and/or passively receiving) the latest IP-to-user-identity mappings from CDA. A consumer device is responsible for:

These updates are sent as RADIUS Accounting-Request messages.

Active Directory Domain Controller Machines

CDA monitors the security event log of the Active Directory domain controllers in order to retrieve information about user logins and deliver this data to the consumer devices.

Upon startup CDA reads a time based window (history) of users that are already logged-in. After CDA is up and running it monitors and retrieves user logins in realtime. Connection is required between CDA and the Active Directory domain controller for retrieving the user login events.

To connect to the Active Directory domain controllers, the CDA uses an Active Directory user.

An Active Directory user used by CDA must have the required permissions in order to connect and monitor the Active Directory domain controllers

The Active directory user used by CDA can be a member of the Domain Admin Group; however this is not mandatory if you have installed the latest CDA patch (any future CDA patches would include this functionality as well).

The connection between CDA and the Active Directory domain controller is also authenticated using MS NTLM protocol. CDA patch 2 supports NTLMv1 and NTLMv2.

Receiving Network Login Information from ISE and ACS

Most wireless networks and a large portion of wired network employees today use 802.1x to control who and what can access the network. When a non-AD workstation (such an Apple MacBook or iMac, Android or iOS phone or tablet, or anything that is not running off a domain member) accesses the network, as it does not login to Active Directory, the domain controllers have no trace of its identity. In such cases CDA cannot build an IP to identity map.

Through the interaction with ISE and ACS, CDA can now be aware of the network logins, be it of a domain member or not, and can build an IP Address to identity map of a much larger portion of the network. CDA receives syslog messages from ISE and/or ACS in order to derive which users have logged in to the network, analyzes those messages to extract the username and the IP Address it is using, and inserts this information into the Identity Mapping table.

Figure 1-2 explains how CDA maps both 802.1x login events and non-802.1x AD login events (AD and non-AD.)

Figure 1-2 Mapping Both AD and Non-AD Events

This integration allows consumer devices such as ASA-CX and WSA to make security decisions for a large portion of network endpoints, including those that are not domain members. CDA passes the information to the consumer devices in the same format whether the user/domain information was received from a Windows domain controller event log or through integration with ISE/ACS.

Syslog Servers and Clients

CDA can forward logs containing administrative and troubleshooting information to one or more syslog servers. It also updates the IP-to-user-identity mapping information. The contents of these logs are identical to that of the customer logs that are locally available on the CDA machine. The syslog mechanism allows this information to be distributed remotely, to any target machine running a syslog server and capable of receiving syslog messages.

Читайте также:  Настройка рэа что это

CDA can also act as a syslog server when one or more syslog clients are added. It can connect to Cisco Identity Services Engine (ISE) and Cisco Secure Access Control System (ACS) and receive syslog messages.

CDA Performance and Scalability

CDA can support up to 80 domain controller machines, and can internally cache up to 64,000 IP-to-user-identity mappings. It supports up to 100 Identity consumer devices. CDA processes 1000 IP-to-user-identity mappings per second (input and output).

CDA is tested to support three Syslog clients (when it acts as a syslog server), twenty administrators, and five concurrent admin user interface sessions.

CDA Deployment Recommendations

It is recommended to consider the following aspects while deploying CDA:

Figure 1-3 The Recommended CDA Deployment Type


Интеграция Cisco FirePOWER и ISE

Привет habr! Начиная с версии FirePOWER, появилась возможность интеграции с корпоративным сервером централизованной аутентификации и авторизации Cisco ISE. В данной заметке кратко рассмотрим, что именно даёт связь Cisco FirePOWER с ISE и как эта связь настраивается.

Интеграция FirePOWER c ISE даёт в первую очередь новый способ получения идентификационных данных пользователей. До версии FirePOWER аутентификация пользователей происходила в пассивном режиме. Это означает, что где-то в сети на компьютере, входящем в домен, или непосредственно на сервере Active Directory (AD) должен быть установлен агент. Данный агент должен мониторить логи AD на предмет событий login/logoff пользователей и передавать соответствия IP-адреса и учётной записи пользователя на FirePOWER. Последняя реинкарнация данного агента от SourceFIRE получила название Cisco FirePOWER User Agent.

В наследство от SourceFIRE компания Cisco получила агент SourceFIRE User Agent, способный интегрироваться с системой управления Defence Center (FireSIGHT). К слову сказать, сейчас актуальное название системы управления FirePOWER выглядит так: FirePOWER Management Center (сокращённо FMC). А агент именуется Cisco FirePOWER User Agent.

До этого у Cisco были собственные варианты агентов: Cisco Active Directory Agent (AD Agent), управляемый из командной строки, и более позднее решение с графическим интерфейсом — Context Directory Agent (CDA). Данные решения можно было использовать для получения функциональности Identity FireWall на устройстве Cisco ASA. Т.е. на Cisco ASA появлялась возможность создавать списки доступа не по IP-адресам, а по учётным записям из AD. Также CDA можно было использовать с решением Cisco ASA CX (данное решение уже более не продаётся в пользу ASA+FirePOWER), с WEB-proxy сервером Cisco WSA и с сервером аутентификации и авторизации Cisco ISE.

Преимущество использования агента для аутентификации пользователей – полная прозрачность процесса аутентификации. Другими словами, User Experience для конечного пользователя абсолютно никак не меняется при внедрении аутентификации на сетевом шлюзе. Однако, у данного метода ряд недостатков. Очевидный минус заключается в самом подходе: нужно устанавливать дополнительное ПО, которое должно круглосуточно мониторить логи AD. Если по какой-то причине логи AD будут недоступны, пользователь не будет авторизован на сетевом устройстве. Также может проявиться проблема с неверным предоставлением прав доступа. Например, если на момент входа пользователя в систему ПК был отключен от сети, в теории, новый пользователь сможет получить права доступа предыдущего пользователя ПК, если через какое-то время подключит ПК обратно к сети.

Другой подход – активная аутентификация, при которой установка агента не требуется, но пользователи должны самостоятельно вводить учётные данные по запросу. Недостаток этого метода очевиден.

Активная аутентификация на FirePOWER также была представлена с выходом версии

Использование Cisco ISE для идентификации пользователей на FirePOWER решает проблемы, присущие как пассивной аутентификации с агентом, так и активной аутентификации. Как следует из определения, Cisco ISE является централизованной системой аутентификации и авторизации пользователей при подключении в сеть. Как только пользователь успешно проходит процедуры аутентификации и авторизации и получает доступ в сеть, на Cisco ISE появляется полная информация об этом пользователе, включающая IP-адрес пользователя и его учётную запись. Далее эту информацию достаточно передать на FirePOWER, а точнее на систему управления FirePOWER Management Center. Cистема получит возможность сопоставить IP-адрес сетевой транзакции с учётной записью пользователя и применить настроенные политики доступа.

Но функциональность Cisco ISE не ограничивается аутентификацией и авторизацией пользователей в сети. Cisco ISE позволяет профилировать пользовательские устройства, т.е. определять, какое устройство подключено к определённому порту определённого коммутатора. К информации об устройстве относятся: производитель, версия ОС, тип устройства (мобильное/стационарное) и т.д. Данная информация также может быть передана на FirePOWER. Это даёт возможность настраивать разные правила доступа для разных типов устройств. Например, для Android и iOS более специфичные ограничения, чем для Microsoft Workstation. Пример настройки правила с учётом типа устройства представлен ниже:

Читайте также:  Yeastar neogate ta410 настройка asterisk

Помимо профилирования устройств Cisco ISE позволяет реализовать архитектуру Cisco TrustSec. Очень кратко, Cisco TrustSec позволяет разграничивать доступ в сети по меткам, называемым Security Group Tags (SGT). Метка представляет собой произвольное число от 1 до 65535 передаётся в рамках Ethernet-кадра. Соответственно, устройства, через которые проходят кадры с метками SGT, должны поддерживать архитектуру TrustSec. В противном случае, информация о метке для сетевой транзакции может передаваться посредством протокола Security Group Tag Exchange Protocol (SXP). При успешном прохождении процедур аутентификации и авторизации пользователю присваивается метка, определяющая его доступ к ресурсам сети. Описание, присвоение метки SGT, а также настройка правил доступа по меткам (SGT ACL) осуществляется при помощи Cisco ISE. Начиная с версии FirePOWER появилась возможность использовать метки SGT в политиках доступа на FirePOWER. Пример настройки правила с учётом метки SGT представлен ниже:

Последний атрибут ISE, который может быть использован в политиках доступа FirePOWER версии, – Location IP. Данный атрибут означает IP-адрес сетевого устройства, которое аутентифицировало пользователя через Cisco ISE. Следовательно, можно создавать различные правила доступа для одного и того же пользователя, в зависимости от того, к какому сетевому устройству он подключен (коммутатор или точка доступа WiFi, или, например, коммутатор в головном офисе или коммутатор в удалённом филиале, или, например, подключение пользователя удалённо через AnyConnect).

Настройка приводится для FirePOWER Management Center версии 6.0.1 и Cisco ISE версии Как говорилось ранее, Cisco ISE хранит подробную информацию об авторизованных в сети пользователях. Основная задача – передать необходимую информацию на FirePOWER.

Традиционно, когда одна система должна коммуницировать с другой системой, используют кастомные или проприетарные API (Application Programing Interface). Cisco предлагает собственную технологию, посредством которой осуществляется взаимодействие различных продуктов Cisco, а также связь решений Cisco с системами других вендоров. Технология именуется Cisco Platform Exchange Grid (pxGrid). Данная технология предлагает общий язык взаимодействия для обмена информации между различными системами, например, FirePOWER, ISE, WSA, Cyber Threat Defense (CTD) и т.д.

Центральным компонентов pxGrid является Cisco ISE. Другие внешние системы выступают в роли клиентов или агентов в рамках pxGrid и подписываются на Cisco ISE для получения или передачи информации. Когда внешние системы подключаются к pxGrid, регистрируясь на Cisco ISE, они получают возможность обмениваться информацией по схеме «каждый с каждым», используя для этого единые методы. Регистрация внешних систем на Cisco ISE в pxGrid осуществляется посредством цифровых сертификатов. Для возможности использования pxGrid на Cisco ISE требуется наличие лицензии PLUS.

Перейдём к настройкам. Сперва Cisco ISE.

1. Активировать pxGrid Persona на Cisco ISE.

Выбрать сервер ISE. Кликнуть по его названию. Установить галку напротив pxGrid:

Нажать Generate Certificate Signing Request (CSR) и заполнить необходимые поля. Пример на изображении ниже:

Нажимам Generate и экспортируем полученный CSR. Теперь идём на корпоративный CA и подписываем по CSR сертификат. На данном моменте подробно останавливаться не буду, просто вставлю скриншоты:

Подписанный сертификат получен. Возвращаемся на ISE, привязываем сертификат к CSR:

Теперь на ISE есть необходимый сертификат для pxGrid:

ISE настроен. Теперь перейдём к настройкам pxGrid на FirePOWER.

5. Заполнить обязательные поля. Необходимо указать IP-адрес или имя сервера ISE:

6. Указать сертификаты «pxGrid Server CA» и «MNT Server CA». В качестве этих сертификатов можно использовать корневой сертификат корпоративного CA:

7. Указать сертификат и ключ «FMC Server Certificate». Данный сертификат FirePOWER Management Center будет предъявлять Cisco ISE при попытке подключения к pxGrid. Чтобы получить этот сертификат, нужно на FirePOWER сгенерировать CSR, подписать его на корпоративном CA и загрузить полученный подписанный сертификат на FirePOWER. Для этого нужно сгенерировать пару ключей и CSR из командной строки FMC, используя утилиту openssl:

Я использовал следующую строку параметров для создания CSR и Private Key:

Нажимаем Add Internal Cert, выбираем подписанный сертификат и Private Key:

8. В этом же меню нажимаем Test. Должно появиться окно «Success»:

9. Не забыть нажать Save в верхнем правом углу:

Проверим работоспособность настроенного решения. Cisco ISE настроен на аутентификацию тестового сегмента проводной сети. Настройки политик Cisco ISE в рамках данной заметки рассматривать не будем. Подключимся с помощью ноутбука к проводной сети, в качестве сапликанта используем Cisco AnyConnect Network Access Manager (NAM):

Если промотать вывод User Activity правее, то можно увидеть, что FirePOWER Management Center получил от ISE дополнительные атрибуты: Security Group Tag, Endpoint Profile и Endpoint Location:

На этом описание настройки интеграции ISE и FirePOWER я завершаю. Надеюсь, приведённый материал будет полезен читателям.

Если данная тема заинтересует, добро пожаловать к нам на демостенды по Cisco ISE, Cisco FirePOWER.