Il daemon Slapd non può essere avviato: TLS init def deftx fallito: -1

Consiglierei creare un altro certificato autofirmato in Server.app che puoi utilizzare per proteggere i servizi (se gli altri erano scaduti / cancellati). Creando il certificato utilizzando Server.app, sarà automaticamente disponibile per altri servizi (come Open Directory).

Dopo aver creato un nuovo certificato autofirmato, segui i passaggi da 6 a 12 in questo articolo (che descrivono come il tuo certificato SSL può essere configurato per l'uso con Open Directory). Esecuzione di Open Directory - > Impostazioni - > LDAP - > La configurazione SSL tramite Server Admin scriverà i percorsi dei certificati corretti nel file di configurazione slapd .

Una volta risolti i problemi relativi ai certificati, Apri Directory ( slapd ) dovrebbe avviarsi normalmente (senza che tu debba avviarlo manualmente). Se il server delle password non viene ancora visualizzato in esecuzione, è possibile provare a riavviare (o verificare se sta generando registri di arresti anomali o altri errori in Console).

Modifica

Dopo aver modificato la configurazione del certificato per l'utilizzo con LDAP, è probabilmente opportuno verificare che la macchina abbia fornito percorsi certificati aggiornati a slapd nel file slapd_macosxserver.conf . Cioè, la stringa univoca di numeri e caratteri nei percorsi chiave / cert dovrebbe essere cambiata.

Per confermare che slapd può accedere alla chiave privata corrispondente per il certificato con cui stai proteggendo i servizi LDAP, puoi controllare il file in /etc/openldap/slapd_macosxserver.conf ... Cerca una riga che menzioni certadmin ... Quella riga specifica il comando che slapd sta usando per recuperare la chiave privata dal Portachiavi. È possibile eseguire tale comando (copia e incolla) nel terminale per vedere se è possibile recuperare la passphrase della chiave privata:

/usr/sbin/certadmin --get-private-key-passphrase /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem

Dopo aver recuperato la passphrase, verifica se puoi visualizzare la chiave privata utilizzando la seguente passphrase:

sudo openssl rsa -in /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem -text -noout

Quando viene richiesta la passphrase, copia e incolla il valore che hai ottenuto nel passaggio precedente. Dovresti vedere l'output dei dati della chiave privata sullo schermo. Ciò confermerebbe che:

1.) La passphrase della chiave privata può essere richiamata dal portachiavi

2.) La passphrase nel portachiavi può essere utilizzata per decrittografare la chiave

Se non riesci a ottenere la passphrase e a sbloccare la chiave, è possibile che slapd non sia in grado di farlo. Credo che il software stia utilizzando un portachiavi nel portachiavi del sistema denominato "Gestione dei certificati del server Mac OS X" con un tipo di "password dell'applicazione". Il "Conto" per quell'elemento portachiavi dovrebbe essere impostato sulla stessa stringa univoca di caratteri e numeri ( 456DACFFC771F8EB2F5A8E0EBB269969B8164097 in questo esempio) che vedi nei percorsi cert / chiave in /etc/certificates . Se non visualizzi una di queste password dell'applicazione corrispondenti nel portachiavi di sistema, potrebbe esserci il tuo problema.

Quanto segue è stato testato su snow-leopard 10.6 e lion 10.7 versioni del sistema operativo quando il server LDAP OpenDirectory non si avvia e il server delle password è ancora in esecuzione.

Se dai un'occhiata alla coda del file sudo tail /etc/openldap/slapd.d/cn=config.ldif vedrai un insieme di voci del certificato TLS simile al blocco sottostante:

olcTLSCertificateFile: /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.cert.pem

olcTLSCACertificateFile: /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.chain.pem

olcTLSCertificateKeyFile: /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.key.pem

olcTLSCertificatePassphraseTool: /usr/sbin/certadmin --get-private-key-passphrase /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.key.pem

entryCSN: 20120628190714.643255Z#000000#001#000000

Se confronti queste voci con i valori mostrati in / etc / certificates, molto probabilmente troverai che il numero magico è diverso per il tuo certificato rispetto al valore mostrato nella directory / etc / certificates per i tuoi certificati.

Se esegui il comando

sudo /usr/libexec/slapd -d 1

vedrai verso la fine della traccia una linea che si avvicina a

TLS: could not load verify locations (file:'/etc/certificates…

Per superare questo problema, rimuovi manualmente le ultime cinque righe dal file /etc/openldap/slapd.d/cn=config.ldif utilizzando l'editor preferito e sudo .

Quindi per riavviare ldap emettere i seguenti comandi

sudo /usr/bin/db_recover -h /var/db/openldap/openldap-data
sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

Tutti dovrebbero quindi essere corretti.