Introduzione
Perché OpenLDAP?
Il progetto consiste nel copiare il codice sorgente di riferimento LDAP. OpenLDAP è l'abbreviazione di Lightweight Directory Access Protocol. LDAP è un protocollo applicativo indipendente dal fornitore che consente di valutare e mantenere i servizi di informazioni di directory distribuiti su un ISP. Esistono molti modi diversi per fornire una directory. Ad esempio, l'utilizzo di LDAP ti aiuta a fornire un luogo centrale in cui archiviare nomi utente e password.
Pertanto, molte applicazioni e servizi diversi potrebbero connettersi al server LDAP per convalidare gli utenti. I server LDAP sono ampiamente utilizzati nelle Organizzazioni per memorizzare il nome utente e la password in un server centralizzato rispetto al quale l'utente può autenticarsi ulteriormente a programmi e servizi presenti sulla rete. Inoltre, utilizzeremo i pacchetti Symas OpenLDAP per i comandi standard di manutenzione del software nativi del tuo sistema operativo. OpenLDAP è il principale contributore nella scrittura del 90% del codice OpenLDAP. Inoltre, controlla Tutorial OpenLdap su RHEL8 e Documentazione OpenLDAP.
Pro di OpenLDAP
È gratis. Simile a Linux è open source. Protocollo standard. In secondo luogo, inoltre, è facile associare l'autenticazione a molte applicazioni. Personalizzabile e leggero.
Contro di OpenLDAP
Sarebbe meglio se ti preparassi. Oltre alla tua infrastruttura supporta tutti i requisiti. Politiche e regole di sicurezza in atto. Quindi i database o ActiveDirectory dovrebbero sempre archiviare i dati. Tutti gli attributi e le politiche si interromperanno se le informazioni correnti non sono a posto. Supponendo che Microsoft nella tua zona, sovvenzioni per OpenLDAP con Active Directory.
Ottieni l'immagine OpenLDAP
#podman pull osixia/openldap:latest
Crea contenitore
Non dimenticare di aggiungere la mappatura delle porte per entrambe le porte 389 e 636 se desideri accedere al server ldap da un'altra macchina.
# podman pod create --name openldapapp -p 389:389 -p 636:636 --network bridgeCrea il contenitore openldap
Questo è il comportamento predefinito quando si esegue questa immagine. Creerà un ldap aperto per Unixcop.com. E il dominio example.com . Per impostazione predefinita, l'amministratore ha la password admin . Tutte queste impostazioni predefinite possono essere modificate dalla riga di comando della finestra mobile, ad esempio:
podman run --pod openldapapp --name openldap-server --uts=private --hostname=openldap.example.com \
--env LDAP_ORGANISATION="My UnixCop" --env LDAP_DOMAIN="example.com" \
--env LDAP_ADMIN_PASSWORD="UnixCop@SoFreaky" --env LDAP_TLS=false \
--env LDAP_READONLY_USER=ldapuser01 --env LDAP_CONFIG_PASSWORD="UnixCop@SoFreaky" \
--env LDAP_READONLY_USER_PASSWORD="UnixCop@SoFreaky" \
--env LDAP_READONLY_USER_PASSWORD="UnixCop@SoFreaky" \
--env LDAP_BASE_DN="cn=admin,dc=example,dc=com" -d osixia/openldap:latestLe directory /var/lib/ldap (file di database LDAP) e /etc/ldap/slapd.d (file di configurazione LDAP) vengono utilizzate per mantenere lo schema e le informazioni sui dati. Dovrebbero essere mappati come volumi, quindi i tuoi file ldap vengono salvati all'esterno del contenitore (usa un database ldap esistente). Tuttavia, può essere utile non utilizzare i volumi se l'immagine deve fornire l'immagine completa di dati di test:ciò è particolarmente utile quando si ricavano altre immagini da questa.
Questa immagine può caricare file ldif e schema da un percorso interno all'avvio. Inoltre, puoi copiare i certificati da una directory interna. Ciò è utile se un servizio di integrazione continua monta automaticamente la copia di lavoro (sorgenti) in un servizio docker, correlato al lavoro ci.
Ad esempio, GitLab non può montare percorsi personalizzati nei servizi docker di un processo ci, ma Gitlab ridimensiona automaticamente la copia di lavoro in ogni contenitore di servizi. Quindi la copia di lavoro (sorgenti) è accessibile in /built-in in ogni servizio di un lavoro ci. La directory del certificato può ottenere il percorso della copia di lavoro tramite ${CI_PROJECT_DIR}. Vedi anche:https://docs.gitlab.com/runner/executors/docker.html#build-directory-in-service
Questo può funzionare anche con altri servizi CI se montano automaticamente la directory di lavoro sui servizi di un lavoro ci come fa Gitlab ci.
Per eseguire il seeding di file ldif o schema dal percorso interno, è necessario impostare la variabile di ambiente specifica LDAP_SEED_INTERNAL_LDIF_PATH e LDAP_SEED_INTERNAL_SCHEMA_PATH. Se selezionato, copierà tutti i file nella directory specificata nelle directory di seeding predefinite di questa immagine.
LDAP_SEED_INTERNAL_LDAP_TLS_CRT_FILE: "${CI_PROJECT_DIR}/docker/certificates/certs/cert.pem"
LDAP_SEED_INTERNAL_LDAP_TLS_KEY_FILE: "${CI_PROJECT_DIR}/docker/certificates/certs/key.pem"
LDAP_SEED_INTERNAL_LDAP_TLS_CA_CRT_FILE: "${CI_PROJECT_DIR}/docker/certificates/ca/ca.pem"
LDAP_SEED_INTERNAL_LDAP_TLS_DH_PARAM_FILE: "${CI_PROJECT_DIR}/certificates/dhparam.pem"Aggiungi gruppo al contenitore openldap
# cat group.ldif
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People
dn: ou=othergroup,dc=example,dc=com
objectClass: organizationalUnit
ou: othergroup
Può essere fatto all'interno del contenitore
# podman exec -it openldap-server /bin/bash
/# ldapadd -x -W -D "cn=admin,dc=example,dc=com" -f /tmp/new-user.ldif -H ldap://openldap.example.com
Aggiunta utente al contenitore openldap
# cat new-user.ldif
dn: uid=ldapuser,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: adam
uid: adam
uidNumber: 16859
gidNumber: 100
homeDirectory: /home/ldapuser
loginShell: /bin/bash
gecos: ldapuser
userPassword: {crypt}x
shadowLastChange: 0
shadowMax: 0
shadowWarning: 0
