Eventi
Ottieni gratuitamente la certificazione in Microsoft Fabric.
19 nov, 23 - 10 dic, 23
Per un periodo di tempo limitato, il team della community di Microsoft Fabric offre buoni per esami DP-600 gratuiti.
Prepara oraQuesto browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
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.
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 è 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:
krb5.conf
o krb5.ini
)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:
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.
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
.
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.
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.
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).
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:
Eventi
Ottieni gratuitamente la certificazione in Microsoft Fabric.
19 nov, 23 - 10 dic, 23
Per un periodo di tempo limitato, il team della community di Microsoft Fabric offre buoni per esami DP-600 gratuiti.
Prepara ora