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 (denominato anche AD gestito dal cliente (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 Google Cloud progetto sono necessari i seguenti elementi:

  • Affinché l'autenticazione funzioni, le 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 OU, devi anche disporre di un account amministratore con le seguenti autorizzazioni:
      • Crea oggetti computer
      • Eliminare gli oggetti Computer
      • Creare oggetti User
      • Elimina oggetti utente
      • Scrittura di tutte le proprietà
      • Reimposta password
      • Read lockout time, write lockout time
    • 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, per connetterti all'istanza dovrai creare manualmente i 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 di 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. 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 di 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 ulteriori informazioni, vedi 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 per risolvere i problemi di configurazione di AD con il tuo dominio on-premise e le istanze Cloud SQL per SQL Server nella console Google Cloud . Salta i passaggi relativi a Managed Service for Microsoft Active Directory.

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 gli account utente individuali 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 i 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, questi devono essere connessi tramite una relazione di trust bidirezionale. Le relazioni di trust unidirezionali ed esterne non sono supportate.
  • In generale, ai nuovi utenti creati tramite la console viene assegnato il ruolo CustomerDbRootRole, che dispone del seguente ruolo di database fisso di SQL Server Agent: SQLAgentUserRole. Google Cloud 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 nomi di dominio (nomi brevi) anziché FQDN quando crei gli accessi SQL Server. Ad esempio, se il 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 che l'autenticazione Windows è stata attivata 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 a connetterti.

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 dei 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