問題
LDAP ユーザーに対して「id」コマンドを実行すると、一部のセカンダリ グループの gid のみが表示され、グループ名は出力されません:
# id user1 uid=48254(user1) gid=100(users) groups=100(users),5002(group1),5001(group2),41257(group3),856(group4),56971
そして、以下のエラーが /var/log/sssd/sssd_nss.log に記録されました:
(Tue Mar 14 05:40:09 2020) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0010): getgrgid call returned more than one result !?!
解決策
新しいグループは、既存のグループと同じ GID で追加されました。
# id user1 uid=48254(user1) gid=100(users) groups=100(users),5002(group1),5001(group2),41257(group3),856(group4),56971(group6) # getent group group5 group5:*:56971: # id user1 uid=48254(user1) gid=100(users) groups=100(users),5002(group1),5001(group2),41257(group3),856(group4)
同じ ID が group5 と group6 の 2 つのグループにマッピングされます。したがって、一度 id を実行すると、ユーザーの正しい結果が得られます (すべてのユーザー グループが表示されます)。次に、他のグループに対して getent グループを実行します:
# getent group group5
しかし、その後、id の結果からグループが削除されたようです。
SSSD の SysDB には、特定の ID を持つ 1 つのグループのみが存在できるという厳しい制限があります。サーバー上でグループの名前が変更されると、それを正しく処理するかどうかに関係なく、操作の順序の問題になります。同じ GID を持つ複数のエントリはサポートされていません。これを行うと、予期しない動作が発生します。
したがって、以下のエラーが /var/log/sssd/sssd_nss.log に記録されました:
(Tue Mar 14 05:40:09 2020) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0010): getgrgid call returned more than one result !?!
したがって、LDAP サーバーのエントリを修正すると、sssd は再び正しく取得できるはずです。キャッシュ自体がフラッシュされるデフォルトの時間は 300 秒 (つまり 5 分) であるため、そうでない場合は 300 秒待機します。また、以下のコマンドを使用して、要件に従って適切なオプションで sssd キャッシュをフラッシュすることもできます:
-E フラグを使用して、キャッシュされたすべてのエントリを無効にすることができます。例外は sudo ルールです。
# sss_cache -E
-u を使用して、特定のユーザーのみをキャッシュから無効にすることもできます フラグ、その後にユーザー名。
# sss_cache -u user1
また、/var/lib/sss/db/ ディレクトリ内から sss_cache ファイルを削除することもできます。
# service sssd stop # rm -rf /var/lib/sss/db/* # service sssd start