Panoramica di Microsoft AD gestito in Cloud SQL

Puoi integrare Cloud SQL per SQL Server con Managed Service for Microsoft Active Directory (chiamato anche Managed Microsoft AD).

Questa pagina contiene informazioni da esaminare prima di avviare un'integrazione. Dopo aver esaminato le informazioni riportate di seguito, inclusi i limiti, consulta Utilizzo di Cloud SQL con Microsoft AD gestito.

Vantaggi dell'integrazione con Microsoft AD gestito

Autenticazione, autorizzazione e altro ancora sono disponibili tramite Managed Microsoft AD. Ad esempio, l'unione di un'istanza a un dominio Microsoft AD gestito consente di accedere utilizzando l'autenticazione Windows con un'identità basata su AD.

L'integrazione di Cloud SQL per SQL Server con un dominio AD offre il vantaggio aggiuntivo dell'integrazione di Cloud con i domini AD on-premise.

Prerequisiti per l'integrazione

Puoi effettuare l'integrazione con Microsoft AD gestito, aggiungendo il supporto per l'autenticazione Windows a un'istanza. Tuttavia, prima dell'integrazione, per il tuo progetto Google Cloud sono richiesti i seguenti requisiti:

Crea e configura un account di servizio

Devi avere un account di servizio per prodotto e per progetto per ogni progetto che prevedi di integrare con Microsoft AD gestito. Utilizza gcloud o la console per creare l'account a livello di progetto. All'account di servizio per prodotto e per progetto deve essere concesso il ruolo managedidentities.sqlintegrator nel progetto. Per ulteriori informazioni, consulta gcloud projects set-iam-policy.

Se utilizzi la console Google Cloud, Cloud SQL crea automaticamente un account di servizio per te e ti chiede di concedere il ruolo managedidentities.sqlintegrator.

Per creare un account di servizio con gcloud, esegui questo comando:

gcloud beta services identity create --service=sqladmin.googleapis.com \
             --project=[PROJECT]

Il comando restituisce il nome di un account di servizio nel seguente formato:
service-[PROJECT_NUMBER]@gcp-sa-cloud-sql.iam.gserviceaccount.com

Ecco un esempio di nome di un account di servizio:
service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

La concessione dell'autorizzazione necessaria per l'integrazione richiede le autorizzazioni esistenti. Per le autorizzazioni richieste, vedi Autorizzazioni richieste.

Per concedere l'autorizzazione necessaria per l'integrazione, esegui questo comando. Se Microsoft AD gestito si trova in un progetto diverso, [AD_PROJECT_ID] deve essere quello contenente l'istanza Microsoft AD gestita, mentre [SQL_PROJECT_NUMBER] dell'account di servizio deve essere quello contenente l'istanza SQL Server:

gcloud projects add-iam-policy-binding [AD_PROJECT_ID] \
--member=serviceAccount:service-[SQL_PROJECT_NUMBER]@gcp-sa-cloud-sql.iam.gserviceaccount.com \
--role=roles/managedidentities.sqlintegrator

Vedi anche gcloud beta services identity create.

Best practice per l'integrazione con Microsoft AD gestito

Quando pianifichi un'integrazione, esamina quanto segue:

Avere un'istanza SQL Server e un'istanza AD gestita nella stessa regione offre la latenza di rete più bassa e le migliori prestazioni. Pertanto, quando possibile, configura un'istanza SQL Server e un'istanza AD nella stessa regione. Inoltre, a prescindere dal fatto che siano configurate o meno nella stessa regione, configurane una principale e una di backup per una maggiore disponibilità.

Topologie per l'integrazione con Microsoft AD gestito

Cloud SQL per SQL Server non supporta i gruppi locali del dominio. Tuttavia, puoi:

  • Aggiungi gruppi globali o accessi di singoli utenti direttamente in SQL Server
  • Utilizza i gruppi universali quando tutti i gruppi e gli utenti appartengono alla stessa foresta

Se fossero supportati i gruppi locali del dominio, è possibile aggiungere singoli account utente e gruppi globali e universali come elementi secondari di un gruppo locale del dominio (che protegge l'accesso a SQL Server). In questo modo potrai aggiungere un gruppo locale di dominio come accesso a SQL Server. In Cloud SQL per SQL Server, puoi abilitare una funzionalità simile, come descritto in questa sezione.

Opzione 1: aggiungi account utente e gruppi come accessi a SQL Server

Se hai più domini, in più foreste e hai più gruppi globali, puoi aggiungere tutti i singoli account utente e i gruppi globali e universali direttamente come accessi a SQL Server. Come esempio di opzione 1, vedi il seguente diagramma:

Topologia AD, opzione 1.

Opzione 2: definisci un gruppo universale in uno dei tuoi domini

Se i tuoi domini si trovano nella stessa foresta, puoi definire un gruppo universale in uno dei tuoi domini. Quindi puoi aggiungere tutti i singoli account utente, nonché i gruppi globali e universali, come elementi secondari di quel gruppo universale definito e aggiungere il gruppo universale definito come accesso a SQL Server. Come esempio di opzione 2, vedi il seguente diagramma:

Topologia AD, opzione 2.

Limitazioni e alternative

Durante l'integrazione con Microsoft AD gestito si applicano le limitazioni seguenti:

  • I gruppi locali del dominio non sono supportati, ma puoi aggiungere gruppi globali o accessi di singoli utenti direttamente in SQL Server. In alternativa, puoi utilizzare i gruppi universali quando tutti i gruppi e gli utenti appartengono alla stessa foresta.
  • In generale, ai nuovi utenti creati tramite la console Google Cloud viene assegnato il ruolo CustomerDbRootRole, che ha questo ruolo database fisso di SQL Server Agent: SQLAgentUserRole. Tuttavia, agli utenti creati direttamente tramite SQL Server, ad esempio gli utenti di Microsoft AD gestito, non è possibile concedere questo ruolo o utilizzare SQL Server Agent, perché il database MSDB in cui è necessario concedere questo ruolo è protetto.
  • Alcune operazioni limitate potrebbero causare il seguente errore: "Impossibile ottenere informazioni sul gruppo/utente di Windows NT". Un esempio di questo tipo di operazione limitata è la creazione di accessi da parte di utenti da domini collegati tramite una relazione di attendibilità. Un altro esempio è la concessione di privilegi agli utenti dai domini collegati tramite una relazione di attendibilità. In questi casi, spesso ritentare l'operazione ha esito positivo. Se un nuovo tentativo non riesce, chiudi la connessione e aprine una nuova.
  • I nomi di dominio completi non sono supportati da SQL Server su Windows. Di conseguenza, quando crei gli accessi a SQL Server, utilizza nomi di dominio (nomi brevi) anziché nomi di dominio completi. Ad esempio, se il nome di dominio è ad.mydomain.com, crea credenziali di accesso SQL Server per ad\user, anziché per ad.mydomain.com\user.
  • Per accedere alle istanze SQL Server, utilizza sempre i nomi di dominio completi. Ad esempio, potresti utilizzare un nome di dominio completo simile a private.myinstance.us-central1.myproject.cloudsql.mydomain.com. I nomi Netbios non sono supportati né sono supportati i nomi brevi se i suffissi DNS sono omessi.
  • Gli accessi a SQL Server basati su utenti e gruppi di Active Directory non possono essere gestiti dalla console Google Cloud.
  • In Cloud SQL, se un'istanza SQL Server è stata creata il o prima del 12 marzo 2021, non può essere integrata con Microsoft AD gestito.
  • L'autenticazione Windows non funziona con un trust esterno. L'errore potrebbe essere il seguente: "Il nome dell'entità di destinazione non è corretto. Impossibile generare il contesto SSPI." Inoltre, per quanto riguarda i suggerimenti di Microsoft, utilizza un trust forestale invece di un trust esterno per l'autenticazione Kerberos.

Non supportata per l'integrazione

Al momento, le seguenti funzionalità non sono supportate durante l'integrazione con Microsoft AD gestito:

  • Gruppi locali del dominio.
  • Eliminazione degli accessi SQL Server da parte di utenti da domini connessi tramite una relazione di attendibilità. Puoi eseguire questa operazione con un utente dal tuo dominio gestito o tramite l'accesso a sqlserver.
  • Autenticazione NTLM.
  • Accedi con un indirizzo IP da domini collegati attraverso una relazione di attendibilità.
  • Istanze con nomi lunghi (più di 63 caratteri).

Passaggi successivi