Abilitazione del protocollo LDAPS in Dominio senza PKI Enterprise

Recentemente nell’articolo Implementazione del protocollo LDAPS in Active Directory è stata proposta una soluzione per la gestione di LDAP su protocollo cifrato.

Questa implementazione si basa sulla disponibilità di una CA di tipo Enterprise all’interno di un dominio Active Directory la cui installazione aziendale è stata analizzata nell’articolo Windows Server 2016 Deploy PKI pubblicato su ICTPOWER.

Tuttavia, si possono verificare casi in cui è disponibile una foresta e quindi uno o più domini AD completamente disgiunti dalla struttura in cui è presente la PKI e, in questi domini “secondari”, non è prevista l’installazione di una Certification Autority.

In uno scenario di questo tipo la gestione tramite GPO e l’automazione vista in precedenza non è utilizzabile.

È comunque possibile gestire l’abilitazione del protocollo LDAPS chiedendo ad una PKI installata in un dominio completamente separato i certificati necessari ai Domain Controller per l’abilitazione del protocollo LDAPs

In questo articolo partiamo da uno scenario in cui sono presenti due Domini ictpower.local e contoso.local e nessuno dei due domini ha relazioni di dipendenza o trust. Sono, per essere più chiari, due foreste separate:

  • il dominio ictpower.local ospita l’intera struttura della CA , così come descritto negli articoli menzionati sopra
  • Il dominio contoso.local non ha alcuna CA al suo interno, ma necessita per ragioni di sicurezza, di aver implementato il protocollo LDAPs sui DC
  • I due domini sono completamente a sé stanti, in due foreste distinte, senza trust

I passi da seguire per fare sì che i DC del dominio contoso.local possano utilizzare i certificati della Certification Authority in ictpower.local sono i seguenti

  • Deploy sui DC della foresta contoso.local dei certificati delle root ed Issuing CA
  • Creazione di un template che preveda gli stessi OID del template usato per l’autoenroll, sulla CA di Issuing,
  • Creazione della CSR sul server DC del dominio contoso. local
  • Sottomissione della richiesta e successivo rilascio del certificato, sulla CA di Issuing nel dominio ictpower.local
  • Installazione del certificato sul domain controller dc02.contoso. local
  • Generazione ed export del certificato in formato .pfx

Lo schema della struttura usata per il test è il seguente

Dominio/Foresta AD ictpower.local

DC01 (Domain Controller)

CAROOT (Server Stand-Alone con CA Root stand-alone)

CASUB (Server Domain Member con la CA di Issuing integrata in AD)

WEB01 (Server Domain Member di pubblicazione della CRL)

Dominio/Foresta AD contoso.local

DC02 (Domain Controller)

  1. Deploy sui DC della foresta contoso.local dei certificati delle root root ed Issuing CA della PKI

Per fare sì che il dominio contoso.local possa utilizzare la CA del dominio ictpower.local è necessario esportare il certificato della root CA del dominio ictpower.local e distribuirlo su contoso.local tramite una GPO oppure installarlo sul Domain Controller, è sufficiente distribuire questo certificato, nello store “Trusted Root Certification Authority” in quanto il certificato della Issuing CA viene automaticamente installato nello store “Intermediate Certification Authority” nel momento in cui viene installato il certificato richiesto dal DC

Figura 1: certificato della Issuing CA e store di archiviazione

L’export del certificato della CA Root è possibile tramite la console di gestione della CA oppure per mezzo di certutil.exe con il comando certutil -ca.cert <nome_file.cer>

Figura 2: export del certificato CA Root

2 ) Creazione di un template per il rilascio del certificato

Questo passaggio è necessario, in quanto, come detto sopra, dal Domain controller della foresta contoso.local, non essendo disponibile una CA, bisogna generare una richiesta da sottomettere alla CA in ictpower.local.

Per la creazione del Template sulla Issuing CA di ictpower.local, è sufficiente duplicare il template Domain Controller Authentication

Figura 3: duplicazione del template

Una volta duplicato il template è necessario impostare nel Tab Subject Name la proprietà che specifica se il nome host per cui rilasciare il certificato deve essere reperito da AD o se deve essere specificato nella generazione della richiesta. In questo caso imposteremo il template in modo da inserire questa informazione nella richiesta che genereremo più avanti.

Figura 4: modalità di assegnazione del Subject Name

Terminata questa impostazione si dovrà, nel Tab Compatibility, definire i livelli di compatibilità del certificato relativamente a CA e Sistema Operativo, tale compatibilità dovrà essere coerente con l’ambiente in cui dovrà essere gestito il certificato.

Figura 5: compatibilità

Nel Tab General dovremo identificare il nuovo Template con il nome, che dovrà essere utilizzato in fase di generazione della richiesta sul DC del dominio contoso.local e del periodo di validità dei certificati emessi secondo questo template

Figura 6: definizione del nome

Nell’ultimo passo, ritornati allo snap-in di gestione della CA, dovremo autorizzare quest’ultima all’emissione di certificati secondo il nuovo Template accedendo a Certificate Template\New\Certificate Template to Issue ed abilitando così il nuovo Template.

Figura 7: abilitazione del template

3) Creazione della CSR sul server DC del dominio contoso.local

Il passo successivo prevede che si faccia accesso al domain controller del dominio contoso.local e si generi la Certificate Signing Request da sottomettere alla CA, la CSR dovrà essere generata a partire da un file di configurazione che oltre al nome host dovrà anche indicare alla CA quale template dovrà essere utilizzato per il rilascio del certificato e

Figura 8: compilazione del file .inf

Subject = dc02.contoso.local

È il nome host richiedente il certificato

[RequestAttributes]

CertificateTemplate=”DomainControllerAuthentication-ExternalDomain”

È la dichiarazione che viene inserita per la richiesta secondo il nome del Template

Avendo a disposizione il file .inf è sufficiente tramite il comando certreq.exe generare la richiesta

certreq -new DcCertificateRequest.inf 20181117-dc02.contoso.local.req

non essendo presente il template su DC02 viene proposto il warning

Figura 9: Warning per il template non esistente

E la procedura di generazione completa comunque la richiesta

Figura 10: geneazione della CSR

  1. Sottomissione della richiesta e successivo rilascio del certificato, sulla CA di issuing

A questo punto è necessario copiare il file generato dal comando certreq e copiarlo sulla Issuing CA del dominio ictpower.local da cui con il comando certreq -submit <nome-file>.req viene sottomessa la richiesta alla CA

Figura 11: richiesta alla CA

La quale, per le impostazioni generali del template e di sicurezza proposte qui, rilascerà il certificato per dc01.contoso. local

Figura 12 rilascio del certificato

Dalla Management Console della CA è visibile il certificato emesso che riporta il nome del template definito al punto 2

Figura 13: gestione della CA

  1. Installazione del certificato sul domain controller dc02.contoso.local

L’ultimo passaggio prevede che il certificato venga copiato sul server dc02.contoso.local ed importato nello store macchina del server, questa operazione viene eseguita tramite certlm.msc

Figura 14: importazione certificato nello store macchina

Figura 15: importazione certificato nello store macchina

Figura 16: certificato correttamente installato nello Store

È da notare che il certificato presenta il simbolo della chiave, che significa che è a disposizione la chiave privata, a questo punto è possibile esportare in un pfx l’intero certificato e la chiave in modo da poterlo archiviare o riutilizzare

Ad importazione completata il certificato è installato nello store macchina ed è utilizzato immediatamente dal server per abilitare il protocollo LDAPs, la verifica può essere fatta con l’utility LDP.EXE

Figura 17: Verifica del protocollo LDAPS

  1. Generazione ed export del certificato in formato .pfx

Quest’ultimo passaggio in realtà non è necessario all’attivazione del protocollo LDAPs da parte del DC ma è utile per “Archiviare” il certificato con la sua chiave privata, che è necessaria per un uso di questo tipo, in modo da essere eventualmente riutilizzato in futuro.

Per effettuare l’export è possibile utilizzare certlm.msc oppure tramite powershell effettuare un’operazione di export molto più rapida.

Figura 18: export Pfx con Powershell

L’esportazione proposta con Powershell con l’opzione -ProtectTo permette esclusivamente all’utente indicato per il dominio per cui è stato generato il certificato la sua apertura e riutilizzo

Conclusioni:

La procedura vista qui è indicata in ambienti dove i domain controller non sono molti, in quanto le interazioni manuali hanno una certa rilevanza. Tuttavia deve essere anche considerato il tempo di gestione ed amministrazione di una PKI in relazione al tempo impiegato per l’installazione del certificato su più server.

Come sempre non esiste un’unica possibilità ma l’adozione di una soluzione piuttosto che un’altra deve essere messa in stretta relazione con l’ambiente in cui viene utilizzata.

Elenco dei comandi utilizzati nella procedura e descrizione breve:

certutil -ca.cert <nome_file.cer> # Export del certificato della CA

certreq -new <nome_file.inf> <nome_file.req> # Generazione della Signing Request

certreq -submit <nome-file.req> # Sottomissione della richiesta alla CA di Issuing

certlm.msc # Apertura della MMC direttamente sui certificati Macchina

# Export in formato PFX del Certificato DC

Riferimenti:

Articoli pubblicati si ICTPower riferiti alla gestione delle PKI aziendali

https://www.ictpower.it/?s=pki

Articolo Technet Relativo a Ldaps

https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx