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 AD gestito dal cliente o CMAD).

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

Prima di iniziare

Puoi eseguire l'integrazione con CMAD, aggiungendo il supporto per l'autenticazione di 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. Ciò include 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 domain controller: 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:
      • Gestisci oggetti computer (crea oggetto/elimina oggetto/modifica proprietà oggetto)
      • Gestisci oggetti utente (crea oggetto/elimina oggetto/modifica proprietà oggetto)
    • 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.

      In alternativa, puoi connetterti 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 Manager secret, 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: il secondo accesso 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 ospitare rotazioni pianificate e anticipate.

    Il campo validAfterUTC è facoltativo. Se non viene specificato, si presuppone 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 le ruoti.

    Anche se puoi eliminare il secret dopo la creazione dell'istanza, tieni presente che le 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.

  • Avere 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.

Creare e configurare 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 il seguente 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 il seguente comando:

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

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

Quindi, esegui il seguente 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, 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 per risolvere i problemi di configurazione di AD con il tuo dominio on-premise e le istanze Cloud SQL per SQL Server in Google Cloud console. 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 di dominio. Tuttavia, sono disponibili le seguenti alternative:

  • Aggiungi gruppi globali o accessi utente individuali 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 di dominio come accessi. Per concedere le autorizzazioni agli utenti del dominio, devi utilizzare invece 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 hai più gruppi globali, puoi aggiungere tutti i singoli account utente e i gruppi globali e universali direttamente come accessi a SQL Server. Per un esempio dell'opzione 1, consulta 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. Quindi puoi aggiungere tutti i singoli account utente e i gruppi globali e universali come figli del gruppo universale definito e aggiungere il gruppo universale definito come accesso a SQL Server. Per un esempio dell'opzione 2, consulta 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 di dominio non sono supportati, ma puoi aggiungere gruppi globali o accessi utente individuali direttamente in SQL Server. In alternativa, puoi utilizzare i gruppi universali quando tutti i gruppi e gli utenti appartengono alla stessa foresta.
  • Se sono presenti altri domini attendibili e prevedi di accedere alle istanze SQL Server con nomi utente da questi domini, devono essere connessi tramite un trust bidirezionale. I trust unidirezionali ed esterni non sono supportati.
  • In generale, agli utenti creati tramite la Google Cloud console viene assegnato il CustomerDbRootRole ruolo, che ha questo ruolo di database fisso di SQL Server Agent: SQLAgentUserRole. Tuttavia, agli utenti creati direttamente tramite SQL Server , ad esempio gli utenti CMAD, non è possibile concedere questo ruolo o 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, quando crei gli accessi a SQL Server, utilizza i nomi di dominio (nomi brevi) anziché i 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 i FQDN. Ad esempio, puoi 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 a SQL Server basati su utenti e gruppi di Active Directory non possono essere gestiti dal Google Cloud console.
  • 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 base alle raccomandazioni di Microsoft, utilizza un trust di foresta anziché un trust esterno per l'autroenticazione Kerberos.
  • Viene sempre utilizzata la versione più recente del secret. Il secret deve essere attivo e non può essere eliminato.

Endpoint di Active Directory e connessioni TLS

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

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

Non supportato per l'integrazione

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

  • Gruppi locali di dominio.
  • Autenticazione NTLM.
  • Accedi con un indirizzo IP da 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 CMAD è raggiungibile dall'istanza Cloud SQL. È uno strumento utile per risolvere i problemi di rete:

cloudsql.googleapis.com/database/active_directory/instance_available

Passaggi successivi