Gli utenti possono accedere a vCenter Server solo se fanno parte di un dominio che è stato aggiunto come origine identità di vCenter Single Sign-On. Gli utenti amministratori di vCenter Single Sign-On possono aggiungere origini identità o modificare le impostazioni relative alle origini identità che hanno aggiunto.

Un'origine identità può essere Active Directory su LDAP, un dominio nativo di Active Directory (autenticazione integrata Windows) o un servizio di directory OpenLDAP. Vedere Origini identità per vCenter Server con vCenter Single Sign-On.

Immediatamente dopo l'installazione, è disponibile il dominio vsphere.local (o il dominio specificato durante l'installazione) con gli utenti interni di vCenter Single Sign-On.

Nota:

Se è stato aggiornato o sostituito il certificato SSL di Active Directory, è necessario rimuovere e quindi aggiungere nuovamente l'origine identità in vCenter Server.

Prerequisiti

Per aggiungere un'origine identità Active Directory (autenticazione integrata Windows), vCenter Server deve far parte del dominio Active Directory. Vedere Aggiunta di un vCenter Server a un dominio Active Directory.

Procedura

  1. Accedere con vSphere Client a vCenter Server.
  2. Specificare il nome utente e la password per [email protected] o un altro membro del gruppo di amministratori di vCenter Single Sign-On.
    Se durante l'installazione è stato specificato un dominio diverso, accedere come administrator@ mydomain.
  3. Passare all'interfaccia utente di configurazione.
    1. Dal menu Home, selezionare Amministrazione.
    2. In Single Sign-On fare clic su Configurazione.
  4. Nella scheda Provider di identità, fare clic su Origini identità, quindi su Aggiungi.
  5. Selezionare l'origine identità e immetterne le impostazioni.
    Opzione Descrizione
    Active Directory (autenticazione integrata Windows) Utilizzare questa opzione per le implementazioni native di Active Directory. Se si desidera utilizzare questa opzione, la macchina in cui è in esecuzione il servizio vCenter Single Sign-On deve trovarsi in un dominio Active Directory.

    Vedere Impostazioni dell'origine identità Active Directory.

    Active Directory su LDAP Per questa opzione è necessario specificare il controller di dominio e altre informazioni. Vedere Impostazioni di Active Directory su LDAP e impostazioni dell'origine identità del server OpenLDAP.
    OpenLDAP Utilizzare questa opzione per un'origine identità OpenLDAP. Vedere Impostazioni di Active Directory su LDAP e impostazioni dell'origine identità del server OpenLDAP.
    Nota:

    Se l'account utente è bloccato o disattivato, le autenticazioni e le ricerche di gruppi e utenti nel dominio Active Directory non vengono eseguite correttamente. L'account utente deve disporre dell'accesso in sola lettura sull'unità organizzativa di utenti e gruppi e deve essere in grado di leggere gli attributi di utenti e gruppi. Active Directory fornisce questo accesso per impostazione predefinita. Per maggiore sicurezza, utilizzare un utente del servizio speciale.

  6. Fare clic su Aggiungi.

Operazioni successive

Inizialmente, a ogni utente viene assegnato il ruolo Nessun accesso. Affinché un utente possa accedere, un amministratore di vCenter Server deve assegnargli almeno il ruolo Sola lettura. Vedere l'argomento sull'utilizzo dei ruoli per assegnare privilegi nella documentazione Sicurezza di vSphere.

Impostazioni di Active Directory su LDAP e impostazioni dell'origine identità del server OpenLDAP

L'origine identità Active Directory su LDAP è preferibile rispetto all'opzione Active Directory (autenticazione integrata Windows). L'origine identità del server OpenLDAP è disponibile per ambienti che utilizzano OpenLDAP.

Se si configura un'origine identità OpenLDAP, vedere l'articolo della Knowledge Base di VMware all'indirizzo https://kb.vmware.com/s/article/2064977 per informazioni sui requisiti aggiuntivi.

Importante: I gruppi nelle origini identità AD su LDAP non possono usare utenti in domini diversi, anche se si crea un'origine identità aggiuntiva per ogni dominio.

I gruppi nelle origini identità LDAP riconoscono solo gli utenti presenti nel DN di base dell'utente specificato. Questo può causare problemi imprevisti in ambienti Active Directory di grandi dimensioni con domini secondari. Ad esempio, si consideri lo scenario seguente:

  1. Una foresta di Active Directory con due domini secondari, ChildA e ChildB.
  2. Un vCenter Server configurato con due origini identità AD su LDAP, una per il dominio secondario ChildA e una per il dominio secondario ChildB.
  3. ChildA contiene due utenti denominati UserA1 e UserA2.
  4. ChildB contiene due utenti denominati UserB1 e UserB2.

L'amministratore di vCenter Server crea in ChildA un gruppo denominato TestGroup contenente UserA1, UserA2, UserB1 e UserB2. L'amministratore di vCenter Server concede privilegi di accesso (o ANY) a TestGroup. Purtroppo, UserB1 e UserB2 non possono accedere perché si trovano in un dominio diverso da quello del gruppo.

Per risolvere questo problema, eseguire le operazioni seguenti:

  1. Creare un altro gruppo denominato SecondTestGroup in ChildB.
  2. Rimuovere UserB1 e UserB2 da TestGroup.
  3. Aggiungere UserB1 e UserB2 a SecondTestGroup.
  4. In vCenter Server, assegnare a SecondTestGroup gli stessi privilegi concessi a TestGroup.
Nota: In Microsoft Windows, il comportamento predefinito di Active Directory è stato modificato in modo da richiedere autenticazione e crittografia forti. Questa modifica influisce sul modo in cui vCenter Server esegue l'autenticazione in Active Directory. Se si utilizza Active Directory come origine identità per vCenter Server, è necessario abilitare LDAPS. Per ulteriori informazioni su questo aggiornamento della sicurezza di Microsoft, vedere https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023 e https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html.
Tabella 1. Impostazioni server OpenLDAP e Active Directory su LDAP
Opzione Descrizione
Nome Nome dell'origine identità.
DN di base per gli utenti Nome distinto di base per gli utenti. Immettere il DN da cui iniziare le ricerche utente. Ad esempio, cn=Users,dc=myCorp,dc=com.
DN di base per i gruppi Il nome distinto di base per i gruppi. Immettere il DN da cui iniziare le ricerche di gruppi. Ad esempio, cn=Groups,dc=myCorp,dc=com.
Nome dominio FQDN del dominio.
Alias dominio Per le origini identità di Active Directory, il nome NetBIOS del dominio. Aggiungere il nome NetBIOS del dominio Active Directory come alias dell'origine identità se si utilizzano autenticazioni SSPI.

Per le origini identità OpenLDAP, viene aggiunto il nome dominio in lettere maiuscole se non si specifica un alias.

Nome utente ID di un utente nel dominio che dispone di un minimo di accesso in sola lettura al DN di base per utenti e gruppi. L'ID può essere in uno dei seguenti formati:
  • Nome principale ([email protected])
  • NetBIOS (DOMINIO\utente)
  • DN (cn=user,cn=Users,dc=domain,dc=com)
Il nome utente deve essere completo. La voce "user" non è utilizzabile.
Password Password dell'utente specificato da Nome utente.
Connetti a Controller di dominio a cui connettersi. Può essere qualsiasi controller di dominio nel dominio o un controller specifico.
URL server primario Server LDAP del controller di dominio primario relativo al dominio. È possibile utilizzare il nome host o l'indirizzo IP.

Utilizzare il formato ldap://hostname_or_IPaddress:port o ldaps://hostname_or_IPaddress:port. La porta è in genere 389 per le connessioni LDAP e 636 per le connessioni LDAPS. In caso di distribuzioni del controller multi-dominio Active Directory, le porte sono in genere 3268 per LDAP e 3269 per LDAPS.

Quando si utilizza ldaps:// nell'URL LDAP primario o secondario, è necessario un certificato che stabilisca l'attendibilità per l'endpoint LDAPS del server di Active Directory.

URL server secondario Indirizzo di un server LDAP del controller di dominio secondario utilizzato quando il controller di dominio primario non è disponibile. È possibile utilizzare il nome host o l'indirizzo IP. Per ogni operazione di LDAP, vCenter Server prova sempre il controller di dominio primario prima di eseguire il fallback al controller di dominio secondario. Per questo è possibile che gli accessi ad Active Directory impieghino un po' di tempo e addirittura non riescano quando il controller di dominio primario non è disponibile.
Nota: Quando si verifica un errore nel controller di dominio primario, è possibile che il controller di dominio secondario non venga attivato automaticamente.
Certificati (per LDAPS) Se si desidera utilizzare LDAPS con il server LDAP di Active Directory o con l'origine identità del server OpenLDAP, fare clic su Sfoglia per selezionare un certificato esportato dal controller del dominio specificato nell'URL Ldaps. (Si noti che il certificato qui utilizzato non è un certificato CA radice). Per esportare il certificato da Active Directory, consultare la documentazione Microsoft.

È possibile cercare e selezionare più certificati.

Suggerimento: Quando si cercano e si selezionano più certificati, devono trovarsi nella stessa directory.

vCenter Server considera attendibili solo i certificati firmati direttamente da un'autorità di certificazione registrata e attendibile. vCenter Server non traccia il percorso fino a un certificato CA registrato e controlla solo se il certificato è firmato da un'autorità di certificazione registrata e attendibile. Se il certificato è firmato da un'autorità di certificazione pubblicamente attendibile o è autofirmato, non sono necessarie ulteriori azioni. Tuttavia, se si creano certificati interni personalizzati (ovvero si utilizza un'autorità di certificazione privata), potrebbe essere necessario includere tali certificati. Ad esempio, se l'organizzazione utilizza Microsoft Enterprise Root Certificate Authority per generare il certificato LDAPS, è necessario selezionare anche il certificato root aziendale per aggiungerlo a vCenter Server. Inoltre, se si utilizzano autorità di certificazione intermedie tra il certificato LDAPS e il certificato root aziendale, è necessario selezionare anche tali certificati intermedi per aggiungerli a vCenter Server.

Impostazioni dell'origine identità Active Directory

Se si seleziona il tipo di origine identità Active Directory (Integrated Windows Authentication, autenticazione integrata Windows), è possibile utilizzare l'account della macchina locale come Nome entità servizio (SPN) o specificare esplicitamente un SPN. Per poter utilizzare questa opzione è necessario che il server di vCenter Single Sign-On faccia parte di un dominio Active Directory.

Prerequisiti per l'utilizzo di un'origine identità Active Directory (autenticazione integrata Windows)

È possibile configurare vCenter Single Sign-On in modo che utilizzi un'origine identità Active Directory (autenticazione integrata Windows) solo se tale origine è disponibile. Seguire le istruzioni riportate nella documentazione di Configurazione di vCenter Server.

Nota: Active Directory (autenticazione integrata Windows) utilizza sempre la radice della foresta di domini Active Directory. Per configurare l'origine identità dell'Autenticazione integrata Windows con un sottodominio all'interno della foresta di Active Directory, vedere l'articolo della Knowledge Base di VMware all'indirizzo https://kb.vmware.com/s/article/2070433.

Selezionare Usa account macchina per velocizzare la configurazione. Se si prevede di rinominare la macchina locale in cui viene eseguito vCenter Single Sign-On, è preferibile specificare esplicitamente un SPN.

Se è stata abilitata la registrazione degli eventi diagnostici in Active Directory per individuare dove potrebbe essere necessaria una protezione avanzata, è possibile visualizzare un evento del registro con ID evento 2889 nel server della directory. L'ID evento 2889 viene generato come anomalia anziché come rischio di sicurezza quando si utilizza l'autenticazione integrata Windows. Per ulteriori informazioni sull'ID evento 2889, vedere l'articolo della Knowledge Base di VMware all'indirizzo https://kb.vmware.com/s/article/78644.

Tabella 2. Impostazioni aggiunta origine identità
Casella di testo Descrizione
Nome dominio FQDN del nome dominio, ad esempio: mydomain.com. Non specificare un indirizzo IP. Il nome dominio deve essere risolvibile tramite DNS dal sistema vCenter Server.
Usa account macchina Selezionare questa opzione per utilizzare l'account della macchina locale come SPN. Quando si seleziona questa opzione, è sufficiente specificare il nome del dominio. Non selezionare questa opzione se si prevede di rinominare la macchina.
Usa nome entità servizio (SPN) Selezionare questa opzione se si prevede di rinominare la macchina locale. È necessario specificare un nome entità servizio, un utente in grado di autenticarsi con l'origine identità e una password utente.
Nome entità servizio (SPN) Nome dell'entità del servizio che consente a Kerberos di identificare il servizio Active Directory. Includere il dominio nel nome, ad esempio STS/example.com.

Il nome SPN deve essere univoco nel dominio. L'esecuzione del comando setspn -S controlla che non venga creato alcun duplicato. Per informazioni su setspn, vedere la documentazione Microsoft.

Nome dell'entità utente (UPN)

Password

Nome e password di un utente che può eseguire l'autenticazione con questa origine identità. Utilizzare il formato dell'indirizzo e-mail, ad esempio [email protected]. È possibile verificare il nome dell'entità utente con l'editor delle interfacce del servizio Active Directory (ADSI Edit).

Aggiunta o rimozione di un'origine identità tramite la CLI

È possibile utilizzare l'utilità sso-config per aggiungere o rimuovere un'origine identità.

Un'origine identità può essere un dominio Active Directory nativo (autenticazione integrata Windows), AD su LDAP, AD su LDAP tramite LDAPS (LDAP su SSL) o OpenLDAP. Vedere Origini identità per vCenter Server con vCenter Single Sign-On. È inoltre possibile utilizzare l'utility sso-config per configurare l'autenticazione con RSA SecurID e smart card.

Prerequisiti

Per aggiungere un'origine identità Active Director, vCenter Server deve trovarsi nel dominio Active Directory. Vedere Aggiunta di un vCenter Server a un dominio Active Directory.

Abilitare l'accesso a SSH. Vedere Gestione di vCenter Server mediante la shell di vCenter Server.

Procedura

  1. Utilizzare SSH o un'altra connessione a console remota per avviare una sessione nel sistema di vCenter Server.
  2. Accedere come root.
  3. Passare alla directory in cui si trova l'utilità sso-config.
    cd /opt/vmware/bin
  4. Per esempi di utilizzo, fare riferimento alla guida di sso-config eseguendo il comando sso-config.sh -help oppure consultare l'articolo della Knowledge Base di VMware all'indirizzo https://kb.vmware.com/s/article/67304.