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

Страницы: [1] 2 3 ... 10
1
Работа с LDAP-клиентами / Re: Extended Operation(1.3.6.1.4.1.4203.1.11.1) not supported
« Последний ответ от ZenMaster 20 Октябрь 2019, 15:09:52 »
Да, Егор
Покапался в исходниках samba

кроме start_tls - она ничего не поддерживает
https://github.com/samba-team/samba/blob/0afd655e80262ea8505a2e6d0dd9cc453fbdfd8c/source4/ldap_server/ldap_extended.c#L154
ниже в ldapsrv_ExtendedRequest идет reject


а PAM или SSSD используют протокол openldap
так что можно делать тока черех samba-tool
2
Работа с LDAP-клиентами / Re: Extended Operation(1.3.6.1.4.1.4203.1.11.1) not supported
« Последний ответ от egor 18 Октябрь 2019, 02:28:34 »
Здравствуйте! AD никогда не поддерживал расширенную операцию LDAP Password Modify (RFC3062, тот самй OID 1.3.6.1.4.1.4203.1.11.1), samba4 также её не поддерживает. Nslcd, скорее всего, умеет менять пароли только с помощью этой операции.

По идее, sssd умеет при привязке к AD менять там пароли пользователей, поищите в интернете на предмет параметра chpass_provider=ad в sssd.conf, так что и с samba4 тоже должно работать. Но нужно будет менять nslcd на sssd.

У меня сейчас нет стенда с samba4, так что придётся экспериментировать самому.

Егор
3
Работа с LDAP-клиентами / Extended Operation(1.3.6.1.4.1.4203.1.11.1) not supported
« Последний ответ от ZenMaster 17 Октябрь 2019, 12:03:54 »
Доброго дня
samba 4.9.3
+laptop с конфигурированным PAM-LDAP
для нужного пользователя делаю на ldap expired password (shadowLastChange=0)
на laptop делаю коннект под этим пользоватлем
pam_ldap.so - нормалтно все понимает
но потом вызывает ldap_passwd_s из openldap,
которая генерит extended operation 1.3.6.1.4.1.4203.1.11.1 для samba-ы

а вот сервер = отвечает
nslcd: [3ab105] <pwmod="testuser5"> ldap_passwd_s() with old password failed: Protocol error: Extended Operation(1.3.6.1.4.1.4203.1.11.1) not supported
ну ответ то понятный - хотя по коду samba смотрел - нет там таких резких ограничений

все под ssl

плюс smb.conf - что уже и не писал - все равно отказ
        pam password change = yes
   client plaintext auth = yes
   client lanman auth = yes      

Может есть все же решение?
4
Простите, не совсем понятно, Вы пробовали предлагаемые мной варианты? Получили то, что хотели?

Егор
5
Добрый день!
Попробовал следующий фильтр:
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
    filter=(objectClass=organizationalUnit)
    by users read
    by * none
К сожалению данный фильтр прячет не только компьютеры, но и пользователей - т.е. видно только пустые OU.

Спасибо за Вашу помощь.
6
Здравствуйте! Использовать фильтр с 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.

Егор

7
Добрый день!
В данный момент все просто:
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. А значит не может получить информацию о том пользователе, который хочет биндится.
8
Здравствуйте! Покажите, пожалуйста, полные настройки ACL (все правила).

Егор
9
Имеется разветвленное дерево 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, которые содержать объекты (прошедшие фильтр)?

Заранее спасибо.
10
Работа с LDAP-клиентами / Re: Проверка сертификата SSL
« Последний ответ от 2life 12 Август 2019, 14:55:34 »
А по итогу всё работает :) Я ldapsearch сделал вот только сейчас.
Это не ошибка видимо, а предупреждение, про сертификат самоподписанный.
Вообщем виноват только сам, т.к. запутался между сертификатом, и ключом.
Большое спасибо! Вроде бы у меня вопросы закончились. Путь пройдён по настройке OpenLDAP.
Страницы: [1] 2 3 ... 10