MDSとOpenLDAPの連携について

今回、LDAPサーバ側はOpenLDAPを使用しているのですが、OpenLDAPとの連携の場合、MDS側:ldap search-mapのattribute-nameはdescriptionを指定
LDAP側：descriptionにnetwork-adminを指定
で合っておりますでしょうか。

はい、合っているはずです。
[参考]MDS LDAP の設定

それ以外に必要な設定がありましたら併せてご教授いただけないでしょうか。

LDAPサーバに対する認証ではじかれているようなので、気になるのはrootDNとして指定しているouの階層がPeopleであるのに対し、base-DNのou階層がGroupと異なっている点くらいでしょうか。
（これ異なっていても問題ないのでしたっけ？）

あとはサーバ認証ではなくユーザ認証に関することですが、MDS側のsearch-filterでは"cn=$userid"と検索対象のユーザidを"cn"として認識させているのに対し、LDAPサーバ側ではユーザidを"uid"として認識しているようなので、この点も揃えないと問題になるかもしれません。

それ以外だと

https://dell.to/417ZIvL
https://dell.to/4gPvl2G
などにあるようなSSL/TLS関係の問題かもしれないと思ったのですが、「ldap: ldap_client_auth_init: (user testuser01) - ldap_init success for host https://dell.to/41jJ90W port 636」というポート636を利用した通信が成功したログが残ってるのでこれは違いそう。

最悪の場合はLDAP authentication is failing only when the ip name-server configured on the switchにあるような問題かもしれません（そうなるとサポート部門の対応が必要になってしまいます）。

-------------------------

LDAPサーバに対する認証ではじかれているようなので、気になるのはrootDNとして指定しているouの階層がPeopleであるのに対し、base-DNのou階層がGroupと異なっている点くらいでしょうか。
（これ異なっていても問題ないのでしたっけ？）

-------------------------
⇒念のため、ldapsearchコマンドにてbindユーザがbaseDNのユーザを検索できるか確認いたしました。

$ ldapsearch -x -D "uid=mds_bind_only,ou=People,dc=test,dc=local" -W -b "ou=Group,dc=test,dc=local" "(cn=mds-admin)"
#
# LDAPv3
# base <ou=Group,dc=test,dc=local> with scope subtree
# filter: (cn=mds-admin)
# requesting: ALL
#
# mds-admin, Group, test.local
dn: cn=mds-admin,ou=Group,dc=test,dc=local
objectClass: posixGroup
cn: mds-admin
gidNumber: 1000
memberUid: testuser01
description: network-admin

# search result
search: 2
result: 0 Success

特に問題はないように見受けられます。

-------------------------
あとはサーバ認証ではなくユーザ認証に関することですが、MDS側のsearch-filterでは"cn=$userid"と検索対象のユーザidを"cn"として認識させているのに対し、LDAPサーバ側ではユーザidを"uid"として認識しているようなので、この点も揃えないと問題になるかもしれません。

-------------------------
⇒search-filterで指定している"cn=$userid"ですが、"cn=$uid"でもMDS側の書式として問題ございませんでしょうか。

-------------------------

最悪の場合はLDAP authentication is failing only when the ip name-server configured on the switchにあるような問題かもしれません（そうなるとサポート部門の対応が必要になってしまいます）。

-------------------------
⇒こちらのリンクにある、「This issue occurs only when ip name server is configured on the switch.」はMDSにDNSサーバを設定しているかということでしょうか。それであれば、DNSサーバの設定はしていないため、該当しないと思われます。

特に問題はないように見受けられます。

実機確認ありがとうございます。
バインドするDNと検索ベースのDNのouは違くても問題はないということですね。

（まだまだここら辺は勉強が必要ですが、参照先URLとして記載して頂いたCisco社のページにある「検索してからバインドする方式の利点は、baseDN の前にユーザ名（cn 属性）を追加することで認定者名（DN）を形成するのではなく、検索結果で受け取った DN をバインディング時にユーザ DN として使用できることです。この方式は、ユーザ DN がユーザ名と baseDN の組み合わせとは異なる場合に特に役立ちます。」という部分がそれを説明してるように見えてきました）

⇒search-filterで指定している"cn=$userid"ですが、"cn=$uid"でもMDS側の書式として問題ございませんでしょうか。

$useridはMDSが利用している変数名（の値）だと考えられるので、"cn=$userid"か"uid=$userid"のどちらかに揃える必要があるのではないかと考えていました。

⇒こちらのリンクにある、「This issue occurs only when ip name server is configured on the switch.」はMDSにDNSサーバを設定しているかということでしょうか。それであれば、DNSサーバの設定はしていないため、該当しないと思われます。

はい、私もその認識なので当該問題はあてはまらないと考えて頂いて問題ありません。

再度記載して頂いた情報を確認してみたのですが

ldap: ldap_do_initial_bind: (user testuser01) - ldap_bind for root failed - error[-1] Can't contact LDAP server 

を見るとそもそも"testuser01"を探す前のサーバ認証で失敗しており、かつその失敗はrootDNに対するものに見えます。
（[参考]MDS:LDAP rootDN getting extra '\' in debug if it has value "dc=il" and LDAP is failing－bug情報のKBですが、該当箇所に問題がないとrootDNへのバインドが成功していることが読み取れます）

また、ご確認頂いたldapsearchコマンドにおいてバインド用のDNは"uid=mds_bind_only,ou=People,dc=test,dc=local"であり、上記ldapログの3行上に記録されてる

ldap: ldap_do_initial_bind: rootDN : cn=mds_bind_only,ou=People,dc=test,dc=local 

の情報とは異なっている点が問題な可能性がありそうです（uid=mds_bind_onlyとcn=mds_bind_onlyの違い）。

この問題有無の切り分けには、以下のコマンドが通るかの確認が有効だと思います（通れば問題なし、通らなかったら問題あり）

$ ldapsearch -x -D "cn=mds_bind_only,ou=People,dc=test,dc=local" -W -b "ou=Group,dc=test,dc=local" "(cn=mds-admin)"

$ ldapsearch -x -D "cn=mds_bind_only,ou=People,dc=test,dc=local" -W -b "ou=Group,dc=test,dc=local" "(cn=mds-admin)"
上記コマンドはエラーとなりました。

ただ、改めて情報を確認した内容をまとめてました。

■rootDN
dn: uid=mds_bind_only,ou=People,dc=test,dc=local

$ ldapsearch -x -D "uid=mds_bind_only,ou=People,dc=test,dc=local" -W -b "ou=Group,dc=test,dc=local" "(cn=mds-admin)"
上記コマンドは問題ない

■MDSの設定
ldap-server host xxx.xxx.xxx.xxx rootDN "cn=mds_bind_only,ou=People,dc=test,dc=local"  password 7 xxxxxxxxxxxxxxxx port 636 
参考にしたサイトに合わせてrootDNをcn/ou/dcにしてしまっていたが、
指定する情報が誤っていた？

正しくは
ldap-server host xxx.xxx.xxx.xxx rootDN "uid=mds_bind_only,ou=People,dc=test,dc=local"  password 7 xxxxxxxxxxxxxxxx port 636 
にしないといけない？

その上でsearch-filterが"cn=$userid"の指定のため、"uid=$userid"にして、認証するユーザがbaseDNにいるユーザを検索する
ようにすることでtest aaaおよびMDSへのログインが可能と考えますが、いかがでしょうか。

search-filterが"cn=$userid"の指定のため、"uid=$userid"にして、認証するユーザがbaseDNにいるユーザを検索する
ようにすることでtest aaaおよびMDSへのログインが可能と考えますが、いかがでしょうか。

はい。以前に記載した「"cn=$userid"か"uid=$userid"のどちらかに揃える」においてuid側にそろえるというパターンなので、うまくいくのではないでしょうか。

あとはあまりuidでの指定は見たことがないので、うまくいかなかったらcn側にそろえて試してみることもおすすめします（ってこれはLDAPサーバ側の情報の持ち方にもよるとは思いますが・・・）。

度々申し訳ありません。
rootDNの指定を変更し、test aaaを実行したところ、失敗しました。

■前回

ldap-server host xxx.xxx.xxx.xxx rootDN "cn=mds_bind_only,ou=People,dc=test,dc=local"  password 7 xxxxxxxxxxxxxxxx port 636 

■新

ldap-server host xxx.xxx.xxx.xxx rootDN "uid=mds_bind_only,ou=People,dc=test,dc=local"  password 7 xxxxxxxxxxxxxxxx port 636 

デバッグを有効にし、ログを確認したところ以前共有いただいたバグのように見受けられます。

uid部分に\が含まれてしまっています。

https://quickview.cloudapps.cisco.com/quickview/bug/CSCvc62286?linkId=752622036

■デバッグログ

ldap: ldap_escape_special_characters Before escaping : uid=mds_bind_only,ou=People,dc=test,dc=local 
ldap:  ldap_escape_special_characters: After escaping : uid\=mds_bind_only,ou=People,dc=test,dc=local 
ldap: ldap_get_vrf_applicable:(user testuser01) greturning default vrf :vrf default 
ldap: ldap_do_initial_bind: rootDN : uid\=mds_bind_only,ou=People,dc=test,dc=local 
ldap: ldap_do_initial_bind: baseDN : cn=mds-admin,ou=Group,dc=test,dc=local 
ldap: ldap_do_initial_bind: userDN :  
ldap: ldap_do_initial_bind: (user testuser01) - ldap_bind for root failed - error[-1] Can't contact LDAP server 
ldap: ldap_client_auth_init: (user testuser01) -Initial auth failed isssl: 1 

■質問事項

・このバグはVer7.3のもので、今回の機器のバージョンは9.4(1)になりますが、バグ対象になりますでしょうか

・こちらの回避策はありますでしょうか。

・rootDNの指定方法で、uidは使用できないのでしょうか。rootDNをcnで指定した時は「\」は出ていませんでした。