как узнать ldap сервер в домене
Как узнать, на каком сервере размещается LDAP в моем домене windows?
Я также слышал слухи о том,что имя сервера (ldap://server/) не всегда необходимо, пока у меня есть dc=domain, dc=com В моей строке запроса, но до сих пор я мог работать с ним таким образом.
3 ответов
Если вы используете AD, вы можете использовать привязка независимая чтобы найти контроллер домена для домена по умолчанию, используйте LDAP: / / rootDSE для получения информации о сервере каталогов, как описано в связанной статье.
AD регистрирует записи ресурсов местоположения службы (SRV) на своем DNS-сервере, которые вы можете запросить, чтобы получить порт и имя хоста ответственного сервера LDAP в вашем домене.
просто попробуйте это в командной строке:
(при условии, что ваш сервер имен-это сервер имен объявлений, который должен функционировать должным образом)
если машина, на которой вы находитесь, является частью домена AD, ее серверы имен должны быть установлены на серверы имен AD (или, надеюсь, использовать путь DNS-сервера, который в конечном итоге разрешит ваши домены AD). Используя Ваш пример dc=domain, dc=com, Если вы посмотрите вверх domain.com на серверах имен AD он вернет список IP-адресов каждого контроллера AD. Пример из моей компании (с измененным доменным именем, но в остальном это реальный пример):
обратите внимание, что я на самом деле делаю запрос от не-AD машины, но наши серверы имен unix знают, чтобы отправлять запросы для нашего домена AD (пример.ad) на DNS-серверы AD.
Я уверен, что есть супер-гладкий способ windowsy сделать это, но мне нравится использовать метод DNS, когда мне нужно найти серверы LDAP с сервера, отличного от windows.
Как я могу выяснить мою строку подключения LDAP?
Мы находимся в корпоративной сети, в которой работает активный каталог, и мы хотели бы протестировать некоторые элементы LDAP (на самом деле, поставщика членства в активном каталоге), и до сих пор никто из нас не мог понять, какова наша строка подключения LDAP. Кто-нибудь знает, как мы можем найти его? Единственное, что мы знаем, это домен, в котором мы находимся.
Поставщик членства в ASP.NET Active Directory выполняет аутентифицированную привязку к Active Directory, используя указанное имя пользователя, пароль и «строку подключения». Строка подключения состоит из имени сервера LDAP и полного пути к объекту-контейнеру, в котором находится указанный пользователь.
Объедините LDAP://dc1.corp.domain.com/ с полностью определенным путем к контейнеру, где находится пользователь привязки (например, скажем LDAP://dc1.corp.domain.com/OU=Service Accounts,OU=Corp Objects,DC=corp,DC=domain,DC=com ), и вы получите свою «строку подключения».
(Вы можете использовать имя домена в строке подключения, а не имя контроллера домена. Разница в том, что имя домена будет преобразовано в IP-адрес любого контроллера домена в домене. Это может быть как хорошо, так и плохо. Вы не зависите ни от одного контроллера домена, который бы работал и работал для провайдера членства, но имя оказывается разрешающим, скажем, DC в удаленном месте с нестабильным сетевым подключением, тогда у вас могут возникнуть проблемы с членством провайдер работает.)
Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Утилита ldapsearch (клиент OpenLDAP) и проверка подключения к контроллеру домена Active Directory
Проверку выполняем на примере Debian GNU/Linux 8 (Jessie). Сначала убедимся в том, что клиент OpenLDAP установлен в системе:
Исходные данные для проверки подключения клиента OpenLDAP к LDAP-каталогу на примере контроллера домена Active Directory (AD):
Проверка подключения по протоколу LDAP (TCP 389)
Используется подключение типа ldap:/. Учётные данные пользователя s-LDAP-Check-User передаются по сети в открытом виде:
Проверка подключения по протоколу LDAPS (TCP 636)
Используется подключение типа ldaps:/. LDAP-сессия шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Чтобы LDAP-клиент доверял сертификату контроллера домена, нам нужно создать файл, содержащий корневые сертификаты доменных Центров сертификации, которыми подписан сертификат контроллера домена. Назовём этот файл, например /etc/ssl/certs/cacerts.pem, и скопируем в него корневые сертификаты доменных ЦС в формате PEM и кодировке Base-64.
Изменим на время проверки конфигурационный файл клиента OpenLDAP /etc/ldap/ldap.conf, указав в переменной TLS_CACERT путь к созданному нами файлу с корневыми сертификатами доменных ЦС:
После этого можно попробовать выполнить поиск по протоколу LDAPS:
Проверка подключения по протоколу LDAP с защитой StartTLS (TCP 389)
Используется подключение типа ldap:/ с дополнительными ключами, включающими TLS : -Z и -ZZ. LDAP-сессия также шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Первичное подключение к контроллеру домена AD происходит по порту 389, затем создаётся отдельный защищённый TLS-туннель, внутри которого и происходит весь LDAP-обмен между клиентом и сервером. Используется настроенный нами ранее файл корневых сертификатов доменных ЦС.
Автор первичной редакции:
Алексей Максимов
Время публикации: 19.03.2017 18:04
LDAP. Настройка отказоустойчивого LDAP сервера
В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).
Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.
Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)
Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:
Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).
Ключевые особенности этого LDAP-сервера:
После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.
Общая структура 389 Directory Server
389 DS состоит из нескольких компонентов.
Сначала я хотел написать теоретическую и практическую части отдельно, но потом стало ясно, что первая часть стала бы слишком скучной, а вторая слишком сухой. Поэтому сразу за куском теории будет идти практическое применение.
Итак, задача. Необходимо настроить отказоустойчивый сервис службы каталогов. Для этого настроим два сервера, настроим multimaster-репликацию между ними и поднимем перемещающийся IP-адрес (pacemaker + openais).
Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.
После восстановления сервера данные будут реплицированы на него и IP-адрес переключится обратно на LDAP00, или же, в зависимости от настройки кластера, останется на LDAP01.
На одном сервере может быть несколько изолированных инстансов ns-slapd со своими настройками, схемой, правилами репликации и т.д. Чтобы иметь возможность управлять этими инстансами из консоли управления на каждом сервере должен стоять сервер Administration Server (далее admin server). admin server сам нуждается в одном инстансе LDAP сервера, поскольку хранит там run-time конфигурацию. По умолчанию конфигурация admin server хранится вместе с пользовательскими данными, но я считаю это небезопасным, поэтому у нас будет два инстанса на каждом сервере: один будет содержать конфигурацию для admin server-а, а второй данные. В такой схеме в случае отказа одной из нод сохраняется не только работоспособность LDAP-сервиса, но и возможность управления им.
Установка первого сервера на ldap00
Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.
Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.
Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.
Вот некоторые из них:
Для начала запустим dsktune:
# dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.
NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).
NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.
WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.
WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.
tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.
echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
Добавим в /etc/sysctl.conf:
для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:
запускаем еще раз dsktune и убедимся, что у нас все готово для установки.
Теперь запускаем скрипт setup-ds-admin.pl
Нас спросят, хотим ли мы установить 389 Directory и Administration Server, согласны ли мы с лицензией, еще раз запустят dsktune и, наконец, появится меню выбора типа установки.
1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.
2. Typical
Allows you to specify common defaults and options.
3. Custom
Allows you to specify more advanced options. This is
recommended for experienced server administrators only.
To accept the default shown in brackets, press the Enter key.
Choose a setup type [2]:
Выбираем третий пункт (мы же experienced server administrators =) )
Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.
If you do not yet have a configuration directory server, enter ‘No’ to
be prompted to set up one.
Do you want to register this software with an existing
configuration directory server? [no]:
Тут нас спрашивают, хотим ли мы использовать существующий сервер каталогов для сохранения информации о сервере. Так как это наш первый сервер, отвечаем No.
Далее идут вопросы об admin server-е: administrator ID, пароль, Administration Domain, ответы на них оставляем по умолчанию (кроме пароля).
Затем надо будет указать, какой порт будет слушать LDAP-сервер. Мы договорились, что это инстанс, который хранит лишь конфигурацию для admin server-а, поэтому пересаживаем его на порт 6389. Далее указываем Directory server identifier. Назовем свой инстанс config-instance. На вопрос о суффиксе корневого дерева отвечаем по умолчанию, корневого дерева в этом инстансе не будет, так что его потом можно удалить.
Затем нас ждет вопрос о Directory Manager DN.
Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.
Далее следуют вопросы о пароле к Directory Manager-у, хотим ли мы поставить примеры записей в наш root suffix и хотим ли мы заполнить наш новый инстанс какими-нибудь данными, спросят имя порта, IP-адрес и имя пользователя от которого admin server будет работать. После этого последний раз спросят подтверждение и начнут установку.
Настройка репликации на ldap00
Для подключения к серверу нужно поставить и запустить консоль управления 389-console.
В качестве Adminstration URL нужно ввести адрес admin server-а и порт который вы указали при установке.
Далее мы попадаем в панель управления серверами. У нас сейчас только один инстанс, выберем его.
Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local
У нас остался всего один суффикс и база, в которой находятся конфигурационные данные для admin server-а.
Теперь немного теории о принципах репликации.
В репликации участвуют два типа серверов, supplier и consumer.
supplier — сервер, который копирует реплику на другой сервер.
Если связь с supplier сервером будет потеряна, то запись в каталог станет невозможна.
consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.
Supplier сервер повторяет эти изменения на каждом consumer сервере.
Теперь, когда мы немного подкованы теоретически, можно настраивать мультимастер репликацию инстанса с конфигурацией.
Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.
Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.
Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.
Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.
Ответ должен быть
adding new entry «cn=replication manager,cn=config»
Итого, у нас получилось:
Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:
Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.
Установка и настройка ldap инстанса на ldap01
Теперь нужно настроить второй LDAP-сервер. С ним несколько иначе, т.к. установка admin server-а должна уже происходить в установленный LDAP-сервер и первичную настройку мы будем производить из консоли с помощью утилиты ldapmodify (что является нехилым плюсом, если стоит задача разобраться, как же работает этот сервер каталогов).
Сначала на втором сервере с помощью скрипта setup-ds.pl нужно создать инстанс, который не управляется admin server-ом.
Ответы на вопросы скрипта аналогичны предыдущим.
После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.
Подключение производится примерно так:
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb
changelogdir должен указывать на директорию с названием вашего инстанса.
2) добавляем пользователя replication manager:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:
20380119031407Z означает, что срок действия пароля не ограничен.
3) Создаем суффикс netscaperoot:
dn: cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: «o=netscaperoot»
4) Создаем базу для суффикса netscaperoot:
dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot
Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.
5) Создаем корневой o=NetScapeRoot:
dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot
6) Разрешаем репликацию для o=netscaperoot:
dn: cn=replica,cn=»o=netscaperoot», cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3
Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).
На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.
Последним этапом будет:
7) Настройка репликации от ldap01 на ldap00:
dn: cn=Multimaster replication, cn=replica, cn=»o=netscaperoot», cn=mapping
tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Multimaster replication
description: replication for netscaperoot
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaCredentials:
nsDS5ReplicaHost: ldap00.edu.scalaxy.local
nsDS5ReplicaPort: 6389
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaUpdateInProgress: FALSE
nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
nsDS5ReplicaCredentials — пароль
8) Первичная инициилизация репликации с ldap00 на ldap01:
На первом сервере выполняем эту команду:
dn: cn=Multimaster replication,cn=replica,cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start
Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.
Теперь мы имеем полностью реплицируемые каталоги с конфигурацией admin server-а.
Установка admin server-а на ldap01
Нужно поднять admin server на втором сервере. Запускаем скрипт register-ds-admin.pl
Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot
Дальнейшая настройка тривиальна, следуем указаниям скрипта.
Установка и настройка ldap инстансов для хранения пользовательских данных
Теперь подключаться через консоль управления можно к любому admin server-у.
На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.
Настраиваем мультимастер репликацию между двумя инстансами по тому же принципу (теперь вы можете настроить репликацию как через GUI, так и через консоль).
Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.
Cisco ISE: Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2
Приветствую во второй публикации цикла статей, посвященному Cisco ISE. Ссылки на все статьи в цикле приведены ниже:
В данной статье мы углубимся в создание учетных записей, добавлению LDAP серверов и интеграцию с Microsoft Active Directory, а также в нюансы при работе с PassiveID. Перед прочтением настоятельно рекомендую ознакомиться с первой частью.
1. Немного терминологии
Более того, у каждого пользователя и группы пользователей есть дополнительные атрибуты, которые позволяют выделить и более конкретно определить данного пользователя (группу пользователей). Больше информации в гайде.
2. Создание локальных пользователей
1) В Cisco ISE есть возможность создать локальных пользователей и использовать их в политике доступа или даже дать роль администрирования продуктом. Выберите Administration → Identity Management → Identities → Users → Add.
Рисунок 1. Добавление локального пользователя в Cisco ISE
2) В появившемся окне создайте локального пользователя, задайте ему пароль и другие понятные параметры.
Рисунок 2. Создание локального пользователя в Cisco ISE
3) Пользователей также можно импортировать. В этой же вкладке Administration → Identity Management → Identities → Users выберите опцию Import и загрузите csv или txt файлик с пользователями. Для того, чтобы получить шаблон выберите Generate a Template, далее следует его заполнить информацией о пользователях в подходящем виде.
Рисунок 3. Импорт пользователей в Cisco ISE
3. Добавление LDAP серверов
ISE поддерживает 2 типа лукапа (lookup) при работе с LDAP серверами: User Lookup и MAC Address Lookup. User Lookup позволяет делать поиск пользователю в базе данных LDAP и получать следующую информацию без аутентификации: пользователи и их атрибуты, группы пользователей. MAC Address Lookup позволяет так же без аутентификации производить поиск по MAC адресу в каталогах LDAP и получать информацию об устройстве, группу устройств по MAC адресам и другие специфичные атрибуты.
В качестве примера интеграции добавим Active Directory в Cisco ISE в качестве LDAP сервера.
1) Зайдите во вкладку Administration → Identity Management → External Identity Sources → LDAP → Add.
Рисунок 4. Добавление LDAP сервера
2) В панели General укажите имя LDAP сервера и схему (в нашем случае Active Directory).
Рисунок 5. Добавление LDAP сервера со схемой Active Directory
Примечание: используйте данные домен админа во избежание потенциальных проблем.
Рисунок 6. Ввод данных LDAP сервера
4) Во вкладке Directory Organization следует указать область каталогов через DN, откуда вытягивать пользователей и группы пользователей.
Рисунок 7. Определение каталогов, откуда подтянуться группы пользователей
5) Перейдите в окно Groups → Add → Select Groups From Directory для выбора подтягивания групп из LDAP сервера.
Рисунок 8. Добавление групп из LDAP сервера
6) В появившемся окне нажмите Retrieve Groups. Если группы подтянулись, значит предварительные шаги выполнены успешно. В противном случае, попробуйте другого администратора и проверьте доступность ISE c LDAP сервером по LDAP протоколу.
Рисунок 9. Перечень подтянутых групп пользователей
7) Во вкладке Attributes можно опционально указать, какие атрибуты из LDAP сервера следует подтянуть, а в окне Advanced Settings включить опцию Enable Password Change, которая заставит пользователей изменить пароль, если он истек или был сброшен. В любом случае нажмите Submit для продолжения.
8) LDAP сервер появился в соответствующий вкладке и в дальнейшем может использоваться для формирования политик доступа.
Рисунок 10. Перечень добавленных LDAP серверов
4. Интеграция с Active Directory
1) Добавив Microsoft Active Directory сервер в качестве LDAP сервера, мы получили пользователи, группы пользователей, но не логи. Далее предлагаю настроить полноценную интеграцию AD с Cisco ISE. Перейдите во вкладку Administration → Identity Management → External Identity Sources → Active Directory → Add.
Примечание: для успешной интеграции с AD ISE должен находиться в домене и иметь полную связность с DNS, NTP и AD серверами, в противном случае ничего не выйдет.
Рисунок 11. Добавление сервера Active Directory
2) В появившемся окне введите данные администратора домена и поставьте галочку Store Credentials. Дополнительно вы можете указать OU (Organizational Unit), если ISE находится в каком-то конкретном OU. Далее придется выбрать ноды Cisco ISE, которые вы хотите соединить с доменом.
Рисунок 12. Ввод учетных данных
Примечание: для проверки статуса Passive ID введите в консоли ISE show application status ise | include PassiveID.
Рисунок 13. Включение опции PassiveID
4) Перейдите во вкладку Administration → Identity Management → External Identity Sources → Active Directory → PassiveID и выберите опцию Add DCs. Далее выберите галочками необходимые контроллеры домена и нажмите OK.
Рисунок 14. Добавление контроллеров домена
5) Выберите добавленные DC и нажмите кнопку Edit. Укажите FQDN вашего DC, доменные логин и пароль, а также опцию связи WMI или Agent. Выберите WMI и нажмите OK.
Рисунок 15. Ввод данных контроллера домена
6) Если WMI не является предпочтительным способом связи с Active Directory, то можно использовать ISE агентов. Агентский способ заключается в том, что вы можете установить на сервера специальные агенты, которые будут отдавать login события. Существует 2 варианта установки: автоматический и ручной. Для автоматической установки агента в той же вкладке PassiveID выберите пункт Add Agent → Deploy New Agent (DC должен иметь доступ в Интернет). Затем заполните обязательные поля (имя агента, FQDN сервера, логин/пароль доменного администратора) и нажмите OK.
Рисунок 16. Автоматическая установка ISE агента
7) Для ручной установки Cisco ISE агента требуется выбрать пункт Register Existing Agent. К слову, скачать агента можно во вкладке Work Centers → PassiveID → Providers → Agents → Download Agent.
Рисунок 17. Скачивание ISE агента
Важно: PassiveID не читает события logoff! Параметр отвечающий за тайм-аут называется user session aging time и равняется 24 часам по умолчанию. Поэтому следует либо делать logoff самому по окончании рабочего дня, либо же писать какой-то скрипт, который будет делать автоматический logoff всем залогиненым пользователям.
Ниже приведен пример, актуальный для конфигурации Cisco ISE + AD без 802.1X и RADIUS: пользователь залогинен на Windows машине, не делая logoff, логиниться с другого ПК по WiFi. В этом случае сессия на первом ПК по-прежнему будет активна, пока не случится тайм-аут или не произойдет принудительный logoff. Тогда если у устройств разные права, то последнее залогиненное устройство будет применять свои права.
8) Дополнительно во вкладке Administration → Identity Management → External Identity Sources → Active Directory → Groups → Add → Select Groups From Directory вы можете выбрать группы из AD, которые хотите подтянуть на ISE (в нашем случае это было сделано в пункте 3 “Добавление LDAP сервера”). Выберите опцию Retrieve Groups → OK.
Рисунок 18 а). Подтягивание групп пользователей из Active Directory
9) Во вкладке Work Centers → PassiveID → Overview → Dashboard вы можете наблюдать количество активных сессий, количество источников данных, агентов и другое.
Рисунок 19. Мониторинг активности доменных пользователей
10) Во вкладке Live Sessions отображаются текущие сессии. Интеграция с AD настроена.
Рисунок 20. Активные сессии доменных пользователей
5. Заключение
В данной статьей были рассмотрены темы создания локальных пользователей в Cisco ISE, добавление LDAP серверов и интеграция с Microsoft Active Directory. В следующей статье будет освещен гостевой доступ в виде избыточного гайда.
Если у вас появились вопросы по данной тематике или же требуется помощь в тестировании продукта, обращайтесь по ссылке.