web-dev-qa-db-ja.com

winbindを使用したLinuxネストグループ

Winbindを使用してActiveDirectoryに接続されているRHEL6サーバーがいくつかあります。すべてのサーバーは、構成管理ツールを使用して同じように構成されます。ただし、groupsコマンドやSudoを使用してグループにクエリを実行すると、サーバーは異なる結果を生成します。ただし、Getentとwinbindは、すべてのサーバーで正しい一貫した結果を返します。

user.name1とuser.name2は、グループtest.group1のメンバーです。 test.group1はグループtest.group2のメンバーです

次のコマンドの実行は、すべてのサーバーで一貫しています。

# getent group test.group1 
test.group1:*:16126:user.name1,user.name2

# getent group test.group2
test.group2:*:16125:user.name1,user.name2

# wbinfo --group-info test.group1 
test.group1:*:16126:user.name1,user.name2

# wbinfo --group-info test.group2
test.group2:*:16125:user.name1,user.name2

ただし、サーバーAは誤って次を返します。

# groups user.name2
test.group1

サーバーBは正しく戻ります：

# groups user.name2
test.group1
test.group2

Sambaの設定は次のようになります。

   winbind use default domain = true
   winbind offline logon = false
   winbind separator = + 
   winbind enum users = Yes
   winbind enum groups = Yes
   winbind nested groups = Yes
   winbind expand groups = 10
   server string = Linux Server
   strict locking = no
   wins server = 192.168.0.1
   idmap config * : range = 10000-50000000
   idmap config * : backend = rid
   idmap config SENT : range = 10000-50000000
   idmap config SENT : default = yes 
   idmap config SENT : backend = rid
   idmap uid = 10000-50000000
   idmap gid = 10000-50000000

nsswitch.confは次のようになります。

passwd:     files winbind
shadow:     files winbind
group:      files winbind

私は答えがPAMのどこかにあるか、おそらくwinbindルックアップエラーであると推測するのは危険だと思います。 Winbind /サーバーが再起動され、tdbファイルが再構築されました。問題は断続的に発生する可能性もあります。

編集：

最後に、この問題をもう一度見てみましょう。 winbindの代わりにSSSDを使用して認証を再構築しましたが、同じことが起こります

sssd.conf

[sssd] 
config_file_version = 2 
domains = sent.local 
services = nss, pam 
debug_level = 1

[nss] 

[pam] 

[domain/sent.local]
id_provider = ad 
auth_provider = ad 
access_provider = ad

default_Shell = /bin/bash 
fallback_homedir = /home/domain/%u

use_fully_qualified_names = False

これで興味深い結果が得られました。ドメイン管理者になったことがないユーザーは、メンバーであることがわかっているグループを事前にキャッシュするまで、以前と同じ結果になります。次に例を示します。

[root@test-smg1 - (11:46:40) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users)

[root@test-smg1 - (11:46:43) sssd]#  getent group testg2
testg2:*:1084806126:test.user5,test.user4,test.user3,test.user2

[root@test-smg1 - (11:46:46) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users),1084806126(testg2)

[root@test-smg1 - (11:46:49) sssd]#  getent group testg2-nest
testg2-nest:*:1084806125:test.user4,test.user3,test.user2,test.user5

[root@test-smg1 - (11:46:54) sssd]#  id test.user5
uid=1084806380(test.user5) gid=1084800513(domain users) 
groups=1084800513(domain users),1084806126(testg2),1084806125(testg2-nest)

これにより、問題はLinux側よりもActive DirectoryとこのAD固有の実装の方にあると考えられます。ユーザーをドメイン管理者のメンバーにすると、すべてのグループが正しく表示されます。ドメイン管理者からユーザーを削除すると、ユーザーはこの「固定」状態のままになります。

active-directorysambapamwinbindsssd
2
Antitribu

AD設定内の非常に特殊な問題のようです。「グループメンバーシップの読み取り」は、現在機能しているユーザーの認証済みユーザーに対してチェックされ、機能していないユーザーに対してはオフになっています。この権利を追加すると問題が修正されます（ただし、winbindは変更を取得するのにかなりの時間がかかります）。

security panel

1
Antitribu


winbindでも同じ問題が発生します。
ここに私のケースの詳細を分析します：
-この問題の影響を受けるユーザーは数人です（合計800ユーザー）。
-問題のあるアカウントに欠落しているグループはごくわずかです（wbinfo -r; id）（一部はまだ割り当てられています）-おそらくADでの問題のあるユーザー許可が原因ではありません
-グループ内のユーザーのリストが完成しました（グループを取得しました。残念ながら、wbinfoでグループユーザーをリストする方法が見つかりませんでした）
-すべてのサーバーが同じバージョンのsambaを使用しており、同じユーザーのすべてのサーバーで問題が発生します。
SSSDを設定して確認します。この問題は、SAMBAよりもADに関連しています。

0
Robert Heryan