====== RHEL7: Installazione di 389 Directory Server 1.3.6 e successive ====== //ultima verifica documento: 22 feb. 2018// ** NOTA BENE ** Gli esempi citati in questa guida si intendono per 389 Directory Server 1.3.6.x e successive su CentOS 7.x In caso di installazione con diverse versioni alcuni path o nomi dei pacchetti potrebbero differire. // E’ inoltre vivamente consigliato che IP address, IP Name e Hostname della macchina siano coerenti. // hostnamectl status ed eventualmente hostnamectl set-hostname ===== Componenti del 389-ds ===== Il 389-DS è composto da vari pacchetti che si possono installare separatamente * 389-ds-base (e relative librerie) la cui versione è la 1.3 e si trova nel repository "base" della distribuzione CentOS7 * 389-admin (e relative utilities) la cui versione è la 1.1 ed ha il 389-ds-base tra le sue dipendenze. Si trova nel repository EPEL * 389-ds-console la cui versione è la 1.2 ed ha il 389-admin (e quindi anche il 389-ds-base) tra le sue dipendenze. Si trova nel repository EPEL * 389-dsgw la cui versione è la 1.1 ed ha il 389-admin (e quindi anche il 389-ds-base) tra le sue dipendenze. Si trova nel repository EPEL * 389-ds la cui versione è la 1.2 e contiene tutti i pacchetti di cui sopra. In linea di principio non è necessario avere tutti i pacchetti su tutti i server (basta un solo server con 389-ds-console e 389-admin). Noi installeremo tutto su tutti per due motivi: - E' utile avere sempre una console funzionante - La configurazione di SSL/TLS sulla console ===== Preparazione del sistema ===== Modificare i parametri kernel in /etc/sysctl.conf: echo "fs.file-max = 256000" >> /etc/sysctl.conf echo "net.ipv4.ip_local_port_range = 1024 65000" >> /etc/sysctl.conf echo "net.ipv4.tcp_keepalive_time = 300" >> /etc/sysctl.conf echo "vm.swappiness = 10" >> /etc/sysctl.conf Ricaricare sysctl: sysctl --system Modificare i limits in /etc/security/limits.conf inserendo la linea: echo "* soft nofile 32768" >> /etc/security/limits.conf echo "* hard nofile 63536" >> /etc/security/limits.conf echo "* soft nproc 4096" >> /etc/security/limits.conf echo "* hard nproc 16384" >> /etc/security/limits.conf Effettuare log-out e log-in in modo da ricaricare i limits. Installare cyrus-sasl e le librerie necessarie per INFN-AAI yum -y install cyrus-sasl cyrus-sasl-devel cyrus-sasl-gssapi cyrus-sasl-plain cyrus-sasl-lib Installazione del client LDAP standard di Linux: yum -y install openldap-clients ===== Firewall ===== L'installazione di default di CentOS 7.x abilita il firewalld. E' necessario aggiungere le regole che permettano l'accesso alle porte utilizzate dal 389DS firewall-cmd --permanent --add-port=389/tcp firewall-cmd --permanent --add-port=636/tcp firewall-cmd --permanent --add-port=9830/tcp E renderle attive facendo ripartire il servizio firewall-cmd --reload ===== Installazione 389-ds ===== Abilitare il repository yum EPEL yum -y install epel-release yum clean all Inatallare il 389-DS con tutte le sue dipendenze yum -y install 389-ds Modificare i limits che sistema assegna al processo, modificando il file /etc/sysconfig/dirsrv.systemd: echo "LimitNOFILE=32768" >> /etc/sysconfig/dirsrv.systemd echo "LimitNPROC=16384" >> /etc/sysconfig/dirsrv.systemd Rendere effettive le modifiche facendo ricaricare le configurazioni dal daemon di systemctl systemctl daemon-reload ===== Setup di 389-ds ===== Creare l’utente ds: useradd -r -s /bin/false ds Lanciare il setup di 389-ds /usr/sbin/setup-ds-admin.pl Scegliere l’opzione 3 in modo da personalizzare l’installazione: * Configurare come utente/gruppo "ds"; * Controllare il root suffix; * Tutto il resto può essere lasciato al default. ** Attenzione **: In questa fase verra' chiesto il nome dell'istanza del DS, di default corrisponde all'hostname senza dominio. // Si consiglia di lasciare il default e impostare la variabile DSUID in ~/.bash_profile. // Di seguito si farà infatti riferimento a tale valore con $DSUID. echo 'export DSUID=nome.istanza.ds' >> ~/.bash_profile source ~/.bash_profile Impostare la partenza dei servizi di 389-ds al boot systemctl enable dirsrv.target systemctl enable dirsrv-admin.service Fermare 389ds e verificare lo stato del servizio systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service ===== Directory Manager password ===== E' utile memorizzare la password del Directory Manager in un file accessibile solo a root: echo "" > /root/.ssh/dmpw chmod 400 /root/.ssh/dmpw ===== 389 Directory Server Console ===== Da questo momento e' possibile lanciare la console di gestione del Directory Server, attraverso la quale e' possibile fare ogni tipo di configurazione e gestire i dati della Directory. Per eseguire la console (a Directory Server attivo): 389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw & ===== Performance ===== Per migliorare le performance di 389ds, secondo le istruzioni della [[https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/file-descriptors|guida RedHat]] originale, bisogna incrementare il massimo numero di file descriptor a disposizione del server. Questo si può effettuare modificando il file ''/etc/dirsrv/slapd-$DSUID/dse.ldif'' e ''/etc/sysconfig/dirsrv'' sed -i 's/^nsslapd-localuser: .*$/nsslapd-localuser: ds\nnsslapd-maxdescriptors: 16384\nnsslapd-reservedescriptors: 8192/' /etc/dirsrv/slapd-$DSUID/dse.ldif sed -i 's/^#* *ulimit -n.*$/ulimit -n 16384/' /etc/sysconfig/dirsrv (nota: i parametri nsslapd-maxdescriptors e nsslapd-reservedescriptors non sono rportati per default nel file dse.ldif perche' utilizzati i valori di default). Eliminare il limite di entry nelle ricerche sed -i 's/^nsslapd-sizelimit: .*$/nsslapd-sizelimit: -1/' /etc/dirsrv/slapd-$DSUID/dse.ldif sed -i 's/^nsslapd-lookthroughlimit: .*$/nsslapd-lookthroughlimit: -1/' /etc/dirsrv/slapd-$DSUID/dse.ldif Definire la quantità di RAM che viene assegnata alle cache (vedi nota tra le FAQ a fine pagina) sed -i 's/^nsslapd-cache-autosize: .*$/nsslapd-cache-autosize: 30/' /etc/dirsrv/slapd-$DSUID/dse.ldif Far ripartire 389ds e verificare lo stato del servizio systemctl start dirsrv.target ; systemctl status dirsrv@$DSUID.service Controllare che il limite "Max open files" sia effettivo: cat /proc/`pidof ns-slapd`/limits ===== Modifica dello schema ===== Fermare 389ds e verificare lo stato del servizio systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service === Schema per supporto autofs e nis === Attivare lo schema rfc2307bis ([[https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Schema_Reference/Directory_Server_Object_Class_Reference.html]]) rm -f /usr/share/dirsrv/schema/10rfc2307.ldif cp -p /usr/share/dirsrv/data/10rfc2307bis.ldif /usr/share/dirsrv/schema/ Disabilitare la definizione della ObjectClass nisMap (OID 1.3.6.1.1.1.2.13) dallo schema rfc2307 (in quanto è incompatibile con quella dello schema rfc2307bis) sed -i 's/^objectClasses: \(.*1\.3\.6\.1\.1\.1\.2\.13.*$\)/#\1/' /usr/share/dirsrv/schema/10rfc2307.ldif === Estensione schema per INFN-AAI e federazioni === Scaricare gli schema personalizzati INFN-AAI: cd /etc/dirsrv/slapd-$DSUID/schema curl http://wiki.infn.it/_media/cn/ccr/aai/doc/97schac.ldif > 97schac.ldif curl http://wiki.infn.it/_media/cn/ccr/aai/doc/98infn.ldif > 98infn.ldif curl http://wiki.infn.it/_media/cn/ccr/aai/doc/61edumember.ldif > 61edumember.ldif chown ds:ds 98infn.ldif 97schac.ldif 61edumember.ldif chmod 440 98infn.ldif 97schac.ldif 61edumember.ldif Far ripartire 389ds e verificare lo stato del servizio systemctl start dirsrv.target ; systemctl status dirsrv@$DSUID.service ===== Configurazione SSL/TLS per il Directory Server ===== **NOTA**: In coda al documento e' disponibile in alternativa la procedura grafica per la Configurazione SSL/TLS. Fermare il 389DS e verificare lo stato del servizio systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service Impostare la password per il DB dei certificati cd /etc/dirsrv/slapd-$DSUID modutil -dbdir . -changepw "NSS Certificate DB" Creare un il file con la password del DB dei certificati: cd /etc/dirsrv/slapd-$DSUID vi pin.txt Inserire: Internal (Software) Token:PASSWORD Impostare i permessi: chown ds:ds pin.txt chmod 600 pin.txt Far ripartire 389ds e verificare lo stato del servizio systemctl start dirsrv.target ; systemctl status dirsrv@$DSUID.service Convertire il certificato con chiave privata del server in formato pkcs12 in un file temporaneo. **Non impostare una password**. openssl pkcs12 -export -inkey ds_server_key.pem -in ds_server_crt.pem -out /tmp/crt.p12 -nodes -name 'server-cert' Importare il certificato con chiave privata del server nel DB di 389-ds. Verrà richiesto di inserire la password per l'accesso al "NSS Certificate DB" impostata precedentemente. La prima password che viene chiesta è quella del DB di 389-ds, la seconda è invece quella eventualmente impostata nell’export (premere semplicemente invio, se non è stata impostata la password per il p12). cd /etc/dirsrv/slapd-$DSUID pk12util -i /tmp/crt.p12 -d . rm /tmp/crt.p12 E' necessario importare nel DB dei certificati **TUTTI** i certificati delle CA dalle quali ci serviamo. Le istruzioni sono in [[cn:ccr:aai:howto:389ds-certificates|]] Verificare quindi che nel "NSS Certificate DB" ci siano tutti i certificati certutil -d /etc/dirsrv/slapd-$DSUID -L Configurare il client ldap di default di linux (openldap) inserendo la chiave pubblica della CA nella directory /etc/pki/CA/certs/ e creare gli hash link eseguendo: cacertdir_rehash /etc/pki/CA/certs/ Impostare la directory anche nella configurazione del client ldap: echo "TLS_CACERTDIR /etc/pki/CA/certs/" >> /etc/openldap/ldap.conf Far ripartire 389-ds e verificare lo stato del servizio systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service ===== Abilitare l'encryption per il 389-DS ===== Se non già attiva, far partire la console 389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw & Nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open" -> tab Configuration -> Encryption Abilitare le opzioni "Enable SSL for this server" e "Use this Cipher Family: RSA" Assicurarsi che in Certificate ci sia "server-cert", altrimenti uscire e rientrare nella console. Far ripartire 389-ds e verificare lo stato del servizio systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service ===== Configurazione Mapping dei certificati x509 ===== Per consentire l’autenticazione con certificati x509 è necessario configurare un mapping tra i subject dei certificati e le entry del DS. Nel file /etc/dirsrv/slapd-$DSUID/certmap.conf troviamo la possibilità di impostare l’attributo del DS in cui 389-ds troverà il subject x509. Le sole righe non commentate dovranno essere: certmap default default default:CmapLdapAttr infnCertSubjectDN Far ripartire 389-ds e verificare lo stato del servizio systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service ===== Configurazione Kerberos client ===== Installare il client Kerberos sui server LDAP yum -y install krb5-workstation Modificare opportunamente il file di configurazione /etc/krb5.conf, in particolare * nella stanza [libdefaults] * e' consigliato fare sempre riferimento al DNS * per compatibilita' con il pregresso e' necessario abilitare la crittografia debole: dns_lookup_realm = true dns_lookup_kdc = true allow_weak_crypto = true * è inoltre necessario specificare il REALM di default che deve essere INFN.IT nel caso in cui la struttura NON abbia un REALM Kerberos locale. default_realm = INFN.IT * Ovviamente, nel caso di server LDAP installato in una sede con REALM Kerberos locale, deve essere indicato tale REALM e, per permettere l'autenticazione nativa Kerberos via GSSAPI, deve essere configurata la cross-authentication (mandare una e-mail ad **afs-admin lists.infn.it** ) default_realm = LE.INFN.IT * nella stanza [realms] specificare le informazioni relativi al realm di default; nel caso del realm INFN.IT le informazioni da riportare sono le seguenti: [realms] INFN.IT = { kdc = afs2.infn.it:88 kdc = afs1.infn.it:88 kdc = afs3.infn.it:88 kdc = k5.infn.it:88 kpasswd_server = k5.infn.it admin_server = k5.infn.it:749 default_domain = infn.it } * nella stanza [domain_realm], per consentire la cross-autenticazione tra i realm INFN, indicare nell'ordine di seguito riportato almeno i seguenti: [domain_realm] .infn.it = INFN.IT infn.it = INFN.IT .le.infn.it = LE.INFN.IT le.infn.it = LE.INFN.IT .lnf.infn.it = LNF.INFN.IT lnf.infn.it = LNF.INFN.IT .pi.infn.it = PI.INFN.IT pi.infn.it = PI.INFN.IT .lngs.infn.it = LNGS.INFN.IT lngs.infn.it = LNGS.INFN.IT .mi.infn.it = MI.INFN.IT mi.infn.it = MI.INFN.IT .mib.infn.it = MI.INFN.IT mib.infn.it = MI.INFN.IT ===== Configurazione SASL / GSSAPI ===== Installare il pacchetto che permette l'autenticazione gssapi con 389ds: yum install cyrus-sasl-gssapi.x86_64 Generare il krb5 keytab di servizio (via warc o con modalita' locali) e copiarlo in /etc/dirsrv/$DSUID.keytab Assicurarsi che solo l’utente ds possa accedervi: chown ds /etc/dirsrv/$DSUID.keytab chmod 400 /etc/dirsrv/$DSUID.keytab Aggiungere al file /etc/sysconfig/dirsrv il path al keytab: echo "KRB5_KTNAME=/etc/dirsrv/$DSUID.keytab" >> /etc/sysconfig/dirsrv Nella Management Console definire i SASL Mapping: * Nel primo tab "Servers and Applications" espandere l’albero di sinistra e cliccare con il tasto destro su "Directory Server" * Si aprirà la Management Console * Cliccare sul tab "Configuration" * Cliccare sul nome del server a sinistra e a destra scegliere il tab "SASL Mapping" * Selezionare e cancellare (tasto Delete) le regole esistenti. **Fermare** 389ds e verificare lo stato del servizio systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service Aggiungere le seguenti righe al file ''/etc/dirsrv/slapd-$DSUID/dse.ldif'', **sostituendo tutte le occorrenze di DEFAULT.REALM** con il realm di default indicato nel file /etc/krb5.conf (grep default_realm /etc/krb5.conf). dn: cn=20-krb5_people_default_realm,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: 20-krb5_people_default_realm nsSaslMapRegexString: ^[^@]+$ nsSaslMapBaseDNTemplate: ou=people, dc=infn, dc=it nsSaslMapFilterTemplate: (infnKerberosPrincipal=&@DEFAULT.REALM) dn: cn=20-krb5_people_other_realm,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: 20-krb5_people_other_realm nsSaslMapRegexString: ^.+@.+$ nsSaslMapBaseDNTemplate: ou=people, dc=infn, dc=it nsSaslMapFilterTemplate: (infnKerberosPrincipal=&) dn: cn=30-krb5_services_default,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: 30-krb5_services_default_realm nsSaslMapRegexString: ^[^@]+/[^@+]+$ nsSaslMapBaseDNTemplate: ou=services, dc=infn, dc=it nsSaslMapFilterTemplate: (infnKerberosPrincipal=&@DEFAULT.REALM) dn: cn=30-krb5_services_other_realm,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: 30-krb5_services_other_realm nsSaslMapRegexString: ^.+/.+@.+$ nsSaslMapBaseDNTemplate: ou=services, dc=infn, dc=it nsSaslMapFilterTemplate: (infnKerberosPrincipal=&) dn: cn=40-krb5_hosts_default_realm,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: 40-krb5_hosts_default_realm nsSaslMapRegexString: ^host/[^@]+$ nsSaslMapBaseDNTemplate: ou=hosts, dc=infn, dc=it nsSaslMapFilterTemplate: (infnKerberosPrincipal=&@DEFAULT.REALM) dn: cn=40-krb5_hosts_other_realm,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: 40-krb5_hosts_other_realm nsSaslMapRegexString: ^host/.+@.+$ nsSaslMapBaseDNTemplate: ou=hosts, dc=infn, dc=it nsSaslMapFilterTemplate: (infnKerberosPrincipal=&) **Fare attenzione a lasciare una riga vuota alla fine del file** Far ripartire 389-ds e verificare lo stato del servizio systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service ===== Configurazione plugin Kerberos Password back-end ===== Per compilare e configurare il plugin Kerberos5 per 389-ds eseguire le seguenti operazioni: Installare il compilatore, i sorgenti di Kerberos e di openldap: yum install gcc krb5-devel 389-ds-base-devel libss-devel git * Ottenere il codice sorgente git clone https://baltig.infn.it/dmaselli/389ds-krb5-plugin.git * Compilare ed installare 22/2/2018: Rilevato e risolto problema di compilazione.
In attesa che la modifica sia riportata nel pacchetto disponibile su //baltig// e' necessario aggiungere -DHAVE_INTTYPES_H alla stringa di definizione degli CFLAGS nel Makefile, che dovra' quindi essere la seguente: CFLAGS = -Wall -fPIC $(INCLUDE_FLAGS) -ggdb -DKRB5PLUGIN -D_REENTRANT -DHAVE_INTTYPES_H Compilato con questi CFLAGS ed installato, funziona regolarmente. cd 389ds-krb5-plugin make clean make make install ===== INFN-AAI ===== Pe poter ricevere la replica del ramo nazionale DC=INFN,DC=IT e del ramo locale DC=,DC=INFN,DC=IT dai master di INFN-AAI è necessario inviare al supporto di INFN-AAI un mail contenente * il FQDN del vostro nuovo server LDAP * la password dell'utente CN="Directory Manager" che sarà utilizzata per la configurazione delle repliche. Una volta configurate, le repliche saranno effettuate con autenticazione via Certificato X.509 e quindi a configurazione effettuata potrete modificare la password di CN="Directory Manager" ([[http://directory.fedoraproject.org/wiki/Howto:ResetDirMgrPassword| wiki del 389-ds]]). ===== FAQ ===== ==== "BRASARE" 389-ds ==== cd ~ yum remove "389*" rm -rf /etc/dirsrv /var/lib/dirsrv /var/log/dirsrv /usr/lib64/dirsrv /usr/share/dirsrv /var/lock/dirsrv ==== Modificare la password di CN="Directory Manager" ==== Istruzioni disponibili nel [[http://directory.fedoraproject.org/wiki/Howto:ResetDirMgrPassword| wiki del 389-ds]] ==== ERRORE "attrcrypt_unwrap_key" ==== attrcrypt_unwrap_key: failed to unwrap key for cipher AES: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/ssl-and-attr-encryption.html ==== Verificare che il keytab sia quello corretto ==== kinit -k -t /etc/dirsrv/dsm1.keytab ldap/dsm1.infn.it@INFN.IT klist ==== Tuning RAM da assegnare alla Cache ==== Il 389 Directory Server può valutare le dimensioni della cache ottimizzandole rispetto alle risorse hardware. A partire dalla versione 10.1.1 di RedHat Enterprise Directory Server (che corrisponde alla versione 1.3.? di 389DS) tale funzionalità è abilitata per default. Come si può leggere nella [[https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/memoryusage#DB_and_entry_cache_RAM_usage|Documentazione RedHat]] originale, i due attributi che regolano la quantità di RAM che viene assegnata alle cache sono: * nsslapd-cache-autosize * nsslapd-cache-autosize-split ed i loro valori di default, definiti all'interno della entry, cn=config,cn=ldbm database,cn=plugins,cn=config sono: nsslapd-cache-autosize: 10 nsslapd-cache-autosize-split: 40 Il primo indica la percentuale di RAM libera (libera in fase di startup del 389DS) da dedicare alle cache (database-cache ed entry-cache) mentre il secondo indica la percentuale di cache da dedicare al database-cache (il complemento a 100 sarà assegnato all'entry-cache). Date le dimensioni dell'info-db, su un server con 4GB di RAM, il valore di default di nsslapd-cache-autosize risulta essere basso. Su un server che sia solo server LDAP si può tranquillamente dedicare il 30% della RAM alle cache, quindi: systemctl stop dirsrv.target sed -i 's/^nsslapd-cache-autosize: .*$/nsslapd-cache-autosize: 30/' /etc/dirsrv/slapd-$DSUID/dse.ldif systemctl start dirsrv.target systemctl status dirsrv@$DSUID.service -l e nel log si può vedere se questa assegnazione di RAM è sufficiente: ...omissis... - NOTICE - ldbm_back_start - found 3882016k physical memory ...omissis... - NOTICE - ldbm_back_start - found 3399568k available ...omissis... - NOTICE - ldbm_back_start - cache autosizing: db cache: 465841k ...omissis... - NOTICE - ldbm_back_start - cache autosizing: NetscapeRoot entry cache (2 total): 393216k ...omissis... - NOTICE - ldbm_back_start - cache autosizing: infn-db entry cache (2 total): 393216k ...omissis... - NOTICE - ldbm_back_start - total cache size: 1207895588 B; ...omissis... - INFO - dblayer_start - Resizing db cache size: 127205900 -> 381617700 ...omissis... - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests ...omissis... - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests Nel caso in cui l'assegnazione di RAM non bastasse, troverete una linea del tipo ...omissis... - NOTICE - ldbm_back_start - infn-db: entry cache size 134217728 B is less than db size 153378816 B; We recommend to increase the entry cache size nsslapd-cachememsize. ==== Configurazione SSL/TLS per il Directory Server - Procedura grafica ==== Documentazione originale in [[https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10.1/html/Administration_Guide/managing-certs.html#Managing_SSL-Obtaining_and_Installing_Server_Certificates|Documentazione RedHat]] E' necessario installare il certificato per il 389-DS e quello della CA che lo ha firmato, nel DB dei certificati. Far partire la console 389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw & Nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open" Andare in Console -> tab "Tasks" -> Manager Certificates {{:cn:ccr:aai:howto:set_security_device_password.png?200 |Set Security Device Password}} La prima volta che viene attivato questo task, viene richiesto di inserire la password per la protezione del DB dei certificati. Impostare la password, che dovrà poi essere inserita in un file che il 389-DS legge alla partenza. Tramite il tasto "Request..." completare la procedura di richiesta di certificato, definendo il subject ed il tipo di encryption {{:cn:ccr:aai:howto:certificate_request_wizard_1.png?200|}} {{:cn:ccr:aai:howto:certificate_request_wizard_2a.png?200|}} {{:cn:ccr:aai:howto:certificate_request_wizard_2b.png?200|}} {{:cn:ccr:aai:howto:certificate_request_wizard_3.png?200|}} {{:cn:ccr:aai:howto:certificate_request_wizard_4.png?200|}} {{:cn:ccr:aai:howto:certificate_request_wizard_5.png?200|}} Inviare la richiesta di certificato alla propria CA ed installare il certificato firmato {{:cn:ccr:aai:howto:certificate_install_wizard_4.png?200 |}} {{ :cn:ccr:aai:howto:certificate_install_wizard_2.png?200 |}} {{ :cn:ccr:aai:howto:certificate_install_wizard_3.png?200|}} {{:cn:ccr:aai:howto:certificate_install_wizard_4.png?200|}} Installare il certificato della CA che ha firmato il certificato del 389-DS 389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw & Nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open" Andare in Console -> tab Tasks -> Manager Certificates -> tab CA Certs Tramite il tasto "Install" installare il certificato della CA che ha rilasciato il certificato server, di tutta la chain e delle CA che si vuole autorizzare. ==== "BRASARE" 389-ds ==== cd ~ yum remove "389*" rm -rf /etc/dirsrv /var/lib/dirsrv /var/log/dirsrv /usr/lib64/dirsrv /usr/share/dirsrv /var/lock/dirsrv /etc/sysconfig/dirsrv* /etc/tmpfiles.d/dirsrv*