Последние сообщения

Страницы: [1] 2 3 ... 10
1
Здравствуйте! Использовать фильтр с memberOf не получилось. Думаю, что memberOf в AD -- динамический атрибут, на момент проверки ACL его в каталоге нет и поэтому условие отбора всегда возвращает false. В обычном каталоге OpenLDAP такие фильтры в условии ACL работают, поскольку memberOf является статическим атрибутом.

Более-менее то, что Вы хотели в плане ограничений по конкретным ou и с выводом конкретных атрибутов:
access to dn.children="OU=Office,OU=Company,DC=example,DC=com"
    filter="(&(objectClass=organizationalPerson)(!(objectClass=computer)))"
    attrs=entry,sAMAccountName,sn,givenName,mail
    by users read
    by * none

access to * by * search

Так в запросе с аутентификацией выводятся только пользователи (не компьютеры) из определённой подветки и только с перечисленными атрибутами. При анонимном запросе не выводится ничего.

По ограничению аутентификации -- трудно сказать. Не думаю, что аутентификация в AD напрямую связана с атрибутами из каталога (как это происходит с simpleBind аутентификацией в OpenLDAP), поскольку даже при таких достаточно строгих ограничениях, которые я привёл выше, аутентификация всё равно происходит. Единственное, что приходит в голову:
access to dn.children="OU=Office,OU=Company,DC=example,DC=com"
    filter="(&(objectClass=organizationalPerson)(!(objectClass=computer)))"
    attrs=entry,sAMAccountName,sn,givenName,mail
    by dn.children="OU=Office,OU=Company,DC=example,DC=com" read
    by * none

access to * by * search

То есть только пользователи из этой подветки смогут прочитать свою подветку, остальные получат пустой ответ.

Наверное, это всё, что можно выжать из прокси к AD.

Егор

2
Добрый день!
В данный момент все просто:
access to dn.children="OU=Office,OU=Company,DC=example,DC=com"
    filter=(objectClass=organizationalPerson)
    attrs=entry,sAMAccountName,sn,givenName,mail
    by users read
    by * none

access to
    filter=(objectClass=organizationalUnit)
    by users read
    by * none

Но я так же пробовал и варианты:

Убрать из выборки компьютеры:
access to
    filter=(objectClass=computer)
    by * none
access to
    filter=(objectClass=COMPUTER)
    by * none

access to dn.children="OU=Office,OU=Company,DC=example,DC=com"
    filter=(objectClass=organizationalPerson)
    attrs=entry,sAMAccountName,sn,givenName,mail
    by users read
    by * none

access to
    filter=(objectClass=organizationalUnit)
    by users read
    by * none
- не помогло. Компьютеры в выборке присутствуют.

Отбирать пользователей, по членству в группе:
 
access to
    filter=(|(objectClass=organizationalUnit)(&(objectClass=organizationalPerson)(memberOf=cn=Role_N1,ou=Groups,ou=Office,ou=Company,dc=example,dc=com)))
    by users read
    by * none
Вижу только пустые OU.

По вопросу ограничения логина/бинд - у меня вообще нет никаких идей. Возможно тут проблема в том, что пока пользователь не забиндился, LDAP proxy не может сделать rebind-as-user. А значит не может получить информацию о том пользователе, который хочет биндится.
3
Здравствуйте! Покажите, пожалуйста, полные настройки ACL (все правила).

Егор
4
Имеется разветвленное дерево AD. Имеется ряд сервисов/серверов которым нужен доступ к AD по протоколу LDAP через LDAP proxy. Особого доверия к серверам нет. Все ограничения должны быть реализованы на LDAP proxy: Сервера должны видеть минимальное количество полей/атрибутов, и только в только в тех объектах, которые необходимы.
1. Ограничить возможность читать объекты:
1.1 Только пользователей, состоящих в определенной группе;
1.2 Если 1.1 реализовать не возможно, то только пользователей, находящихся в определенном месте дерева (в определенном OU);
1.3 Также возможность считывать все родительские объекты, в которых находятся объекты из пункта 1;
1.4 Если 1.3 реализовать не возможно, то: Все объекты типа DC и OU;
2. Ограничить возможность считывания атрибутов объекта;
3. Разрешить возможность проверки пароля пользователя (авторизация/бинд) только тем пользователям, которые соответствуют критериям пунктов 1.1 или 1.2;

Я развернул LDAP proxy - Debian, OpenLDAP:
uname -a
Linux ldap-proxy.example.com 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64 GNU/Linux
apt list slapd
slapd/oldstable,now 2.4.44+dfsg-5+deb9u2 amd64 [installed]
slapd -V
@(#) $OpenLDAP: slapd  (May 23 2018 04:25:19) $
        Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>

Удалось реализовать пункты 1.2, 1.4 и 2:
pidfile /var/run/slapd/slapd.pid

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/microsoftattributetype.schema

moduleload back_ldap.la

database ldap
uri "ldap://1.2.3.4"
readonly on
suffix "dc=example,dc=com"
rebind-as-user

access to dn.children="OU=Office,OU=Company,DC=example,DC=com"
    filter=(objectClass=organizationalPerson)
    attrs=entry,sAMAccountName,sn,givenName,mail
    by users read
    by * none

access to
    filter=(objectClass=organizationalUnit)
    by users read
    by * none

Но никак не удается закрыть следующие вопросы:

1. К сожалению в выборку попадают не только объекты типа User, но и типа Computer. Пробовал добавить в начало следующее правило:
access to
    filter=(objectClass=computer)
    by * none

- не помогло. Подскажите пожалуйста, как удалить из выборки компьютеры?

2. Пытался ограничить по членству в группе. Использовал следующие фильтры:
access to
filter=(&(objectClass=organizationalPerson)(memberOf=cn=Role_N1,ou=Groups,ou=Office,ou=Company,dc=example,dc=com))
    by users read
    by * none
access to
    filter=(objectClass=organizationalUnit)
    by users read
    by * none
и результат - только пустые OU. Причем если использовать фильтр в LDAP browser - все Ок. Подскажите, как можно построить отбор по членству в группе (полагаю, что если решить этот вопрос, то вопрос 1. станет не актуальным)?

3. К сожалению, никак не удается ограничить возможность проверки пароля. Например в LDAP Browser, в параметра подключения к LDAP proxy, я могу использовать пользователя, который находится вне "OU=Office,OU=Company,DC=example,DC=com", хотя для чтения, фильтр работает - я его в дереве не вижу. Подскажите, есть ли возможность ограничить возможность проверки паролей/авторизации?

4. Пока выводятся все объекты типа OU. Т.е. видно все дерево, хотя, благодаря фильтрам, большая часть веток пустая. Есть ли возможность выводить только те OU, которые содержать объекты (прошедшие фильтр)?

Заранее спасибо.
5
Работа с LDAP-клиентами / Re: Проверка сертификата SSL
« Последний ответ от 2life 12 Август 2019, 14:55:34 »
А по итогу всё работает :) Я ldapsearch сделал вот только сейчас.
Это не ошибка видимо, а предупреждение, про сертификат самоподписанный.
Вообщем виноват только сам, т.к. запутался между сертификатом, и ключом.
Большое спасибо! Вроде бы у меня вопросы закончились. Путь пройдён по настройке OpenLDAP.
6
Работа с LDAP-клиентами / Re: Проверка сертификата SSL
« Последний ответ от 2life 12 Август 2019, 14:47:18 »
Мой случай это второй случай (с самоподписанным сертификатом).  Вы правы, я указал файл ключа, а не сертификата, и даже не заметил этого J. Ошибку поправил.

Вывод команды следующий:

root@ldapsrv:/etc/ldap/tmp# ps ax | grep slapd
 9954 ?        Ssl    0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Ситуация с проверкой продвинулась дальше, но ненамного, к сожалению.

Вот так вроде нормально всё
root@ldapsrv:/etc/ldap/ssl# openssl verify -verbose -x509_strict -CAfile rootca.crt ldapsrv.domain.lan.crt
ldapsrv.domain.lan.crt: OK

Тут уже не очень...
root@ldapsrv:/etc/ldap/tmp# openssl s_client -connect ldapsrv.domain.lan:636 -showcerts -CApath /etc/ldap/ssl/
CONNECTED(00000003)
depth=1 C = RU, ST = CITY, L = CITY, O = COMPANY, OU = ITdept, CN = ca-server, emailAddress = info@domain.lan
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 C = RU, ST = CITY, L = CITY, O = COMPANY, OU = ITdept, CN = ca-server, emailAddress = info@domain.lan
verify return:1
depth=0 C = RU, ST = CITY, O = COMPANY, OU = ITdept, CN = ldapsrv.domain.lan, emailAddress = info@domain.lan
verify return:1

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3218 bytes and written 401 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self signed certificate in certificate chain)

Пока отправился гуглить.
7
Работа с LDAP-клиентами / Re: Проверка сертификата SSL
« Последний ответ от egor 12 Август 2019, 13:32:21 »
Здравствуйте! Чтобы правильно настроить TLS-сессию, нужно немного знать о сертификатах и процессе доверия. В двух словах об этом не расскажешь, если интересно, можно почитать этот материал.

По существу Вашего вопроса. Сначала нужно разобраться, как был сгенерирован сертификат для Вашего LDAP-сервера. В настройках LDAP-сервера есть атрибут olcTLSCACertificateFile, значением которого должен быть путь к сертификату удостоверяющего центра, закрытым ключом которого подписан сертификат LDAP-сервера. То есть ситуация может быть двоякая:

Первый вариант: у Вас уже был корневой сертификат и закрытый ключ удостоверяющего центра, и Вы с их помощью подписали сертификат для сервера LDAP. В этом случае в атрибуте olcTLSCertificateFile указывается путь к сертификату сервера LDAP, а в атрибуте olcTLSCACertificateFile -- путь к сертификату удостоверяющего центра, с помощью которого можно удостовериться в действительности сертификата сервера LDAP.
Второй вариант: Вы сгенерировали так называемый "самоподписанный" сертификат для сервера LDAP, то есть сертификат, подписанный своим же закрытым ключом. В этом случае в обоих атрибутах  olcTLSCertificateFile и olcTLSCACertificateFile указывается путь к сертификату сервера, поскольку он его помощью проверяется действительность самого себя.

В любом случае, в атрибуте olcTLSCACertificateFile указывается именной файл сертификата, а не файл ключа (у Вас же, скорее всего, там указан файл закрытого ключа).

Далее, чтобы LDAP-клиент смог проверить действительность сертификата сервера, он должен знать где получить файл сертификата удостоверяющего центра, закрытым ключом которого подписан сертификат LDAP-сервера. То есть, в настройках LDAP-клиента (/etc/ldap/ldap.conf) должна быть задана как минимум директива TLS_CACERT, в которой при первом рассмотренном нами варианте указывается путь к сертификату удостоверяющего центра, а при втором -- путь к самому сертификату сервера LDAP.

Потом, когда Вы вызываете команду ldapsearch с параметрами ZZ, Вы указываете LDAP-клиенту подключиться к порту 389, а затем выполнить операцию StartTLS. А при вызове openssl s_client пытаетесь подключиться к порту 636. С какими параметрами запущен Ваш сервер slapd (вывод команды ps ax | grep slapd)?

Наконец, для проверки действительности сертификата, при подключении к серверу нужно указывать то имя, которое фигурирует в атрибуте CN сертификата. То есть в первом нашем случае (с отдельным сертификатом удостоверяющего центра) вызов команды openssl s_client должен выглядеть так:
# openssl s_client -connect ldapsrv.domain.lan:636 -CAfile /etc/ldap/ssl/rootca.crt
(в последнем параметре нужно указать правильный путь к сертификату удостверяющего центра).
Во втором так:
# openssl s_client -connect ldapsrv.domain.lan:636 -CAfile /etc/ldap/ssl/ldapsrv.domain.lan.crt

Как видите, тонкостей много и затык может быть в любом месте. Надеюсь, мои замечания наведут на нужные мысли.

Егор
8
Если Вы планируете серьёзно работать с Linux, я бы порекомендовал сразу начать изучения какой-нибудь системы управления конфигурациями типа ansible. Они позволяют запуском одного скрипта настроить сразу несколько (или все) компьютеры в сети из одной точки. Очень экономит время (и поднимает самомнение =) ).

Егор
9
Работа с LDAP-клиентами / Проверка сертификата SSL
« Последний ответ от 2life 12 Август 2019, 09:45:29 »
Добрый день,
В целом и общем сервер OpenLDAP у меня прекрасно заработал. При запуске секция TLS была пропущена. Сейчас нужно к ней вернуться.
На данный момент при попытке подключится, через SSL получаю след. ошибку:

#ldapsearch -xZZLLLWD cn=admin,dc=domain,dc=lan -b cn=config -s base
ldap_start_tls: Connect error (-11)
        additional info: (unknown error code)
Без защиты:
/etc/ldap/tmp# ldapsearch -xLLLWD cn=admin,dc=domain,dc=lan -b cn=config -s base
Enter LDAP Password:
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: any
olcPidFile: /var/run/slapd/slapd.pid
olcTLSVerifyClient: never
olcToolThreads: 1
olcTLSCertificateFile: /etc/ldap/ssl/ldapsrv.domain.lan.crt
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldapsrv.domain.lan.key
olcTLSCACertificateFile: /etc/ldap/ssl/private/rootca.key

В логах вижу следующее:
Aug  9 19:01:46 fssrv2 slapd[23182]: connection_get(14): got connid=1001
Aug  9 19:01:46 fssrv2 slapd[23182]: connection_read(14): checking for input on id=1001
Aug  9 19:01:46 fssrv2 slapd[23182]: connection_read(14): unable to get TLS client DN, error=49 id=1001
Aug  9 19:01:46 fssrv2 slapd[23182]: conn=1001 fd=14 TLS established tls_ssf=256 ssf=256
Но т.к. используется TLSVerifyclient never, и на клиенте tls_reqcert "demand", то на ошибку «unable to get TLS client DN» можно внимание не обращать. Я верно понял?

При проверке через openssl картина такая:
root@ldapsrv:/etc/ldap/ssl# openssl s_client -connect 127.0.0.1:636 -CAfile /etc/ldap/ssl/ldapsrv.domain.lan.crt
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = RU, ST = CITY, O = COMPANY, OU = ITdept, CN = ldapsrv.domain.lan, emailAddress = info@domain.lan
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = RU, ST = CITY, O = COMPANY, OU = ITdept, CN = ldapsrv.domain.lan, emailAddress = info@domain.lan
verify error:num=21:unable to verify the first certificate
verify return:1
.......
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2143 bytes and written 373 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)


Опять я «забуксовал»...
10
Егор, ваш ответ можно считать образцовым. Всё описано подробно, но при этом вы использовали всего несколько абзацев. Читать приятно, и всё необычайно просто описано. Спасибо за вашу работу!
По поводу частной задачи вы правы, не стоит делать такие костыли. К тому же,  я подумал, при маппинге за всем этим добром придётся следить, всё таки нужно пересилить себя, и настроить LDAP клиентов на конечных машинах.
Страницы: [1] 2 3 ... 10