web-dev-qa-db-ja.com

macOSクライアントでOpenLDAPユーザーを認証できません「ユーザーが見つかりません：データベースにシークレットがありません」

OpenLDAPサーバーを実行しているUbuntu16.04サーバーがあります。私はすべてをうまく見ることができます：

serveradmin@Magic:~$ ldapsearch -x -H ldap://localhost -D cn=admin,dc=example,dc=com -W
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: work
dc: example

# admin, example.com
dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
...

# Groups, example.com
dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups

...

# Policies, example.com
dn: ou=Policies,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Policies
description: Password policy for users

# foo, People, example.com
dn: uid=foo,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
sn: foo
...

OS High SierraからEl Capitanまでの任意のmacOSクライアントで、次のコマンドを実行できます。

a0216:data admin$ dscl localhost -list /LDAPv3/example.com/Users
foo
bar
...

これにより、すべてのユーザーのリストが取得されます。

High Sierraを実行しているMacBookPro2016エディションを使用しています。ディレクトリユーティリティでユーザーとして認証しようとすると、正常に認証できます。

Jun 14 16:36:23 magic slapd[344850]: conn=1276 op=1 SRCH attr=uidNumber uid userPassword
Jun 14 16:36:23 magic slapd[344850]: conn=1276 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:36:24 magic slapd[344850]: conn=1277 fd=19 ACCEPT from IP=10.0.1.20:65410 (IP=0.0.0.0:389)
Jun 14 16:36:24 magic slapd[344850]: conn=1277 fd=19 closed (connection lost)
Jun 14 16:36:24 magic slapd[344850]: conn=1278 fd=19 ACCEPT from IP=10.0.1.20:65411 (IP=0.0.0.0:389)
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SRCH attr=supportedSASLMechanisms defaultNamingContext namingContexts schemaNamingContext saslRealm
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 BIND dn="uid=foo,ou=People,dc=example,dc=com" method=128
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 BIND dn="uid=foo,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 RESULT tag=97 err=0 text=

ただし、High SierraまたはEl Capitanのいずれかを実行しているiMacから同じことを試みると、次のようになります。

Jun 14 16:40:04 magic slapd[344850]: conn=1345 op=3 SRCH attr=uidNumber uid userPassword
Jun 14 16:40:04 magic slapd[344850]: conn=1345 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:40:04 magic slapd[344850]: conn=1358 fd=19 ACCEPT from IP=10.0.1.67:49545 (IP=0.0.0.0:389)
Jun 14 16:40:04 magic slapd[344850]: conn=1358 fd=19 closed (connection lost)
Jun 14 16:40:04 magic slapd[344850]: conn=1359 fd=19 ACCEPT from IP=10.0.1.67:49546 (IP=0.0.0.0:389)
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SRCH attr=supportedSASLMechanisms defaultNamingContext namingContexts schemaNamingContext saslRealm
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=1 BIND dn="" method=163
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not match required
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=2 BIND dn="" method=163
Jun 14 16:40:04 magic slapd[344850]: SASL [conn=1359] Failure: no secret in database
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=2 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=3 UNBIND
Jun 14 16:40:04 magic slapd[344850]: conn=1359 fd=19 close

私は考えられるすべてのことを試しましたが、その答えは私を直接顔に向けていると感じています。 iMacからログインしようとしているときにNo secret in databaseが表示され続ける理由を誰かが知っていますか？この問題の簡単な解決策はありますか？

私はいくつかの調査を行い、いくつかのことに遭遇しました（IE this ）、しかし、私が遭遇した方向性とアイデアは明確ではなく、それはすべての人にとって異なった働きをするようです。どんな助けや正しい方向へのポイントも大歓迎です。ありがとうございました

ldapmac-osxopenldapubuntu-16.04
1
CertifcateJunky

私はそれを考え出した！

問題は、macOSがCRAM-MD5を使用して認証を試みることです。 OpenLDAPのデフォルトはDIGEST-MD5です。これを機能させるには、SASL認証が失敗した場合のハッシュアルゴリズムをplistに追加する必要があります。そうするために：

Sudo su 
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string DIGEST-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist 
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string CRAM-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string NTLM" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string GSSAPI" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist

Macを再起動すると、正常に動作します。また、plistをコピーして、もうねじ込む必要がないようにしてください。

1
CertifcateJunky

また、MacOSをOpenLDAPベースのIAMソリューションと統合するときにこれに遭遇しました。このソリューションは、パスワードがハッシュされているため、CRAM-MD5やDIGEST-MD5などのチャレンジレスポンスメカニズムをサポートしていません。

MacOSは、LDAPサーバーのrootDSEの属性supportedSASLMechanismsで見つかったSASLメカニズムを試行します。そのため、各MacOS LDAPクライアントでSASLメカを構成する代わりに、OpenLDAP（静的）構成のACLで不要なSASLメカを非表示にしました。

次の2つのACLは、EXTERNAL（LDAPIおよびTLSクライアント証明書で使用）を除くすべてのSASLメカを非表示にします。

# allow anonymous access to supportedSASLMechanisms: EXTERNAL
access to
  dn.base=""
  attrs=supportedSASLMechanisms
  val.regex="^EXTERNAL$"
    by * read
# deny access to all other SASL mech values
access to
  dn.base=""
  attrs=supportedSASLMechanisms
    by * none
0
Michael Ströder