web-dev-qa-db-ja.com

Linux ACLはドメイングループに間違ったGIDを使用していますが、数値GIDは問題ありません

以下の編集を参照してください、問題はuid/gidからsidへのマッピングにあることが判明し、問題をより迅速に理解するのに役立つ回避策を示しています。

likewise-open が提供するツールを使用して、Windowsドメインに結合されたUbuntu 11.04サーバーマシン（これをデータと呼びます）があります。

  1. AD資格情報でマシンにログオンします
  2. 拡張ACLを使用してファイルとフォルダーのアクセス許可を設定すると、それらは機能します。したがって、フォルダに「ドメイン管理者」権限を設定することで、別のドメイン管理者アカウントでマシンにログオンし、そのフォルダにアクセスできます。

そのため、コンピュータ自体が、自分がメンバーになっているドメイングループを理解し、権限を正しく処理できます。

しかし、問題は、samba共有からファイルにアクセスしたいときです。 Windowsは、同じ「ドメイン管理者」または他のドメインユーザー/グループについて話していることを理解していないようです。

細部

ホームフォルダーのACLが有効になっている

Smb.confにある私のシェア：

[home]
        path = /home/local/MYDOMAIN
        browsable = yes
        guest ok = no
        read only = no
        writeable = yes
        valid users = MYDOMAIN\Administrator, @MYDOMAIN\"Domain Users", @MYDOMAIN\"Domain Admins"
        write list = @MYDOMAIN\"Domain Users", @MYDOMAIN\"Domain Admins"
        nt acl support = yes
        create mask = 700
        directory mask = 700
        hide dot files = yes

これまでのところ、フォルダに「その他」の読み取り/実行権限ビットが設定されていれば、共有にアクセスできます。

それでは、ドメイン権限を設定してtest_directoryにアクセスしてみましょう。 UNIXのアクセス許可をすべて削除します。

janis.veinbergs@data:/home/local/MYDOMAIN$ whoami
janis.veinbergs
janis.veinbergs@data:/home/local/MYDOMAIN$ id janis.veinbergs
...1319633408(domain^admins)...
janis.veinbergs@data:/home/local/MYDOMAIN$ cd /home/local/MYDOMAIN
janis.veinbergs@data:/home/local/MYDOMAIN$ Sudo chown root:root ./test_directory/
janis.veinbergs@data:/home/local/MYDOMAIN$ Sudo chmod 700 ./test_directory/

だからマシン上で、私が試してみると

ls ./test_directory/

明らかに、私は得る

ls: cannot open directory ./test_directory/: Permission denied

したがって、「ドメイン管理者」のすべての権限を追加します。 （MYDOMAINはマシンのデフォルトのドメインであるため、MYDOMAIN \をスキップすることもできます）

$ Sudo setfacl -m g:MYDOMAIN\\"Domain Admins":rwx ./test_directory/

ディレクトリでできること

$ echo "yay" >> ./test_directory/test.txt
$ ls ./test_directory/
test.txt

これまでのところ、データはドメイングループを理解しています。

しかし、Windowsマシン（PowerShellから）でその共有にアクセスしようとすると：

PS> whoami
mydomain\janis.veinbergs
PS> gci \\data\home\test_directory
Get-ChildItem : Access to the path '\\data\home\test_directory' is denied.

次に、データから、他のユーザーのアクセス許可を追加して、Windowsからそのフォルダーにアクセスできるようにします。

$ Sudo chmod o+rx ./test_directory/

今、私はウィンドウズから、私はファイルを見ることができます：

PS> gci \\data\home\test_directory


    Directory: \\data\home\test_directory


Mode                LastWriteTime     Length Name                                                                                      
----                -------------     ------ ----                                                                                      
-----       2012.02.06.     14:56          4 test.txt

これで、プロパティウィンドウでアクセス許可を表示できます（ローカライズされていますが、アイデアを得ることができます） Permission properties

MYDOMAIN\domain ^ adminsではなく、Unix Group\domain ^ adminsと表示されるのはなぜですか。ここで何が欠けているのか、それを機能させる方法は？

編集：回避策を見つけました

回避策と考えられる原因を見つけましたが、解決方法がわかりません。ID間のマッピングが間違っていることがわかりました。

MYDOMAIN\Domain Adminsグループのwbinfoを使用してsidからgidへのマッピングを検索すると、マップされたUNIXのgidが10010であることがわかります。また、名前ではなくgidを使用してアクセス許可を設定すると、アクセス許可が機能し、Windowsがそれらを理解します。

$ Sudo setfacl -m g:10010:rwx ./test_directory/

パーミッションを数値形式で列挙すると、gidとsidを確認するために、MYDOMAIN\"Domain Admins"のようなパーミッションを設定すると、実際には別のGIDが使用されることがわかります。

$ getfacl -n ./test_directory/
# file: test_directory/
# owner: 0
# group: 0
user::rwx
group::r-x
group:10010:rwx  <-- this is the actual GID mapping for MYDOMAIN\\"Domain Admins" group (setfacl -m g:10010:rwx) and it works when browsing share with windows
group:1319633408:rwx <-- this entry is when setting permission like setfacl -m g:MYDOMAIN\\"Domain Admins":rwx
mask::rwx
other::---

次に、smb.confでidmap構成を確認しました。

   idmap domains = ALL
   idmap config ALL:backend = lwicompat_v4
   idmap config ALL:default = yes
   idmap config ALL:readonly = yes
   idmap uid = 10000-33554431
   idmap gid = 10000-33554431

ACLエントリ1319633408からのgidが定義されたスコープに入らないことがわかります。したがって、スコープを10000-3355443100に拡張してsmbdを再起動しようとしましたが、それでも機能しませんでした。

だから今私は回避策を持っています、gid、sidを使用してアクセス許可を設定しますが、それはユーザーフレンドリーではありません。これを修正するにはどうすればよいですか？

linuxwindowsactive-directorypermissionslikewise-open
6
Janis Veinbergs

私はまだ同様にインストールする必要があったことが判明しました-cifsサポート。

それはこれらのコマンドを実行することの問題でした：

$ /opt/likewise/bin/samba-interop-install --install
$ service smbd restart
$ service winbind restart

クレジット Likewise Open 6＆Samba-A Better Open Source File Server

ここで、SIDからGIDへのマッピング時に、短いGID 10010ではなく、同様に使用する正しいGIDを取得します。

Sudo wbinfo -n "Domain Admins"
<i get long SID: S-...-512>
wbinfo -Y S-...-512
1319633408
4
Janis Veinbergs

1つの提案： 同様にCentrifyスペースを含む名前を引用符で囲むのは好きではありません。代わりに、バックスラッシュを使用してグループに注意する必要があります。したがって、DebianでLikely Openを使用してWindowsグループDomain Adminsを参照している場合、%Domain\ Adminsと記述します。それを試して、GIDが正しく割り当てられるかどうかを確認できますか？

更新：

ぐっすり眠った後、私は同様にオープンではなく、競合他社のCentrifyExpressを使用していることに気付きました。これは、一方の投票ではなく、将来その答えを読む可能性のある他の人への説明です。

同様に開くをインストールできる予備のマシンがあります。それを使用して問題を再現し、新しい回答を作成します。混乱させて申し訳ありません！

0
Simon Hova