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.
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
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.
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:
- Una foresta di Active Directory con due domini secondari, ChildA e ChildB.
- Un vCenter Server configurato con due origini identità AD su LDAP, una per il dominio secondario ChildA e una per il dominio secondario ChildB.
- ChildA contiene due utenti denominati UserA1 e UserA2.
- 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:
- Creare un altro gruppo denominato SecondTestGroup in ChildB.
- Rimuovere UserB1 e UserB2 da TestGroup.
- Aggiungere UserB1 e UserB2 a SecondTestGroup.
- In vCenter Server, assegnare a SecondTestGroup gli stessi privilegi concessi a TestGroup.
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:
|
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.
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.
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.