私の組織は、RHEL/CentOS7サーバーをMicrosoftADドメインに参加させようとしています。ドメインコントローラーは、2台のWindows2008R2サーバーと1台のWindows2016サーバーで構成されています。
Linux側では、realm
を使用してドメインに参加していますが、これは正常に実行できました。
# realm list
mydomain.net
type: kerberos
realm-name: MYDOMAIN.NET
domain-name: mydomain.net
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %[email protected]
login-policy: allow-realm-logins
特定のグループのメンバーのみにSSHへのアクセスを許可したい:
# realm permit -g [email protected]
それは私が問題に遭遇したときです。 userAとuserBの2人のユーザーでテストすると、userAは許可されますが、userBは拒否されます。 / var/log/sssd/sssd_mydomain.net.logファイルは、userBに補足グループがないことを示しています。
(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_access_check_send] (0x0200): Simple access check for [email protected]
(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_check_get_groups_send] (0x0400): User [email protected] is a member of 0 supplemental groups
(Tue Sep 19 20:53:37 2017) [sssd[be[mydomain.net]]] [simple_check_get_groups_send] (0x0400): All groups had name attribute
というか、そうですが、SSSDが見ることのできるものはありません。次のコマンドは、次のことを確認します。
# id [email protected]
uid=1918001261([email protected]) gid=1918000513(domain [email protected]) groups=1918000513(domain [email protected]),1918001757([email protected]),1918003900(sccm [email protected]),1918004006(ts remote desktop [email protected]),1918004329([email protected])
# id [email protected]
uid=1918003883([email protected]) gid=1918000513(domain [email protected]) groups=1918000513(domain [email protected])
最終的に、userAのAD/LDAPオブジェクトでadminCount
属性が1
に設定されていることがわかりました。この属性がどのような影響を与えるのかは完全にはわかりませんが、SSSDがそのすべての補足グループを見つけることができ、その結果、userBに対して何も見つけられない理由です。
どんな助けでも大歓迎です!私は長い間この問題に頭を悩ませてきました。
[sssd]
domains = mydomain.net
config_file_version = 2
services = nss, pam
[domain/mydomain.net]
ad_domain = mydomain.net
krb5_realm = MYDOMAIN.NET
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_Shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = [email protected]
debug = 6
SSSDトラブルシューティング ガイドを読んだとき、私は問題を理解しました。このガイドでは、以下について簡単に説明しています。
非標準のLDAP検索ベースを使用する場合は、
ldap_use_tokengroups=False
を設定して、TokenGroupsのパフォーマンス向上を無効にしてください。そうしないと、ADプロバイダーは、カスタム検索ベースによって制限されない特別な呼び出しを介してグループメンバーシップを受け取り、予測できない結果が発生します。
また、ブログ投稿 ユーザーがSSSDでメンバーになっているグループのセットを制限する では、TokenGroupsについてもう少し説明されています。
最初のステップは、AD固有のtokenGroups属性を検索する代わりに、ユーザーがプレーンLDAPルックアップを使用してメンバーであるグループをクライアントに検索させることです。通常、すべてのグループを返す場合は、tokenGroups属性を使用すると、パフォーマンス上の大きなメリットが得られます。これは、すべてのグループのリストがメンバーであるため、ユーザーエントリの単一のBASEスコープ検索で返すことができるためです。ただし、tokenGroups属性は、ユーザーがメンバーになっているSIDの多値リストであり、前述のとおり、いずれにしてもすべてのSIDをグループ名に解決する必要があります。
TokenGroupsは、ユーザーのグループの解決において、デフォルトで有効になっている最適化手法のようです。しかし、これらの記事がほのめかしているように、私の場合のように、問題があることがわかるかもしれません。
この問題は、パラメータをfalse
に設定するだけで修正されました。
[domain/mydomain.net]
ldap_use_tokengroups = false
私のsssd.confファイル内。