ECS：UIでADまたはLDAPサーバー接続を設定する方法

使用する正確なADまたはLDAP情報を確認します。

ECSに入力された値(以下を参照)がADまたはLDAPサーバーの詳細と一致しない場合があり、ドメイン ユーザーのログイン試行時に無効な認証情報のエラーが出力されることがあります

ADまたはLDAPサーバーの値を表示して確認します。

『ECS管理者ガイド』の「認証プロバイダー」の章の「ADまたはLDAP認証プロバイダーの追加」をお読みください

セクション1)
認証プロバイダーを正しく設定する必要があります。
認証プロバイダーは、ADまたはLDAPサーバーへのECS接続が定義される場所です

セクション2および3)
ECSは、ADまたはLDAPユーザーをオブジェクト ユーザーまたは管理ユーザーとして使用してECS UIにログインするようにセットアップできます。

セットアップまたはトラブルシューティングでは、考えられる問題の複雑さを最小限に抑えることから始めて、いくつかの手順を進めます。

1. ECS UI > Authentication Providerに移動し、1つのサーバーURLを持つ1つのADまたはLDAPサーバーに認証プロバイダーを設定します。これは、複雑さを最小限に抑えるためです。
   1. サーバーURLボックスで、可能であれば、テストにLDAPSではなくLDAPを使用してみてください。LDAPが機能しないかのように、LDAPSも機能しません。 
   2. 正しいマネージャDNがある。
   3. 大規模な検索ベースではなく、正確なユーザー フォルダーに検索ベースを設定します。これは、LDAPタイムアウト値の超過を割り引くためです。
   4. 検索フィルターとして正しいタイプを選択すると、ADまたはLDAPサーバーのユーザー属性にどちらを使用するかが表示されます。下記を参照してください。使用可能な検索フィルター オプション: sAMAccountName=%U, userPrincipalName=%u, uid=%U
   5. 一般的な質問は、どの認証プロバイダーの種類を使用するかです。AD、Keystone、LDAPのどれですか? サーバーがWindows Active Directoryの場合は、ADタイプを使用することをお勧めします。サーバーがLinux OpenLDAPの場合は、LDAPタイプを使用します。サーバーがKeystoneの場合は、Keystoneを使用します。 
2. テスト ユーザーをドメイン管理ユーザーとして追加し、ログインをテストします。
   1. ECS UIでテスト ユーザーを追加する>>管理ユーザーを追加して>追加します。
   2. 正しい形式はusername@domainnameです。ECSは、認証プロバイダーで定義されているドメイン ユーザーを検索する必要があることを検出するために、@記号asを使用します。
   3. ECSに対する権限(adminまたはmonitorユーザー権限)を定義するには、ユーザーをユーザー リストに追加する必要があります。
3. ユーザー ログインをテストします。
   1. ドメイン ユーザーのログインに失敗した場合は、調査とトラブルシューティングを行います  
      1. 成功した場合は、検索ベースをユーザーが必要とするメインの検索ベース、つまりルートの場所に変更します。
         1. その後ログインに失敗した場合、ログインの成功と失敗の間の唯一の変更は、検索ベースの変更です。ナレッジベース記事「ECS: AD/LDAPのタイムアウト値の超過によって発生するドメイン ユーザーの断続的なログイン失敗
         2. 成功した場合は、ドメイン グループをテストできます。
   2. ユーザーがログインできる場合は、ユーザーグループも使用できます。
      1. グループと必要なグループのユーザーが検索ベースの範囲内にあることを確認します。
      2. 上記のようなテスト ユーザーをテストして、接続が機能していることを確認するのが最善です。
      3. グループのテスト ユーザーをECS管理リストから削除し、代わりにユーザーが属するテスト グループをECS管理ユーザー リストに追加します。これは、上記の手順と同様に、考えられるトラブルシューティングを最小限に抑えようとしています。唯一の違いは、ECSが直接ユーザーではなくグループを認識するようになったことです。
      4. ナレッジベース記事(記事にアクセスするには、Dellサポート アカウントへのログインが必要)に注意してください。つまり、グループを使用する場合は、このナレッジベース記事に注意する必要があります。
4. 管理ユーザーまたはグループがログインできる場合は、ドメイン オブジェクト ユーザーのセットアップよりもドメイン管理ユーザーのセットアップのトラブルシューティングが簡単なので、テストすることをお勧めします。
   1.  ユーザーがドメイン オブジェクトを使用したいと考えていて、同じドメイン ユーザーが UI 管理ユーザーとして動作することを自分自身に証明できる場合は、ユーザーが UI 管理ユーザーとして作業できる場合は、オブジェクト ユーザーとして作業する必要があるため、知っておくと便利です。
5. LDAP(LDAP over SSLまたはTLS)証明書については、管理者ガイドとナレッジベース記事「ECS: ECS上でLDAPSを介してすべての証明書をセットアップして受け入れる方法
   1. LDAPSのセットアップを確認する前に、LDAP接続が機能し、ユーザーがLDAPにログインできることを確認することをお勧めします。
   2. 有効で完全な証明書チェーンが必要になる場合があることに注意してください。
   3. LDAPSを使用する場合、認証プロバイダーのサーバーURLは、IPアドレスではなくFQDN形式にする必要があります。これは、IPアドレスではなく、LDAPサーバーのFQDNをリストするLDAPS証明書と一致するためです。   
       

リストされている手順の目的は、確認するステップに問題を簡略化することで、考えられる問題を割り引くことです

セクション1: 認証プロバイダー
すべての手順については、『ECS管理者ガイド』を参照してください

ECS外部のシステムでユーザーを認証する場合は、認証プロバイダーをECSに追加できます。

認証プロバイダーは、ECSに代わってユーザーを認証できるECSの外部にあるシステムです

ECSは、認証プロバイダーへの接続を可能にする情報を格納して、ECSがユーザーの認証を要求できるようにします

ECSでは、次のタイプの認証プロバイダーを使用できます。

• Active Directory (AD)認証またはLightweight Directory Access Protocol (LDAP)認証: ECSの管理ロールに割り当てられているドメイン ユーザーの認証に使用されます。
• キーストーン：OpenStack Swiftオブジェクト ユーザーの認証に使用されます。

1. ECSにログインする必要がある特定のユーザーを含むユーザーまたはグループをADに作成します。

1. ナビゲーション：>の管理 認証

2.  [Name]と[Description]フィールドに入力し、正しいサーバー タイプを選択します。

 
注：誤ったタイプの保存を試みると、エラー メッセージが表示されることがあります。

3. 使用するドメインを入力します。

4. ADまたはLDAPサーバーのURL:

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

5. マネージャ DN の変更または更新。

 
例：マネージャDN: CN=Administrator,CN=Users,DC=nas2008test,DC=com
ADまたはLDAPサーバー上のManager DNユーザーの正しい場所である必要があります。

マネージャーDN:
これは、ECSがActive DirectoryまたはLDAPサーバーへの接続に使用するActive Directoryバインド ユーザー アカウントです。このアカウントは、ECS管理者がロールの割り当てのためにユーザーを指定するときに、Active Directoryの検索に使用されます

このユーザー アカウント は 、Active Directory で "すべての inetOrgPerson 情報を読み取る" 必要があります。InetOrgPerson オブジェクト クラスは、組織内のユーザーを表すために、Microsoft 以外のいくつかのディレクトリ サービス、LDAP、および X.500 ディレクトリ サービスで使用されています。

6. プロバイダー オプション

7. グループ属性の設定:

8. グループのホワイトリストを更新または変更する

9. 検索範囲の更新または変更

10. 検索ベースの更新または変更。

11. 検索フィルター

1. ユーザーが使用する正しい検索フィルターを確認します。

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. マルチドメイン フォレストのセットアップ。

マルチドメイン フォレストは、親ドメインと子ドメインなど、相互に接続されているドメインがある場所です

親の例: dell.com
子ドメインの例: amer.dell.com、emea.dell.com、apac.dell.com

1) グループはドメインの 1 つに属していて、そのユーザーの一部は他のドメインに属している場合があります
2)通常、ドメインは相互に表示されませんが、親ドメインはすべての子ドメインを認識できるため、マルチドメインフォレスト接続を設定する場合は、親ドメインを認証プロバイダーのプライマリドメインとして使用します。

異なる手順:
A)親ドメインにちなんでドメインに名前を付けます。
B)認証プロバイダーのドメインボックスに、関心のあるすべてのドメインを一覧表示します。
C)認証プロバイダーがマルチドメイン フォレストをサポートしている場合は、グローバル カタログ サーバーIPを使用し、常にポート番号を指定します。デフォルト ポート: LDAP: 3268、LDAPS: 3269
D)検索ベースを親ドメインのルートに設定します。
E)認証プロバイダー名は、ドメインユーザーの使用法のプライマリ識別子になることに注意してください。つまり、この例では、次のようなサブドメインではなく、たとえば group1@dell.com のようなユーザーまたはグループを追加します group1@amer.dell.com
管理およびオブジェクト ユーザーの設定セクションを参照してください。

 
 

セクション2：管理およびオブジェクト ユーザーのセットアップ 

1. グループを管理ユーザーとして追加し、適切なロールを選択します。

2. グループ内の他のユーザーでログインをテストします。

セクション3：オブジェクト ユーザーとしてのADまたはLDAPユーザーは
をセットアップします 管理ユーザーの作成は、ADまたはLDAPへの接続をテストするのに役立ちます。オブジェクト ユーザーを作成する前に行う必要があります

管理者ガイドとデータ アクセス ガイドを参照してください。

1. ドメイン ユーザーをオブジェクト ユーザーが使用するネームスペースに追加します。

ドメイン ユーザーでECSオブジェクトのユーザー操作を実行させるには、これらのユーザーにネームスペースを追加(割り当て)する必要があります。ECSオブジェクト ストアにアクセスするには、オブジェクト ユーザーとネームスペース管理者をネームスペースに割り当てる必要があります。ユーザーのドメイン全体をネームスペースに追加することも、ドメインに関連づけられている特定のグループまたは属性を指定してドメイン ユーザーのサブセットをネームスペースに追加することもできます。

ドメインは、複数のネームスペースのユーザーを提供できます。たとえば、"yourco.com" ドメインの Accounts 部門などのユーザーを namespace1 に追加し、"yourco.com" ドメインの Finance 部門などのユーザーを namespace2 に追加できます。この例では、「yourco.com」ドメインは2つのネームスペースにユーザーを提供しています

ドメイン全体、特定のユーザー セット、または特定のユーザーを複数のネームスペースに追加することはできません。たとえば、「yourco.com」ドメインをnamespace1に追加することはできますが、ドメインをnamespace2に追加することはできません

次の例は、システム管理者または名前空間管理者が "yourco.com" ドメイン内のユーザーのサブセットを名前空間に追加したことを示しています。部門属性 = Active Directory のアカウントを持つユーザー。システム管理者またはネームスペース管理者が、ECS Portalの[Edit]ネームスペースを使用して、このドメインのアカウント部門のユーザーをネームスペースに追加しました。

図 1.1つのAD属性を使用してドメイン ユーザーのサブセットをネームスペースに追加すると
ドメイン オブジェクト ユーザーが[domain]の選択で選択され、管理者 以外のオブジェクト ユーザーは 、自分で作成したバケットへのアクセス権のみを持つことになります。

 
属性は、「X」をクリックして削除できるサブセット オプションです
属性サブセットは、ADサーバー上のドメイン ユーザー属性と一致する必要があります。

次の例は、システム管理者またはネームスペース管理者が、ネームスペースにユーザーを追加する際に、より細分性の高い方法を使用している別の例を示しています。この例では、システム管理者またはネームスペース管理者が、部門属性 = Accounts AND Region属性 = PacificでStorage Adminsグループに属するメンバー、または部門属性 = FinanceでStorage Adminsグループに属するメンバーを「yourco.com」ドメインに追加しました。

図2複数のAD属性を使用したドメイン ユーザーのサブセットのネームスペースへの追加

2. ドメイン ユーザーは『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>

ユーザー ログイン エラー:

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

 
 

3.4 ECS UIの例:

 
    

1. ユーザーまたはパスワードが正しくありません。
2. User not found。user not foundは、そのユーザーの認証プロバイダーの 検索ベースが正しく ないことが原因である可能性があります。
3. ECS認証プロバイダーへの変更が 有効になるまで数分かかる場合があり、修正された認証プロバイダーは引き続きADまたはLDAPへの接続をアップデートしています。
4. ユーザーADパラメーター「User must change password at next login」がそのユーザーに対して有効です。注意:ECSはADまたはLDAPサーバー上のドメイン ユーザーのパスワードを変更できません。したがって、ADまたはLDAPサーバーがパラメーターを適用しようとすると、エラーが発生します。別のアプリケーションでパスワードを変更するか、パラメーターのチェックボックスをオフにします。また、この問題では3.6.2.0以降を使用することも推奨されます。ECSは、次のADサーバー リクエストについてユーザーにプロンプトを表示します。 "User must change password at next login."
5. sAMAccountNameタイプのユーザーには、username@domain正しいドメイン値がありません。
6. 検索ベースを次のように設定している可能性があります。

"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. 正確に正しいユーザーの場所に設定されています。CN=Administrator,CN=Users,DC=CAS,DC=EMC,DC=comではなく、CN=Administrator,CN=Users,DC=CAS,DC=EMC,DC=com 
2. パスワードが正しい。
3. ユーザーには、マネージャ 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'

ユーザーがLDAPサーバーを変更した場合、新しいLDAPサーバーのFQDNが古いLDAPサーバーのFQDNと一致します。

現在のLDAP SSL証明書は古いLDAPサーバーを指している場合があるため、LDAP SSL証明書をアップデートされたLDAP SSL証明書に置き換える必要があります

考えられるエラー メッセージ:

 

発行された証明書を確認し、FQDNがECS UIで使用されるURLと完全に一致していることを確認します。または、[Subject Alternative Names]が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

 
ECSでLDAPS証明書を確認します。一致しない場合は、新しい正しい証明書がECSに必要である可能性があります。

その場合は、ECSサポートでSRを開くことを検討できます。

---

 

1. [Authentication Provider]フィールドはユーザーによって正しく入力されていますか?
2. 管理ユーザーは作成されていますか?
3. テスト ユーザーとパスワードはECSログイン時に正しく入力されていますか?
4. ドメインから他のユーザーと一緒にログインできますか?
5. ECSでADまたはLDAPをセットアップするのは今回が初めてですか?
6. ECSに新しいADまたはLDAPがセットアップされていない場合、これらの認証情報を使用してログインできたことはありますか? その場合は、承認に影響を与える変更があったかどうかを特定します。