IMPLEMENTAZIONE del PROTOCOLLO LDAPs in Active Directory

All’interno di realtà aziendali complesse, con sistemi eterogenei, può essere abbastanza comune riferirsi ad Active Directory come provider di autenticazione “esterno” per le applicazioni aziendali.

In alcuni casi, questi ambienti possono utilizzare in modo nativo le credenziali con cui un utente ha effettuato il login sulla postazione, ma più frequentemente è richiesto che l’applicazione, a prescindere dalla credenziale fornita per l’accesso al pc, esegua l’autenticazione dell’operatore richiedendo username e password.

Questa modalità operativa è utilizzata principalmente nelle realtà dove una singola postazione è utilizzata da operatori diversi in tempi brevi e con brevi attività di lavoro.

Un esempio è sicuramente una realtà ospedaliera dove un PC è utilizzato quasi continuamente da più operatori e per ognuno di questi deve essere garantita la “tracciabilità” delle operazioni compiute. Questa modalità operativa prevede (per ovvie ragioni di velocità di accesso) che le applicazioni permettano una funzione di “Cambio Operatore” senza essere chiuse.

Inoltre essendo demandata all’ambiente applicativo la gestione delle autenticazioni è utile che possa essere eseguito anche il cambio password all’interno dell’applicazione stessa, così come i vari controlli sulle password policies implementate a livello Aziendale

In uno scenario di questo tipo non è raro trovare applicazioni che utilizzano il protocollo LDAP per le funzioni di autenticazione e gestione delle credenziali utente.

Limitazioni nell’uso del protocollo LDAP

l’articolo How to change a Windows Active Directory and LDS user password through LDAP riporta:

  • The password is stored in the AD and LDS database on a user object in the unicodePwd attribute. This attribute can be written under restricted conditions, but it cannot be read. The attribute can only be modified; it cannot be added on object creation or queried by a search.
  • In order to modify this attribute, the client must have a 128-bit Transport Layer Security (TLS)/Secure Socket Layer (SSL) connection to the server.

È evidente che tramite LADP, che non dispone di una connessione cifrata, non è possibile gestire in modo completo le funzioni di cambio password, risulta quindi necessario ricorrere al protocollo LDAPs

Attivazione del Protocollo LDAPs

Durante la “promozione” di un sistema alle funzioni di Domain Controller viene attivato anche il protocollo LDAP, mentre per poter attivare la connessione cifrata con LDAPs è necessario che venga fornito un certificato che deve contenere l’OID 1.3.6.1.5.5.7.3.1 8 (Server Authentication) come è ampiamente spiegato nel seguente articolo Technet LDAP over SSL (LDAPS) Certificate

  • Certificate must be valid for the purpose of Server Authentication. This means that it must also contains the Server Authentication object identifier (OID): 1.3.6.1.5.5.7.3.1
  • The Subject name or the first name in the Subject Alternative Name (SAN) must match the Fully Qualified Domain Name (FQDN) of the host machine, such as Subject:CN=server1.contoso.com. For more information, see How to add a Subject Alternative Name to a secure LDAP certificate (http://support.microsoft.com/kb/931351).

Ed è anche richiesto che l’account macchina del DC possa accedere alla chiave privata del certificato

  • The host machine account must have access to the private key.

 

 

Installazione di un PKI aziendale

Sul sito ICTPOWER, abbiamo proposto una serie di articoli in cui viene spiegato il modo corretto per installare e configurare una PKI all’interno di un dominio Active Directory.

Di default se un Domain Controller rileva la presenza di una Certification Authority ( Enterprise ) richiede in modo automatico un certificato alla CA ed attiva le comunicazioni cifrate in LDAPs di fatto attivando questo protocollo.

 

Figura 1 Certificato presente nello Store Computer di un DC

Il libro Windows Server 2008 PKI and Certificate Security” di Brian Komar affronta in modo completo le problematiche e gli scenari di attivazione di una CA, in particolare a pagina 671 viene sipegato il comportamento citato in precedenza.

 

 

 

Scelta del posizionamento della CA nel dominio

 

La scelta del dove installare il ruolo e le funzioni della PKI non è di secondo piano, numerosi articoli consultabili nel web ne propongono l’installazione direttamente su un Domain Controller, gli articoli proposti su ICTPower.it delineano uno scenario in cui le funzioni della CA sono installate su server dedicati.

Si riporta di seguito la nota di Brian Komar che propone il medesimo scenario di installazione

Mentre sul Technet l’articolo Public Key Infrastructure Design Guidance argomenta ulteriormente la scelta di server dedicati.

 

Se la scelta di implementazione della CA è basata su due livelli con la CA Root off-line è necessario considerare il fatto che i Domain Controller presenti NON inizieranno a richiedere i certificati in autonomia finché non verrà distribuito il certificato della Root-CA, questo comportamento è spiegato dal fatto che i sistemi conoscono sì la issuing-CA ma non è disponibile il certificato che attesta l’autenticità di quest’ultima.

Per fare si che i DC possano quindi “Dialogare” con questo servizio è necessario creare una GPO che distribuisca il certificato Root, che deve essere scaricato dalla Root-CA.

Figura 2 Export del certificato della Root-CA

A questo punto è sufficiente creare la GPO con cui viene distribuito il certificato della Root-CA, per comodità di configurazione è possibile creare una GPO applicata a livello di Dominio.

Figura 3 Definizione della GPO

Non appena i vari DC ricevono la Group-Policy eseguono la richiesta del proprio certificato alla Issuing-CA

Figura 4 Issuing CA e relativi rilasci per i DC

 

A questo punto per determinare se il Domain Controller ha effettivamente attivato le comunicazioni in LDAPs è sufficiente verificare la connessione tramite il tool LDP.exe

 

Figura 5 connessione LDAPs

La connessione avvenuta riporta le informazioni relative al DC ed ai servizi disponibili

Figura 6 connessione LDAPs

 

 

Il funzionamento a questo punto è anche verificabile attivando e disattivando la GPO creata, se questa viene disattivata, in modo del tutto automatico i DC ritornano ad utilizzare il protocollo LDAP ( che in ogni caso non viene disattivato)

 

Riferimenti

Di seguito il link agli articoli pubblicati su IctPower.it insieme ad Ermanno Goletto relativi ad una architettura PKI a due livelli

 

Annunci