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 Microsoft Active Directory con RDS Custom per SQL Server
RDS Custom per SQL Server consente di aggiungere istanze ad Active Directory autogestito o AWS Managed Microsoft AD. Questo indipendentemente da dove è ospitato AD, ad esempio un data center on-premises, Amazon EC2 o qualsiasi altro provider di servizi cloud.
Per l’autenticazione di utenti e servizi è possibile utilizzare l’autenticazione NTLM oi Kerberos sull’istanza database RDS Custom per SQL Server senza utilizzare domini intermedi o trust tra foreste. Quando un utente tenta di eseguire l’autenticazione sull’istanza database RDS Custom per SQL Server con un Active Directory aggiunta autonomamente, le richieste di autenticazione vengono inoltrate a un determinato AD autogestito o AWS Managed Microsoft AD.
Nelle sezioni seguenti, puoi trovare informazioni sull’utilizzo di Active Directory autogestito e Active Directory gestito da AWS per RDS Custom per SQL Server.
**Topics**
+ [Disponibilità di regioni e versioni](#custom-sqlserver-WinAuth.Regions)
+ [Configurazione di AD autogestito o on-premises](custom-sqlserver-WinAuth.config-Self-Managed.md)
+ [Configurare Microsoft Active Directory utilizzando Directory Service](custom-sqlserver-WinAuth.config-ADS.md)
+ [Regole per le porte della configurazione di rete](custom-sqlserver-WinAuth.NWConfigPorts.md)
+ [Convalida di rete](custom-sqlserver-WinAuth.NWValidation.md)
+ [Configurazione dell’autenticazione di Windows per le istanze RDS Custom per SQL Server](custom-sqlserver-WinAuth.settingUp.md)
+ [Gestione di un'istanza database in un dominio](custom-sqlserver-WinAuth.ManagingDBI.md)
+ [Appartenenza al dominio](custom-sqlserver-WinAuth.Understanding.md)
+ [Risoluzione dei problemi di Active Directory](custom-sqlserver-WinAuth.Troubleshoot.md)
## Disponibilità di regioni e versioni
RDS Custom per SQL Server supporta sia AD autogestito che AWS Managed Microsoft AD utilizzando NTLM o Kerberos in tutte le Regioni in cui è supportato RDS Custom per SQL Server. Per ulteriori informazioni, consulta [Regioni e motori di database supportati per RDS Custom](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md).
# Configurazione di AD autogestito o on-premises
Per aggiungere Microsoft AD autogestito o on-premises a un’istanza database RDS Custom per SQL Server, è necessario che il dominio attivo sia configurato come segue:
+ Definisci le sottoreti nel VPC associato all’istanza database RDS Custom per SQL Server in AD autogestito o on-premises. Verifica che non vi siano conflitti tra le sottoreti nel VPC e le sottoreti nei tuoi 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 Custom per SQL Server non supporta i domini SLD.
+ Il nome di dominio completo (FQDN) per AD non può superare i 47 caratteri.
## Configurazione della connettività di rete
Configura la connettività di rete per AD autogestito o on-premises nel modo seguente:
+ Configura la connettività tra Amazon VPC in cui viene eseguita l’istanza RDS Custom per SQL Server e AD. Usa Direct Connect, Site-to-Site VPN AWS Transit Gateway, e peering VPC.
+ Consenti il traffico sulle porte, sui gruppi di sicurezza e sulla rete di RDS Custom for SQL Server ACLs verso il tuo AD autogestito o locale. Per ulteriori informazioni, consulta [Regole per le porte della configurazione di rete](custom-sqlserver-WinAuth.NWConfigPorts.md).
![\[Directory di autenticazione Microsoft SQL Server Windows\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/custom-sqs-SM-NC.png)
## Configurazione della risoluzione DNS
Imposta i seguenti requisiti per configurare la risoluzione DNS con AD autogestiti o on-premises:
+ Configura la risoluzione DNS all’interno del VPC per risolvere i nomi di dominio completi (FQDN) di Active Directory con hosting autonomo. Un esempio di FQDN è `corp.example.local`. Per configurare la risoluzione DNS, configura il risolutore DNS VPC per inoltrare le query per determinati domini con un endpoint in uscita e una regola del risolutore Amazon Route 53. Per ulteriori informazioni, consulta [Configure a Route 53 Resolver outbound endpoint to resolve DNS records](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint).
+ Per i carichi di lavoro che sfruttano sia le risorse locali che quelle locali, devi risolvere VPCs i record DNS ospitati in locale. Le risorse locali potrebbero dover risolvere i nomi ospitati su. AWS
Per creare una configurazione cloud ibrido, utilizza gli endpoint e le regole di inoltro condizionale del risolutore per risolvere le query DNS tra le risorse on-premises e un VPC personalizzato. Per ulteriori informazioni, consulta [Risolvere le query DNS tra VPCs e la tua rete](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) nella *Amazon Route 53* Developer Guide.
**Importante**
Quando si modificano le impostazioni del risolutore DNS dell’interfaccia di rete su RDS Custom per SQL Server, gli endpoint VPC in cui è abilitato il DNS non funzionano più correttamente. Gli endpoint VPC in cui è abilitato il DNS sono necessari per le istanze all’interno di sottoreti private senza accesso a Internet.
# Configurare Microsoft Active Directory utilizzando Directory Service
AWS Managed Microsoft AD crea una Microsoft Active Directory completamente gestita basata su Windows Server 2019 e AWS che opera ai livelli funzionali Forest e Domain di 2012 R2. Directory Service crea i controller di dominio in diverse sottoreti in un Amazon VPC, rendendo la directory altamente disponibile anche in caso di errore.
*Per creare una directory con AWS Managed Microsoft AD, consulta Guida [introduttiva AWS Managed Microsoft AD nella Guida all'amministrazione](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html).AWS Directory Service *
## Configurazione della connettività di rete
### Abilitazione del traffico tra VPC tra la directory e l’istanza database
Per individuare la directory e l’istanza database nello stesso VPC, salta questo passaggio e procedi al passaggio successivo in [Regole per le porte della configurazione di rete](custom-sqlserver-WinAuth.NWConfigPorts.md).
Per localizzare la directory e l'istanza DB in modo diverso VPCs, configura il traffico cross-VPC utilizzando il peering VPC o. AWS Transit Gateway Per ulteriori informazioni sull'utilizzo del peering VPC, consulta Cos'[è il peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)? [nella *Amazon VPC Peering Guide* e cos'è? AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) nei gateway di *transito Amazon VPC*.
**Abilitazione del traffico tra VPC utilizzando il peering VPC**
1. Configurare le regole di routing VPC appropriate per garantire che il traffico di rete possa scorrere in entrambe le direzioni.
1. Consenti al gruppo di sicurezza dell’istanza database di ricevere traffico in entrata dal gruppo di sicurezza della directory. Per ulteriori informazioni, consulta [Regole per le porte della configurazione di rete](custom-sqlserver-WinAuth.NWConfigPorts.md).
1. La lista di controllo degli accessi (ACL) della rete non deve bloccare il traffico.
Se la directory è di Account AWS proprietà di un altro, devi condividerla. *Per condividere la directory in cui Account AWS si trova l'istanza di RDS Custom for SQL Server, segui il [Tutorial: Sharing your AWS Managed Microsoft AD for seamless EC2 domain-join](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) nella Administration Guide.AWS Directory Service *
**Condivisione di una directory tra Account AWS**
1. Accedi alla Directory Service console utilizzando l'account per l'istanza DB e verifica se il dominio ha lo `SHARED` stato prima di procedere.
1. Dopo aver effettuato l'accesso alla Directory Service console utilizzando l'account per l'istanza DB, annota il valore **Directory ID**. Utilizza questo ID per aggiungere l’istanza database al dominio.
## Configurazione della risoluzione DNS
Quando crei una directory con AWS Managed Microsoft AD, Directory Service crea due controller di dominio e aggiunge il servizio DNS per tuo conto.
Se ne disponi già AWS Managed Microsoft AD o intendi avviarne una in un VPC diverso dall'istanza DB RDS Custom for SQL Server, configura il resolver DNS VPC per inoltrare le query per determinati domini con una regola di risoluzione e uscita Route 53, [vedi](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint) Configurare un endpoint DNS in uscita Route 53 Resolver per risolvere i record DNS.
# Regole per le porte della configurazione di rete
Assicurati di soddisfare le seguenti configurazioni di rete:
+ Connettività configurata tra Amazon VPC in cui desideri creare l’istanza database RDS per SQL Server e Active Directory autogestito o AWS Managed Microsoft AD. Per Active Directory autogestito, configura la connettività utilizzando AWS Direct Connect, AWS VPN, peering VPC o AWS Transit Gateway. Per AWS Managed Microsoft AD, configura la connettività utilizzando il peering VPC.
+ Assicurati che il gruppo di sicurezza e le liste di controllo degli accessi (ACL) alla rete VPC per le sottoreti in cui stai creando l’istanza database RDS Custom per SQL Server consentano il traffico sulle porte e nelle direzioni mostrate nel diagramma seguente.
![\[Regole per le porte della configurazione di rete per Microsoft Active Directory.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/custom_sqlserver_ActiveDirectory_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/custom-sqlserver-WinAuth.NWConfigPorts.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 le liste di controllo degli accessi (ACL) alla rete VPC, devi anche consentire il traffico in uscita sulle porte dinamiche (49152-65535) dall’istanza database RDS Custom 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 Custom per SQL Server.
Mentre i gruppi di sicurezza VPC richiedono che le porte siano aperte solo nella direzione in cui viene avviato il traffico di rete, la maggior parte dei firewall Windows e delle liste di controllo degli accessi della rete VPC richiedono che le porte siano aperte in entrambe le direzioni.
# Convalida di rete
Prima di aggiungere un’istanza RDS Custom a AWS Managed Microsoft AD o autogestito, controlla quanto segue da un’istanza EC2 nello stesso VPC in cui prevedi di avviare l’istanza RDS Custom per SQL Server.
+ Verifica se sei in grado di risolvere il nome di dominio completo (FQDN) sull’IP del controller di dominio.
```
nslookup corp.example.com
```
Il comando deve restituire un output simile al seguente:
```
Server: ip-10-0-0-2.us-west-2.compute.internal
Address: 25.0.0.2
Non-authoritative answer:
Name: corp.example.com
Addresses: 40.0.9.25 (DC1 IP)
40.0.50.123 (DC2 IP)
```
+ Risolvi i servizi AWS da un’istanza EC2 nel VPC in cui stai avviando l’istanza RDS Custom:
```
$region='input-your-aws-region'
$domainFQDN='input-your-domainFQDN'
function Test-DomainPorts {
param (
[string]$Domain,
[array]$Ports
)
foreach ($portInfo in $Ports) {
try {
$conn = New-Object System.Net.Sockets.TcpClient
$connectionResult = $conn.BeginConnect($Domain, $portInfo.Port, $null, $null)
$success = $connectionResult.AsyncWaitHandle.WaitOne(1000) # 1 second timeout
if ($success) {
$conn.EndConnect($connectionResult)
$result = $true
} else {
$result = $false
}
}
catch {
$result = $false
}
finally {
if ($null -ne $conn) {
$conn.Close()
}
}
Write-Host "$($portInfo.Description) port open: $result"
}
}
# Check if ports can be reached
$ports = @(
@{Port = 53; Description = "DNS"},
@{Port = 88; Description = "Kerberos"},
@{Port = 389; Description = "LDAP"},
@{Port = 445; Description = "SMB"},
@{Port = 5985; Description = "WinRM"},
@{Port = 636; Description = "LDAPS"},
@{Port = 3268; Description = "Global Catalog"},
@{Port = 3269; Description = "Global Catalog over SSL"},
@{Port = 9389; Description = "AD DS"}
)
function Test-DomainReachability {
param (
[string]$DomainName
)
try {
$dnsResults = Resolve-DnsName -Name $DomainName -ErrorAction Stop
Write-Host "Domain $DomainName is successfully resolving to following IP addresses: $($dnsResults.IpAddress)"
Write-Host ""
return $true
}
catch {
Write-Host ""
Write-Host "Error Message: $($_.Exception.Message)"
Write-Host "Domain $DomainName reachability check failed, please Configure DNS resolution"
return $false
}
}
$domain = (Get-WmiObject Win32_ComputerSystem).Domain
if ($domain -eq 'WORKGROUP') {
Write-Host ""
Write-Host "Host $env:computername is still part of WORKGROUP and not part of any domain"
}
else {
Write-Host ""
Write-Host "Host $env:computername is joined to $domain domain"
Write-Host ""
}
$isReachable = Test-DomainReachability -DomainName $domainFQDN
if ($isReachable) {
write-Host "Checking if domain $domainFQDN is reachable on required ports "
Test-DomainPorts -Domain $domainFQDN -Ports $ports
}
else {
Write-Host "Port check skipped. Domain not reachable"
}
# Get network adapter configuration
$networkConfig = Get-WmiObject Win32_NetworkAdapterConfiguration |
Where-Object { $_.IPEnabled -eq $true } |
Select-Object -First 1
# Check DNS server settings
$dnsServers = $networkConfig.DNSServerSearchOrder
if ($dnsServers) {
Write-Host "`nDNS Server settings:"
foreach ($server in $dnsServers) {
Write-Host " - $server"
}
} else {
Write-Host "`nNo DNS servers configured or unable to retrieve DNS server information."
}
write-host ""
# Checks reachability to dependent services
$services = "s3", "ec2", "secretsmanager", "logs", "events", "monitoring", "ssm", "ec2messages", "ssmmessages"
function Get-TcpConnectionAsync {
param (
$ServicePrefix,
$region
)
$endpoint = "${ServicePrefix}.${region}.amazonaws.com"
$tcp = New-Object Net.Sockets.TcpClient
$result = $false
try {
$connectTask = $tcp.ConnectAsync($endpoint, 443)
$timedOut = $connectTask.Wait(3000)
$result = $tcp.Connected
}
catch {
$result = $false
}
return $result
}
foreach ($service in $services) {
$validationResult = Get-TcpConnectionAsync -ServicePrefix $service -Region $region
Write-Host "Reachability to $service is $validationResult"
}
```
Il valore `TcpTestSucceeded` deve restituire `True` per `s3`, `ec2`, `secretsmanager`, `logs`, `events`, `monitoring`, `ssm`, `ec2messages` e `ssmmessages`.
# Configurazione dell’autenticazione di Windows per le istanze RDS Custom per SQL Server
È consigliabile creare un’unità organizzativa dedicata e credenziali del servizio aventi come ambito tale unità organizzativa per qualsiasi Account AWS proprietario di un’istanza database RDS Custom per SQL Server aggiunta al tuo dominio AD. Dedicando un’unità organizzativa e le credenziali di servizio, puoi evitare autorizzazioni in conflitto e seguire il principio del privilegio minimo.
Le policy di gruppo a livello di Active Directory potrebbero entrare in conflitto con le automazioni e autorizzazioni AWS. È consigliabile selezionare GPO applicabili solo all’unità organizzativa creata per RDS Custom per SQL Server.
+ Per creare un’unità organizzativa e un utente di dominio AD in un AD autogestito o on-premises, è possibile connettere il controller di dominio come amministratore di dominio.
+ Per creare utenti e gruppi in una directory Directory Service, è necessario essere connessi a un’istanza di gestione e avere effettuato l’accesso con un utente che dispone di privilegi per creare utenti e gruppi. Per ulteriori informazioni, consulta [User and group management in AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) nella *Guida di amministrazione di AWS Directory Service*.
+ Per gestire Active Directory da un’istanza Amazon EC2 Windows Server, è necessario installare i servizi di dominio Active Directory e gli strumenti del servizio Active Directory Lightweight Directory nell’istanza EC2. Per ulteriori informazioni, consulta [Installazione degli strumenti di amministrazione di Active Directory per AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html) nella *Guida di amministrazione di AWS Directory Service*.
+ Per semplificare l’amministrazione, è consigliabile installare questi strumenti su un’istanza EC2 separata per l’amministrazione e non sull’istanza database RDS Custom per SQL Server.
Di seguito sono indicati i requisiti per un account del servizio di dominio AD.
+ Devi disporre di un account del servizio nel tuo dominio AD con autorizzazioni delegate per aggiungere computer al dominio. Un account del servizio di dominio è un account utente nel tuo dominio AD che dispone di autorizzazione delegata per eseguire determinate attività.
+ Delega le seguenti autorizzazioni all’account del servizio di dominio nell’unità organizzativa 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
+ Per AD autogestito e on-premises, l’account del servizio di dominio deve essere membro del gruppo “AWS Delegated Domain Name System Administrators”.
+ Per AWS Managed Microsoft AD, l’account del servizio di dominio deve essere membro del gruppo “DnsAdmins”.
Questo è il set minimo di autorizzazioni necessarie per aggiungere oggetti computer ad AD autogestito e AWS Managed Microsoft AD. Per ulteriori informazioni, consulta [Error: Access is denied when non-administrator users who have been delegated control try to join computers to a domain controller](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/access-denied-when-joining-computers) nella documentazione di Microsoft Windows Server.
**Importante**
Non spostare gli oggetti computer creati da RDS Custom per SQL Server nell’unità organizzativa (UO) dopo la creazione dell’istanza database. Lo spostamento degli oggetti associati potrebbe causare una configurazione errata dell’istanza database RDS Custom per SQL Server. Se devi spostare gli oggetti computer creati da Amazon RDS, utilizza l’operazione API RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) per modificare i parametri del dominio in base alla posizione desiderata degli oggetti computer.
**Topics**
+ [Fase 1: creazione di un’unità organizzativa (UO) in AD](#custom-sqlserver-WinAuth.settingUp.CreateOU)
+ [Fase 2: creazione un utente di dominio AD](#custom-sqlserver-WinAuth.settingUp.ADuser)
+ [Fase 3: delega del controllo all’utente AD in AWS Managed Microsoft AD o autogestito](#custom-sqlserver-WinAuth.settingUp.Delegate)
+ [Fase 4: creazione di un segreto](#custom-sqlserver-WinAuth.settingUp.ASM)
+ [Fase 5: creazione o modifica di un’istanza database RDS Custom per SQL Server](#custom-sqlserver-WinAuth.settingUp.CreateDBInstance)
+ [Fase 6: creazione di account di accesso di SQL Server per l’autenticazione di Windows](#custom-sqlserver-WinAuth.settingUp.CreateLogins)
+ [Fase 7: utilizzo dell’autenticazione Kerberos o NTLM](#custom-sqlserver-WinAuth.settingUp.KerbNTLM)
## Fase 1: creazione di un’unità organizzativa (UO) in AD
Utilizza la procedura seguente per creare un’unità organizzativa in AD:
**Creazione di un’unità organizzativa (UO) in AD**
1. Connettiti all’AD del dominio 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à organizzativa.
Abilita **Proteggi il container dall’eliminazione accidentale**.
1. Scegli **OK**. La nuova unità organizzativa apparirà sotto il dominio.
Per AWS Managed Microsoft AD, il nome di questa UO è basato sul nome NetBIOS digitato quando la directory è stata creata. Questa UO è di proprietà di AWS e contiene tutti i gli oggetti di directory correlati ad AWS per cui ti è stato concesso il controllo completo. Per impostazione predefinita, a questa UO corrispondono due UO secondarie: **Computer e Utenti**. Le nuove unità organizzative create da RDS Custom sono secondarie rispetto all’unità organizzativa basata su NetBIOS.
## Fase 2: creazione un utente di dominio AD
Le credenziali dell’utente del dominio vengono utilizzate per il segreto in Secrets Manager.
**Creazione di un utente 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. Fai clic su **Next (Successivo)**.
1. Immetti una password per l’utente. Non selezionare **L’utente deve cambiare la password al prossimo accesso** o **L’account è disabilitato**. Fai clic su **Next (Successivo)**.
1. Fai clic su **OK**. Il nuovo utente appare sotto il dominio.
## Fase 3: delega del controllo all’utente AD in AWS Managed Microsoft AD o autogestito
**Per delega il controllo all’utente del dominio AD nel dominio**
1. Apri lo snap-in MMC **Utenti e computer di Active Directory** e seleziona il dominio.
1. Fai clic con il pulsante destro del mouse sull’unità organizzativa creata in precedenza e scegli **Delega controllo**.
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’utente AD creato in precedenza e fai clic su **Controlla nomi**. Se il controllo degli utenti AD ha esito positivo, fai clic su **OK**.
1. Nella sezione **Utenti o gruppi**, verifica che l’utente AD sia stato aggiunto e fai clic su **Avanti**.
1. Nella pagina **Operazioni da delegare**, seleziona **Crea un’operazione personalizzata da delegare**, quindi fai clic su **Avanti**.
1. Nella sezione **Tipo di oggetto Active Directory**:
Seleziona **Solo i seguenti oggetti contenuti nella cartella**.
Seleziona **Oggetti computer**.
Seleziona **Crea oggetti selezionati in questa cartella**.
Seleziona **Elimina gli oggetti selezionati in questa cartella** e fai clic su **Avanti**.
1. Nella sezione **Autorizzazioni**:
Mantieni selezionata l’opzione **Generale**.
Seleziona **Scrittura convalidata in nome host DNS**.
Seleziona **Scrittura convalidata in nome principale servizio** e fai clic su **Avanti**.
1. In **Completamento della delega guidata del controllo**, conferma le impostazioni e fai clic su **Fine**.
## Fase 4: creazione di un segreto
Crea il segreto nello stesso Account AWS e nella stessa Regione contenente l’istanza database RDS Custom per SQL Server che desideri includere nella tua Active Directory. Memorizza le credenziali dell’utente del dominio AD creato in [Fase 2: creazione un utente di dominio AD](#custom-sqlserver-WinAuth.settingUp.ADuser).
------
#### [ Console ]
+ In Gestione dei segreti AWS, scegli **Archivia un nuovo segreto**.
+ Per **Secret type** (Tipo di segreto), scegli **Other type of secret** (Altro tipo di segreto).
+ In **Coppie chiave/valore**, aggiungi due chiavi:
+ Per la prima chiave, `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME` e inserisci il nome del tuo utente AD (senza il prefisso del dominio) come valore.
+ Per la seconda chiave, inserisci `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD` e inserisci la password per l’utente AD nel dominio.
+ Per **Chiave di crittografia**, inserisci la stessa AWS KMS chiave utilizzata per creare l’istanza RDS Custom per SQL Server.
+ Per **Nome segreto**, scegli il nome segreto che inizia con `do-not-delete-rds-custom-` per consentire al profilo dell’istanza di accedere a questo segreto. Se desideri scegliere un nome diverso per il segreto, aggiorna `RDSCustomInstanceProfile` per accedere a **Nome segreto**.
+ (Facoltativo) In **Descrizione**, inserisci una descrizione per il nome del segreto.
+ Aggiungi i tag `Key="AWSRDSCustom",Value="custom-sqlserver"`
+ Fai clic su **Salva**, quindi su **Avanti**.
+ In **Configura impostazioni di rotazione**, non modificare i valori predefiniti e scegli **Avanti**.
+ Controlla le impostazioni relative al segreto e fai clic su **Archivio**.
+ Scegli il nuovo segreto e copia il valore per **ARN secreto**. Questa informazione verrà utilizzata nella fase successiva per configurare Active Directory.
------
#### [ CLI ]
Esegui il comando seguente nella CLI per creare il segreto:
```
# Linux based
aws secretsmanager create-secret \
--name do-not-delete-rds-custom-DomainUserCredentails \
--description "Active directory user credentials for managing RDS Custom" \
--secret-string "{\"SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME\":\"tester\",\"SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD\":\"xxxxxxxx\"}" \
--kms-key-id \
--tags Key="AWSRDSCustom",Value="custom-sqlserver"
# Windows based
aws secretsmanager create-secret ^
--name do-not-delete-rds-custom-DomainUserCredentails ^
--description "Active directory user credentials for managing RDS Custom" ^
--secret-string "{\"SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME\":\"tester\",\"SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD\":\"xxxxxxxx\"}" ^
--kms-key-id ^
--tags Key="AWSRDSCustom",Value="custom-sqlserver"
```
------
## Fase 5: creazione o modifica di un’istanza database RDS Custom per SQL Server
Crea o modifica un’istanza database RDS Custom per SQL Server per l’utilizzo con la directory. Puoi utilizzare la console, CLI o l'API RDS per associare un'istanza database a una directory. Questa operazione può essere eseguita in uno dei seguenti modi:
+ Creare una nuova istanza database di SQL Server utilizzando la console, il comando CLI [ create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) o l'operazione API RDS [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html).
Per istruzioni, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md).
+ Modificare un'istanza database di SQL Server esistente utilizzando la console, il comando CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) o l'operazione API RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html).
Per istruzioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md).
+ Ripristinare un'istanza database 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 API RDS [ RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html).
Per istruzioni, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md).
+ Ripristinare un'istanza database di SQL Server in un point-in-time utilizzando la console, il comando CLI [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) o l’operazione API RDS [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html).
Per istruzioni, consultare [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md).
**Nota**
Se l’istanza RDS Custom per SQL Server è già aggiunta manualmente a un AD, controlla le impostazioni relative a [Regole per le porte della configurazione di rete](custom-sqlserver-WinAuth.NWConfigPorts.md) e [Convalida di rete](custom-sqlserver-WinAuth.NWValidation.md) e completa i passaggi da 1 a 4. Aggiorna `--domain-fqdn`, `--domain-ou` e `--domain-auth-secret-arn` sul tuo AD, in modo che le credenziali e le configurazioni di aggiunta al dominio siano registrate in RDS Custom per monitorare, registrare CNAME e intraprendere azioni di ripristino.
Quando utilizzi AWS CLI, sono necessari i seguenti parametri per consentire all'istanza database di utilizzare la directory che hai creato:
+ Per il parametro `--domain-fqdn`, usa il nome di dominio completo del dominio Active Directory 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 **ARN segreto** che hai creato.
**Importante**
Se modifichi un’istanza database per aggiungerla o rimuoverla da un dominio AD autogestito o AWS Managed Microsoft AD, è 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** comporta un tempo di inattività per le istanze database Single-AZ. Un cluster di database Multi-AZ esegue un failover prima di completare il riavvio. Per ulteriori informazioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md).
Il seguente comando CLI crea una nuova istanza database RDS Custom per SQL Server e la aggiunge a un dominio AWS Managed Microsoft AD o autogestito.
Per Linux, macOS o Unix:
```
aws rds create-db-instance \
--engine custom-sqlserver-se \
--engine-version 15.00.4312.2.v1 \
--db-instance-identifier my-custom-instance \
--db-instance-class db.m5.large \
--allocated-storage 100 --storage-type io1 --iops 1000 \
--master-username my-master-username \
--master-user-password my-master-password \
--kms-key-id my-RDSCustom-key-id \
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
--db-subnet-group-name my-DB-subnet-grp \
--vpc-security-group-ids my-securitygroup-id \
--no-publicly-accessible \
--backup-retention-period 3 \
--port 8200 \
--region us-west-2 \
--no-multi-az
```
Per Windows:
```
aws rds create-db-instance ^
--engine custom-sqlserver-se ^
--engine-version 15.00.4312.2.v1 ^
--db-instance-identifier my-custom-instance ^
--db-instance-class db.m5.large ^
--allocated-storage 100 --storage-type io1 --iops 1000 ^
--master-usernamemy-master-username ^
--master-user-password my-master-password ^
--kms-key-id my-RDSCustom-key-id ^
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
--db-subnet-group-name my-DB-subnet-grp ^
--vpc-security-group-ids my-securitygroup-id ^
--no-publicly-accessible ^
--backup-retention-period 3 ^
--port 8200 ^
--region us-west-2 ^
--no-multi-az
```
**Importante**
Se il NetBIOS per AWS Managed Microsoft AD è **corpexample**, viene visualizzato come UO. Qualsiasi nuova unità organizzativa creata in precedenza verrà visualizzata come unità organizzativa nidificata. Per AWS Managed Microsoft AD, imposta `--domain-ou` su `"OU=RDSCustomOU,OU=corpexample,DC=corp,DC=example,DC=com"`.
Il seguente comando modifica un’istanza database RDS Custom per SQL Server esistente in modo che utilizzi un dominio Active Directory.
Per Linux, macOS o Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
```
Per Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
```
Il seguente comando CLI rimuove un’istanza database RDS Custom per SQL Server da un dominio Active Directory.
Per Linux, macOS o Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--disable-domain
```
Per Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--disable-domain
```
Quando usi la console per creare o modificare l’istanza, fai clic su **Abilita l’autenticazione di Windows di Microsoft SQL Server** per visualizzare le seguenti opzioni.
![\[Directory di autenticazione Microsoft SQL Server Windows\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/custom-sqs-WinAuth.png)
È tua responsabilità assicurarti che il nome FQDN del tuo dominio venga risolto negli indirizzi IP del controller di dominio. Se gli IP del controller di dominio non vengono risolti, le operazioni di aggiunta al dominio non riescono, ma la creazione dell’istanza RDS Custom per SQL Server ha esito positivo. Per informazioni sulla risoluzione dei problemi, consulta [Risoluzione dei problemi di Active Directory](custom-sqlserver-WinAuth.Troubleshoot.md).
## Fase 6: creazione di account di accesso di 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, 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 tuo dominio AD. 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 utente AD possa autenticarsi su SQL Server, deve essere disponibile un accesso Windows SQL Server per l’utente AD o un gruppo di Active Directory di cui l’utente è membro. Il controllo granulare degli accessi viene gestito assegnando o revocando le autorizzazioni per questi login di SQL Server. Un utente che non dispone di un accesso SQL Server o non appartiene a un gruppo con tale accesso, non può accedere all’istanza database SQL Server.
È necessaria l’autorizzazione `ALTER ANY LOGIN` per creare un accesso SQL Server per AD. 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 crea gli accessi SQL Server per AD nel contesto dell’utente principale.
Esegui il comando DDL (Data Definition Language) seguente per creare un accesso SQL Server per un utente o un gruppo AD.
```
USE [master]
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
Gli utenti (persone e applicazioni) del tuo dominio possono ora connettersi all’istanza RDS Custom per SQL Server da un computer client associato al dominio utilizzando l’autenticazione di Windows.
## Fase 7: utilizzo dell’autenticazione Kerberos o NTLM
### Autenticazione NTLM tramite endpoint RDS
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 tramite l’autenticazione NTLM, devi connetterti all’endpoint RDS.
Durante una manutenzione pianificata del database o un’interruzione non pianificata del servizio, Amazon RDS esegue automaticamente il failover nel database secondario aggiornato, in modo che le operazioni possano riprendere rapidamente senza intervento manuale. 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 Custom per SQL Server richiede la connessione a uno specifico nome 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 Custom 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`, il corrispondente endpoint 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.
### Trovare il CNAME
Per trovare il tuo CNAME, connettiti al controller di dominio e apri **DNS Manager**. Vai a **Forward Lookup Zones** e al tuo FQDN.
Navigare in **awsrds**, **aws-region** e **hash specifico dell’account e della Regione**.
Se stai connettendo l’istanza RDS Custom EC2 e stai tentando di connetterti al database localmente utilizzando CNAME, la connessione utilizzerà l’autenticazione NTLM anziché Kerberos.
Se dopo aver connesso CNAME dal client remoto viene restituita una connessione NTLM, controlla se le porte richieste sono incluse nella lista consentita.
Per verificare che la connessione utilizzi Kerberos, esegui la seguente query:
```
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SSPID;
```
# Gestione di un'istanza database in un dominio
Puoi utilizzare la console, la AWS CLI o l'API Amazon RDS per gestire l'istanza database e la relativa relazione con il dominio. 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 provare ad associare nuovamente i domini per un'appartenenza non riuscita, utilizza l'operazione API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) e specifica l'ID della directory dell'appartenenza corrente.
+ Per aggiornare il nome del ruolo IAM dell'appartenenza, utilizza l'operazione API `ModifyDBInstance` e specifica l'ID della directory dell'appartenenza corrente e il nuovo ruolo IAM.
+ Per rimuovere un'istanza database da un dominio, utilizza l'operazione API `ModifyDBInstance` e specifica `none` come il parametro del dominio.
+ Per spostare un'istanza database da un dominio a un altro, utilizza l'operazione API `ModifyDBInstance` e specifica l'identificatore di dominio del nuovo dominio come parametro del dominio.
+ Per elencare l'appartenenza per ciascuna istanza database, utilizza l'operazione API [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html).
## Ripristino di un’istanza database RDS Custom per SQL Server e relativa aggiunta a un dominio Active Directory
Puoi ripristinare uno snapshot di database o eseguire il recupero point-in-time (PITR) di un’istanza database SQL Server e aggiungerla a un dominio Active Directory. Dopo aver ripristinato l’istanza database, modificala utilizzando il processo illustrato in [Fase 5: creazione o modifica di un’istanza database RDS Custom per SQL Server](custom-sqlserver-WinAuth.settingUp.md#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) per aggiungere l’istanza database a un dominio AD.
# Appartenenza al dominio
Quando l'istanza di database viene creata o modificata diventa membro del dominio. La console AWS indica lo stato di appartenenza al dominio dell'istanza di database. Lo stato dell'istanza di database può essere uno dei seguenti:
+ **joined (associata)** – L'istanza è membro del dominio.
+ **joining (in fase di associazione)** – L'istanza sta diventando membro del dominio.
+ **pending-join (associazione in sospeso)** – L'associazione dell'istanza è in sospeso.
+ **pending-maintenance-join**: AWS proverà a rendere l'istanza membro del dominio durante il successivo periodo di manutenzione programmato.
+ **pending-removal (rimozione in sospeso)** – La rimozione dell'istanza dal dominio è in sospeso.
+ **pending-maintenance-removal**: AWS proverà a rimuovere l'istanza dal dominio durante il successivo periodo di manutenzione programmato.
+ **failed (non riuscita)** – Un problema di configurazione ha impedito l'associazione dell'istanza al dominio. Verifica e correggi la configurazione prima di eseguire nuovamente il comando di modifica dell'istanza.
+ **removing (rimozione)** – È in corso la rimozione dell'istanza dal dominio.
Una richiesta di associazione a un dominio potrebbe non riuscire a causa di un problema di connettività di rete o di un ruolo IAM non corretto. Ad esempio, è possibile che venga creata un'istanza database o modificata un'istanza esistente senza però che questa diventi un membro di un dominio. In questo caso, emettere nuovamente il comando per creare o modificare l'istanza database o modificare l'istanza appena creata per aggiungerla al dominio.
# Risoluzione dei problemi di Active Directory
Di seguito sono riportati i problemi che potresti riscontrare quando configuri o modifichi AD.
| Codice di errore | Descrizione | 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 collegarsi all'unità organizzativa. | Rivedi il parametro `—domain-ou`. Assicurati che l'account del servizio di dominio disponga delle autorizzazioni corrette per l'unità organizzativa. |
| 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 Custom 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. |
| Errore 234/0xEA | L'unità organizzativa (UO) specificata non esiste. | L’unità organizzativa specificata con il parametro `—domain-ou` non esiste nel tuo AD. | Rivedi il parametro `—domain-ou` e assicurati che l’unità organizzativa specificata esista nel tuo AD. |
| 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 nel tuo AD. | Assicurati che le credenziali fornite in AWS Secrets Manager siano corrette e che l’account di dominio sia abilitato nel tuo Active Directory. |
| Errore 1355/0x54B | Il nome di dominio specificato non esiste o non può essere contattato. | Il dominio è inattivo, il set di IP DNS 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 Custom per SQL Server e assicurati che il tuo AD sia raggiungibile. |
| 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 Custom per SQL Server. |
| Errore 2224/0x8B0 | L'account utente esiste già. | L’account del computer che sta tentando di aggiungersi al tuo AD esiste già. | Identifica l’account del computer eseguendo `SELECT @@SERVERNAME` sull’istanza database RDS Custom per SQL Server, quindi rimuovilo con attenzione dal tuo AD. |
| 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 Custom per SQL Server al tuo AD. |