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

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 vengono usati per:

• autenticare il servizio stesso in un altro servizio in rete oppure
• decrittografare il ticket di servizio Kerberos di un utente di una directory in entrata 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:

ini

[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 ambito, è possibile impostare il valore kdc per specificare i Centri di Distribuzione delle Chiavi (KDC) da contattare quando si cercano account di Active Directory. Se hai impostato più di un centro di distribuzione delle chiavi, il centro per ogni connessione verrà selezionato tramite un sistema a turno.

• domain_realm (facoltativo) - I mapping per ogni ambito possono essere forniti. In caso contrario, SQL Server su Linux presume che il dominio contoso.com corrisponda al realm 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 Service Principal Name (nome principale del 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 (DC) per quel SPN. Sia il TGT che l'SPN vengono inviati al DC.

• Dopo che il controller di dominio convalida il TGT e lo SPN, invia la chiave di sessione al client per connettersi allo SPN di SQL Server.

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

• SQL Server legge la password per il SPN dal suo file keytab (mssql.keytab), che è un file su disco contenente tuple crittografate (SPN, password).

• SQL Server decrittografa il BLOB crittografato dal client utilizzando la password appena trovata, 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.

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 è l'SPN dell'host SQL Server. Nello scenario precedente, l'SPN era MSSQLSvc/<host>:<port> poiché ci stavamo connettendo tramite il nome dell'host del 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. Inoltre, c'è una discreta possibilità che la porta esposta per SQL Server non sia quella predefinita 1433.

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

Aggiornamento del gruppo SQL Server

Ci si potrebbe chiedere perché è presente un account utente nel keytab se è necessario solo un Service Principal Name per l'autenticazione.

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 è configurato o tramite mssql-conf con l'impostazione network.privilegedadaccount, oppure è predefinito sull'account della macchina 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

• Risolvere i problemi di autenticazione di Active Directory per SQL Server in Linux e contenitori
• Ruotare i keytab per SQL Server su Linux
• Esercitazione: Usare adutil per configurare l'autenticazione di Active Directory con SQL Server in Linux