大規模環境向けのPowerFlex 4.x LDAP構成
Summary: PowerFlex Management Platform SSOバックエンドを使用してユーザーとグループの両方のLDAP検索フィルターを絞り込むことで、複数のUIとプラットフォームの問題を引き起こすことが確認されている同期の問題を軽減できます。
Instructions
背景:
デフォルトでは、PowerFlex Management Platform (PFMP)ディレクトリー プロバイダーは、構成された検索範囲内のすべてのLDAPオブジェクトをインポートします。これには、非ユーザー アカウントやRBACで必要のないその他のオブジェクトも含まれます。
大規模な環境では、この動作により、PFMP管理VM (MVM)、サポートするPostgresデータベース、およびプラットフォーム全体でリソース使用率が大幅に低下する可能性があります。
したがって、LDAP同期が許容期間内に完了せず、ジョブのバックログ、メモリー リーク、同時実行の問題が発生する可能性があります。
1.準備
要件:
Active Directoryグローバル カタログの使用
注: 標準LDAPにはポート3268、AD環境のLDAPSにはポート3269を使用する必要があります。これにより、子ドメインまたはその他の信頼できるドメインのLDAPグループ メンバーをPFMPで使用できるようになります。
ADグループの例:

na.powerflex.lab.dell.com より上の子ドメインは、グローバル カタログ ポートを使用して、PFMPのLDAPユーザー フェデレーションKeycloakによって認識できる必要があります。
これは、PFMPディレクトリー プロバイダーでobjectGUIDを使用する理由でもあります。これは、アカウントをグローバルに一意のUUIDに結び付けます。
両方の子ドメインが [信頼] タブに表示されている場合は、サブ ドメインが既定で相互に信頼し合っている可能性があります。
Microsoft Active Directory (AD)環境では、親ドメインとその子(サブ)ドメインは本質的に階層構造で相互に信頼し合っています。これは推移的な信頼と呼ばれます。
既定では、これらの信頼は双方向で推移的であり、親ドメインは子ドメインを信頼し、その逆も同様です。この推移的な性質により、親子階層内のすべてのドメインに信頼が拡張されます。
DNSエントリーから使用可能なLDAPまたはAD GCサーバーを検索する
通常、お客様は使用するLDAPアドレスを提供します。 これらの設定は、このガイドの次の手順の一環として削除する前に、PFMPディレクトリー プロバイダー構成からコピーできます。
または、特定のドメインのDNSから使用可能なサーバーを取得することもできます。
# listing LDAP server
$ host -t srv _ldap._tcp.powerflex.lab.dell.com
Server: nameserver.dell.com
Address: 10.8.8.8
Non-authoritative answer:
_ldap._tcp.powerflex.lab.dell.com service = 0 100 636 hcihopad1.powerflex.lab.dell.com. _ldap._tcp.powerflex.lab.dell.com service = 0 100 389 hcihopad1.powerflex.lab.dell.com. _ldap._tcp.powerflex.lab.dell.com service = 0 100 389 hcick3ad2.powerflex.lab.dell.com. _ldap._tcp.powerflex.lab.dell.com service = 0 100 636 hcick3ad1.powerflex.lab.dell.com. _ldap._tcp.powerflex.lab.dell.com service = 0 100 389 hcihopad3.powerflex.lab.dell.com.
# listing AD GC servers (Active Directory Global Catalog)
host -t srv _gc._tcp.powerflex.lab.dell.com
Server: nameserver.dell.com
Address: 10.8.8.8
Non-authoritative answer:
_gc._tcp.powerflex.lab.dell.com service = 0 100 3268 hcihopad3.powerflex.lab.dell.com.
_gc._tcp.powerflex.lab.dell.com service = 0 100 3268 hcick3ad3.powerflex.lab.dell.com.
_gc._tcp.powerflex.lab.dell.com service = 0 100 3268 hcick3ad2.powerflex.lab.dell.com.
OU またはグループの区別名を見つける方法。
まず、ユーザーをPFMPに読み込むOUとグループの識別名(DN)が必要になります。 これらのパスは、DNS命名に厳密に従うわけではなく、手動で抽出できるx.500 LDAPパス内にOUが含まれています。
これらのDNは、OSによって異なるユーティリティを使用して見つけることができます。簡単な方法の1つは、curlを使用することです。
Linuxでcurlユーティリティーを使用してPFMP LDAP設定をテストする方法。
MVM にインストールされている新しいバージョンの curl を使用して、必要な完全識別名を検索できます。たとえば、LabAdmins グループ CN の完全な DN を検索します。
#Get the DN of your groups for use in the LDAP User filter while also validating your LDAP Group Filter syntax# Set this to the group filter you intend to use in keycloak GROUPFILTER='(CN=LabAdmins)'# Use the LDAP svc bind creds to confirm the user can in fact call LDAP and see the group(s)BINDUSER="user@powerflex.lab.dell.com"# LDAP server URL. For TLS use ldaps:// and port 3269LDAPSERVER='ldap://ldap.powerflex.lab.dell.com:3268'# Use the same search base as you intend for the group path, generally just the DC componentsSEARCHBASE=DC=powerflex,DC=lab,DC=dell,DC=com# Call curl which will request the password of the bind user and return resultscurl -s sub --user "$BINDUSER" "$LDAPSERVER/$SEARCHBASE?distinguishedName?sub?$GROUPFILTER"
Enter host password for user 'jacqup@powerflex.lab.dell.com':
DN:CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com
distinguishedName:CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com
DN: CN=LabAdmins,CN=Users,DC=na,DC=powerflex,DC=lab,DC=dell,DC=com distinguishedName: CN=LabAdmins,CN=Users,DC=na,DC=powerflex,DC=lab,DC=dell,DC=com

Manual examples:
curl -s sub --user "FLEXLAB\jacqup"
"ldap://ldap.powerflex.lab.dell.com:3268/DC=powerflex,DC=lab,DC=dell,DC=com?distinguishedName,objectGUID?sub?(|(CN=FLEXLAB-APP-PROD-SDS-Admin)(CN=LabAdmins)(CN=LabUsers)(CN=EMEALabAdmins))"
Enter host password for user 'FLEXLAB\jacqup':
DN: CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=comdistinguishedName: CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=comDN: CN=LabAdmins,CN=Users,DC=na,DC=powerflex,DC=lab,DC=dell,DC=comdistinguishedName: CN=LabAdmins,CN=Users,DC=na,DC=powerflex,DC=lab,DC=dell,DC=comDN: CN=LabUsers,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=comdistinguishedName: CN=LabUsers,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com
keycloakバックエンドに配置できるフィルタープロパティを使用して、LDAPグループのすべてのメンバーを検索します。
#check for all members of the group with CN=LabAdmins
curl -s sub --user "jacqup@powerflex.lab.dell.com" "ldap://ldap.powerflex.lab.dell.com:3268/DC=powerflex,DC=lab,DC=dell,DC=com?member?sub?(&(objectClass=group)(cn=LabAdmins))"DN:CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=matrixadmin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=matrixadmin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=svc_adfsck3,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=svc_mcp_rw,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=adcertsvc,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=bobthebuilder,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=Ashish Rahangdale,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=Packer Admin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=FDLabAdmins,OU=Foundations,DC=powerflex,DC=lab,DC=dell,DC=commember: CN=Tejas Wadekar,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com
Linuxでldapsearchまたはcurlユーティリティーを使用してPFMP LDAP設定をテストする方法。
ネットワーク上でLinuxホストが使用可能な場合は、 ldapsearch ユーティリティーを使用して、PFMP/Keycloakで使用されるLDAP設定をテストおよび検証するのに役立ちます。
または、 管理 VM/MVMのいずれかからのLDAPクエリーにcurlユーティリティーを使用することもできます。
簡単な紹介 (一般的に使用されるオプション):
ldapsearch - LDAP search tool
ldapsearch opens a connection to an LDAP server, binds, and performs a search using specified parameters.
usage: ldapsearch [options] [filter
[attributes...]]
where:
filter RFC 4515 compliant LDAP search filter
attributes whitespace-separated list of attribute descriptions
Search options:
-b basedn base dn for search
-LLL print responses in LDIF format without comments and version Common options: -D binddn bind DN -H URI LDAP Uniform Resource Identifier(s) -N do not use reverse DNS to canonicalize SASL host name -w passwd bind password (for simple authentication) -W prompt for bind password -x Simple authentication
ツールの確認/インストール:
$ which ldapsearch
/usr/bin/ldapsearch
#RHEL/CentOS install
sudo yum install openldap-clients
# SLES install
sudo zypper install openldap2-client
LDAPルート エントリーからの ベースDN (-b)の定義:
$ curl "ldap://ldap.powerflex.lab.dell.com:3268/?rootDomainNamingContext"
DN:
rootDomainNamingContext: DC=powerflex,DC=lab,DC=dell,DC=com
# ldapsearch (with simple auth)
$ ldapsearch -LLL -H ldap://ldap.powerflex.lab.dell.com -x -D "FLEXLAB\ck3-user" -W -b "" -s base "dn=" rootDomainNamingContext
dn: rootDomainNamingContext: DC=powerflex,DC=lab,DC=dell,DC=com
ルート エントリーは、ディレクトリ サーバーに関する情報を提供します。ADでは、rootDomainNamingContext属性は、検索に使用できる最上位のベースDNを提供します。
-W -b "
LDAP URI、バインドDN(読み取りアクセス権を持つユーザー/パスワード)、およびユーザー検索設定のテスト:
$ ldapsearch -LLL -H ldap://powerflex.lab.dell.com:3268 -x -D "CN=ck3-user,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com" -W \ -b "dc=powerflex,dc=lab,dc=dell,dc=com" "(sAMAccountName=damonl)"
Enter LDAP Password: ********
dn: CN=Luc Damon,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com
objectClass: person
cn: Luc Damon memberOf: CN=EMEALabAdmins,OU=LabAdmins,DC=powerflex,DC=lab,DC=dell,DC=com memberOf: CN=LabUsers,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com memberOf: CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com objectGUID:: 6Z359eP5vky4P0Ye8iFp8g== sAMAccountName: damonl
# equivalent curl command:
$ curl -u 'CN=ck3-user,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com' \
"ldap://ldap.powerflex.lab.dell.com:3268/DC=powerflex,DC=lab,DC=dell,DC=com??sub?(sAMAccountName=damonl)"
# OR (with attributes selection)
$ curl -u 'FLEXLAB\ck3-user' \
"ldap://ldap.powerflex.lab.dell.com:3268/DC=powerflex,DC=lab,DC=dell,DC=com?cn,objectClass,memberOf,objectGUID,sAMAccountName?sub?(sAMAccountName=damonl)"
この例では、sAMAccountName属性を使用して、既存のユーザー アカウントについてLDAPにクエリーを実行し ています(必要な属性のみを表示するために出力は切り捨てられています)。
PFMP UIの対応する設定:
アドレス (-H): ldap://active.directory.domain.address.com:3268
バインドDN (-D): "CN=ck3-user,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com" #(「FLEXLAB\ck3-user」または「ck3-user@powerflex.lab.dell.com」は相当)
(デフォルトのSASLモードを回避するため、シンプル認証には-xが必要です)
バインドDNパスワード (-W):パスワードの入力を求めるプロンプト(または -w '***' を使用してコマンドで指定)
The output of the command validates the following PFMP User Search Settings:
Username LDAP Attribute: sAMAccountName
ID 属性: objectGUID
オブジェクトクラス: person
検索パス (-b): 「DC = PowerFlex、DC = Lab、DC = Dell、DC = COM」
グループ検索設定のテスト:
$ ldapsearch -LLL -H ldap://powerflex.lab.dell.com:3268 -x -D "FLEXLAB\ck3-user" -W \ -b "dc=powerflex,dc=lab,dc=dell,dc=com" "(&(objectClass=group)(|(cn=FLEXLAB-APP-PROD-SDS-Admin)(cn=EMEALabAdmins)))" cn
dn: CN=EMEALabAdmins,OU=LabAdmins,DC=powerflex,DC=lab,DC=dell,DC=com
sAMAccountName: Administrator
member: CN=ck3-builder,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com
sAMAccountName: jacqup member: CN=Luc Damon,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com sAMAccountName: damonl member: CN=Patrick Jacques,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com sAMAccountName: bobthebuilder
$ curl -u 'FLEXLAB\ck3-user' "ldap://ldap.powerflex.lab.dell.com:3268/DC=powerflex,DC=lab,DC=dell,DC=com?member?sub?(&(objectClass=group)(cn=EMEALabAdmins))"
In this example, we are querying LDAP for an existing group (objectClass) using its cn attribute and requesting member value(s).
It permits to validate following PFMP settings:
Group Member Attribute: member
Group ID Attribute: cn
Group Object Class: group
Group Search Path: "dc=powerflex,dc=lab,dc=dell,dc=com"
グループLDAPフィルターをテストしています:
$ ldapsearch -LLL -H ldap://powerflex.lab.dell.com:3268 -x -D "FLEXLAB\ck3-user" -W \ -b "dc=powerflex,dc=lab,dc=dell,dc=com" "(&(objectClass=group)(|(cn=FLEXLAB-APP-PROD-SDS-Admin)(cn=EMEALabAdmins)))" cn dn:
CN=EMEALabAdmins,OU=LabAdmins,DC=powerflex,DC=lab,DC=dell,DC=com
cn:EMEALabAdmins
dn:CN=FLEXLAB-APP-PROD-SDS-Admin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com
cn:FLEXLAB-APP-PROD-SDS-Admin
$ curl -u 'FLEXLAB\ck3-user' "ldap://ldap.powerflex.lab.dell.com:3268/DC=powerflex,DC=lab,DC=dell,DC=com?cn?sub?(&(objectClass=group)(|(cn=FLEXLAB-APP-PROD-SDS-Admin)(cn=EMEALabAdmins)))"
ユーザーLDAPフィルターのテスト:
$ ldapsearch -LLL -H ldap://powerflex.lab.dell.com:3268 -x -D "FLEXLAB\ck3-user" -W -b "dc=powerflex,dc=lab,dc=dell,dc=com" \dn: CN=Administrator,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com"(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=FLEXLAB-APP-PROD-SDS-Admin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)\(memberOf=CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)))" sAMAccountNamesAMAccountName:Administratordn: CN=Patrick Jacques,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com sAMAccountName:jacqup dn: CN=Luc Damon,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com sAMAccountName: damonl dn: CN=bobthebuilder,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com sAMAccountName: bobthebuilder
$ curl -u 'FLEXLAB\ck3-user' "ldap://ldap.powerflex.lab.dell.com:3268/DC=powerflex,DC=lab,DC=dell,DC=com?sAMAccountName?sub?(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=FLEXLAB-APP-PROD-SDS-Admin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)(memberOf=CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)))"
Windows
[Active Directoryユーザーとコンピューター]を起動します。表示をクリックして、高度な機能を選択します。
DNは、ディレクトリー内のエントリーを一意に識別する名前です。DNの最初のコンポーネントは、相対識別名(RDN)と呼ばれます。
DNは、次のように、コンマで区切られたattribute=valueのペアで構成されます。
CN=PowerFlex Admin,OU=sio-group1,DC=powerflex,DC=lab,DC=dell,DC=com
これらは「LDAPのFQDN」、つまり完全なx500アドレスの「URL」と考えてください。
ADユーザーとコンピューターを使用して、DNおよびその他の属性を特定できます。

ユーザーを読み取る OU に移動して右クリックし、[プロパティ] を選択します。

OUのプロパティで、属性エディタータブを選択します。
distinguishedNameをクリックしてハイライト表示し、「表示」をクリックします。
ハイライト表示された値を右クリックし、[コピー]を選択します。
キャンセル(Cancel)をクリックしてからOKをクリックし、属性エディタ(Attribute Editor)ウィンドウとOUプロパティ(OU Properties)ウィンドウを閉じます。

ナロースコープのLDAPユーザー フィルターの例:
(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=FLEXLAB-APP-PROD-SDS-Admin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)(memberOf=CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)))
視覚的な説明:

ユーザー要件をバインドします。
このバインド ユーザーには、ストレージ システムがこれらのユーザーを認証できるように、LDAPサーバーで定義されているユーザーとグループをクエリーする権限が少なくとも必要です。
既定では、[Active Directory ユーザーとコンピュータ] でトップレベル ドメインの [セキュリティ] タブにユーザーが追加されると、PFMP の LDAP 認証に必要な既定の読み取り専用要件が与えられます。例えば。



参考: ディレクトリーで読み取る必要のあるADグループにLDAPバインド ユーザーを実際に「含める」必要はありません。[Security]タブの[Read]権限が必要です。

PFMP LDAPプロバイダーの一般要件
アドレス: ldaps://ad.ldap.domain:3269(SSL)または ldap://ad.ldap.domain:3268(PLAIN)
バインドDN: ADNTDOMAIN\serviceaccountまたはバインドDN識別名。
バインドDNパスワード:サービス アカウントのパスワード
Timeout 30000
Username LDAP attribute: sAMAccountName
ID 属性: objectGUID
Object Class: Person
検索パス: (すべてのグループをクエリーできる最上位レベル(ドメイン コンポーネント/DCのみなど): DC=powerflex、DC=ラボ、DC=dell、DC=com)
Group Member Attribute: member
Group ID Attribute: cn
Group Object Class: group
グループ検索パス:(ユーザー検索パスと同じか、必要に応じてさらに細かく指定します。 狭いフィルターを使用するため、パフォーマンスに影響を与えることなく範囲を広くすることができます。
次のエントリー #The、keycloakがディレクトリー全体からすべてのグループを検索しないように、LDAPグループ フィルター(PFMP 4.6.x+)に少なくとも1つのグループを提供します。
Group LDAP Filter: (CN=GROUP1)
PFMP UIの場合のみこのフィールドに64文字の制限がある #Given、それを超えるグループ(たとえば3つの異なるグループなど)を追加する場合は、keycloakを使用して回避する必要があります。
Group LDAP Filter: (|(CN=GROUP1)(CN=GROUP2)(CN=GROUP3))
接続をテストし、成功した場合は[Submit]をクリックします。
例えば。

2.LDAPプロバイダーの削除とクリーンアップ
管理者ユーザーとして、PFMP UIからLDAPユーザー、グループ、ディレクトリー プロバイダーを削除します。 LDAPユーザーとして実行しないでください。管理者としてのみ実行してください。
警告:PFMPからの「ディレクトリー プロバイダー」と「リモート ユーザー/グループ」マッピングの現在の構成を記録します(特に、以前のロール マッピングを復元する必要がある場合)。
グループ/ロール マッピングがPFMPに表示されない場合(既知の問題)は、次の手順に従います。
# from any mvm
cmo_pri=$(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master,postgres-operator.crunchydata.com/instance-set' -o name)
# Group role
kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak -c "SELECT keycloak_group.name AS group_name,keycloak_role.name AS role_name FROM group_role_mapping JOIN keycloak_group ON (group_role_mapping.group_id = keycloak_group.id) JOIN keycloak_role ON (group_role_mapping.role_id = keycloak_role.id);"
# Group attributes
kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak -c "SELECT keycloak_group.name AS group_name,group_attribute.name AS attribute_name, value FROM group_attribute JOIN keycloak_group ON (group_attribute.group_id = keycloak_group.id);"
Example:
mvm01:~
# kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak
keycloak=# SELECT keycloak_group.name AS group_name,keycloak_role.name AS role_name FROM group_role_mapping JOIN keycloak_group ON (group_role_mapping.group_id = keycloak_group.id) JOIN keycloak_role ON (group_role_mapping.role_id = keycloak_role.id);---------------+----------------+---------group_name | role_name---------------+----------------EMEALabAdmins | SuperUserLabAdmins | LifecycleAdminLabUsers | Monitor(3 rows)keycloak=# SELECT keycloak_group.name AS group_name,group_attribute.name AS attribute_name, value FROM group_attribute JOIN keycloak_group ON (group_attribute.group_id = keycloak_group.id);group_name | attribute_name | valueEMEALabAdmins | remote_type | LdapEMEALabAdmins | SuperUser | GLB:GLBEMEALabAdmins | is_remote | trueLabAdmins | remote_type | LdapLabAdmins | LifecycleAdmin | GLB:GLBLabAdmins | is_remote | trueLabUsers | remote_type | LdapLabUsers | Monitor | GLB:GLBLabUsers | is_remote | true(9 rows)keycloak=# \q
古いLDAPグループがkeycloakデータベースに残っている場合は、次のプロセスを使用して手動で削除できます。
Keycloakデータベースのバックアップとkeycloak_groupデータベース テーブルのクリーンアップ コマンド。
注:keycloakを手動でクリーンアップする必要がない場合があります。
PFMP UIを使用してプロバイダーを削除し(常に最初にPFMPから)、次に/auth/ URLを使用してkeycloakからクリアされていることを確認する必要があります。
任意のMVMからkeycloakのLDAPグループ数を確認する方法:
# これを実行して、最初に変数を設定します。
cmo_pri=$(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master,postgres-operator.crunchydata.com/instance-set' -o name)
#check count of groups in keycloak
kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak -c "SELECT COUNT (*) FROM keycloak_group;"
# We usually want 0 groups after removing the LDAP provider.
#Backup the current keycloak DB before any edits.
kubectl exec -it -n powerflex $cmo_pri -- bash -c 'pg_dump -U postgres -d keycloak' >/home/delladmin/keycloak.sql
#delete all entries inside of keycloak_group (and related roles and attributes) while preserving its structure
kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak -c "DELETE FROM group_attribute;"
kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak -c "DELETE FROM group_role_mapping;"
kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak -c "DELETE FROM keycloak_group;"
#check that the group count has reduced:
kubectl exec -it -n powerflex $cmo_pri -- psql -U postgres -d keycloak -c "SELECT COUNT (*) FROM keycloak_group;"
これは、PFMP UIで最初に削除した後で、プロバイダー データがバックエンドに残っている場合にのみ発生します。 PFxM 4.6.0.1を使用している場合は、次の方法を実行して、Keycloak UIでインポートされたユーザーを削除することもできます。
- keycloakユーザーとして/auth/を使用してログインします
- Keycloakパスワードはインストールごとに一意であり、次のものを使用して任意のMVMで確認できます。
kubectl get secret -n powerflex keycloak-admin-credentials -o jsonpath="{.data.password}" | base64 --decode; echo
3.User federation -> LDAP -> Settingsを選択し、右上のActionsドロップダウンでRemove Importedを選択します。

グループとディレクトリー プロバイダーをクリーンアップして削除したら、3つのMVMノードを再起動します。
-手記:これは、環境が大規模で、以下のログに示されているように、LDAPクエリが繰り返しスタックされる場合にのみ必要です。
- 環境が同期の問題で過負荷になっておらず、UIが安定している場合は、通常、MVMの再起動をスキップできます。しかし、一般的には良い対策です。
KB https://www.dell.com/support/kbdoc/en-us/000225550 再起動
MVMグレースフル リブート(一度に1つのノードで実行する必要があります)データベースが同期スタンバイを報告していることを確認するまで、次のノードに移動しないでください。
ベスト プラクティス #As、現在のPostgresリーダーであるノードを特定し、このノードを最後に再起動します。
MVMで次のコマンド #Run、関連付けられているデータベースのステータスとデータベース名を一覧表示します。
kubectl exec -n powerflex -c database $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master, postgres-operator.crunchydata.com/instance-set' | grep Running | cut -d' ' -f1) -- sh -c 'patronictl list'
このコマンド #Run、postgresデータベースpodをホストしているMVMノードを特定します。
for x in `kubectl get pods -n powerflex | grep "postgres-ha-cmo" |awk '{print $1}'` ; do echo $x; kubectl get pods -n powerflex $x -o json | grep '"nodeName"' | cut -d ':' -f2 ; echo " "; done
Postgresリーダー ポッド インスタンスであるMVM #On ます。 「watch kubectl get nodes」を実行して、再起動のステータスを監視します。このMVMは、再起動される最後のノードである必要があります。
#pfmp-mgmt-1がPostgresリーダーの場合の再起動順序の例。どのMVMがPostgresリーダーであるかに応じて、次のコマンドの順序を調整します。
3番目のMVMに接続されているターミナルを開き、最初の2つのコマンドを実行します。
kubectl label
node pfmp-mgmt-3 cmo.maintenance.mode=true
kubectl drain pfmp-mgmt-3 --ignore-daemonsets --delete-emptydir-data && sudo reboot
#When ノードが再起動から起動します。次のコマンドを実行します。
kubectl uncordon pfmp-mgmt-3 ; kubectl label node pfmp-mgmt-3 cmo.maintenance.mode-
MVM3に関連付けられているデータベースが同期スタンバイを報告するまで、次のコマンド #Run ます。その時点で、次のMVMに進むことができます。
kubectl exec -n powerflex -c database $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master, postgres-operator.crunchydata.com/instance-set' | grep Running | cut -d' ' -f1) -- sh -c 'patronictl list'
2番目のMVMに接続されているターミナルを開き、最初の2つのコマンドを実行します。
kubectl label node pfmp-mgmt-2 cmo.maintenance.mode=true
kubectl drain pfmp-mgmt-2 --ignore-daemonsets --delete-emptydir-data && sudo reboot
#When ノードが再起動から起動します。 次のコマンドを実行します。
kubectl uncordon pfmp-mgmt-2 ; kubectl label node pfmp-mgmt-2 cmo.maintenance.mode-
MVM2に関連付けられているデータベースが同期スタンバイを報告するまで、次のコマンド #Run ます。その時点で、次のMVMに進むことができます。
kubectl exec -n powerflex -c database $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master, postgres-operator.crunchydata.com/instance-set' | grep Running | cut -d' ' -f1) -- sh -c 'patronictl list'
このMVMをノード ステータス監視MVMとして使用するには、次のコマンド #Run ます。
'watch kubectl get nodes'
「watch kubectl get nodes」を実行している最初のMVMに接続されているターミナルに移動します。 ctrl+cを押してターミナルに戻り、最初の2つのコマンドを実行します。
kubectl label
node pfmp-mgmt-1 cmo.maintenance.mode=true
kubectl drain pfmp-mgmt-1 --ignore-daemonsets --delete-emptydir-data && sudo reboot
#When ノードが再起動から起動します。 次のコマンドを実行します。
kubectl uncordon pfmp-mgmt-1 ; kubectl label node pfmp-mgmt-1 cmo.maintenance.mode-
MVM1に関連付けられているデータベースが同期スタンバイを報告するまで、次のコマンド #Run ます。 この MVM がリーダーでしたが、MVM1 が枯渇すると、新しいリーダーが引き継ぎます。
kubectl exec -n powerflex -c database $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master, postgres-operator.crunchydata.com/instance-set' | grep Running | cut -d' ' -f1) -- sh -c 'patronictl list'
MVMグレースフル リブート手順の終了
再起動し、PFMPのUIがリストアされたら、管理者としてログインし、次の手順に従ってSettings -> Directory Provider を追加します。
3.LDAPプロバイダーの再構築
準備のセクションで説明したように、PFMPで使用するグループに子ADドメインまたはADドメイン信頼アカウントがある場合は、グローバル カタログ(GC)LDAPポート3268(プレーン)および3269(SSL)を使用する必要があります。
例えば。
ldaps://ad.ldap.corporate.domain.com:3269Users DN: DC=powerflex,DC=lab,DC=dell,DC=com Bind DN:DOMAIN\svc_ldapbindaccountUsername LDAP attribute: sAMAccountName UUID LDAP attribute: objectGUID User Object Classes: Person This field has a 64 character limit in PFMP UI only. You can put one group in to prevent 'full' directory sync, then use the keycloak UI to refine and add on to the group filter. Group LDAP Filter: (|(CN=FLEXLAB-APP-PROD-SDS-Admin)(CN=LabAdmins)) Timeout 22222
4.狭いLDAPユーザーおよびグループ スコープのアプリケーション
keycloakユーザーとして/auth/を使用してログインします
ユーザー フィルター:
# ユーザーLDAPフィルターがPFMP UIにないため、次を使用して変更する必要があります。
Keycloak PowerFlexレルムで #This フィルターを適用する必要があります(PowerFlex --> User federation --> User LDAPフィルター)
ユーザーLDAPフィルター:
(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=FLEXLAB-APP-PROD-SDS-Admin,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)(memberOf=CN=LabAdmins,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)(memberOf=CN=LabUsers,CN=Users,DC=powerflex,DC=lab,DC=dell,DC=com)))
変更を保存します。
この絞り込まれたフィルターの説明:
objectCategory が Person と等しい。
および
sAMAccountName が存在します
および
memberOfはCN=PowerFlex Admin,OU=sio-group1,DC=powerflex,DC=lab,DC=dell,DC=comと等しい
または
memberOfはCN=FLEX-STOR-MON,OU=15G,OU=FLEXLAB,DC=powerflex,DC=lab,DC=dell,DC=comと等しい
<から https://ldap-builder.powerflex.lab.dell.com/>
User federation -> LDAP -> Settingsを選択し、右上のActionsドロップダウンでremove importedを選択します。

4.6.x+ UIによるグループ マッピングの削除方法。

[Membership User LDAP Attribute]の[LDAP Group Mapping]設定では、「cn」として出荷され、PFMP UIでは変更できない正しい値がkeycloak UIではDNに変更されていることを確認する必要もあります。

グループLDAPフィルターでは、どちらか一方の演算子| 各グループのCN(例:
(|(CN=FLEXLAB-APP-PROD-SDS-Admin)(CN=CN=PRV_US_SA_SRV_SVS))