ECS: How to set up an AD or LDAP server connection in the UI

1. Go to the ECS UI > Authentication Provider and set up an Authentication Provider to 1 AD or LDAP server with one server url. Note, it is to minimize the complexity.
   1. In the server URL box, try and use LDAP instead of LDAPS for testing, if possible. As if LDAP does not work, then surely LDAPS will not either. 
   2. Have a correct manager DN.
   3. Set the search base it an exact users folder, not a large search base, just this is to discount the LDAP timeout value being exceeded.
   4. As a search filter, select the correct type, the users attributes on the AD or LDAP server would show which to use. See below. Possible search filter options: sAMAccountName=%U, userPrincipalName=%u, uid=%U
   5. Note, a common question is what Authentication Provider type to use: AD, Keystone, or LDAP. The advice is that if the server is a Windows Active Directory, then use AD type. If a Linux openLDAP, use LDAP type. If the server is a Keystone, then use Keystone. 
2. Add the test user as a domain management user and test the login.
   1. Add the test user on ECS UI > users > management user > add
   2. The correct format would be username@domainname, ECS uses the @ symbol as to detect that it should look for a domain user as defined in the Authentication Provider.
   3. Not you must add users to the users list as to define their rights on ECS, that is admin or monitor user privileges.
3. Test the user log-in.
   1. If unsuccessful in domain user logging in, examine and troubleshoot  
      1. If successful, then change the search base to the main search base the users wants, that is the root location,
         1. If it then fails, the only change between a successful log-in and unsuccessful is a search base change, see KB 58587: ECS: Intermittent login failure of domain users due to AD/LDAP timeout value exceeded
         2. If successful then the domain groups can now be tested.
   2. If a user can log in, then a user group may be used as well.
      1. Be sure that the group and the users of the required group are within the search base scope.
      2. Best to test a test user like above to determine that the connection is working.
      3. Remove the test user of the group from the ECS management list and instead add the test group that the user belongs to, to the ECS management users list. That is like the steps above we are trying to minimizing possible troubleshooting. The only difference is now ECS is aware of the group and not the direct user.
      4. Be aware of KB 81219: ECS: LDAP login group supportability that is if you want to use groups you must be aware of this KB.
4. With a management user or group able to log in, that is helpful to know as it is easier to troubleshoot domain management user set up than domain object user setup, so it is good to test.
   1.  If a user then wants to use domain object and can prove to themselves that same domain users work as UI management user, then that is helpful to know, as if a user can work as a UI management user then they should work as an object user.
5. For LDAPS (LDAP over SSL or TLS) certificates, see the admin guide and KB 183654: ECS: How to setup and accept all certificates over LDAPS on ECS
   1. It is advisable to confirm that the LDAP connections works and users can log in on LDAP, before looking into setup LDAPS.
   2. Note, a valid and complete certificate chain may be required.
   3. If using LDAPS, The server urls in the authentication provider must be in the FQDN format rather than the IP address, as to match the LDAPS certificates that would list the LDAP servers FQDN instead of the IP address.   
       

• Active Directory (AD) authentication or Lightweight Directory Access Protocol (LDAP) authentication: Used to authenticate domain users that are assigned to management roles in ECS.
• Keystone: Used to authenticate OpenStack Swift object users.

1. Create the user or group in AD that contains the specific users that must log in ECS:

1. Navigation: Manage > Authentication

2.  Enter the Name and Description field and select the correct server type:

 

3. Enter in the domains to be used.

4. AD or LDAP server URL:

5. Changing or updating the Manager DN.

 

6. Providers option

7. Setting Group Attributes:

8. Updating or changing the Group whitelisting

9. Updating or changing the Search scope

10. Updating or changing the Search Base.

11. Search Filter

1. Confirm the correct search filter that the users are to use:

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. Multidomain forest setup.

A Multidomain forest is where there are domains that are connected to each other, for example, a Parent and children domains.

Parent example: dell.com
Children domains example: amer.dell.com, emea.dell.com, apac.dell.com

1) A group may be in one of the domains and some of its users may be in other domains.
2) normally the domains are not visible to each other, but the parent domain can see all the children domains, therefore in setting up a multidomain forest connection, use the parent domain as the primary domain for the authentication provider. 

Steps that are different:
A) Name the domain after the parent domain.
B) List all the domains of interest in the domains box of the authentication provider.
C) If the Authentication Provider supports a multidomain forest, use the global catalog server IP and always specify the port number. Default ports: LDAP: 3268, LDAPS: 3269  
D) Set the search base to the root of the parent domain.
E) Note, the authentication provider name would be the primary identifier for the domain user usage. That is for this example, add users or groups like for example: group1@dell.com, not a subdomain like group1@amer.dell.com  
See the section Management and object Users set up.

1. Add the Group as the management User and choose the right roles:

2. Test the login with the user in the group.

1. Add Domain users to a namespace for object user use:

You must add (assign) domain users into a namespace if you want these users to perform ECS object user operations. To access the ECS object store, object users and namespace Administrators must be assigned to a namespace. You can add an entire domain of users into a namespace, or you can add a subset of the domain users into a namespace by specifying a particular group or attribute that is associated with the domain.

A domain can provide users for multiple namespaces. For example, you might decide to add users such as the Accounts department in the "yourco.com" domain into Namespace1, and users such as the Finance department in the "yourco.com" domain into Namespace2. In this case, the "yourco.com" domain is providing users for two namespaces.

An entire domain, a particular set of users, or a particular user cannot be added into more than one namespace. For example, the "yourco.com" domain can be added into Namespace1, but the domain cannot also be added into Namespace2.

The following example shows that a System or namespace Administrator has added into a namespace a subset of users in the "yourco.com" domain; the users that have their Department attribute = Accounts in Active Directory. The System or namespace Administrator has added the users in the Accounts department from this domain into a namespace by using the Edit namespace page in the ECS Portal.

Figure 1. Adding a subset of domain users into a namespace using one AD attribute
Domain object users selected under the "domain" selection would be nonadmin object users with access rights to their own created buckets only.

Attributes are a subset option that can be removed by clicking "X."
The Attributes subset must match the Domain users Attributes on the AD server.

The following example shows a different example where the System or namespace Administrator is using more granularity in adding users into a namespace. In this case, the System or namespace Administrator has added the members in the "yourco.com" domain who belong to the Storage Admins group with the Department attribute = Accounts AND Region attribute = Pacific, OR belong to the Storage Admins group with the Department attribute = Finance.

Figure 2. Adding a subset of domain users into a namespace using multiple AD attributes

2. Domain user to create a secret key as per the ECS Data access guide

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>

 

Example from 3.4 ECS UI:


    

1. User or Password is incorrect.
2. User not found, and user not found may be due to an incorrect search base in the authentication provider for that user.
3. Changes to an ECS Authentication Provider can take a few minutes to take effect, and the corrected Authentication Provider is still updating the connection to AD or LDAP.
4. User AD parameter "User must change password at next login" is active for that user. Note, ECS cannot change the domain users password on the AD or LDAP server therefore this causes an error, as the AD or LDAP server tries to enforce the parameter. Either change the password on a different application, or clear the parameter checkbox. 
5. sAMAccountName type user is missing the correct domain value that is username@domain.
6. You may have set the search base to:

 

1. Is set to the exact correct user location, that is CN=Administrator,CN=Users,DC=CAS,DC=EMC,DC=com not CN=Users,DC=CAS,DC=EMC,DC=com 
2. Password is correct.
3. The user has the required authorization to be the Manager DN user.  

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'

If a user has changed the LDAP server, while the FQDN of the new LDAP server matches the FQDN of the old LDAP server.

The current LDAP SSL certificate may point to the old LDAP server, therefore the LDAP SSL certificate must be replaced with an updated LDAP SSL certificate.

Possible error message:



Review that the certificate issued and ensure that FQDN matches exactly the URL used in the ECS UI. Alternatively review the Subject Alternative Names matches exactly from the certificate:

Command:

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

Example:

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

 
Review your LDAPS certificate on ECS matches, if not, it may be that a new, correct certificate would be required for ECS. 

A user may look into opening an SR with ECS support for assistance, if that is the case.

---

 

1. Has the Authentication Provider fields been correctly filled out by the user?
2. Has the Management User been created?
3. Are the test user and password entered correctly on the ECS log-in?
4. Are they able to log in with other user from a domain?
5. Is this the first time set up of the AD or LDAP on the ECS?
6. If not a new AD or LDAP set up on ECS, have they ever been able to log in with these credentials? If so, identify if there were any changes which would affect authorization?