ECS: Come configurare una connessione al server AD o LDAP nell'interfaccia utente di

Confermare le informazioni ESATTE AD o LDAP da utilizzare.

È possibile che i valori immessi in ECS (vedere di seguito) non corrispondano ai dettagli sul server AD o LDAP e ciò può generare un output di errore di credenziale non valido per i tentativi di accesso dell'utente di dominio.

Visualizzare e verificare i valori nel server AD o LDAP.

Leggere la sezione Guida dell'amministratore ECS sul capitolo Provider di autenticazione e "Aggiunta di un provider di autenticazione AD o LDAP".

Sezione 1)
È obbligatorio che il provider di autenticazione sia configuratocorrettamente.
Il provider di autenticazione è la posizione in cui viene definita la connessione ECS al server AD o LDAP.

Sezione 2 e 3)
ECS può essere configurato in modo da utilizzare gli utenti AD o LDAP come utenti di oggetti o come utenti di gestione per accedere all'interfaccia utente di ECS.

Nella configurazione o nella risoluzione dei problemi, iniziare riducendo al minimo la complessità dei possibili problemi e procedendo in diversi passaggi.

1. Passare al provider di autenticazione dell'interfaccia utente > ECS e configurare un provider di autenticazione su un server AD o LDAP con un URL del server. Questo per ridurre al minimo la complessità.
   1. Nella casella URL del server, provare a utilizzare LDAP anziché LDAPS per il test, se possibile. Come se LDAP non funzionasse, allora nemmeno LDAPS funziona. 
   2. Disporre di un DN manager corretto.
   3. Impostare la base di ricerca in una cartella utenti esatta, non in una base di ricerca ampia, per evitare il superamento del valore di timeout LDAP.
   4. Come filtro di ricerca, selezionare il tipo corretto; gli attributi users sul server AD o LDAP mostreranno quale utilizzare. Vedere di seguito. Possibili opzioni di filtro di ricerca: sAMAccountName=%U, userPrincipalName=%u, uid=%U
   5. Si noti che una domanda comune è quale tipo di provider di autenticazione utilizzare. AD, Keystone o LDAP? Il consiglio è che se il server è un Active Directory di Windows, utilizzare il tipo AD. Se il server è un OpenLDAP Linux, utilizzare il tipo LDAP. Se il server è un Keystone, utilizzare Keystone. 
2. Aggiungere l'utente di test come utente di gestione del dominio e verificare l'accesso.
   1. Aggiunta dell'utente di test nell'interfaccia utente> ECS Aggiunta dell'utente> di gestione degli utenti >
   2. Il formato corretto sarebbe username@domainname, ECS utilizza il simbolo @ per rilevare che deve cercare un utente di dominio come definito nel provider di autenticazione.
   3. È necessario aggiungere utenti all'elenco degli utenti per definire i loro diritti su ECS, ovvero privilegi di amministratore o monitoraggio dell'utente.
3. Testare l'accesso dell'utente.
   1. Se l'accesso dell'utente di dominio non riesce, esaminare e risolvere i problemi  
      1. In caso di esito positivo, modificare la base di ricerca nella base di ricerca principale desiderata dall'utente, ovvero la posizione radice.
         1. Se l'operazione ha esito negativo, l'unica modifica tra accesso riuscito e non riuscito è una modifica della base di ricerca. Consultare l'articolo della knowledgebase ECS: errore intermittente di login non riuscito degli utenti di dominio a causa del superamento del valore del timeout AD/LDAP
         2. In caso di esito positivo, è ora possibile testare i gruppi di dominio.
   2. Se un utente può effettuare l'accesso, è possibile utilizzare anche un gruppo di utenti.
      1. Assicurarsi che il gruppo e gli utenti del gruppo richiesto rientrino nell'ambito della base di ricerca.
      2. È meglio testare un utente di prova come sopra per determinare che la connessione funzioni.
      3. Rimuovere l'utente di test del gruppo dall'elenco di gestione ECS e aggiungere invece il gruppo di test a cui appartiene l'utente all'elenco degli utenti di gestione ECS. Come nei passaggi precedenti, stiamo cercando di ridurre al minimo le possibili procedure di risoluzione dei problemi. L'unica differenza è che ora ECS è a conoscenza del gruppo e non dell'utente diretto.
      4. Leggere l'articolo della knowledgebase (per accedere all'articolo è necessario accedere all'account del supporto Dell). Ovvero, se si desidera utilizzare i gruppi, è necessario essere a conoscenza di questo articolo della Knowledge Base.
4. Con un utente o un gruppo di gestione in grado di effettuare l'accesso, è utile saperlo in quanto è più facile risolvere i problemi dell'utente di gestione del dominio configurato rispetto alla configurazione dell'utente dell'oggetto di dominio, quindi è bene eseguire un test.
   1.  Se un utente desidera quindi utilizzare un oggetto di dominio e può dimostrare a se stesso che gli stessi utenti di dominio funzionano come utente di gestione dell'interfaccia utente, è utile saperlo, poiché se un utente può lavorare come utente di gestione dell'interfaccia utente, dovrebbe lavorare come utente di oggetti.
5. Per i certificati LDAP (LDAP su SSL o TLS), consultare la guida dell'amministratore e l'articolo della knowledgebase ECS: Come configurare e accettare tutti i certificati su LDAPS su ECS
   1. Si consiglia di verificare che le connessioni LDAP funzionino e che gli utenti possano accedere su LDAP, prima di esaminare la configurazione di LDAPS.
   2. Nota: potrebbe essere necessaria una catena di certificati valida e completa.
   3. Se si utilizza LDAPS, gli URL del server nel provider di autenticazione devono essere nel formato FQDN anziché nell'indirizzo IP, in modo da corrispondere ai certificati LDAPS che elencherebbero l'FQDN dei server LDAP anziché l'indirizzo IP.   
       

Lo scopo dei passaggi elencati è quello di scontare i possibili problemi semplificandoli in passaggi da controllare.

Sezione 1: Provider
di autenticazioneConsultare la Guida dell'amministratore ECS per tutti i passaggi.

È possibile aggiungere provider di autenticazione a ECS se si desidera che gli utenti vengano autenticati da sistemi esterni a ECS.

Un provider di autenticazione è un sistema esterno a ECS in grado di autenticare gli utenti per conto di ECS.

ECS archivia le informazioni che gli consentono di connettersi al provider di autenticazione in modo che ECS possa richiedere l'autenticazione di un utente.

In ECS sono disponibili i seguenti tipi di provider di autenticazione:

• Autenticazione AD (Active Directory) o LDAP (Lightweight Directory Access Protocol): Utilizzata per autenticare gli utenti di dominio assegnati ai ruoli di gestione in ECS.
• Chiave di volta: Utilizzata per autenticare gli utenti di oggetti OpenStack Swift.

1. Creare l'utente o il gruppo in AD contenente gli utenti specifici che devono accedere a ECS:

1. Navigazione: Amministrare >Autenticazione

2.  Immettere il campo Name and Description e selezionare il tipo di server corretto:

 
Nota: Se si tenta di salvare un tipo errato, potrebbe essere visualizzato un messaggio di errore.

3. Inserire i domini da utilizzare.

4. URL del server AD o LDAP:

ldap://<Domain controller IP>:<port> Or ldaps://<Domain controller IP>:<port>

5. Modifica o aggiornamento del DN Manager.

 
Ad esempio: DN responsabile: CN=Administrator,CN=Users,DC=nas2008test,DC=com
Deve essere la posizione corretta dell'utente Manager DN sul server AD o LDAP.

Il DN del manager:
Si tratta dell'account utente associato ad Active Directory utilizzato da ECS per connettersi al server Active Directory o LDAP. Questo account viene utilizzato per eseguire ricerche in Active Directory quando un amministratore ECS specifica un utente per l'assegnazione dei ruoli.

Questo account utente deve disporre di "Leggi tutte le informazioni inetOrgPerson" in Active Directory. La classe oggetto InetOrgPerson viene utilizzata in diversi servizi directory non Microsoft, LDAP e X.500 per rappresentare le persone in un'organizzazione.

6. Opzione Provider

7. Impostazione degli attributi del gruppo:

8. Aggiornamento o modifica della whitelist del gruppo

9. Aggiornamento o modifica dell'ambito di ricerca

10. Aggiornamento o modifica della base di ricerca.

11. Filtro di ricerca

1. Verificare il filtro di ricerca corretto che gli utenti devono utilizzare:

dn:CN=user1,CN=Users,DC=marketing,DC=example,DC=com
userPrincipalName: user1@marketing.example.com
memberOf: CN=marketing,CN=Users,DC=example,DC=com

dn: uid=ldapuser1,ou=People,dc=example,dc=com
uid: ldapuser1
cn: ldapuser1
sn: ldapuser1

12. Configurazione di una foresta multidominio.

Una foresta multidominio è la posizione in cui sono presenti domini connessi tra loro, ad esempio un dominio padre e un dominio figlio.

Esempio principale: dell.com
esempio di domini figlio: amer.dell.com, emea.dell.com apac.dell.com

1) Un gruppo può trovarsi in uno dei domini e alcuni dei relativi utenti possono trovarsi in altri domini.
2) Normalmente i domini non sono visibili l'uno all'altro, ma il dominio padre può visualizzare tutti i domini figli, pertanto nella configurazione di una connessione forestale multidominio, utilizzare il dominio padre come dominio primario per il provider di autenticazione. 

Passaggi diversi:
A) Assegnare al dominio il nome dopo il dominio padre.
B) Elencare tutti i domini di interesse nel box domini del provider di autenticazione.
C) Se il provider di autenticazione supporta una foresta multidominio, utilizzare l'IP del server di catalogo globale e specificare sempre il numero di porta. Porte predefinite: LDAP: 3268, LDAPS: 3269
D) Impostare la base di ricerca sulla radice del dominio padre.
E) Nota: il nome del provider di autenticazione è l'identificatore principale per l'utilizzo da parte dell'utente di dominio. Cioè, per questo esempio, aggiungi utenti o gruppi come ad esempio: group1@dell.com, non un sottodominio come group1@amer.dell.com
Vedere la sezione Gestione e configurazione degli utenti dell'oggetto.

 
 

Sezione 2. Gestione e configurazione degli utenti dell'oggetto 

1. Aggiungere il gruppo come utente di gestione e scegliere i ruoli appropriati:

2. Testare l'accesso con l'altro utente del gruppo.

Sezione 3. Utenti AD o LDAP come utenti di oggetti configurati
La creazione di un utente di gestione è utile per testare la connessione ad AD o LDAP e deve essere eseguita prima di creare un utente di oggetti.

Consulta la guida per l'amministratore E la guida all'accesso ai dati.

1. Aggiungere utenti di dominio a un namespace per l'utilizzo da parte degli utenti di oggetti:

È necessario aggiungere (assegnare) utenti di dominio a un namespace se si desidera che questi utenti eseguano operazioni di utente di oggetti ECS. Per accedere all'archivio oggetti ECS, gli utenti di oggetti e gli amministratori dei namespace devono essere assegnati a un namespace. È possibile aggiungere un intero dominio di utenti a un namespace oppure è possibile aggiungere un sottoinsieme di utenti di dominio a un namespace specificando un particolare gruppo o attributo associato al dominio.

Un dominio può fornire utenti per più namespace. Ad esempio, è possibile decidere di aggiungere utenti, ad esempio il reparto Accounts nel dominio "yourco.com" in namespace1 e utenti come il reparto Finance nel dominio "yourco.com" in namespace2. In questo caso, il dominio "yourco.com" fornisce utenti per due namespace.

Un intero dominio, un determinato set di utenti o un determinato utente non può essere aggiunto a più di un namespace. Ad esempio, il dominio "yourco.com" può essere aggiunto al namespace1, ma il dominio non può essere aggiunto anche al namespace2.

L'esempio seguente mostra che un amministratore di sistema o di namespace ha aggiunto in un namespace un sottoinsieme di utenti nel dominio "yourco.com"; gli utenti con attributo Department = Accounts in Active Directory. L'amministratore di sistema o di namespace ha aggiunto gli utenti del reparto Accounts di questo dominio a un namespace utilizzando Edit namespace nel portale ECS.

Figura 1. Aggiunta di un sottoinsieme di utenti di dominio a un namespace utilizzando un attributo
AD Gli utenti dell'oggetto Domain selezionati nella selezione "domain" saranno utenti di oggetti non admin con diritti di accesso solo ai bucket creati.

 
Gli attributi sono un'opzione di sottoinsieme che può essere rimossa cliccando su "X".
Il sottoinsieme di attributi deve corrispondere agli attributi degli utenti di dominio sul server AD.

L'esempio seguente mostra un esempio diverso in cui System o Namespace Administrator utilizza una maggiore granularità nell'aggiunta di utenti a un namespace. In questo caso, l'amministratore di sistema o di namespace ha aggiunto nel dominio "yourco.com" i membri appartenenti al gruppo Storage Admins con l'attributo Department = Accounts AND Region attribute = Pacific, OPPURE appartengono al gruppo Storage Admins con l'attributo Department = Finance.

Figura 2. Aggiunta di un sottoinsieme di utenti di dominio a un namespace utilizzando più attributi AD

2. L'utente di dominio può creare una chiave segreta secondo quanto definito nella Guida all'accesso ai dati di ECS

user@device:~$ curl -ik -u TestUser@TestDomain.com https://10.xxx.xxx.xxx:4443/login
Enter host password for user 'TestUser@TestDomain.com':
HTTP/1.1 200 OK
Date: Thu, 09 Apr 2020 14:30:04 GMT
Content-Type: application/xml
Content-Length: 106
Connection: keep-alive
X-SDS-AUTH-TOKEN: BAAcYnJ_token_NlU0PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1ODYzNjE0Mjg5MTADAC51cm46VG9rZW46NGE3M2Q5ODYtODQ3My00ZjYxLTkwYWQtMzg5NTcyNmRmZGM3AgAC0A8=
X-SDS-AUTH-USERNAME: TestUser@TestDomain.com
X-SDS-AUTH-MAX-AGE: 28800

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn><user>TestUser@TestDomain.com</user></loggedIn>

user@device:~$ curl -ks -H "X-SDS-AUTH-TOKEN: BAAcYnJ_token_NlU0PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1ODYzNjE0Mjg5MTADAC51cm46VG9rZW46NGE3M2Q5ODYtODQ3My00ZjYxLTkwYWQtMzg5NTcyNmRmZGM3AgAC0A8=" https://10.xxx.xxx.xxx:4443/object/secret-keys | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user_secret_keys>
  <secret_key_1/>
  <secret_key_1_exist>false</secret_key_1_exist>
  <secret_key_2/>
  <secret_key_2_exist>false</secret_key_2_exist>
  <key_timestamp_1/>
  <key_timestamp_2/>
</user_secret_keys>

user@device:~$ curl -ks -H "X-SDS-AUTH-TOKEN: BAAcYnJ_token_NlU0PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1ODYzNjE0Mjg5MTADAC51cm46VG9rZW46NGE3M2Q5ODYtODQ3My00ZjYxLTkwYWQtMzg5NTcyNmRmZGM3AgAC0A8=" -H "Content-Type:application/json" -X POST -d "{}" https://10.xxx.xxx.xxx:4443/object/secret-keys | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user_secret_key>
  <link rel="self" href="/object/user-secret-keys/TestUser@TestDomain.com"/>
  <secret_key>6C7fW_Secret_Key_COl38yzAHIRorJ3oiK</secret_key>
  <key_expiry_timestamp/>
  <key_timestamp>2020-04-09 14:44:27.431</key_timestamp>
</user_secret_key>

Errore di accesso utente:

"Access is denied due to invalid or expired credentials."

 
 

Esempio dall'interfaccia utente di ECS 3.4:

 
    

1. Utente o password errato.
2. User not found e user not found potrebbero essere dovuti a una base di ricerca errata nel provider di autenticazione per tale utente.
3. L'applicazione delle modifiche apportate a un provider di autenticazione ECS può richiedere alcuni minuti e il provider di autenticazione corretto sta ancora aggiornando la connessione ad AD o LDAP.
4. Il parametro AD dell'utente "L'utente deve modificare la password al successivo accesso" è attivo per tale utente. ECS non può modificare la password degli utenti di dominio sul server AD o LDAP, pertanto ciò causa un errore, poiché il server AD o LDAP tenta di applicare il parametro. Modificare la password in un'applicazione diversa o deselezionare la casella di controllo del parametro. Si consiglia inoltre di utilizzare la versione 3.6.2.0 o successiva per questo problema, in quanto ECS richiede agli utenti di richiedere al server AD di "User must change password at next login."
5. All'utente di tipo sAMAccountName manca il valore di dominio corretto username@domain.
6. È possibile che la base di ricerca sia stata impostata su:

"Error 1008 (http:400): invalid parameter"

 
"Connection to the LDAP server succeeded, but the Manager DN CN=Users,DC=CAS,DC=EMC,DC=com or its password failed to authenticate"
 

1. È impostato sull'esatta posizione utente corretta, CN=Administrator,CN=Users,DC=CAS,DC=EMC,DC=com not CN=Users,DC=CAS,DC=EMC,DC=com 
2. La password è corretta.
3. L'utente dispone dell'autorizzazione richiesta per essere l'utente Manager DN.  

command type REQUEST_AUTHPROVIDER_CREATE failed with error code ERROR_RG_NOT_FOUND and message 'replication group urn:storageos:ReplicationGroupInfo:00000000-0000-0000-0000-000000000000:global not found'

Se un utente ha modificato il server LDAP, mentre l'FQDN del nuovo server LDAP corrisponde all'FQDN del server LDAP precedente.

Il certificato SSL LDAP corrente può puntare al server LDAP precedente, pertanto il certificato SSL LDAP deve essere sostituito con un certificato SSL LDAP aggiornato.

Possibile messaggio di errore:

 

Verificare che il certificato sia stato emesso e verificare che l FQDN corrisponda esattamente all'URL utilizzato nell'interfaccia utente di ECS. In alternativa, verificare che i nomi alternativi del soggetto corrispondano esattamente al comando certificate:

Command:

sudo openssl s_client -connect :636 < /dev/null | openssl x509 -noout -text | grep DNS:

Esempio:

node1:~ # sudo openssl s_client -connect XXX.XXX.XXX:636 < /dev/null| openssl x509 -noout -text | grep DNS:
 
depth=0
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
verify error:num=21:unable to verify the first certificate
verify return:1
                DNS:FQDN.LDAPS1.LOCAL


node1:~ # sudo openssl s_client -connect XXX.XXX.XXX:636| openssl x509 -noout -text | grep DNS:
 
depth=0
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
verify error:num=21:unable to verify the first certificate
verify return:1
                DNS:FQDN.LDAPS.LOCAL

 
Esaminare il certificato LDAPS sulle corrispondenze ECS. In caso contrario, potrebbe essere necessario un nuovo certificato corretto per ECS. 

In tal caso, un utente potrebbe valutare la possibilità di aprire una SR con il supporto ECS per assistenza.

---

 

1. Il campo Authentication Provider è stato compilato correttamente dall'utente?
2. L'utente di gestione è stato creato?
3. L'utente e la password di test sono stati immessi correttamente al momento dell'accesso ECS?
4. È in grado di accedere con un altro utente da un dominio?
5. È la prima volta che si configura AD o LDAP su ECS?
6. Se non è stato configurato un nuovo AD o LDAP su ECS, è mai stato possibile accedere con queste credenziali? In caso affermativo, identificare se sono state apportate modifiche che potrebbero influire sull'autorizzazione.