Come configuro la manutenzione inversa dei gruppi su un server openldap? (membro di)

Attualmente sto lavorando all'integrazione dell'autenticazione LDAP in un sistema e vorrei limitare l'accesso in base al gruppo LDAP. L'unico modo per farlo è tramite un filtro di ricerca e quindi credo che la mia unica opzione sia l'uso dell'attributo "memberOf" nel mio filtro di ricerca. Sono consapevole che l'attributo "memberOf" è un attributo operativo che può essere creato dal server per me ogni volta che viene creato un nuovo attributo "member" per qualsiasi voce "groupOfNames" sul server. Il mio obiettivo principale è quello di poter aggiungere un attributo "membro" a una voce "groupOfNames" esistente e aggiungere un attributo "memberOf" corrispondente al DN fornito.

Quello che sono riuscito a raggiungere finora:

Sono ancora abbastanza nuovo nell'amministrazione LDAP, ma in base a ciò che ho trovato nella guida dell'amministratore di openldap, sembra che Reverse Group Membership Maintence, noto anche come "memberof overlay", ottenga esattamente l'effetto che sto cercando.

Il mio server sta attualmente eseguendo un'installazione di pacchetto (slapd su ubuntu) di openldap 2.4.15 che utilizza la configurazione di runtime in stile "cn = config". La maggior parte degli esempi che ho trovato fanno ancora riferimento al vecchio metodo "slapd.conf" di configurazione statica e ho fatto del mio meglio per adattare le configurazioni al nuovo modello basato su directory.

Ho aggiunto le seguenti voci per abilitare il modulo overlay memberof:

Abilita il modulo con 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

Abilitato l'overlay per il database e consentito l'utilizzo delle impostazioni predefinite (groupOfNames, member, memberOf, ecc.)

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

Il mio risultato attuale:

Utilizzando la configurazione sopra, sono in grado di aggiungere un NUOVO "groupOfNames" con un numero qualsiasi di voci "member" e avere tutti i DN coinvolti aggiornati con un attributo "memberOf". Questo fa parte del comportamento che mi aspetterei. Mentre credo che quanto segue dovrebbe essere stato realizzato con il membro overlay, non so ancora come fare e sarei lieto di ricevere qualsiasi consiglio:

1. Aggiungi un attributo "membro" a un "groupOfNames" ESISTENTE e crea automaticamente un attributo "memberOf" corrispondente.
2. Rimuovere un attributo "membro" e far rimuovere automaticamente l'attributo "membroOf" corrispondente.

Ho avuto problemi con la stessa cosa, la documentazione di openldap è minimalista e per nulla utile. Quando sono passati a un database di configurazione (non una cattiva idea in linea di principio) tutte le opzioni sono cambiate, quindi quando le persone danno l'esempio da /etc/ldap/slapd.conf è inutile con una moderna configurazione slapd (come Ubuntu).

Finalmente ho funzionato. Ecco il riassunto ... primo file LDIF:

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

Secondo file 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

Aggiungili nel database di configurazione usando ldapadd (come le normali cose di configurazione).

Non aggiorna automaticamente i dati esistenti nel database, quindi ho dovuto usare slapcat per copiare tutto in un file temporaneo, visitare ogni gruppo, eliminare il gruppo e aggiungere nuovamente lo stesso gruppo (impone l'aggiornamento degli attributi memberOf correttamente). Se si inizia con un database vuoto, aggiornerà correttamente gli attributi man mano che vengono aggiunti gli oggetti.

Inoltre, nota che "olcDatabase = {1} hdb" è molto tipico, ma non è garantito che corrisponda alla tua configurazione. Assicurati di controllare quello.

Ne ho scritto di recente sul mio blog, www.jordaneunson.com, in cui ho copiato e incollato le parti pertinenti.

Quello che dovevo fare era interrompere il servizio "slapd" sul mio server LDAP e modificare il mio file slapd.conf e aggiungere le seguenti due righe.

moduleload memberof.la
overlay memberof

Avevo già un groupOfNames chiamato vpn, quindi ho dovuto creare un file LDIF con i seguenti contenuti:

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

E aggiunto questo al mio database ldap

slapadd -f file.ldif

Dopo questo ho avviato il server LDAP in debug per verificare la presenza di errori

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

e ho verificato che la mia appartenenza al gruppo di "vpn" fosse elencata nella mia voce utente.

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

e bam! successo!

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

Così ho riavviato il servizio slapd e da allora ho avuto molto successo. Per un nuovo strumento di gestione della GUI sto usando phpLDAPAdmin e non ho problemi con l'attributo memberOf assegnato e non assegnato ai miei utenti.

Un'ultima cosa da notare è che l'attributo "memberOf" non fa parte dello schema di base LDAP v3 e quindi fare una ricerca LD non rivelerà questo attributo se non specificamente interrogato. Questo è il motivo per cui nel mio esempio sopra è dichiarato alla fine dei parametri di ldapsearch.

Spero che sia di aiuto.

Modifica: ho appena provato il tuo problema con Apache Directory Studio: fintanto che inserisco il valore del membro dell'attributo nel suo insieme come sopra menzionato, funziona A-OK. Tuttavia l'attributo memberOf non viene visualizzato nella voce utente. Questo perché l'attributo memberOf non fa parte dello schema LDAPv3. Per verificare che sia lì, usa lo strumento da riga di comando ldapsearch:

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