☰

シナリオ

tag-icon • tag-icon samba groups
シナリオ

私は、winbind を介して AD アカウントに対してユーザーを認証するように設定された RHEL5 サーバーをいくつか継承しました。AD でグループ メンバーシップを更新するまではすべて正常に動作します。一部のユーザーの場合、変更は「getent group <groupname>」の出力には反映されますが、「groups」コマンドの出力には反映されません。

たとえば、次のことを考慮してください。

[root@hcc1pl1 ~]# グループ plubans
plubans : ドメイン ユーザー システム インフラストラクチャ 開発
[root@hcc1pl1 ~]# getent グループ q1esb
q1esb:*:23136:q1qai,q1prodi

winbind が使用している DC 上の q1esb に自分自身を追加すると、メンバーシップが更新されていることがわかります。

[root@hcc1pl1 ~]# lsof -i | grep winbind
winbindd 31339 root 17u IPv4 63817934 TCP hcc1pl1:56541->hcnas01:microsoft-ds (確立済み)
winbindd 31339 root 21u IPv4 63817970 TCP hcc1pl1:53622->hcnas01:ldap (確立済み)
[root@hcc1pl1 ~]# ldapsearch -u -x -LLL -h hcnas01 -D "[メールアドレス]" -W -b "CN=Peter Lubans、OU=Standard User Accounts、OU=Users、OU=XXX、DC=XXX、DC=XXX" "(sAMAccountName=*)" memberOf
LDAP パスワードを入力してください:
...
memberOf: CN=q1esb、OU=Security Groups、OU=Groups、OU=XXX、DC=XXX、DC=XXX
...

winbind はキャッシュなしで実行されていることに注意してください (-n フラグ)。

[root@hcc1pl1 ~]# ps -ef | grep winbind
root 31339 1 0 13:50 ? 00:00:00 winbindd -n
root 31340 31339 0 13:50 ? 00:00:00 winbindd -n root
31351 31339 0 13:50 ? 00:00:00 winbindd -n
root 31352 31339 0 13:50 ? 00:00:00 winbindd -n
root 31353 31339 0 13:50 ? 00:00:00 winbindd -n

ここで、getent はグループに正しいメンバーが含まれていることを示します。

[root@hcc1pl1 ~]# getent グループ q1esb
q1esb:*:23136:q1qai,plubans,q1prodi

しかし、更新されたメンバーシップはアカウントの詳細に反映されません。

[root@hcc1pl1 ~]# グループ plubans
plubans : ドメイン ユーザー システム インフラストラクチャ 開発
[root@hcc1pl1 ~]#

この問題の本当に厄介な部分は、このマシン上の他のアカウントや、私が最初から構成したマシン上の私のアカウントでは正常に機能することです。

何か案は？

答え1

これは、ログオン時に /var/cache/samba/netsamlogon_cache.tdb にキャッシュされたグループ情報によって発生したようです。 '-n' は winbind に LDAP に対するクエリをキャッシュしないように指示しましたが、その TDB ファイルにメンバーシップ情報が存在することで、状況が混乱したのではないかと思います。

答え2

私はなんとかマルチンの紛失した記事を手に入れた（https://marcinm.co.uk/group-membership-not-updating-in-winbind/) をメールで尋ねてみました。これが少なくとも何人かの人の役に立つと確信しているので、彼のブログ投稿全体をここに掲載します。

シナリオ

smbd を実行しているファイル サーバーsecurity=ads(つまり、ドメイン メンバーとして動作) では、ユーザーは Samba 共有に接続し、最初の接続時にグループ メンバーシップが正しく取得されますが、その後は更新されません。

根本的な原因

Samba は、グループ メンバーシップが AD ドメイン コントローラーによって計算されたときにそれを更新します。これは、ユーザーが smbd および winbind を実行しているサーバーにログインした場合にのみ計算されます。これは、wbinfo -aKerberos 化された SMB ログインによってのみトリガーされます。これは重大な制限であり、ユーザーがログインしないマシンではグループ メンバーシップがまったく認識されないことを意味するため、ユーザーがログインせずに AD からユーザーのグループ メンバーシップを取得するフォールバック グループ メンバーシップ コードが開発されましたが、winbind によって使用されるマシン アカウントにはユーザー グループ メンバーシップを要求する権限がないため、結果は信頼できないため不安定であると見なされています。したがって、winbind はこれに依存することはありません。グループ メンバーシップがまったく認識されていない場合はこれを呼び出しますが、キャッシュされたグループ メンバーシップを更新するためにこれを使用することはありません。その結果、いくつかのシナリオでは、winbind はユーザー グループ メンバーシップを一度取得し、それ以降は更新しません。

グループ メンバーシップのキャッシュを無効にすることはできません。つまり、 に行を追加してもsmb.conf、このような動作を無効にする方法はありません。これは Samba の問題ではなく、AD 設計の問題であることに注意してください。このような動作は、Windows の動作と一致しており、実質的には、ユーザーがログイン時に認証すると、AD グループ メンバーシップが更新されます。

ユーザーのグループメンバーシップを強制的に更新する方法

グループ メンバーシップは、netsamlogon_cache.tdbtdbtool (Samba のすべてのバージョン) または (Samba 4.7 以降) で調査できる という名前のファイルにキャッシュされますnet cache samlogon。そのファイルからキャッシュされたエントリを削除すると、フォールバック更新コードを呼び出してその結果を戻すことで、グループ メンバーシップの 1 回限りの更新がトリガーされnetsamlogon_cache.tdb、その後は再び永久にキャッシュされます。

tdbtoolの方法:

$ wbinfo -n user.name
S-1-5-21-3023451936-689652692-1079546996-40725 SID_USER (1)

SID に追加し\0、引用符で囲みます:

$ tdbtool netsamlogon_cache.tdb delete "S-1-5-21-3023451936-689652692-1079546996-40725\0"

グループメンバーシップはOSが必要としたときに初めて更新されます。tdbファイルに入力されるまで数分間待ちます。

ネットキャッシュサムログオンの方法:

$ net cache samlogon list|head
SID                                                Name                                     When cached
---------------------------------------------------------------------------------------------------------------------------
S-1-5-21-3023451936-689652692-1079546996-40725     DOM\user.name                            Tue Apr 27 07:59:19 AM 2018 BST
S-1-5-21-3023451936-689652692-1079546996-41432     DOM\user.name2                           Tue Apr 27 02:13:33 PM 2018 BST

$ net cache samlogon delete S-1-5-21-3023451936-689652692-1079546996-40725

以前と同じです - グループ メンバーシップは、OS が必要としたときに初めて更新されます。tdb ファイルに情報が入力されるまで数分間待ちます。

答え3

私が唯一考えたことは、非常に漠然としたものではありますが、これはインフラストラクチャ マスター (ドメイン間でグループ メンバーシップを更新する役割を担う) との通信に関係している可能性があるということです。

答え4

私も同じようなことがありました。問題を解決するために、「authconfig --disablecache --update」を実行しました。もちろん、ログオンが遅くなりました。

関連情報