Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Utilizzo di Active Directory autogestito con un’istanza database Amazon RDS per SQL Server Amazon RDS per SQL Server si integra perfettamente con il dominio Active Directory (AD) autogestito, indipendentemente da dove è ospitato Active Directory: nel data center, su Amazon EC2 o presso altri provider di servizi cloud. Questa integrazione consente l’autenticazione diretta degli utenti tramite i protocolli NTLM o Kerberos, eliminando la necessità di domini intermedi complessi o trust tra foreste. Quando ti connetti all’istanza database RDS SQL Server, le richieste di autenticazione vengono inoltrate in modo sicuro al dominio AD designato, mantenendo la struttura di gestione delle identità esistente e sfruttando al contempo le funzionalità del database gestito Amazon RDS. **Topics** + [Disponibilità di regioni e versioni](#USER_SQLServer_SelfManagedActiveDirectory.RegionVersionAvailability) + [Requisiti](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md) + [Considerazioni](#USER_SQLServer_SelfManagedActiveDirectory.Limitations) + [Configurazione di Active Directory autogestito](USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md) + [Unione di un’istanza database ad Active Directory autogestito](USER_SQLServer_SelfManagedActiveDirectory.Joining.md) + [Gestione di un'istanza database in un dominio Active Directory gestito dal cliente](USER_SQLServer_SelfManagedActiveDirectory.Managing.md) + [Informazioni sull'iscrizione al dominio Active Directory gestito dal cliente](#USER_SQLServer_SelfManagedActiveDirectory.Understanding) + [Risoluzione dei problemi di Active Directory gestito dal cliente](USER_SQLServer_SelfManagedActiveDirectory.TroubleshootingSelfManagedActiveDirectory.md) + [Ripristino e aggiunta di un'istanza di database SQL Server a un dominio Active Directory gestito dal cliente](#USER_SQLServer_SelfManagedActiveDirectory.Restore) ## Disponibilità di regioni e versioni Amazon RDS supporta AD per SQL Server autogestito utilizzando NTLM e Kerberos in tutte le applicazioni commerciali e. Regioni AWS AWS GovCloud (US) Regions # Requisiti Assicurati di soddisfare i seguenti requisiti prima di aggiungere un'istanza database RDS per SQL Server al tuo dominio AD gestito dal cliente. **Topics** + [Configurazione di AD on-premise](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.OnPremConfig) + [Configurazione della connettività di rete](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig) + [Configurazione dell'account del servizio di dominio AD](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig) + [Configurazione della comunicazione sicura tramite LDAPS](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.LDAPS) ## Configurazione di AD on-premise Assicurati di disporre di un dominio Microsoft AD on-premise o gestito dal cliente a cui aggiungere l'istanza Amazon RDS per SQL Server. Il tuo dominio AD on-premise deve avere la seguente configurazione: + Se sono stati definiti siti AD, assicurati che le sottoreti nel VPC associato all’istanza database RDS per SQL Server siano definite nel sito AD. Verifica che non siano presenti conflitti tra le sottoreti del VPC e le sottoreti degli altri siti AD. + Il tuo controller di dominio AD ha un livello di funzionalità di dominio di Windows Server 2008 R2 o superiore. + Il nome di dominio AD non può essere nel formato Single Label Domain (SLD). RDS per SQL Server non supporta i domini SLD. + Il nome di dominio completo (FQDN) per AD non può contenere più di 47 caratteri. ## Configurazione della connettività di rete Assicurati di soddisfare le seguenti configurazioni di rete: + Configura la connettività tra l’Amazon VPC in cui desideri creare l’istanza database RDS per SQL Server e AD autogestito. È possibile configurare la connettività utilizzando AWS Direct Connect, AWS VPN, peering VPC o Transit Gateway AWS . + Per i gruppi di sicurezza VPC, il gruppo di sicurezza predefinito per Amazon VPC predefinito è già aggiunto all'istanza database RDS per SQL Server nella console. Assicurati che il gruppo di sicurezza e la rete VPC ACLs per le sottoreti in cui stai creando l'istanza DB RDS per SQL Server consentano il traffico sulle porte e nelle direzioni mostrate nel diagramma seguente. ![\[Regole delle porte per la configurazione di rete per AD autogestito.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/SQLServer_SelfManagedActiveDirectory_Requirements_NetworkConfig.png) Nella tabella seguente è indicato il ruolo di ciascuna porta. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Requirements.html) + In genere, i server DNS del dominio si trovano nei controller di dominio AD. Non è necessario configurare il set di opzioni DHCP nel VPC per utilizzare questa funzionalità. Per ulteriori informazioni, consulta [Set di opzioni DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) nella *Guida per l'utente di Amazon VPC*. **Importante** Se utilizzi una rete VPC ACLs, devi anche consentire il traffico in uscita su porte dinamiche (49152-65535) dall'istanza DB di RDS per SQL Server. Assicurati che queste regole relative al traffico siano implementate anche nei firewall validi per ciascuno dei controller di dominio AD, per i server DNS e per le istanze database RDS per SQL Server. Sebbene i gruppi di sicurezza VPC richiedano l'apertura delle porte solo nella direzione di avvio del traffico di rete, la maggior parte dei firewall Windows e delle reti VPC richiedono che le porte siano aperte in ACLs entrambe le direzioni. ## Configurazione dell'account del servizio di dominio AD Assicurati di soddisfare i seguenti requisiti per un account del servizio di dominio AD: + Assicurati di disporre di un account del servizio di dominio nel dominio AD autogestito con autorizzazioni delegate per aggiungere computer al dominio. Un account del servizio di dominio è un account utente nel tuo dominio AD gestito dal cliente a cui è stata delegata l'autorizzazione per eseguire determinate attività. + All'account del servizio di dominio devono essere delegate le seguenti autorizzazioni nell'unità organizzativa (UO) a cui stai aggiungendo l'istanza database RDS per SQL Server: + Capacità convalidata di scrivere sul nome host DNS + Capacità convalidata di scrivere sul nome principale del servizio + Creazione ed eliminazione degli oggetti computer Rappresentano il set minimo di autorizzazioni necessarie per unire oggetti computer ad AD autogestito. Per ulteriori informazioni, consulta l'argomento relativo agli [errori durante il tentativo di aggiungere computer a un dominio](https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers) nella documentazione di Microsoft Windows Server. + Per utilizzare l'autenticazione Kerberos, devi fornire i nomi principali dei servizi (SPNs) e le autorizzazioni DNS all'account del servizio di dominio AD: + **SPN di scrittura**: delegare l’autorizzazione **SPN di scrittura** all’account del servizio di dominio AD nell’unità organizzativa in cui è necessario unire l’istanza database RDS per SQL Server. Queste autorizzazioni sono diverse dal nome SPN di scrittura convalidato. + **Autorizzazioni DNS**: fornire le seguenti autorizzazioni all’account del servizio di dominio AD nella gestione DNS a livello di server per il controller di dominio: + Elenca contenuti + Leggi tutte le proprietà + Autorizzazioni di lettura **Importante** Non spostare gli oggetti computer creati da RDS per SQL Server nell'unità organizzativa dopo la creazione dell'istanza database. Lo spostamento degli oggetti associati creerà una configurazione errata dell'istanza database RDS per SQL Server. Se devi spostare gli oggetti informatici creati da Amazon RDS, utilizza l'operazione [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API per modificare i parametri del dominio con la posizione desiderata degli oggetti del computer. ## Configurazione della comunicazione sicura tramite LDAPS La comunicazione tramite LDAPS è consigliata per consentire a RDS di interrogare e accedere agli oggetti del computer e al controller di dominio SPNs . Per utilizzare un protocollo LDAP sicuro, si utilizza un certificato SSL valido sul controller di dominio che soddisfi i requisiti del protocollo LDAPS sicuro. Se nel controller di dominio non esiste un certificato SSL valido, per impostazione predefinita l’istanza database RDS per SQL Server utilizza LDAP. Per ulteriori informazioni sulla validità del certificato, consultare [ Requirements for an LDAPS certificate](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority#requirements-for-an-ldaps-certificate). ## Considerazioni Quando si aggiunge un’istanza database RDS per SQL Server ad Active Directory autogestito, occorre tenere presente quanto segue: + Le tue istanze DB si sincronizzano con AWS il servizio NTP e non con il time server del dominio AD. Per le connessioni al database tra istanze SQL Server collegate all’interno del dominio AD, è possibile utilizzare solo l’autenticazione SQL e non l’autenticazione Windows. + Le impostazioni di Group Policy Object del dominio AD autogestito non vengono propagate alle istanze di RDS per SQL Server. # Configurazione di Active Directory autogestito Per configurare AD autogestito, si procede nel modo descritto di seguito. **Topics** + [Fase 1: creazione di un'unità organizzativa in AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateOU) + [Fase 2: creazione un account del servizio di dominio AD in AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateADuser) + [Fase 3: delega del controllo all’account del servizio di dominio AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.DelegateControl) + [Fase 4: Creare una chiave AWS KMS](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateKMSkey) + [Passaggio 5: crea un AWS segreto](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateSecret) ## Fase 1: creazione di un'unità organizzativa in AD **Importante** Ti consigliamo di creare un'unità organizzativa dedicata e una credenziale di servizio con ambito a tale unità organizzativa per qualsiasi AWS account che possiede un'istanza DB RDS per SQL Server aggiunto al tuo dominio AD autogestito. Dedicando un'unità organizzativa e le credenziali di servizio, puoi evitare autorizzazioni in conflitto e seguire il principio del privilegio minimo. **Creazione di un'unità organizzativa in AD** 1. Stabilisci una connessione al dominio AD come amministratore del dominio. 1. Apri **Utenti e computer di Active Directory** e seleziona il dominio in cui desideri creare l'unità organizzativa. 1. Fai clic con il pulsante destro del mouse sul dominio e scegli **Nuovo**, quindi **Unità organizzativa**. 1. Inserisci un nome per l'unità operativa. 1. Mantieni selezionata la casella **Proteggi il container dall'eliminazione accidentale**. 1. Fai clic su **OK**. La nuova unità organizzativa apparirà sotto il dominio. ## Fase 2: creazione un account del servizio di dominio AD in AD Le credenziali dell'account del servizio di dominio verranno utilizzate per il segreto in AWS Secrets Manager. **Per creare un account del servizio di dominio AD in AD** 1. Apri **Utenti e computer di Active Directory** e seleziona il dominio e l'unità organizzativa in cui desideri creare l'utente. 1. Fai clic con il pulsante destro del mouse sull'oggetto **Utenti**, scegli **Nuovo**, quindi **Utente**. 1. Immetti il nome, il cognome e il nome di accesso per l'utente. Fare clic su **Avanti**. 1. Immetti una password per l'utente. Non selezionare **"L'utente deve cambiare la password al prossimo accesso"**. Non selezionare **"L'account è disabilitato"**. Fare clic su **Avanti**. 1. Fai clic su **OK**. Il nuovo utente apparirà sotto il dominio. ## Fase 3: delega del controllo all’account del servizio di dominio AD **Per delegare il controllo all’account del servizio di dominio AD nel dominio** 1. Apri lo snap-in MMC **Utenti e computer di Active Directory** e seleziona il dominio e l'unità organizzativa in cui desideri creare l'utente. 1. Fai clic con il pulsante destro del mouse sull'unità organizzativa creata in precedenza e scegli **Controllo delegato**. 1. Nella pagina **Delega guidata del controllo**, fai clic su **Avanti**. 1. Nella sezione **Utenti o gruppi**, fai clic su **Aggiungi**. 1. Nella sezione **Seleziona utenti, computer o gruppi**, inserisci l’account del servizio di dominio AD creato in precedenza e fai clic su **Controlla nomi**. Se il controllo dell’account del servizio di dominio AD ha esito positivo, fai clic su **OK**. 1. Nella sezione **Utenti o gruppi**, verifica che l’account del servizio di dominio AD sia stato aggiunto e fai clic su **Avanti**. 1. Nella pagina **Operazioni da delegare**, seleziona **Crea un'operazione personalizzata da delegare**, quindi scegli **Avanti**. 1. Nella sezione **Tipo di oggetto Active Directory**: 1. Seleziona **Solo i seguenti oggetti contenuti nella cartella**. 1. Seleziona **Oggetti computer**. 1. Seleziona **Crea oggetti selezionati in questa cartella**. 1. Seleziona **Elimina gli oggetti selezionati in questa cartella** e fai clic su **Avanti**. 1. Nella sezione **Autorizzazioni**: 1. Mantieni selezionata l'opzione **Generale**. 1. Seleziona **Scrittura convalidata in nome host DNS**. 1. Seleziona **Scrittura convalidata in nome principale servizio** e fai clic su **Avanti**. 1. **Per abilitare l'autenticazione Kerberos, mantieni selezionata la **proprietà specifica** e seleziona Scrivi dall'elenco. servicePrincipalName** 1. Per **completare la procedura guidata di delega del controllo**, rivedi e conferma le impostazioni e fai clic su **Fine**. 1. Per l’autenticazione Kerberos, apri la gestione DNS e le proprietà del **server**. 1. Nella finestra di dialogo Windows, digita `dnsmgmt.msc`. 1. Aggiungi l’account del servizio di dominio AD nella scheda **Sicurezza**. 1. Seleziona l’autorizzazione di **lettura** e applica le modifiche. ## Fase 4: Creare una chiave AWS KMS La chiave KMS viene utilizzata per crittografare il tuo AWS segreto. **Per creare una chiave AWS KMS** **Nota** Per la **chiave di crittografia**, non utilizzare la chiave KMS AWS predefinita. Assicurati di creare la AWS KMS chiave nello stesso AWS account che contiene l'istanza DB di RDS per SQL Server a cui desideri aggiungere al tuo AD autogestito. 1. Nella AWS KMS console, scegli **Crea** chiave. 1. In **Tipo di chiave**, scegli **Simmetrica**. 1. In **Utilizzo delle chiavi**, scegli **Crittografa e decrittografa**. 1. In **Advanced options (Opzioni avanzate)**: 1. In **Origine materiale chiave**, scegli **KMS**. 1. In **Regionalità**, scegli **Chiave a regione singola** e fai clic su **Avanti**. 1. In **Alias**, fornisci un nome per la chiave KMS. 1. (Facoltativo) In **Descrizione**, immetti una descrizione per la chiave KMS. 1. (Facoltativo) In **Tag**, inserisci un tag come chiave KMS e fai clic su **Avanti**. 1. In **Amministratori delle chiavi**, fornisci il nome di un utente IAM e selezionalo. 1. In **Eliminazione chiave**, mantieni selezionata la casella **Consenti agli amministratori delle chiavi di eliminare questa chiave** e fai clic su **Avanti**. 1. In **Utenti delle chiavi**, fornisci lo stesso utente IAM della fase precedente e selezionalo. Fare clic su **Avanti**. 1. Riesamina la configurazione. 1. In **Policy delle chiavi**, includi quanto segue nel campo **Dichiarazione** associato alla policy: ``` { "Sid": "Allow use of the KMS key on behalf of RDS", "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com" ] }, "Action": "kms:Decrypt", "Resource": "*" } ``` 1. Fare clic su **Fine**. ## Passaggio 5: crea un AWS segreto **Per creare un segreto** **Nota** Assicurati di creare il segreto nello stesso AWS account che contiene l'istanza DB di RDS per SQL Server che desideri aggiungere al tuo AD autogestito. 1. In AWS Secrets Manager, scegli **Memorizza un nuovo segreto**. 1. Per **Secret type** (Tipo di segreto), scegli **Other type of secret** (Altro tipo di segreto). 1. In **Coppie chiave/valore**, aggiungi le due chiavi: 1. Per la prima chiave, immetti `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME`. 1. Per il valore della prima chiave, immetti solo il nome utente (senza il prefisso di dominio) dell’utente AD. Non includere il nome di dominio in quanto impedisce la creazione dell’istanza. 1. Per la seconda chiave, immetti `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD`. 1. Per il valore della seconda chiave, immetti la password creata per l'utente AD nel dominio. 1. In **Chiave di crittografia**, inserisci la chiave KMS creata in una delle fasi precedenti e fai clic su **Avanti**. 1. In **Nome del segreto**, inserisci un nome descrittivo che semplifichi l'individuazione del segreto in un secondo momento. 1. (Facoltativo) In **Descrizione**, inserisci una descrizione per il nome del segreto. 1. In **Autorizzazioni a livello di risorsa**, fai clic su **Modifica**. 1. Aggiungi la seguente policy alla policy dell'autorizzazione: **Nota** Si consiglia di utilizzare le condizione `aws:sourceAccount` e `aws:sourceArn` nella policy per evitare problemi di tipo *confused deputy*. Usa il tuo Account AWS nome `aws:sourceAccount` e l'`aws:sourceArn`ARN dell'istanza DB di RDS per SQL Server. Per ulteriori informazioni, consulta [Prevenzione del problema "confused deputy" tra servizi](cross-service-confused-deputy-prevention.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "StringEquals": { "aws:sourceAccount": "123456789012" }, "ArnLike": { "aws:sourceArn": "arn:aws:rds:us-west-2:123456789012:db:*" } } } ] } ``` ------ 1. Fai clic su **Salva**, quindi su **Avanti**. 1. In **Configura impostazioni di rotazione**, non modificare i valori predefiniti e scegli **Avanti**. 1. Controlla le impostazioni relative al segreto e fai clic su **Archivio**. 1. Scegli il segreto creato e copia il valore in **ARN secreto**. Questa informazione verrà utilizzata nella fase successiva per configurare Active Directory gestito dal cliente. # Unione di un’istanza database ad Active Directory autogestito Per unire l’istanza database RDS per SQL Server ad AD autogestito: ## Passaggio 1: creare o modificare un'istanza DB di SQL Server È possibile utilizzare la console, l'interfaccia della linea di comando o l'API RDS per associare un'istanza database RDS per SQL Server a un dominio AD gestito dal cliente. Questa operazione può essere eseguita in uno dei seguenti modi: + Crea una nuova istanza DB di SQL Server utilizzando la console, il comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI o l'operazione [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API. Per istruzioni, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). + Modifica un'istanza DB di SQL Server esistente utilizzando la console, il comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI o l'operazione [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API. Per istruzioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). + [Ripristina un'istanza DB di SQL Server da uno snapshot DB utilizzando la console, il comando CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) o l'operazione Restore From RDS API. DBInstance DBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) Per istruzioni, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md). + Ripristina un'istanza DB di SQL Server point-in-time utilizzando la console, il comando [restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI o l'operazione [Restore DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API. Per istruzioni, consulta [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md). Quando si utilizza il AWS CLI, sono necessari i seguenti parametri affinché l'istanza DB possa utilizzare il dominio AD autogestito che è stato creato: + Per il parametro `--domain-fqdn`, utilizza il nome di dominio completo (FQDN) del dominio AD autogestito. + Per il parametro `--domain-ou`, utilizza l'unità organizzativa creata nel dominio AD gestito dal cliente. + Per il parametro `--domain-auth-secret-arn`, utilizza il valore riportato nel campo **ARN segreto** definito in una delle fasi precedenti. + Per il `--domain-dns-ips` parametro, utilizza gli IPv4 indirizzi primari e secondari dei server DNS per il tuo AD autogestito. Se non disponi di un indirizzo IP secondario del server DNS, inserisci l'indirizzo IP primario due volte. I seguenti comandi CLI di esempio mostrano come creare, modificare e rimuovere un'istanza database RDS per SQL Server con un dominio AD gestito dal cliente. **Importante** Se modifichi un'istanza database per aggiungerla o rimuoverla da un dominio AD gestito dal cliente, è necessario riavviare l'istanza database affinché la modifica abbia effetto. Puoi scegliere di applicare le modifiche subito o attendere fino alla prossima finestra di manutenzione. La selezione dell'opzione **Applica immediatamente** causerà tempi di inattività per le istanze database Single-AZ. Un'istanza database Multi-AZ eseguirà un failover prima di completare il riavvio. Per ulteriori informazioni, consulta [Utilizzo dell’impostazione della pianificazione delle modifiche](USER_ModifyInstance.ApplyImmediately.md). Il seguente comando CLI crea una nuova istanza database RDS per SQL Server e la aggiunge a un dominio AD gestito dal cliente. Per Linux, macOS o Unix: ``` aws rds create-db-instance \ --db-instance-identifier my-DB-instance \ --db-instance-class db.m5.xlarge \ --allocated-storage 50 \ --engine sqlserver-se \ --engine-version 15.00.4043.16.v1 \ --license-model license-included \ --master-username my-master-username \ --master-user-password my-master-password \ --domain-fqdn my_AD_domain.my_AD.my_domain \ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` Per Windows: ``` aws rds create-db-instance ^ --db-instance-identifier my-DB-instance ^ --db-instance-class db.m5.xlarge ^ --allocated-storage 50 ^ --engine sqlserver-se ^ --engine-version 15.00.4043.16.v1 ^ --license-model license-included ^ --master-username my-master-username ^ --master-user-password my-master-password ^ --domain-fqdn my-AD-test.my-AD.mydomain ^ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ ^ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` Il seguente comando CLI modifica un’istanza database RDS per SQL Server esistente in modo che utilizzi un dominio AD autogestito. Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier my-DB-instance \ --domain-fqdn my_AD_domain.my_AD.my_domain \ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier my-DBinstance ^ --domain-fqdn my_AD_domain.my_AD.my_domain ^ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" ^ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` Il seguente comando CLI rimuove un’istanza database RDS per SQL Server da un dominio AD autogestito. Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier my-DB-instance \ --disable-domain ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier my-DB-instance ^ --disable-domain ``` ## Fase 2: utilizzo dell’autenticazione Kerberos o NTLM ### autenticazione NTLM Ogni istanza database Amazon RDS dispone di un endpoint e ciascun endpoint è associato a un nome DNS e a un numero di porta per l’istanza database. Per connetterti all'istanza database tramite un'applicazione client SQL, devi conoscere il nome DNS e il numero di porta dell'istanza database. Per eseguire l’autenticazione NTLM, è necessario connettersi all’endpoint RDS o all’endpoint listener se si utilizza un’implementazione Multi-AZ. Durante la manutenzione pianificata del database o l'interruzione non pianificata del servizio, Amazon RDS esegue automaticamente il failover sul database up-to-date secondario in modo che le operazioni possano riprendere rapidamente senza interventi manuali. Le istanze primarie e secondarie utilizzano lo stesso endpoint, il cui indirizzo di rete fisico passa alla replica secondaria come parte del processo di failover. Non è necessario riconfigurare l'applicazione quando si verifica un failover. ### Autenticazione Kerberos L’autenticazione basata su Kerberos per RDS per SQL Server richiede che vengano effettuate connessioni a uno specifico nome del principale del servizio (SPN). Tuttavia, dopo un evento di failover, l’applicazione potrebbe non essere a conoscenza del nuovo SPN. Per risolvere questo problema, RDS per SQL Server offre un endpoint basato su Kerberos. L’endpoint basato su Kerberos segue un formato specifico. Se l’endpoint RDS è `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com`, l’endpoint corrispondente basato su Kerberos sarebbe `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)`. Ad esempio, se l’endpoint RDS è `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com` e il nome di dominio è `corp-ad.company.com`, l’endpoint basato su Kerberos sarebbe `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`. Questo endpoint basato su Kerberos può essere utilizzato per l’autenticazione con l’istanza SQL Server tramite Kerberos, anche dopo un evento di failover, poiché l’endpoint viene aggiornato automaticamente in modo che punti al nuovo SPN dell’istanza SQL Server primaria. ### Individuazione del CNAME Per individuare il CNAME, ci si connette al controller di dominio e si apre **Gestione DNS**. Andare a **Inoltra zone di ricerca** e al FQDN. Navigare in **awsrds**, **aws-region** e **hash specifico dell’account e della Regione**. ![\[Modifica della quantità di storage per un'istanza database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/kerb-endpoint-selfManagedAD-RDSMS.png) Se dopo aver connesso CNAME dal client remoto viene restituita una connessione NTLM, controllare se le porte richieste sono incluse nell’elenco delle porte consentite. Per verificare che la connessione utilizzi Kerberos, eseguire la seguente query: ``` SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SSPID; ``` Se l’istanza restituisce una connessione NTLM al momento della connessione a un endpoint Kerberos, verificare la configurazione della rete e le configurazioni utente. Per informazioni, consulta [Configurazione della connettività di rete](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig). ## Fase 3: Creare gli accessi a SQL Server per l'autenticazione di Windows Utilizza le credenziali dell'utente master Amazon RDS per eseguire la connessione all'istanza database SQL Server analogamente a quanto avviene con qualsiasi altra istanza database. Poiché l'istanza database viene aggiunta al dominio AD gestito dal cliente, puoi eseguire il provisioning degli account di accesso e degli utenti di SQL Server. Puoi eseguire questa operazione dall'utilità Utenti e gruppi AD nel dominio AD gestito dal cliente. Le autorizzazioni per il database vengono gestite tramite le autorizzazioni standard di SQL Server concesse e revocate in base a questi account di accesso Windows. Affinché un account del servizio di dominio AD autogestito possa autenticarsi con SQL Server, è necessario che esista un accesso Windows a SQL Server per l’account del servizio di dominio AD autogestito o un gruppo AD autogestito di cui l’utente è membro. Il controllo granulare degli accessi viene gestito assegnando o revocando le autorizzazioni per questi login di SQL Server. Un account del servizio di dominio AD autogestito che non dispone di un accesso a SQL Server o non appartiene a un gruppo AD autogestito con tale accesso non può accedere all’istanza database SQL Server. È necessaria l'autorizzazione ALTER ANY LOGIN per creare un accesso AD gestito dal cliente per SQL Server. Se non hai ancora creato un accesso con questa autorizzazione, esegui la connessione come utente principale dell'istanza database utilizzando l'autenticazione di SQL Server e quindi crea gli accessi AD gestiti dal cliente per SQL Server nel contesto dell'utente principale. È possibile eseguire un comando DDL (Data Definition Language) come il seguente per creare un accesso a SQL Server per un gruppo o un account del servizio di dominio AD autogestito. **Nota** Specifica utenti o gruppi utilizzando il nome di accesso precedente a Windows 2000 nel formato `my_AD_domain\my_AD_domain_user`. Non puoi utilizzare un UPN (User Principle Name) nel formato *`my_AD_domain_user`*`@`*`my_AD_domain`*. ``` USE [master] GO CREATE LOGIN [my_AD_domain\my_AD_domain_user] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ``` Per maggiori informazioni, consulta [CREATE LOGIN (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx) nella documentazione di Microsoft Developer Network. Gli utenti (persone e applicazioni) del dominio possono ora connettersi all'istanza RDS per SQL Server da un computer client associato al dominio AD gestito dal cliente utilizzando l'autenticazione Windows. # Gestione di un'istanza database in un dominio Active Directory gestito dal cliente Puoi utilizzare la console o l'API Amazon RDS per gestire la tua istanza DB e la sua relazione con il tuo dominio AD autogestito. AWS CLI Ad esempio, puoi spostare l'istanza database all'interno, al di fuori o tra domini. Ad esempio, puoi utilizzare l'API Amazon RDS per effettuare quanto segue: + Per tentare nuovamente l'accesso a un dominio autogestito per un'iscrizione non riuscita, utilizza l'operazione [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API e specifica lo stesso set di parametri: + `--domain-fqdn` + `--domain-dns-ips` + `--domain-ou` + `--domain-auth-secret-arn` + Per rimuovere un'istanza database da un dominio gestito dal cliente, utilizza l'operazione API `ModifyDBInstance` e specifica `--disable-domain` come parametro del dominio. + Per spostare un'istanza database da un dominio gestito dal cliente a un altro, utilizza l'operazione API `ModifyDBInstance` e specifica i parametri di dominio per il nuovo. + `--domain-fqdn` + `--domain-dns-ips` + `--domain-ou` + `--domain-auth-secret-arn` + Per elencare l'appartenenza al dominio AD autogestita per ogni istanza DB, utilizza l'operazione [DBInstancesDescrivi](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) API. ## Informazioni sull'iscrizione al dominio Active Directory gestito dal cliente Dopo aver creato o modificato l’istanza database specificando i dettagli di AD, l’istanza diventa membro del dominio AD autogestito. La AWS console indica lo stato dell'appartenenza al dominio Active Directory autogestito per l'istanza DB. Lo stato dell'istanza di database può essere uno dei seguenti: + **Collegato**: l'istanza è un membro del dominio AD. + **Collegamento in corso**: l'istanza sta diventando un membro del dominio. + **pending-join (associazione in sospeso)** – L'associazione dell'istanza è in sospeso. + **pending-maintenance-join**— AWS tenterà di rendere l'istanza un membro del dominio AD durante la successiva finestra di manutenzione programmata. + **In attesa di rimozione**: la rimozione dell'istanza dal dominio AD è in sospeso. + **pending-maintenance-removal**— AWS tenterà di rimuovere l'istanza dal dominio AD durante la successiva finestra di manutenzione programmata. + **Non riuscito**: un problema di configurazione ha impedito il collegamento dell'istanza al dominio AD. Verifica e correggi la configurazione prima di eseguire nuovamente il comando di modifica dell'istanza. + **Rimozione in corso**: è in corso la rimozione dell'istanza dal dominio AD gestito dal cliente. **Importante** Una richiesta di collegamento a un dominio AD gestito dal cliente potrebbe non riuscire a causa di un problema di connettività di rete. Ad esempio, è possibile che venga creata un'istanza database o modificata un'istanza esistente senza però che questa diventi un membro di un dominio AD gestito dal cliente. In questo caso, devi emettere nuovamente il comando per creare o modificare l'istanza database o modificare l'istanza appena creata per aggiungerla al dominio AD gestito dal cliente. # Risoluzione dei problemi di Active Directory gestito dal cliente Di seguito sono riportati i problemi che potresti riscontrare quando configuri o modifichi AD gestito dal cliente. **** | Codice di errore | Description | Cause comuni | Suggerimenti sulla risoluzione dei problemi | | --- | --- | --- | --- | | Errore 2/0x2 | Il sistema non trova il file specificato. | Il formato o la posizione dell'unità organizzativa (UO) specificati con il parametro `—domain-ou` non è valido. L'account del servizio di dominio specificato tramite AWS Secrets Manager non dispone delle autorizzazioni necessarie per accedere all'unità organizzativa. | Rivedi il parametro `—domain-ou`. Assicurati che l'account del servizio di dominio disponga delle autorizzazioni corrette per l'unità organizzativa. Per ulteriori informazioni, consulta [Configurazione dell'account del servizio di dominio AD](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). | | Errore 5/0x5 | Accesso negato. | Nel dominio esistono già autorizzazioni non configurate correttamente per l'account del servizio di dominio o per l'account del computer. | Controlla le autorizzazioni dell'account del servizio di dominio nel dominio e verifica che l'account del computer RDS non sia duplicato nel dominio. È possibile verificare il nome dell'account del computer RDS eseguendo `SELECT @@SERVERNAME` sull'istanza database RDS per SQL Server. Se utilizzi l'opzione Multi-AZ, prova a riavviare con il failover, quindi verifica nuovamente l'account del computer RDS. Per ulteriori informazioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md). | | Errore 87/0x57 | Il parametro non è corretto. | L'account del servizio di dominio specificato tramite AWS Secrets Manager non dispone delle autorizzazioni corrette. È anche possibile che il profilo utente sia danneggiato. | Verifica i requisiti per l'account del servizio di dominio. Per ulteriori informazioni, consulta [Configurazione dell'account del servizio di dominio AD](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). | | Errore 234/0xEA | L'unità organizzativa (UO) specificata non esiste. | L'unità organizzativa specificata con il parametro `—domain-ou` non esiste nel dominio AD gestito dal cliente. | Rivedi il parametro `—domain-ou` e assicurati che l'unità organizzativa specificata esista in AD gestito dal cliente. | | Errore 1326/0x52E | Il nome utente o la password sono errati. | Le credenziali dell'account del servizio di dominio fornite in AWS Secrets Manager contengono un nome utente sconosciuto o una password errata. L'account di dominio può anche essere disabilitato in AD gestito dal cliente. | Assicurati che le credenziali fornite in AWS Secrets Manager siano corrette e che l’account di dominio sia abilitato in AD autogestito. | | Errore 1355/0x54B | Il nome di dominio specificato non esiste o non può essere contattato. | Il dominio non è attivo, il set di DNS IPs specificato non è raggiungibile o il nome di dominio completo specificato non è raggiungibile. | Controlla i parametri `—domain-dns-ips` e `—domain-fqdn` per assicurarti che siano corretti. Verifica la configurazione di rete dell'istanza database RDS per SQL Server e assicurati che il dominio AD gestito dal cliente sia raggiungibile. Per ulteriori informazioni, consulta [Configurazione della connettività di rete](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig). | | Errore 1.722/0x6BA | Il server RPC non è disponibile. | Si è verificato un problema durante la connessione al servizio RPC del dominio AD. Questo errore potrebbe essere causato da un problema di rete. | Verifica che il servizio RPC sia in esecuzione sui controller di dominio e che le porte TCP `135` e `49152-65535` siano raggiungibili sul dominio dall'istanza database RDS per SQL Server. | | Errore 1727/0x6BF | La chiamata della procedura remota non è riuscita e non è stata eseguita. | Problema di connettività di rete o restrizione del firewall che blocca la comunicazione RPC con il controller di dominio. | Se utilizzi l’unione di domini tra VPC, verifica che la comunicazione tra VPC sia configurata correttamente con il peering VPC o il gateway di transito. Assicurati che le porte con numero elevato TCP `49152-65535` siano raggiungibili sul dominio dall’istanza database RDS per SQL Server, comprese eventuali restrizioni del firewall. | | Errore 2224/0x8B0 | L'account utente esiste già. | L'account del computer che sta tentando di essere aggiunto al dominio AD gestito dal cliente esiste già. | Identifica l'account del computer eseguendo `SELECT @@SERVERNAME` sull'istanza database RDS per SQL Server, quindi rimuovilo con attenzione da dominio AD gestito dal cliente. | | Errore 2242/0x8c2 | La password di questo utente è scaduta. | La password per l'account del servizio di dominio specificato tramite AWS Secrets Manager è scaduta. | Aggiorna la password per l'account del servizio di dominio utilizzato per aggiungere l'istanza database RDS per SQL Server al dominio AD gestito dal cliente. | Dopo aver unito l’istanza database a un dominio Active Directory autogestito, potresti ricevere eventi RDS relativi all’integrità del dominio. ``` Unhealthy domain state detected while attempt to verify or configure your Kerberos endpoint in your domain on node node_n. message ``` Per le istanze Multi-AZ, potresti notare la segnalazione di errori sia per node1 sia per node2, il che indica che la configurazione Kerberos dell’istanza non è pronta per il failover. In caso di failover, potrebbero verificarsi problemi di autenticazione utilizzando Kerberos. Risolvi i problemi di configurazione per garantire che la configurazione di Kerberos sia valida e aggiornata. Per le istanze Multi-AZ, non è necessaria alcuna azione per utilizzare l’autenticazione Kerberos sul nuovo host primario, dato che tutte le configurazioni di rete e di autorizzazione sono presenti. Per le istanze Single-AZ, node1 è il nodo primario. Se l’autenticazione Kerberos non funziona come previsto, controlla gli eventi dell’istanza e risolvi i problemi di configurazione per garantire che la configurazione di Kerberos sia valida e aggiornata. ## Ripristino e aggiunta di un'istanza di database SQL Server a un dominio Active Directory gestito dal cliente È possibile ripristinare un'istantanea del DB o eseguire il point-in-time ripristino (PITR) per un'istanza DB di SQL Server e quindi aggiungerla a un dominio Active Directory autogestito. Dopo aver ripristinato l'istanza database, modificala utilizzando il processo illustrato in [Passaggio 1: creare o modificare un'istanza DB di SQL Server](USER_SQLServer_SelfManagedActiveDirectory.Joining.md#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateModify) per aggiungere l'istanza a un dominio Active Directory gestito dal cliente.