Panoramica di Microsoft Active Directory gestito in Cloud SQL

Puoi integrare Cloud SQL per SQL Server con Managed Service for Microsoft Active Directory (noto anche come Microsoft Active Directory gestito).

Questa pagina contiene informazioni da rivedere prima di avviare un'integrazione. Dopo aver esaminato le informazioni riportate di seguito, incluse le limitazioni, consulta la sezione Utilizzare Cloud SQL con Microsoft Active Directory gestito.

Vantaggi dell'integrazione con Microsoft AD gestito

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

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

Prerequisiti per l'integrazione

Puoi eseguire l'integrazione con Microsoft Active Directory gestito, aggiungendo il supporto per Windows Authentication a un'istanza. Prima di eseguire l'integrazione, tuttavia, sono necessari i seguenti requisiti per il progetto Google Cloud:

Crea e configura un account di servizio

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

Se utilizzi Google Cloud Console, 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 il comando seguente:

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

Questo 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 autorizzazioni esistenti. Per le autorizzazioni richieste, consulta Autorizzazioni obbligatorie.

Per concedere l'autorizzazione necessaria per l'integrazione, esegui questo comando:

gcloud projects add-iam-policy-binding [PROJECT] \
--member=serviceAccount:service-[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 Active Directory gestito

Quando pianifichi un'integrazione, controlla quanto segue:

La presenza di un'istanza SQL Server e di un'istanza AD gestita nella stessa area geografica offre i valori di latenza di rete più bassi e le prestazioni migliori. Pertanto, quando possibile, configura un'istanza SQL Server e un'istanza AD nella stessa area geografica. Inoltre, indipendentemente dal fatto che vengano configurati o meno nella stessa area geografica, configura un'area geografica principale e una di backup per una maggiore disponibilità.

Topologie per l'integrazione con Microsoft Active Directory gestito

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

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

Se erano supportati gruppi locali di domini, gli account utente individuali e i gruppi globali e universali potrebbero essere aggiunti come secondari di un gruppo locale del dominio (che protegge l'accesso a SQL Server). In questo modo, puoi aggiungere un gruppo locale del dominio come accesso di SQL Server. In Cloud SQL per SQL Server, puoi abilitare funzionalità simili, 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 più gruppi globali, puoi aggiungere tutti gli account utente individuali, e i gruppi globali e universali, direttamente come accessi a SQL Server. Per un esempio dell'opzione 1, vedi il seguente diagramma:

Topologia di Active Directory, 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 e i gruppi globali e universali come secondari di tale gruppo universale definito, nonché aggiungere il gruppo universale definito come accesso a SQL Server. Ad esempio, vedi l'opzione 2 nel seguente diagramma:

Topologia di Active Directory, opzione 2.

Limitazioni e alternative

Quando si integra con Microsoft AD gestito, si applicano le seguenti limitazioni:

  • I gruppi locali del dominio non sono supportati, ma puoi aggiungere gruppi globali o singoli accessi utente 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 Google Cloud Console viene assegnato il ruolo CustomerDbRootRole, che include i seguenti ruoli di database fissi dell'agente SQL Server: SQLAgentUserRole, SQLAgentReaderRole e SQLAgentOperatorRole. Tuttavia, non è possibile concedere questi ruoli agli utenti creati direttamente tramite SQL Server, ad esempio gli utenti gestiti di Microsoft AD, né utilizzare l'agente SQL Server perché il database MSDB in cui devono essere concessi è protetto.
  • Alcune operazioni limitate possono causare il seguente errore: "Impossibile ottenere informazioni sul gruppo o l'utente di Windows NT". Un esempio di questo tipo di operazione soggetta a restrizioni è la creazione di accessi da parte di utenti provenienti da domini collegati tramite una relazione di attendibilità. Un altro esempio è concedere privilegi agli utenti di domini collegati tramite una relazione di attendibilità. In questi casi, ripetere l'operazione spesso ha esito positivo. Se non riesci a riprovare, chiudi la connessione e aprine una nuova.
  • Nomi di dominio completi (FQDN) non sono supportati da SQL Server su Windows. Pertanto, quando crei gli accessi a SQL Server, utilizza nomi di dominio (nomi brevi) anziché FQDN. Ad esempio, se il nome di dominio è ad.mydomain.com, crea gli accessi a SQL Server per ad\user anziché per ad.mydomain.com\user.
  • Per accedere alle istanze SQL Server, utilizza sempre FQDN. Ad esempio, puoi utilizzare un nome di dominio completo simile a private.myinstance.us-central1.myproject.cloudsql.mydomain.com. I nomi Netbios non sono supportati, né i nomi brevi se i suffissi DNS vengono omessi.
  • Gli accessi a SQL Server basati su utenti e gruppi di Active Directory non possono essere gestiti da Google Cloud Console.
  • In Cloud SQL, se un'istanza di SQL Server è stata creata il 12 marzo 2021 o in una data precedente, non può essere integrata con Microsoft AD gestito.
  • L'autenticazione di Windows non funziona con un trust esterno. L'errore potrebbe essere il seguente: "Il nome dell'entità target non è corretto. Impossibile generare contesto SSPI." Inoltre, per i consigli di Microsoft, utilizza un trust forestale anziché 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 Active Directory gestito:

  • Raggruppare i gruppi locali.
  • Eliminazione degli accessi a SQL Server dagli utenti ai domini che vengono collegati tramite una relazione di attendibilità. Puoi eseguire questa operazione con un utente dal tuo dominio gestito o tramite l'accesso sqlserver.
  • Autenticazione NTLM.
  • Accedi con un indirizzo IP di domini collegati tramite una relazione di attendibilità.
  • Istanze con nomi lunghi (più di 63 caratteri).

Passaggi successivi