Panoramica di Active Directory gestito dal cliente (CMAD)

Questa pagina contiene informazioni da esaminare prima di iniziare un'integrazione. Dopo aver esaminato le seguenti informazioni, incluse le limitazioni, consulta Utilizzare Active Directory gestito dal cliente.

Puoi integrare Cloud SQL per SQL Server con Microsoft Active Directory gestito dal cliente (noto anche come CMAD).

Autenticazione, autorizzazione e altro ancora sono disponibili tramite CMAD. Ad esempio, l'aggiunta di un'istanza a un dominio CMAD 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 ha l'ulteriore vantaggio dell' Google Cloud integrazione con i tuoi domini AD on-premise.

Prima di iniziare

Puoi eseguire l'integrazione con CMAD, aggiungendo il supporto per l'autenticazione Windows a un'istanza. Tuttavia, prima dell'integrazione, per il tuo progettoGoogle Cloud sono necessari i seguenti elementi:

  • Affinché l'autenticazione funzioni, le tue istanze Cloud SQL devono avere la connettività di rete a tutti i domini Active Directory pertinenti. Sono inclusi il dominio principale a cui si unisce l'istanza, nonché tutti i domini attendibili o secondari contenenti utenti che devono accedere a Cloud SQL per SQL Server. Per abilitare questa funzionalità, assicurati che le seguenti porte (TCP e UDP) siano aperte tra le istanze Cloud SQL e tutti i controller di dominio: 53, 88, 135, 389, 445, 464, 3268, 3269 e da 49152 a 65535.
  • Devi creare un'unità organizzativa (UO) per archiviare tutti gli oggetti di integrazione correlati.
    • All'interno di questa UO, devi anche delegare le seguenti autorizzazioni all'account amministratore. Nella procedura guidata Delega controllo di Active Directory, seleziona:
      • Crea oggetti Computer
      • Eliminare gli oggetti Computer
      • Creare oggetti Utente
      • Eliminare gli oggetti Utente
      • Scrivi tutte le proprietà
      • Leggi e scrivi le norme relative alla password e al blocco del dominio (che includono Reimposta password e Leggi tempo di blocco, scrivi tempo di blocco)

      Lo screenshot seguente mostra un esempio del riepilogo delle autorizzazioni nella procedura guidata Delega controllo di Active Directory (mostrata su Windows Server 2025):

      Riepilogo delle autorizzazioni della procedura guidata Delega controllo di Active Directory

    • Ti consigliamo inoltre di concedere a questo account amministratore le autorizzazioni per gestire i record DNS, ad esempio aggiungendolo al gruppo DnsAdmins.

      Se non concedi queste autorizzazioni, l'integrazione andrà comunque a buon fine. Tuttavia, la connessione all'istanza richiede la creazione manuale dei record DNS necessari, come descritto in Connettersi a un'istanza con un utente.

      L'alternativa è connettersi utilizzando l'indirizzo IP dell'istanza, che presenta limitazioni e non funziona per le connessioni da domini attendibili.

  • Devi archiviare le credenziali di amministratore in un secret Secret Manager utilizzando il seguente formato JSON: 
        {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }

    Sostituisci quanto segue:

    • VALID_AFTER_UTC_VALUE_1: il primo valore UTC che vuoi utilizzare, fornito nel formato YYYY-MM-DDThh:mm:ssZ. Un esempio potrebbe essere 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: il primo accesso amministratore che vuoi utilizzare, ad esempio myadmin. Non includere il nome di dominio nel valore. Le voci simili a myadmin@my-domain-name.com non sono supportate.
    • ADMINISTRATOR_PASSWORD_VALUE_1: la password dell'amministratore.
    • VALID_AFTER_UTC_VALUE_2: il secondo valore UTC che vuoi utilizzare, fornito nel formato YYYY-MM-DDThh:mm:ssZ. Un esempio potrebbe essere 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: le credenziali di accesso del secondo amministratore che vuoi utilizzare, ad esempio myadmin2. Allo stesso modo, non includere il nome di dominio nel valore. Le voci simili a myadmin2@my-domain-name.com non sono supportate.
    • ADMINISTRATOR_PASSWORD_VALUE_2: la password del secondo amministratore.

    Questo file può contenere più voci di credenziali per mitigare i problemi di propagazione lenta o per adattarsi a rotazioni pianificate e anticipate.

    Il campo validAfterUTC è facoltativo. Se non viene specificato, si presume che le credenziali siano sempre valide. Ti consigliamo di mantenere queste credenziali disponibili in modo permanente in Secret Manager e di utilizzare l'automazione per aggiornare la password se esegui la rotazione delle credenziali.

    Anche se puoi eliminare il secret dopo la creazione dell'istanza, tieni presente che operazioni future come la clonazione o l'aggiunta di una replica di lettura comporteranno la mancata unione della nuova istanza al dominio.

    Inoltre, l'eliminazione dell'istanza originale lascerà oggetti orfani, come l'account computer, nel tuo CMAD.

  • Disponi di un elenco di indirizzi IP del server DNS per Active Directory gestito dal cliente, che in genere sono i domain controller. Ti consigliamo di utilizzare indirizzi IP statici per questi server.
  • Assegna service account per prodotto e per progetto.

Crea e configura un account di servizio

Per creare un account di servizio con le autorizzazioni richieste, verifica quanto segue:

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

  gcloud beta services identity create --service=sqladmin.googleapis.com 

      --project=PROJECT_ID

Questo comando restituisce un nome account di servizio nel seguente formato:

  service-PROJECT_ID@gcp-sa-cloud-sql.iam.gserviceaccount.com

Ecco un esempio di nome di account di servizio:

  service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

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

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

Quindi, esegui questo comando:

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

Per saperne di più, consulta gcloud beta services identity create.

Best practice per l'integrazione con CMAD

Quando esegui l'integrazione con CMAD, ti consigliamo di completare i seguenti passaggi.

Prerequisiti per l'integrazione

Utilizza lo strumento di diagnostica di Active Directory gestito dal cliente per risolvere i problemi di configurazione di Active Directory con il tuo dominio prima dell'integrazione con Cloud SQL.

Topologie per l'integrazione con CMAD

Cloud SQL per SQL Server non supporta i gruppi locali del dominio. Tuttavia, sono disponibili le seguenti alternative:

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

Cloud SQL per SQL Server non supporta i gruppi locali del dominio come accessi. Per concedere autorizzazioni agli utenti del dominio, devi utilizzare gruppi globali o universali, 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 CMAD, 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. Poi puoi aggiungere tutti i singoli account utente e i gruppi globali e universali come elementi secondari del gruppo universale definito e aggiungere il gruppo universale definito come accesso SQL Server. Come esempio dell'opzione 2, vedi il seguente diagramma:

Topologia CMAD, opzione 2.

Limitazioni e alternative

Quando esegui l'integrazione con CMAD, si applicano le seguenti limitazioni:

  • Le istanze Cloud SQL per SQL Server che utilizzano Private Service Connect (PSC) per la connettività privata non sono supportate. Utilizza invece l'accesso privato ai servizi (PSA).
  • 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 gruppi universali quando tutti i gruppi e gli utenti appartengono alla stessa foresta.
  • Se esistono altri domini attendibili e prevedi di accedere alle istanze SQL Server con nomi utente da questi domini, devono essere connessi tramite un trust bidirezionale. Le relazioni di trust unidirezionali ed esterne non sono supportate.
  • In generale, ai nuovi utenti creati tramite la console Google Cloud viene assegnato il ruoloCustomerDbRootRole, che dispone del ruolo di database fisso SQL Server Agent: SQLAgentUserRole. Tuttavia, agli utenti creati direttamente tramite SQL Server, ad esempio gli utenti CMAD, non può essere concesso questo ruolo né possono utilizzare SQL Server Agent, perché il database MSDB in cui deve essere concesso questo ruolo è protetto.
  • I nomi di dominio completi (FQDN) non sono supportati da SQL Server. Pertanto, utilizza i nomi di dominio (nomi brevi) anziché i nomi di dominio completi quando crei gli accessi a SQL Server. Ad esempio, se il tuo nome di dominio è ad.mydomain.com, crea accessi 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 FQDN simile a private.myinstance.us-central1.myproject.cloudsql.mydomain.com. I nomi NetBIOS non sono supportati, così come i nomi brevi se i suffissi DNS vengono omessi.
  • Gli accessi SQL Server basati su utenti e gruppi Active Directory non possono essere gestiti dalla console Google Cloud .
  • L'autenticazione di Windows non funziona con un trust esterno. L'errore restituito potrebbe essere il seguente: 
      "The target principal name is incorrect. Cannot generate SSPI context."
    Inoltre, in relazione ai consigli di Microsoft, utilizza un trust tra foreste anziché un trust esterno per l'autenticazione Kerberos.
  • Viene sempre utilizzata l'ultima versione del secret. Il secret deve essere attivo e non può essere eliminato.

Endpoint Active Directory e connessioni TLS

Se utilizzi l'autenticazione Windows e vuoi stabilire una connessione TLS senza considerare attendibile il certificato del server, devi ruotare i certificati dopo l'attivazione dell'autenticazione Windows sull'istanza.

Se la connessione non va a buon fine e uno dei tuoi certificati è stato creato prima del 15 marzo 2025, devi ruotare di nuovo il certificato server e riprovare la connessione.

Non supportato per l'integrazione

Le seguenti funzionalità non sono supportate durante l'integrazione con CMAD:

  • Gruppi locali del dominio.
  • Autenticazione NTLM.
  • Accedi con un indirizzo IP di domini connessi tramite una relazione di trust.
  • Istanze con nomi lunghi (più di 63 caratteri).

Monitoraggio

Puoi utilizzare la seguente metrica per monitorare lo stato e l'integrità di CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

Questa metrica indica se è possibile raggiungere CMAD dall'istanza Cloud SQL. È uno strumento utile per risolvere i problemi di rete:

cloudsql.googleapis.com/database/active_directory/instance_available

Passaggi successivi