ECS: Så här ställer du in en AD- eller LDAP-serveranslutning i användargränssnittet

Bekräfta den EXAKTA AD- eller LDAP-informationen som ska användas.

Det kan hända att de värden som anges i ECS (se nedan) inte matchar informationen på AD- eller LDAP-servern, och detta kan generera felutdata om ogiltiga autentiseringsuppgifter för domänanvändarens inloggningsförsök.

Visa och kontrollera värdena på AD- eller LDAP-servern.

Läs avsnittet i ECS-administratörsguiden i kapitlet Autentiseringsproviders och "Lägg till en AD- eller LDAP-autentiseringsleverantör".

Avsnitt 1)
Det är obligatoriskt att ha autentiseringsprovidern korrekt konfigurerad.
Autentiseringsprovidern är den plats där ECS-anslutningen till AD- eller LDAP-servern definieras.

2 och 3 §)
ECS kan ställas in för att använda AD- eller LDAP-användare som objektanvändare eller som hanteringsanvändare för att logga in på ECS-användargränssnittet.

Börja med att minimera komplexiteten hos de möjliga problemen vid konfigurationen eller felsökningen och fortsätt i flera steg.

1. Gå till ECS UI > Authentication Provider och konfigurera en autentiseringsprovider till en AD- eller LDAP-server med en server-URL. Detta för att minimera komplexiteten.
   1. I rutan server-URL försöker du använda LDAP i stället för LDAPS för testning, om det är möjligt. Som om LDAP inte fungerar, så gör inte LDAPS det heller. 
   2. Ha en korrekt chef DN.
   3. Ställ in sökbasen i en exakt användarmapp, inte en stor sökbas, detta för att diskontera LDAP-timeoutvärdet som överskrids.
   4. Som ett sökfilter väljer du rätt typ, användarattributen på AD- eller LDAP-servern visar vilken som ska användas. Se nedan. Möjliga sökfilteralternativ: sAMAccountName=%U, userPrincipalName=%u, uid=%U
   5. Observera att en vanlig fråga är vilken typ av autentiseringsprovider som ska användas. AD, Keystone eller LDAP? Rådet är att om servern är en Windows Active Directory ska du använda AD-typen. Om servern är en Linux openLDAP använder du LDAP-typen. Om servern är en Keystone ska du använda Keystone. 
2. Lägg till testanvändaren som domänhanteringsanvändare och testa inloggningen.
   1. Lägg till testanvändaren i ECS-användargränssnittet>– hantering >av användare>
   2. Rätt format skulle vara username@domainname. ECS använder symbolen @ för att identifiera att det ska söka efter en domänanvändare enligt definitionen i autentiseringsprovidern.
   3. Du måste lägga till användare i användarlistan för att definiera deras rättigheter för ECS som är administratörs- eller övervakningsanvändarbehörigheter.
3. Testa användarinloggningen.
   1. Om det inte går att logga in på domänanvändaren ska du undersöka och felsöka  
      1. Om det lyckas ändrar du sökbasen till den huvudsakliga sökbasen som användarna vill ha, det vill säga rotplatsen,
         1. Om det sedan misslyckas är den enda ändringen mellan en lyckad inloggning och misslyckad en ändring av sökdatabasen, se kunskapsbasartikel ECS: Återkommande fel vid inloggning för domänanvändare på grund av att AD/LDAP-timeoutvärdet överskrids
         2. Om det lyckas kan domängrupperna nu testas.
   2. Om en användare kan logga in kan även en användargrupp användas.
      1. Se till att gruppen och användarna i den önskade gruppen ligger inom sökdatabasens omfång.
      2. Det är bäst att testa en testanvändare som ovan för att fastställa att anslutningen fungerar.
      3. Ta bort testanvändaren för gruppen från ECS-hanteringslistan och lägg i stället till den testgrupp som användaren tillhör i listan ECS-hanteringsanvändare. Det är som med stegen ovan, vi försöker minimera eventuell felsökning. Den enda skillnaden är att ECS nu känner till gruppen och inte den direkta användaren.
      4. Läs kunskapsbasartikeln (inloggning till Dells supportkonto krävs för att få åtkomst till artikeln). Det innebär att om du vill använda grupper måste du känna till den här kunskapsbasartikeln.
4. Med en hanteringsanvändare eller grupp som kan logga in är det bra att veta eftersom det är lättare att felsöka konfiguration av domänhanteringsanvändare än användarkonfiguration av domänobjekt, så det är bra att testa.
   1.  Om en användare sedan vill använda domänobjekt och kan bevisa för sig själv att samma domänanvändare fungerar som användare av användargränssnittshantering, är det bra att veta, för om en användare kan arbeta som användare av användargränssnittshantering bör de arbeta som en objektanvändare.
5. Information om LDAP-certifikat (LDAP över SSL eller TLS) finns i administratörsguiden och kunskapsartikeln ECS: Så här konfigurerar och accepterar du alla certifikat via LDAPS på ECS
   1. Vi rekommenderar att du kontrollerar att LDAP-anslutningarna fungerar och att användarna kan logga in på LDAP innan du undersöker konfigurationen av LDAPS.
   2. Observera att en giltig och fullständig certifikatkedja kan krävas.
   3. Om du använder LDAPS måste server-URL:erna i autentiseringsprovidern vara i FQDN-format i stället för IP-adressen, för att matcha LDAPS-certifikaten som listar LDAP-servrarnas FQDN i stället för IP-adressen.   
       

Syftet med de steg som listas är att diskontera möjliga problem genom att förenkla problemen i steg som ska kontrolleras.

Avsnitt 1: Autentiseringsleverantör
Alla steg finns i ECS-administratörsmanualen.

Du kan lägga till autentiseringsproviders till ECS om du vill att användare ska autentiseras av system som är externa till ECS.

En autentiseringsleverantör är ett externt system som kan autentisera användare för ECS räkning.

ECS lagrar den information som gör att den kan ansluta till autentiseringsleverantören så att ECS kan begära autentisering av en användare.

I ECS är följande typer av autentiseringsproviders tillgängliga:

• AD-autentisering (Active Directory) eller LDAP-autentisering (Lightweight Directory Access Protocol): Används för att autentisera domänanvändare som har tilldelats hanteringsroller i ECS.
• Hörnsten: Används för att autentisera användare av OpenStack Swift-objekt.

1. Skapa användaren eller gruppen i AD som innehåller de specifika användare som måste logga in ECS:

1. Navigering: Förvalta >Autentisering

2.  Ange fältet Namn och beskrivning och välj rätt servertyp:

 
Obs! Ett felmeddelande kan visas om en felaktig typ försöker sparas.

3. Ange de domäner som ska användas.

4. URL för AD- eller LDAP-server:

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

5. Ändra eller uppdatera chefens DN.

 
Till exempel: Chef DN: CN=Administratör,CN=Användare,DC=nas2008test,DC=com
Måste vara rätt plats för Manager DN-användaren på AD- eller LDAP-servern.

Chefen DN:
Det här är det Active Directory Bind-användarkonto som ECS använder för att ansluta till Active Directory- eller LDAP-servern. Det här kontot används för att söka i Active Directory när en ECS-administratör anger en användare för rolltilldelning.

Det här användarkontot måste ha "Read all inetOrgPerson-information" i Active Directory. Objektklassen InetOrgPerson används i flera katalogtjänster som inte kommer från Microsoft, LDAP och X.500 för att representera personer i en organisation.

6. Leverantörsalternativ

7. Ställa in gruppattribut:

8. Uppdatera eller ändra vitlistningen av grupp

9. Uppdatera eller ändra sökomfånget

10. Uppdatera eller ändra sökbasen.

11. Sökfilter

1. Bekräfta rätt sökfilter som användarna ska använda:

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. Konfiguration av skogar med flera domäner.

En multidomänskog är där det finns domäner som är anslutna till varandra, till exempel en överordnad och underordnad domän.

Exempel på överordnade domäner: Exempel på dell.com
underordnade domäner: amer.dell.com, emea.dell.com, apac.dell.com

1) En grupp kan finnas i en av domänerna och vissa av dess användare kan finnas i andra domäner.
2) Normalt är domänerna inte synliga för varandra, men den överordnade domänen kan se alla underordnade domäner, så när du konfigurerar en skogsanslutning med flera domäner ska du använda den överordnade domänen som primär domän för autentiseringsprovidern. 

Steg som skiljer sig åt:
A) Namnge domänen efter den överordnade domänen.
B) Lista alla domäner av intresse i rutan domäner hos autentiseringsleverantören.
C) Om autentiseringsleverantören har stöd för en skog med flera domäner ska du använda IP-adressen för den globala katalogservern och alltid ange portnumret. Standardportar: LDAP: 3268, LDAPS: 3269
D) Ställ in sökbasen på roten för den överordnade domänen.
E) Observera att autentiseringsleverantörens namn skulle vara den primära identifieraren för domänanvändaranvändningen. Det vill säga i det här exemplet, lägg till användare eller grupper som till exempel: group1@dell.com, inte en underdomän som group1@amer.dell.com
Se avsnittet Hantering och objekt som användare ställer in.

 
 

Avsnitt 2: Hantering och objekt Användarkonfiguration 

1. Lägg till gruppen som hanteringsanvändare och välj rätt roller:

2. Testa inloggningen med den andra användaren i gruppen.

Avsnitt 3: AD- eller LDAP-användare som objektanvändare ställer in
Att skapa en hanteringsanvändare är användbart för att testa anslutningen till AD eller LDAP och bör göras innan du skapar en objektanvändare.

Se administratörsmanualen OCH dataåtkomstguiden.

1. Lägg till domänanvändare i ett namnområde för objektanvändaranvändning:

Du måste lägga till (tilldela) domänanvändare i ett namnområde om du vill att dessa användare ska utföra ECS-objektanvändaråtgärder. För att få åtkomst till ECS-objektlagret måste objektanvändare och namnområdesadministratörer tilldelas ett namnområde. Du kan lägga till en hel domän med användare i ett namnområde, eller så kan du lägga till en delmängd av domänanvändarna i ett namnområde genom att ange en viss grupp eller ett attribut som är associerat med domänen.

En domän kan tillhandahålla användare för flera namnområden. Du kan till exempel välja att lägga till användare som kontoavdelningen i domänen "yourco.com" i namespace1 och användare som ekonomiavdelningen i domänen "yourco.com" i namespace2. I det här fallet tillhandahåller domänen "yourco.com" användare för två namnområden.

En hel domän, en viss uppsättning användare eller en viss användare kan inte läggas till i mer än ett namnområde. Domänen "yourco.com" kan till exempel läggas till i namespace1, men domänen kan inte också läggas till i namespace2.

I följande exempel visas att en system- eller namnområdesadministratör har lagt till en delmängd av användarna i domänen "yourco.com" i ett namnområde. de användare som har sitt avdelningsattribut = Konton i Active Directory. System- eller namnområdesadministratören har lagt till användarna på kontoavdelningen från den här domänen i ett namnområde med hjälp av namnområdet Edit i ECS-portalen.

Figur 1. Lägga till en delmängd av domänanvändare i ett namnområde med hjälp av ett AD-attribut
Domänobjektanvändare som valts under valet "domän" skulle endast vara icke-adminobjektanvändare med åtkomsträttigheter till sina egna skapade bucketar.

 
Attribut är ett delmängdsalternativ som kan tas bort genom att klicka på "X".
Delmängden Attribut måste matcha domänanvändarens attribut på AD-servern.

I följande exempel visas ett annat exempel där system- eller namnområdesadministratören använder mer detaljerad information för att lägga till användare i ett namnområde. I det här fallet har system- eller namnområdesadministratören lagt till medlemmarna i domänen "yourco.com" som tillhör gruppen Lagringsadministratörer med attributet Avdelning = Konton OCH Regionattribut = Pacific, ELLER tillhör gruppen Lagringsadministratörer med attributet Avdelning = Ekonomi.

Bild 2. Lägga till en delmängd av domänanvändare i ett namnområde med hjälp av flera AD-attribut

2. Domänanvändare ska skapa en hemlig nyckel enligt ECS-manualen för dataåtkomst

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>

Fel vid användarinloggning:

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

 
 

Exempel från 3.4 ECS-gränssnitt:

 
    

1. Användaren eller lösenordet är felaktigt.
2. Användaren hittades inte och användaren hittades inte kan bero på en felaktig sökbas i autentiseringsprovidern för den användaren.
3. Det kan ta några minuter innan ändringar av en ECS-autentiseringsprovider börjar gälla och den korrigerade autentiseringsprovidern uppdaterar fortfarande anslutningen till AD eller LDAP.
4. Användarens AD-parameter "Användaren måste ändra lösenordet vid nästa inloggning" är aktiv för den användaren. Observera att ECS inte kan ändra domänanvändarens lösenord på AD- eller LDAP-servern, därför orsakar detta ett fel eftersom AD- eller LDAP-servern försöker framtvinga parametern. Ändra lösenordet i ett annat program eller avmarkera kryssrutan för parametrar. Vi rekommenderar även att du använder 3.6.2.0 eller högre för det här problemet, eftersom ECS då uppmanar användare om AD-serverbegäran att "User must change password at next login."
5. användaren av typen sAMAccountName saknar rätt domänvärde som är username@domain.
6. Du kan ha ställt in sökbasen till:

"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. Är inställd på exakt rätt användarplats, CN=Administratör,CN=Användare,DC=CAS,DC=EMC,DC=com, inte CN=Användare,DC=CAS,DC=EMC,DC=com 
2. Lösenordet är korrekt.
3. Användaren har den behörighet som krävs för att vara chef DN-användare.  

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'

Om en användare har ändrat LDAP-servern, medan FQDN för den nya LDAP-servern matchar FQDN för den gamla LDAP-servern.

Det aktuella LDAP SSL-certifikatet kan peka på den gamla LDAP-servern, därför måste LDAP SSL-certifikatet ersättas med ett uppdaterat LDAP SSL-certifikat.

Möjligt felmeddelande:

 

Granska att certifikatet har utfärdats och se till att FQDN matchar exakt den URL som används i ECS-användargränssnittet. Du kan också granska matchningarna för alternativa ämnesnamn exakt från certifikatet:

Command:

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

Exempel:

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

 
Granska ditt LDAPS-certifikat på ECS-matchningar, annars kan det vara så att ett nytt, korrekt certifikat krävs för ECS. 

En användare kan överväga att öppna en tjänstebegäran med ECS-support för att få hjälp, om så är fallet.

---

 

1. Har fältet Autentiseringsleverantör fyllts i korrekt av användaren?
2. Har hanteringsanvändaren skapats?
3. Har testanvändaren och lösenordet angetts korrekt vid ECS-inloggningen?
4. Kan de logga in med andra användare från en domän?
5. Är det första gången AD eller LDAP konfigureras på ECS?
6. Om inte en ny AD eller LDAP har konfigurerats på ECS, har de någonsin kunnat logga in med dessa autentiseringsuppgifter? Om så är fallet, ange om det fanns några ändringar som skulle påverka tillståndet?