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:
- Dodaj atrybut „member” do ISTNIEJĄCEGO „groupOfNames”, a odpowiedni atrybut „memberOf” zostanie utworzony automatycznie.
- Usuń atrybut „member” i automatycznie usuń odpowiedni atrybut „memberOf”.
slapadd(na zatrzymaną bazę danych) nie jest właściwym sposobem na to?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.
Miałem już groupOfNames o nazwie vpn, więc musiałem utworzyć plik LDIF o następującej treści:
I dodałem to do mojej bazy danych LDAP
Następnie uruchomiłem serwer ldap podczas debugowania, aby sprawdzić błędy
i sprawdziłem, aby upewnić się, że moje członkostwo w grupie „VPN” zostało wymienione w moim wpisie użytkownika.
i bam! sukces!
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:
źródło