Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
5.1. Проверка подключения к LDAP-серверу
При подключении к внешнему серверу аутентификации может возникнуть потребность в проверке, например, наличия в каталоге пользователя, от имени которого zVirt будет осуществлять подключение.
На менеджере управления следует установить пакет openldap-clients:
dnf config-manager --enable baseos
dnf install openldap-clients
dnf config-manager --disable baseosСделать запрос:
ldapsearch -H ldap://name_server -x -W -D "<Тут_логин_Администратора_домена>@domain.name" -b "dc=domane,dc=name" "(sAMAccountName=zvirtadm)"5.2. Диагностика и исправление ошибок при подключении Active Directory
Если попытка подключения к внешнему серверу аутентификации Active Directory заканчивается неудачно и в логе есть запись вида Cannot resolve principal 'ovirtadm@nprt.nn', то это может сигнализировать о том, что служба глобального каталога работает не на стандартном порту 3268, а 389. Следует проверить сервисные записи DNS:
dig _ldap._tcp.gc._msdcs.nprt.nn SRV
dig _ldap._tcp.nprt.nn SRVЕсли действительно обе службы (и локальный контроллер домена тоже) работают на одном порту, то следует для глобального каталога установить порт 3268.
5.3. Ограничения
Профиль LDAP_MATCHING_RULE_IN_CHAIN используется для получения групп пользователей. На текущий момент в данном профиле есть проблема, которая заключается в том, что он не может разрешить локальное доменное имя группы принадлежащей нескольким доменам. Например:
Если пользователь user1 является членом group1, а group1 является членом group2, то этот профиль не разрешит данную конфигурацию. Профиль может разрешить конфигурацию, если user1 будет непосредственным членом group2 в AD2. Шаблон LDAP_MATCHING_RULE_IN_CHAIN используется, так как дает значительный прирост производительности по сравнению с рекурсивным обходом.
5.4. Долгий вход доменного пользователя
При большом количестве объектов в Active Directory и/или большом количестве доменных групп у пользователя, вход доменного пользователя может занимать продолжительное время, также при открытие окна разрешений пользователя может занимать длительное время или приводить к зависанию менеджера управления. Для решения данных проблем необходимо исправить файл конфигурации /etc/ovirt-engine/aaa/example.ru.properties. Параметр include = <ad.properties> заменить на include = <ad-recursive.properties>.
Время на прочтение4 мин
Количество просмотров13K
С одной стороны настройка LDAP-аутентификации в Caché не очень сложная — в документации этот процесс описан шестью пунктами. С другой стороны если LDAP-сервер на базе Microsoft Active Directory, то есть несколько не очевидных моментов, которые надо настроить на стороне LDAP-сервера. Так же для тех, кто не часто занимается подобными настройками, есть шанс запутаться в настройках безопасности Caché. В этой статье пошагово опишем процесс настройки LDAP-аутентификации, а также методы диагностики проблем в случае, если что-то не получается.
Настройка LDAP-сервера
1. Создаем пользователя в ActiveDirectory, с помощью которого будет подключаться Caché и искать информацию в базе LDAP. Этот пользователь должен находиться строго в корне домена
2. Для пользователей, которые будут подключатся к Caché, создадим отдельное подразделение. Назовем его «IdapCacheUsers»
3. Регистрируем там пользователей
4. Протестируем доступность LDAP-базы с помощью программы ldapAdmin. Скачать ee можно здесь.
5. Настраиваем подключение к LDAP-серверу:
6. Подключились. Посмотрели, что всё работает:
7. Так как пользователи, которые будут подключаться к Caché, находятся в подразделении «ldapCacheUsers», ограничим поиск только по этому подразделению
Настройка на стороне Caché
8. LDAP-сервер готов, теперь переходим к настройкам на стороне Caché. Заходим в портал управления -> Администрирование системы ->Безопасность ->Безопасность системы ->Опции LDAP. Поля «Атрибут пользователь для получения области по умолчанию (User attribute to retrieve default namespace)» ,«Атрибут пользователь для получения области по умолчанию (User attribute to retrieve default routine)» и«Атрибут пользователь для получения ролей (User attribute to retrieve roles)» очищаем, так как этих атрибутов пока нет в LDAP-базе.
Комментарий по поводу перевода
Правда, в этом месте русский перевод не совсем удачный правильней было бы перевести так: «Атрибут пользователя для получения области по умолчанию», «Атрибут пользователя для получения программы по умолчанию» и «Атрибут пользователя для получения ролей».
9. Разрешаем LDAP-аутентификацию в разделе Администрирование системы ->Безопасность ->Безопасность системы ->Аутентификация/Настройки CSP-Сессий
10. Разрешаем LDAP-аутентификацию в сервисах. Сервис %Service_CSP отвечает за подключение веб-приложений, сервис %Service_Console отвечает за подключение через терминал.
11. Настраиваем LDAP-аутентификацию в веб-приложениях
12. Пока, чтобы проверить, что подключение работает, настроим так, чтобы новым пользователям в Caché были полные права. Для этого пользователю _PUBLIC надо добавить роль %All. В дальнейшем мы этот момент доработаем……
13. Пробуем открыть настроенное веб-приложение, оно должно открыться.
14. Терминал также открывается
15. При подключении LDAP-пользователи будут появляться в пользователях Caché
16. Правда, при такой конфигурации все новые пользователи получают полный доступ к системе. Чтобы устранить этот пробел, надо в LDAP-базе добавить атрибут, где будем хранить наименование роли, которая будет присваиваться пользователю при подключении к Caché. Предварительно надо сделать резервную копию контроллера домена, чтобы при неудачной настройке не поломать всю сеть.
17. Для модификации схемы ActiveDirectory, на сервере, где находится ActiveDirectory, устанавливаем оснастку Схема ActiveDirectory (по умолчанию она не установлена). Инструкция здесь.
18. Создаем атрибут с именем intersystems-Roles, OID 1.2.840.113556.1.8000.2448.2.3, строка с учетом регистра, многозначный атрибут.
19. Далее добавляем этот атрибут в класс user
20. Далее сделаем, чтобы при просмотре списка пользователей в подразделении отображалась колонка «Роль в InterSystems Cache», для этого нажимаем Пуск->Выполнить вводим adsiedit.msc. Подключаемся к контексту именования Configuration
21. Переходим к контейнеру CN=409, CN=DisplaySpecifiers, CN=Configuration и выбираем тот тип контейнера, при просмотре которого будут выводится дополнительные атрибуты пользователя. Выберем отображение на уровне подразделения (OU), для чего нам понадобится контейнер organisationalUnit-Display. В свойствах находим атрибут extraColumns и вводим там значение «intersystems-Roles, Роль в IntersystemsCache,1,200,0». Принцип заполнения такой: Название атрибута, название колонки в которой будет отображаться атрибут, будет ли отобраться по умолчанию, ширина колонки в пикселах, зарезервированное значение. Еще замечание CN=409 обозначает код языка: в ветке CN=409 для английской версии, CN=419 для русской версии консоли.
22. Теперь можно заполнить название роли, которое будет присваиваться пользователю при подключении к Caché. Если Active Directory на базе Windows Server 2003, то штатных средств для редактирования этого поля нет. Можно воспользоваться программой ldapAdmin (см. пункт 4) для редактирования значения в этом атрибуте. Если Windows более свежей версии, то атрибут можно редактировать в режиме «Дополнительные функции» — у пользователя появится дополнительная вкладка для редактирования атрибутов.
23. После этого в портале управления Caché в опциях LDAP указываем имя этого атрибута.
24. Создаем роль ldapRole с необходимыми привилегиями
25. Удаляем роль %ALL из пользователя _PUBLIC
26. Всё готово, пробуем подключиться к системе.
27. Если не получается включаем и настраиваем аудит
28. Настройки аудита
29. Просмотр базы данных аудита.
Заключение
На практике часто бывает, что для работы в приложении не требуется настройка разных ролей для разных пользователей. Если достаточно, что при входе, например, в веб-приложение, всем пользователям присваивается определенный набор ролей, то пункты с 16 по 23 можно не выполнять. Достаточно в настройках веб-приложения на вкладке «Роли приложений» добавить эти роли и убрать все виды аутентификации, кроме LDAP. В этом случае в веб-приложение может попасть только пользователь, который зарегистрирован на LDAP-сервере, и когда пользователь в него заходит, Caché автоматически присваивает ему роли, которые требуются для работы в данном приложении.
Microsoft Active Directory поддерживает протокол LDAPv3. С его помощью можно авторизовать пользователей из сторонних приложений. Чтобы обеспечить безопасность при передаче учетной информации серверу необходимо использовать LDAPS (SSL). В этой статье мы рассмотрим настройку контролера домена, для обеспечения поддержки SSL.
Для того, чтобы SSL нормально функционировал нам потребуются сертификат.
Проверяем наличие сертификата
Для начала будет полезно проверить наличие сертификата в вашем домене, для этого запустим на нашем ПК утилиту ldp.exe.
Она не поставляется с Windows 10, чтобы использовать её, вам придется установить компоненты администрирования RSAT.
Нажмите Подключение — подключить, заполните окно аналогично рисунку.
Используйте имя домена, не сервера — тогда сервер для подключения будет выбран автоматически.
Если в ответ вы получили сообщение:
ld = ldap_sslinit("altuninvv.local", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to altuninvv.local.Это означает, что либо недоступен ни один контролер домена, либо неправильно настроен DNS, либо ПК не является членом домена, либо не установлен SSL сертификат на контролере домена.
Если сообщение похоже на такое:
Established connection to xxxx.xxxxxxxxx.xxx.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext:
...
forestFunctionality: 6 = ( WIN2012R2 );
highestCommittedUSN: 2153249;
isGlobalCatalogReady: FALSE;
isSynchronized: TRUE;
ldapServiceName: XXXXXXXX$@XXXXXXXXXXXXX;
....
supportedCapabilities (6): 1.2.840.113556.1.4.800 = ( ACTIVE_DIRECTORY ); 1.2.840.113556.1.4.1670 = ( ACTIVE_DIRECTORY_V51 ); 1.2.840.113556.1.4.1791 = ( ACTIVE_DIRECTORY_LDAP_INTEG ); 1.2.840.113556.1.4.1935 = ( ACTIVE_DIRECTORY_V61 ); 1.2.840.113556.1.4.2080 = ( ACTIVE_DIRECTORY_V61_R2 ); 1.2.840.113556.1.4.2237 = ( ACTIVE_DIRECTORY_W8 );
supportedControl (37): 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.2.840.113556.1.4.801 = ( SD_FLAGS ); 1.2.840.113556.1.4.473 = ( SORT ); 1.2.840.113556.1.4.528 = ( NOTIFICATION ); 1.2.840.113556.1.4.417 = ( SHOW_DELETED ); 1.2.840.113556.1.4.619 = ( LAZY_COMMIT ); 1.2.840.113556.1.4.841 = ( DIRSYNC ); 1.2.840.113556.1.4.529 = ( EXTENDED_DN ); 1.2.840.113556.1.4.805 = ( TREE_DELETE ); 1.2.840.113556.1.4.521 = ( CROSSDOM_MOVE_TARGET ); 1.2.840.113556.1.4.970 = ( GET_STATS ); 1.2.840.113556.1.4.1338 = ( VERIFY_NAME ); 1.2.840.113556.1.4.474 = ( RESP_SORT ); 1.2.840.113556.1.4.1339 = ( DOMAIN_SCOPE ); 1.2.840.113556.1.4.1340 = ( SEARCH_OPTIONS ); 1.2.840.113556.1.4.1413 = ( PERMISSIVE_MODIFY ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.10 = ( VLVRESPONSE ); 1.2.840.113556.1.4.1504 = ( ASQ ); 1.2.840.113556.1.4.1852 = ( QUOTA_CONTROL ); 1.2.840.113556.1.4.802 = ( RANGE_OPTION ); 1.2.840.113556.1.4.1907 = ( SHUTDOWN_NOTIFY ); 1.2.840.113556.1.4.1948 = ( RANGE_RETRIEVAL_NOERR ); 1.2.840.113556.1.4.1974 = ( FORCE_UPDATE ); 1.2.840.113556.1.4.1341 = ( RODC_DCPROMO ); 1.2.840.113556.1.4.2026 = ( DN_INPUT ); 1.2.840.113556.1.4.2064 = ( SHOW_RECYCLED ); 1.2.840.113556.1.4.2065 = ( SHOW_DEACTIVATED_LINK ); 1.2.840.113556.1.4.2066 = ( POLICY_HINTS_DEPRECATED ); 1.2.840.113556.1.4.2090 = ( DIRSYNC_EX ); 1.2.840.113556.1.4.2205 = ( UPDATE_STATS ); 1.2.840.113556.1.4.2204 = ( TREE_DELETE_EX ); 1.2.840.113556.1.4.2206 = ( SEARCH_HINTS ); 1.2.840.113556.1.4.2211 = ( EXPECTED_ENTRY_COUNT ); 1.2.840.113556.1.4.2239 = ( POLICY_HINTS ); 1.2.840.113556.1.4.2255 = ( SET_OWNER ); 1.2.840.113556.1.4.2256 = ( BYPASS_QUOTA );
supportedLDAPPolicies (19): MaxPoolThreads; MaxPercentDirSyncRequests; MaxDatagramRecv; MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxBatchReturnMessages; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MinResultSets; MaxResultSetsPerConn; MaxNotificationPerConn; MaxValRange; MaxValRangeTransitive; ThreadMemoryLimit; SystemMemoryLimitPercent;
supportedLDAPVersion (2): 3; 2;
supportedSASLMechanisms (4): GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;
-----------Это значит, что SSL сертификат уже установлен посредством Службы сертификатов Active Directory и дальнейших действий не потребуется.
Установка OpenSSL
В этой статье я буду использовать виртуальный сервер, созданный для цикла статей.
Имя домена — altununvv.local
Имя контролера домена – addc1.altuninvv.local
Виртуальная организация — Altunin Soft
Скачаем свежую версию OpenSSL — вы можете скачать её отсюда — https://slproweb.com/products/Win32OpenSSL.html
Я рекомендую все команды выполнять сразу на сервере, но вы можете так же работать и на вашем ПК, если используете MSYS2.
Те, кто использует, как и я, MSYS2, могут ввести в консоли:
pacman -Sy opensslСоздаем локальный центр сертификации
Создадим папку и назовем её CA.
Создадим в ней файл ca.conf с содержимым:
[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_ca
[ req_distinguished_name ]
# Descriptions
countryName=RU
stateOrProvinceName=Magadan region
localityName=Magadan
0.organizationName= Altunin Soft
1.organizationName=IT
commonName=altuninvv.local
#Modify for your details here or answer the prompts from openssl
countryName_default=RU
stateOrProvinceName_default= Magadan region
localityName_default= Magadan
0.organizationName_default= Altunin Soft
1.organizationName_default=IT
commonName_default= altuninvv.local
[ v3_ca ]
keyUsage=critical,keyCertSign
basicConstraints=critical,CA:TRUE,pathlen:1
extendedKeyUsage=serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = *. altuninvv.local
DNS.2 = altuninvv.localСгенерируем приватный ключ для CA
openssl genrsa -des3 -out ca.key 4096Укажите пароль для ключа, в нашем случае это будет Pa$$w0rd:
Generating RSA private key, 4096 bit long modulus (2 primes) ...................................................................................................................................... ........................................................................................................................................ ....++++..........................++++e is 65537 (0x010001) Enter pass phrase for ca.key: Verifying - Enter pass phrase for ca.key:Создадим сертификат для нашего CA:
openssl req -new -x509 -extensions v3_ca -days 3659 -key ca.key -out ca.crt -config ca.confПросто нажимайте Enter все поля будут заполнены автоматически!
Enter pass phrase for ca.key:
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
RU [RU]:
Magadan region [Magadan region]:
Magadan [Magadan]:
Altunin Soft [Altunin Soft]:
IT [IT]:
altuninvv.local [altuninvv.local]:Теперь нужно импортировать созданный сертификат в хранилище доверенных CA на нашем контролере домена.
Скопируем файл ca.crt на контролер домена. Откроем PowerShell от имени администратора, перейдем в папку с файлом ca.cert и введем команду:
Import-Certificate –Verbose -FilePath ca.crt -CertStoreLocation 'Cert:\LocalMachine\Root'
VERBOSE: Performing the operation "Import certificate" on target "Item: C:\ca\ca.crt Destination: Root".
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
Thumbprint Subject
---------- -------
D5D1306CFFDAF63EDA10710F13F69C0228005350 CN=altuninvv.local, O=IT, O=Altunin Soft, L=Magadan, S=Magadan region, C=RU Сертификат успешно добавлен.
Теперь пришло время создать запрос на клиентский сертификат, который будет использовать контролер домена.
На контролере домена создадим текстовый файл — req.txt
;----------------- request.inf -----------------
[Version]
Signature="$Windows NT$"
;The Subject will need to be your active directory domain name
[NewRequest]
Subject = "CN=altuninvv.local
KeySpec = 1
KeyLength = 4096
Exportable = TRUE
SMIME = FALSE
MachineKeySet = TRUE
PrivateKeyArchive = FALSE
UseExistingKeySet = FALSE
UserProtected = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
;The following will add a subject alternative name of a wildcard cert on *.example.com
;so any ad controller with a hostname of somththing.example.com can use it.
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=*.altuninvv.local&"
_continue_ = "dns=altuninvv.local&"
Выполним запрос на сертификат:
certreq -new req.txt addc1.csr
CertReq: Request CreatedВыполним запрос на сертификат:
certreq -new req.txt addc1.csr CertReq: Request CreatedСкопируем созданный файл на свой ПК в папку нашего CA
В папке CA создадим файл v3ext.txt с содержимым:
# v3ext.txt
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names
#Modify for your details. Must include the commonName in the list below also.
#The *.example.com will allow all Domain controllers with
#the hostname somthing.example.com to use the cert.
[alt_names]
DNS.1 = *.altuninvv.local
DNS.2 = altuninvv.localСгенерируем сертификат для addc1
openssl x509 -req -days 825 -in addc1.csr -CA ca.crt -CAkey ca.key -extfile v3ext.txt -set_serial 01 -out addc1-server.crt
Signature ok
subject=CN = altuninvv.local
Getting CA Private Key
Enter pass phrase for ca.key:Введите пароль закрытого ключа: Pa$$w0rd
Скопируем файл с сертификатом addc1-server.crt обратно на контролер домена addc1 и применим сертификат:
certreq -accept addc1-server.crt
Installed Certificate:
Serial Number: 01
Subject: CN=altuninvv.local (DNS Name=*.altuninvv.local, DNS Name=altuninvv.local)
NotBefore: 2/18/2021 5:37 PM
NotAfter: 5/24/2023 5:37 PM
Thumbprint: 4721d27e9fe34aaa672d20d68c0ec01fd9f7a82cИз PowerShell проверим наличие сертификата:
PS C:\ca> Get-ChildItem "Cert:\LocalMachine\My"
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\My
Thumbprint Subject
---------- -------
4721D27E9FE34AAA672D20D68C0EC01FD9F7A82C CN=altuninvv.localТеперь вы должны перегрузить контролер домена, чтобы все настройки вступили в силу.
Обратите внимание, чтобы подключиться к серверу вы должны указать его полное доменное имя, в нашем случае:
addc1.altuninvv.localЕсли ПК входит в состав домена altuninvv.local, вы можете использовать для подключение его имя:
altuninvv.localТогда контролер домена для подключения будет выбран автоматически из списка доступных, возможно, это будет работать только, при наличии Службы сертификатов на одном из серверов в AD!
Так как мой ПК не входит в домен altuninvv.local и не использует его DNS-сервера, я прописал в файле
C:\Windows\System32\drivers\etc\hostsстроку:
192.168.0.10 addc1.altuninvv.localПроверяем подключение
Для проверки подключения мы будет использовать утилиту ldp.exe.
Она не поставляется с Windows 10, чтобы использовать её, вам придется установить компоненты администрирования RSAT.
Запустим ldp.exe, откроется окно:
В этом окне выберите подключение – подключить
Введем:
Сервер: addc1.altuninvv.local
Порт: 636
Установим галочку SSL
Нажмем Ок, будет осуществлено подключение и выведена дополнительная информация:
Теперь мы может сделать bind к серверу
Выберите Подключение – Привязка
Заполните поля:
Пользователь: CN=ldap-bind,CN=Users,DC=altuninvv,DC=local
Пароль: Pas#w0rds#1
Установите: Простая привязка
нажмите Ок
Будет выведено сообщение:
res = ldap_simple_bind_s(ld, 'CN=ldap-bind,CN=Users,DC=altuninvv,DC=local', <unavailable>); // v.3
Authenticated as: 'ALTUNINVV\ldap-bind'.Это означает, что подключение прошло успешно.
Далее выберем пункт меню Вид – Дерево
И в окне выберем —
DC=altuninvv,DC=localНажмем Ок
Откроется дерево с разделами домена,
Таким образом вы можете просматривать каталог AD через LDAP по SSL.
Заключение
Сегодня мы рассмотрели подключение к контролеру домена AD с использованием протокола LDAP по SSL.
Мы создали свой локальный центр сертификации CA с помощью OpenSSL.
Был выпущен сертификат и установлен на контролере домена.
С помощью утилиты ldp.exe было осуществлено подключение к контролеру домена по SSL.
LDAP Authentication on Windows Server
ProVision supports LDAP authentication (including Windows Server). To setup an LDAP server for authentication, you must perform the following procedures:
Configuring the LDAP functions on your Windows Server
You should confirm these steps with your LDAP admin — the purpose of this walkthrough is to provide some level of detail on how to extend LDAP functionality to support integration with an application like ProVision.
Step 1: Prepare to extend the Schema (http://technet.microsoft.com/en-us/library/cc961754.aspx)
This is not a minor operation and requires interaction with various control modification areas of Windows Server:
- If you have not modified the schema before, you will need to use the Active Directory Schema console on a DC (Domain Controller) to permit write access to the DC schema.
- Since the schema object has dedicated permissions, admins must be a member of the Schema Administrator group (Schema Admins).
- Note that the DC that is holding the Schema Master Role is the only one allowed to write to it.
Step 2: Decide on method for Installing/executing Schema Extensions (http://technet.microsoft.com/en-us/library/cc961742.aspx)
If you have already used other AD integrations, this should be straightforward. We recommend using the LDIF script method
Step 3: Add and Modify a Schema Object (http://technet.microsoft.com/en-us/library/cc961575.aspx)
To add a new attribute to the schema, you first have to create a attribute object. The you will need to complete the following steps:
- Select a name for the attribute (ProVision assumes that the name will be ‘sixConnGroup‘)
- Get a valid Object Identifier (OID) from an issuing authority (http://msdn.microsoft.com/en-us/library/ms677620.aspx)
-
Generate an Object Identifier
-
- Document the attribute syntax
- Confirm that the attribute should be single-value
- Confirm the attribute indexing behavior
- Decide if the attribute needs to be distributed to the Global Catalog
LDAP Schema — Example
attributetype (1.3.6.1.4.1.5023215.2.3.21 NAME 'sixConnGroup' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.3.6.1.4.1.5023215.2.4.2 NAME 'sixConnectPermissionsV2' DESC '6Connect Permissions Object v2' SUP top AUXILIARY MUST ( sixConnGroup ) )
LDAP User Example
SSH into your openLDAP server and create a new ‘ldif’ file. Example:
dn: cn=JoeSmith,ou=people,dc=6connect,dc=com cn: JoeSmith sn: JoeSmith objectclass: top objectclass: person objectclass: sixConnectPermissionsV2 sixConnGroup: "Global Admins" sixConnGroup: "IT Engineering" sixConnGroup: "Sales" sixConnGroup: "Customer Admin" userPassword: testpass
To create a new user, make a new ldif file and change all instances of «JoeSmith» to whatever username you wish to create and update the password. Keep all of the object class definitions as listed above. Add a sixConnGroup declaration for each ProVision user group a user is in.
After the file is created, run the following command to add the new user to LDAP server:
ldapadd -h [SERVER] -x -f [LDIF FILE] -D [ROOTDN] -w [ROOT PW] -v
Example:
ldapadd -h localhost -x -f 6connect.ldif -D "cn=Manager,dc=6connect,dc=com" -w secret -v
The user will now be active in openLDAP and can be used to login to ProVision.
Test the LDAP Server
To query the LDAP server, run the following command on any server which has openLDAP enabled:
ldapsearch -b [BASE] -h [IPADDRESS] -D [DOMAIN] -w [PASSWORD] [USER]
Note: We have not been able to use a v6 address at with this tool, even though multiple sources say it should work.
At the end of the command where [USER] is specified, user or groups can be used (in LDAP format) to query.
Example:
ldapsearch -b "dc=6connect,dc=com" -h 50.240.195.129 -D "cn=Mayor,ou=people,dc=6connect,dc=com" -w testpass "cn=MajorMiner"
Configure ProVision for LDAP Authentication
To configure the use of LDAP authentication, follow the steps below.
- Log into 6connect ProVision
- Go to Settings Tab → Admin Settings -> Authentication
- Select «LDAP» under «Authentication Options»
- Move the LDAP Enable selector to the «ON» position.
- Fill in the hostname or ip address, authentication port, LDAP Security, Auth DN, Fetch DN, and Filter DN.
- Optionally, enter the LDAP Username and Password in order to allow ProVision to import LDAP Contacts and sync LDAP contact information (see: Contact Manager)
- Click «Save Changes».
Example values in this case would be:
- LDAP Enable: (Checked)
- LDAP Server Address: 52.240.195.12
- LDAP Port: 389 ( or SSL/TLS port is 636)
- LDAP Security: None
- LDAP Auth DN: cn=%LOGIN%,ou=people,dc=6connect,dc=com
- LDAP Fetch DN: cn=%LOGIN%
- LDAP Filter DN: cn=%LOGIN%
Setting default login authentication options
In the login screen, you would select the authentication method from the dropdown. If you like, you can set the default login option in the following way:
Go to the /data/globals.php and open in vi (or other editor). Add in the following text as the last line of the file (before the closing ?>)
define(‘DEFAULT_LOGIN_TYPE’, ‘radius’);
Acceptable values are «local», «radius» and «ldap». If this line is not present in globals.php, the default option is «local».
Using SSL encryption
To use SSL encryption with LDAP, the ldap.conf file must be correctly configured on the ProVision server.
Typically, the LDAP configuration file is kept at «/etc/ldap/ldap.conf». Make sure the following line is present:
TLS_REQCERT allow
and restart the webserver.
Add or Update LDAP Settings
To add or update LDAP settings, go to the Settings Tab → Admin to enter the Admin area.
Then, click the «Authentication» sub-tab at the top of the Admin Settings page, and select «LDAP» from the «Authentication Options» module.
Enter or update the following settings:
- LDAP Enable: check the box to enable LDAP functionality.
- LDAP Server Address: Set the IP address of your LDAP server.
- LDAP Port: Set the port for your LDAP server
- LDAP Security: Select the security method of your LDAP server — SSL, TLS or None
- LDAP Auth DN/Fetch DN/Filter DN: These strings are used to first authentication the 6connect user and then to retrieve their permissions. The string ‘%LOGIN%’ should be inserted in place of the user’s common name both strings. (ex: cn=%LOGIN%,ou=people,dc=6connect,dc=com)
- LDAP Group Attribute: If using an internal list of user groups instead of 6connect groups, enter the attribute name for the LDAP groups here. If a Group Attribute is set, it will be used first, otherwise the 6connect schema will be used.
- LDAP Username / LDAP Password: Optionally, you may enter LDAP admin credentials to allow ProVision to import and sync LDAP contacts. See Contact Manager for details on LDAP contacts.
- Mapping Permissions to 6connect schema: To integrate 6connect permissions with your existing directory structure then you will need the 6connect schema. It should snap in with any existing LDAP structure and allow you to assign 6connect permissions to your existing users. You can download a copy of the schema from this section.
Once at least one LDAP server has been added, a list will appear at the top of the Radius module. Add an additional Radius server by clicking «Add new server».
ProVision will try to connect to each server listed in the order listed, until a success is returned. Disabled servers will display in grey, and the currently selected server will display in bold.
When done, click «Save Changes».