Jak skonfigurować konserwację odwróconego członkostwa grupy na serwerze openldap? (członkiem)

Obecnie pracuję nad zintegrowaniem uwierzytelniania LDAP z systemem i chciałbym ograniczyć dostęp w oparciu o grupę LDAP. Jedynym sposobem, aby to zrobić, jest filtr wyszukiwania, dlatego uważam, że moją jedyną opcją jest użycie atrybutu „memberOf” w moim filtrze wyszukiwania. Rozumiem, że atrybut „memberOf” jest atrybutem operacyjnym, który może być dla mnie utworzony przez serwer za każdym razem, gdy dla każdego wpisu „groupOfNames” na serwerze tworzony jest nowy atrybut „memberOf”. Moim głównym celem jest możliwość dodania atrybutu „member” do istniejącego wpisu „groupOfNames” i dodanie pasującego atrybutu „memberOf” do podanej nazwy wyróżniającej.

Co udało mi się dotychczas osiągnąć:

Nadal jestem całkiem nowy w administrowaniu LDAP, ale na podstawie tego, co znalazłem w przewodniku administratora openldap, wygląda na to, że odwrócenie członkostwa w grupie, czyli „element członkowski nakładki”, osiągnę dokładnie taki efekt, którego szukam.

Mój serwer obecnie uruchamia instalację pakietu (slapd na Ubuntu) programu openldap 2.4.15, który używa konfiguracji środowiska wykonawczego „cn = config”. Większość przykładów, które znalazłem, wciąż odwołuje się do starszej metody konfiguracji statycznej „slapd.conf” i starałem się jak najlepiej dostosować konfiguracje do nowego modelu opartego na katalogu.

Dodałem następujące wpisy, aby włączyć moduł nakładki memberof:

Włącz moduł za pomocą olcModuleLoad

cn=config/cn\=module\{0\}.ldif

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}memberof.la
structuralObjectClass: olcModuleList
entryUUID: a410ce98-3fdf-102e-82cf-59ccb6b4d60d
creatorsName: cn=config
createTimestamp: 20090927183056Z
entryCSN: 20091009174548.503911Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009174548Z

Włączono nakładkę dla bazy danych i zezwolono na korzystanie z jej ustawień domyślnych (groupOfNames, member, memberOf itp.)

cn=config/olcDatabase={1}hdb/olcOverlay\=\{0\}memberof

dn: olcOverlay={0}memberof
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
structuralObjectClass: olcMemberOf
entryUUID: 6d599084-490c-102e-80f6-f1a5d50be388
creatorsName: cn=admin,cn=config
createTimestamp: 20091009104412Z
olcMemberOfRefInt: TRUE
entryCSN: 20091009173500.139380Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009173500Z

Mój obecny wynik:

Korzystając z powyższej konfiguracji, jestem w stanie dodać NOWĄ „groupOfNames” z dowolną liczbą pozycji „member” i zaktualizować wszystkie zaangażowane nazwy wyróżniające za pomocą atrybutu „memberOf”. To jest część zachowania, którego bym się spodziewał. Chociaż uważam, że przy użyciu nakładki członka należy wykonać następujące czynności, nadal nie wiem, jak wykonać następujące czynności i chętnie przyjmę wszelkie porady:

1. Dodaj atrybut „member” do ISTNIEJĄCEGO „groupOfNames”, a odpowiedni atrybut „memberOf” zostanie utworzony automatycznie.
2. Usuń atrybut „member” i automatycznie usuń odpowiedni atrybut „memberOf”.

Walczę z tym samym, dokumentacja openldap jest minimalistyczna i prawie wcale nie pomocna. Kiedy przeszli do bazy danych konfiguracji (co nie jest złym pomysłem), wszystkie opcje się zmieniły, więc kiedy ludzie podają przykład z /etc/ldap/slapd.conf, jest to bezużyteczne w przypadku nowoczesnej konfiguracji slapd (takiej jak Ubuntu).

W końcu to działa. Oto podsumowanie ... pierwszy plik LDIF:

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof

Drugi plik LDIF:

dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

Dodaj je do bazy danych konfiguracji za pomocą ldapadd (tak samo jak normalne rzeczy konfiguracyjne).

Nie aktualizuje automatycznie istniejących danych w bazie danych, więc musiałem użyć slapcat, aby skopiować wszystko do pliku tymczasowego i odwiedzić każdą grupę, usunąć grupę i ponownie dodać tę samą grupę (wymusza aktualizację atrybutów memberOf poprawnie). Jeśli zaczynasz od pustej bazy danych, wówczas poprawnie zaktualizuje ona atrybuty w miarę dodawania obiektów.

Pamiętaj też, że „olcDatabase = {1} hdb” jest bardzo typowy, ale nie ma gwarancji, że będzie pasował do twojej konfiguracji. Pamiętaj, aby to sprawdzić.

Napisałem o tym niedawno na moim blogu www.jordaneunson.com, w którym skopiowałem i wkleiłem odpowiednie części.

Musiałem zatrzymać usługę „slapd” na moim serwerze LDAP i edytować plik slapd.conf i dodać następujące dwa wiersze.

moduleload memberof.la
overlay memberof

Miałem już groupOfNames o nazwie vpn, więc musiałem utworzyć plik LDIF o następującej treści:

dn: cn=vpn,ou=Groups,dc=shop,dc=lan
objectclass: groupofnames
cn: vpn
description: Users allowed to connect on VPN
member: uid=jordan,ou=People,dc=shop,dc=lan

I dodałem to do mojej bazy danych LDAP

slapadd -f file.ldif

Następnie uruchomiłem serwer ldap podczas debugowania, aby sprawdzić błędy

slapd -d 99 -f /etc/ldap/slapd.conf 

i sprawdziłem, aby upewnić się, że moje członkostwo w grupie „VPN” zostało wymienione w moim wpisie użytkownika.

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf 

i bam! sukces!

jordan, People, shop.lan
dn: uid=jordan,ou=People,dc=shop,dc=lan
memberOf: cn=vpn,ou=Groups,dc=shop,dc=lan

Więc zwolniłem usługę slapd z powrotem i odniosłem duży sukces od tego czasu. W przypadku nowego narzędzia do zarządzania GUI używam phpLDAPAdmin i nie mam problemów z przypisaniem i nieprzypisaniem atrybutu memberOf do moich użytkowników.

Ostatnią rzeczą, na którą należy zwrócić uwagę, jest to, że atrybut „memberOf” nie jest częścią podstawowego schematu LDAP v3, a zatem wykonanie ldapsearch nie ujawni tego atrybutu, chyba że zostanie o to zapytany. Dlatego w moim powyższym przykładzie jest zadeklarowany na końcu parametrów ldapsearch.

Mam nadzieję że to pomoże.

Edycja: Właśnie przetestowałem twój problem z Apache Directory Studio: tak długo, jak wprowadzę wartość członka atrybutu jako całość, jak wspomniano powyżej, działa OK. Jednak atrybut memberOf nie pojawia się we wpisie użytkownika. Wynika to z faktu, że atrybut memberOf nie jest częścią schematu LDAPv3. Aby sprawdzić, czy tam jest, użyj narzędzia wiersza polecenia ldapsearch:

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf