Informazioni sull'autenticazione Active Directory per SQL Server in Linux e contenitori

  • Articolo

Si applica a: SQL Server - Linux

Questo articolo fornisce informazioni dettagliate sul funzionamento dell'autenticazione Active Directory per istanze di SQL Server distribuite in Linux o in contenitori.

Concetti

Lightweight Directory Access Protocol (LDAP)

LDAP è un protocollo di applicazione da usare con vari servizi directory, tra cui Active Directory. I servizi directory archiviano le informazioni sull'utente e sull'account e le informazioni di sicurezza, ad esempio le password. Tali informazioni vengono crittografate e quindi condivise con altri dispositivi nella rete.

Per altre informazioni sulla protezione di LDAP, vedere Come abilitare l'accesso LDAP in Windows Server.

Kerberos

Kerberos è un protocollo di autenticazione usato per verificare l'identità di un utente o di un host. È possibile considerarlo uno strumento per verificare client e server.

Quando si lavora in un ambiente eterogeneo (misto) in cui sono presenti server e client Windows e non Windows, esistono due tipi di file che è necessario usare con i servizi directory basati su Active Directory:

  • File keytab (abbreviazione di "tabelle chiave")
  • File di configurazione Kerberos (krb5.conf o krb5.ini)

Cos'è un file keytab?

I processi del server nei sistemi Linux o Unix non possono essere configurati per eseguire processi con un account del servizio Windows. Quando si desidera che un sistema Linux o Unix acceda automaticamente ad Active Directory all'avvio, è necessario usare un file keytab.

Con keytab si intende un file di crittografia contenente una rappresentazione di un servizio protetto da Kerberos e la relativa chiave a lungo termine per il nome dell'entità servizio associata nel Centro distribuzione chiavi (KDC). La chiave non è la password.

I file keytab consentono di:

  • autenticare il servizio stesso in un altro servizio in rete oppure
  • decrittografare il ticket di servizio Kerberos di un utente della directory in ingresso al servizio.

Cos'è un file krb5.conf?

Il file /etc/krb5.conf (denominato anche krb5.ini) fornisce input di configurazione per le librerie Kerberos v5 (KRB5) e GNU Simple Authentication and Security Layer API (GSSAPI).

Queste informazioni includono il dominio predefinito, le proprietà di ogni dominio (ad esempio i centri di distribuzione delle chiavi) e la durata predefinita dei ticket Kerberos.

Questo file è necessario per il funzionamento dell'autenticazione Active Directory. krb5.conf è un file INI, ma ogni valore nella coppia chiave-valore può essere un sottogruppo racchiuso tra { e }.

Per altre informazioni sul file krb5.conf, vedere la documentazione del consorzio MIT Kerberos.

Configurare Kerberos per SQL Server in Linux

Questi sono i valori necessari nel server host che esegue SQL Server in Linux. Se si dispone di altri servizi (non SQL Server) in esecuzione nello stesso host, il file krb5.conf potrebbe richiedere più voci.

Ecco un file krb5.conf di esempio per riferimento:

[libdefaults]
default_realm = CONTOSO.COM

[realms]
CONTOSO.COM = {
  kdc = adVM.contoso.com
  admin_server = adVM.contoso.com
  default_domain = contoso.com
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM

  • libdefaults - il valore default_realm deve essere presente. Tale valore specifica il dominio a cui appartiene il computer host.

  • realms (facoltativo) - Per ogni area autenticazione, il valore kdc può essere impostato per specificare i centri di distribuzione delle chiavi che il computer deve contattare durante la ricerca di account Active Directory. Se sono stati impostati più centri di distribuzioni chiavi, il centro per ogni connessione verrà selezionato tramite round robin.

  • domain_realm (facoltativo) - È possibile specificare mapping per ogni area di autenticazione. In caso contrario, SQL Server in Linux presuppone che il dominio contoso.com sia mappato all'area autenticazione CONTOSO.COM.

Processo di autenticazione Kerberos

Come per l'autenticazione Kerberos in Windows, i primi due passaggi per ottenere un ticket-granting ticket (TGT) sono gli stessi:

  • Un client avvia il processo di accesso inviando il nome utente e la password (crittografati) al controller di dominio.

  • Dopo aver controllato il nome utente e la password nello spazio di archiviazione interno, il controller di dominio restituisce un TGT per l'utente al client.

SQL Server in Linux usa il file keytab per leggere la password per il nome dell'entità servizio (SPN) e quindi decrittografa il BLOB crittografato, che usa per autorizzare la connessione. I passaggi successivi descrivono questo processo.

  • Dopo che l'utente riceve il TGT, il client avvia una connessione a SQL Server specificando il nome host e la porta dell'istanza di SQL Server.

  • Il client SQL crea internamente un nome dell'entità servizio nel formato MSSQLSvc/<host>:<port>. Si tratta di un formato hardcoded nella maggior parte dei client SQL Server.

  • Il client avvia l'handshake Kerberos richiedendo una chiave di sessione dal controller di dominio per il nome SPN specifico. Sia il TGT che il nome SPN vengono inviati al controller di dominio.

Diagramma che mostra l’autenticazione Active Directory per SQL Server in Linux - Ticket-granting ticket e nome dell'entità servizio inviati al controller di dominio.

  • Dopo che il controller di dominio convalida il TGT e il nome SPN, invia la chiave di sessione al client per la connessione al nome dell'entità servizio di SQL Server.

Diagramma che mostra l’autenticazione Active Directory per SQL Server in Linux - chiave di sessione restituita dal controller di dominio.

  • Il BLOB crittografato dalla chiave di sessione viene inviato al server.

Diagramma che mostra l’autenticazione Active Directory per SQL Server in Linux - chiave di sessione inviata al server.

  • SQL Server legge la password per il nome dell'entità servizio dal relativo keytab (mssql.keytab), ovvero un file su disco contenente tuple crittografate (SPN, password).

  • SQL Server decrittografa il BLOB crittografato dal client con la password cercata per ottenere il nome utente del client.

  • SQL Server cerca il client nella tabella sys.syslogins per verificare se il client è autorizzato a connettersi.

  • La connessione viene accettata o negata.

Diagramma che mostra l’autenticazione Active Directory per SQL Server in Linux - connessione accettata o negata.

Configurare Kerberos per i contenitori di SQL Server

L'autenticazione Active Directory per SQL Server nei contenitori è essenzialmente uguale a quella per SQL Server in Linux. L'unica differenza è il nome dell'entità servizio dell'host SQL Server. Nello scenario precedente, il nome dell'entità servizio era MSSQLSvc/<host>:<port>a causa della connessione tramite il nome dell'host SQL Server. Ora, tuttavia, è necessario connettersi al contenitore.

Per i contenitori SQL è possibile creare il file krb5.conf all'interno del contenitore. Il nodo host che esegue il contenitore non deve far parte del dominio, ma deve essere in grado di raggiungere il controller di dominio a cui il contenitore tenterà di connettersi.

Poiché ci si connette a un contenitore, il nome del server nella connessione client potrebbe essere diverso dal nome host. Può trattarsi del nome host, del nome del contenitore o di un altro alias. È anche possibile che la porta esposta per SQL Server non sia 1433, ovvero quella predefinita.

È necessario usare il nome dell'entità servizio archiviato in mssql.keytab per connettersi al contenitore SQL Server. Se ad esempio il nome dell'entità servizio in mssql.keytab è MSSQLSvc/sqlcontainer.domain.com:8000, si usa sqlcontainer.domain.com,8000 come stringa di connessione nel client (inclusi sqlcmd, SQL Server Management Studio e Azure Data Studio).

Diagramma che mostra l’autenticazione Active Directory per contenitori SQL Server.

Aggiornamento del gruppo SQL Server

Ci si può chiedere perché nel file keytab sia presente un account utente se per l'autenticazione è necessario solo un nome dell'entità servizio.

Si supponga che sia presente un utente adUser, membro di un gruppo adGroup. Se adGroup viene aggiunto come account di accesso a SQL Server, anche adUser ha l'autorizzazione per accedere all'istanza di SQL Server. Mentre adUser è ancora connesso a SQL Server, un amministratore di dominio potrebbe rimuovere adUser dal gruppo adGroup. Ora adUser non deve più disporre dell'autorizzazione per accedere a SQL Server, ma ha già superato il processo di autenticazione Kerberos ed è connesso.

Viene eseguito periodicamente un processo denominato aggiornamento del gruppo per proteggersi da uno scenario in cui un utente connesso non può più eseguire un'azione con privilegi, ad esempio la creazione di un account di accesso o la modifica di un database.

A SQL Server è associato un account Active Directory con privilegi usato per l'aggiornamento del gruppo. Questo account viene configurato tramite mssql-conf con l'impostazione network.privilegedadaccount oppure con l'impostazione predefinita sull'account del computer host (<hostname>$).

Le credenziali per l'account con privilegi in mssql.keytab vengono usate per rappresentare il client (adUser in questo esempio). SQL Server esegue un handshake Kerberos con se stesso per identificare le informazioni sull'appartenenza al gruppo e lo confronta con sys.syslogins per verificare se adUser dispone ancora delle autorizzazioni necessarie per connettersi ed eseguire i comandi Transact-SQL richiesti. Se adUser è stato rimosso dal gruppo adGroup, la connessione viene terminata da SQL Server.

L'aggiornamento del gruppo richiede le due condizioni seguenti:

  • Connettività di rete tra l'istanza di SQL Server e il dominio Active Directory locale.
  • Trust bidirezionale tra il dominio a cui è connesso SQL Server e il dominio Active Directory locale. Per altre informazioni, vedi Conoscenza di Active Directory.

Contenuto correlato