web-dev-qa-db-ja.com

Windows ACLをCIFS共有のLinux ACLにマップする方法は？

コンテキスト

Active Directoryドメインとネットワーク共有を備えたWindowsサーバーがあります。

Linuxマシンを使用していて、共有をマウントしたい。

Sudo mount -t cifs //server/share /mnt/share -o user=[act-dir user],domain=[domain],uid=[linux user],gid=[linux group]

それは多かれ少なかれ大丈夫です。 Linuxユーザーが共有上のすべてのファイルにマッピングされ、一部のACLが翻訳されます。しかし、私はさらにレベルを上げたいです：

  • Linuxボックスに複数のユーザーが接続している
  • 各Linuxユーザーは専用のActive Directoryアカウントを持っています
  • 各Windows所有者が存在する場合、対応するLinux所有者にマッピングする

解決策と問題

Sambaは、マウントオプションcifsaclを提供しています。これは、セットアップに必要ですcifs.idmapおよびwinbindd。両方がインストールされています。両方のmanページを読んで設定しようとしましたが、機能しません。新しくマウントされたコマンドは次のとおりです。

Sudo mount -t cifs //server/share /mnt/share -o user=[act-dir user],domain=[domain],cifsacl

しかし、すべてがroot：rootにマップされます。つまり、cifs.idmapを実行できませんでした。

実際のところ、実際のマッピングの記述場所がわからなかったので、私は驚くことはありません。WindowsuserXが実際にLinux userYにマップすることをどこに記述すればよいですか。そして、私はwinbindd構成が正しいかどうかわかりません、パラメータの最小セットは何である必要がありますか、そしてsmbdやnmbdが実行するために必要ですか？ファイアウォールでポートを開く必要がありますか？

背景情報

共有構造

共有ディレクトリには、いくつかのサブディレクトリ、いくつかのコモンズ、およびいくつかの「プライベート」があります（ただし、プライベートディレクトリは実際には誰でも読み取り可能です）。各ユーザーは、時々、共有スペースや他のユーザーのプライベートディレクトリにアクセスする必要がありますが、主に/多くの場合は自分のディレクトリにアクセスします。

技術データ

  • RHEL 6、Samba 3.5.6
  • Ubuntu 12.04、Samba 3.6.3
linuxwindowsaccess-control-listcifs
5
Huygens

マッピングが機能するようにsamba（winbind）内のユーザー名マップ機能を使用して、winbindがすべてのLinuxユーザーのADアカウントを認識できるようにする必要があります。ユーザー名マップはコマンドとリスト（およびいくつかのパターン変換）を取ることができると思いますが、たとえばpam_winbindを使用することにより、Linuxユーザー名がADユーザー名と一致する場合ははるかに簡単です。マッピングが機能しているときは、共有が機能しているかどうかの検証を実際に開始できると思います。

1
mycroes

CIFSマルチユーザーマウントを設定する方法

CIFSはセッションベースのプロトコルです。つまり、セッションはCIFSセッションにログオンしたユーザーの権限で実行されます。したがって、CIFSを使用する通常の方法は、ユーザーのログイン時にユーザーのログイン権限で共有をマウントすることです。これがプロトコルの設計です。

それにもかかわらず、Linux CIFSドライバーは、起動時に共有をマウントする方法をすでに提供しています。これはマルチユーザーマウントと呼ばれます。マルチユーザーマウントの戦略は、最小の権限で起動時に共有をマウントすることです。共有にアクセスするすべてのユーザーに対して、CIFSドライバーはサーバーとの個別のCIFSセッションを内部的に作成します。

ユーザーがマルチユーザーがマウントした共有に初めてアクセスするとき、CIFSドライバーはこのユーザーのファイルサーバーとのCIFSセッションを作成する必要があります。これには、セキュリティ情報が必要です。ユーザー名とパスワード。ドライバーはログインデータを要求できないため、現在のLinuxユーザーのカーネルキーリングを調べます。適切なセキュリティ情報が見つかると、CIFSドライバーはそれを使用して、ファイルサーバーと現在のユーザーのCIFSセッションを作成し、ユーザーは共有にアクセスできます。

この投稿はハウツーのように見えるかもしれませんが、実際には、起こり得る落とし穴のコレクションとして意図されています。

ステップ1：ファイルサーバーSHAREに共有FILESERVERを作成し、ローカルユーザー_CIFS_GUEST_に共有を作成します最小限の権限を持つファイルサーバー。ユーザーは、リモートマシンからの共有のマウントのみを許可されている必要があります。ユーザーのパスワードは有効期限が切れてはいけません。

注意と落とし穴：

  • ユーザーはFILESERVERのローカル「リモートデスクトップユーザー」グループに属している必要はありません。

  • 共有SHAREがいわゆる " administrative share "の場合、ユーザー（_CIFS_GUEST_を含む）は管理者権限を持っている必要があります。通常の非管理タイプの共有を作成することをお勧めします。

    ステップ2：Linuxマシンから共有をマウントします。

    mount.cifs // FILESERVER/SHARE/mnt --verbose -o domain = FILESERVER、username = CIFS_GUEST

これにより、共有が適切にマウントされます。そうでない場合は、mount.cifs(8)のマンページを参照することをお勧めします。

注意と落とし穴：

  • オプション_domain=FILESERVER_を必ず指定してください。そうでない場合、ファイルサーバーは_CIFS_GUEST_がドメイン（非ローカル）ユーザーであると想定し、アクセスを拒否します。
  • 認証で問題が発生した場合は、サーバーのログを確認してください（例：Windowsファイルサーバーの場合はWindowsイベントログ）
  • マウントオプションnopermを追加して、クライアント側の権限チェックを無効にすることができます。権限はとにかくサーバーによって実施されます。

ステップ3：multiuserオプションを使用して再度マウントします。

_umount /mnt
mount.cifs //FILESERVER/SHARE /mnt -v -o multiuser,domain=FILESERVER,username=CIFS_GUEST
_

multiuserが使用されていることを確認します。

_mount | grep cifs
_

ステップ4：自動の非対話型マウント用の認証情報ファイルを作成します。すべての非ルートアクセスから保護します。

_/etc/cifs.SHARE.cred_のファイル内容：

_username=CIFS_GUEST
password=<pass>
Domain=FILESERVER
_

次に実行します：

_chown root /etc/cifs.SHARE.cred
chmod 600 /etc/cifs.SHARE.cred
_

注意と落とし穴：

  • UTF-8エンコーディングを使用する場合は、認証情報ファイルにバイトオーダーマーク（BOM）が含まれていないことを確認してください。そうしないと、_mount.cifs_から誤った「資格情報が正しくフォーマットされていません」というメッセージが表示されることがあります。

ステップ5：資格情報ファイルで共有をマウントしてみます。これは完全に非対話型であるはずです：

_umount /mnt
mount.cifs //FILESERVER/SHARE /mnt -v -o multiuser,credentials=/etc/cifs.SHARE.cred
_

これが機能する場合は、マウントを_/etc/fstab_に追加できます。

_...
//FILESERVER/SHARE /mnt cifs rw,auto,multiuser,credentials=/etc/cifs.SHARE.cred 0 0
...
_

注意と落とし穴：

  • 共有の自動マウント用にオプションautoが追加されました。

ステップ6：Linuxマシンに通常のユーザーとしてログインします。マウントされた共有にアクセスしてみます。

_cd /mnt
ls
_

許可は拒否されるべきです。

次に、CIFS資格情報をセッションキーリングに手動で保存します。

_cifscreds add FILESERVER -u <username>
_

パスワードの入力を求められます。その後、_<username>_がファイルサーバー上の共有へのアクセス権限を持っている場合は、共有にアクセスできるはずです。

注意と落とし穴：

  • Windowsエクスプローラーを使用して、_<username>_に共有へのアクセス権限があることを確認できます。このようにして、エラーがFILESERVERにあることを除外できます。
  • cifscredsが非永続的なセッションキーリングに関する警告を表示する場合は、_keyctl session_と入力して再試行してください。
  • _keyctl show -3_を使用して、キーリングの内容を表示できます。
  • cifscredsは、ファイルサーバーとのCIFSセッションを作成しません。セキュリティ情報をキーリングに入れるだけなので、CIFSドライバーは、共有にアクセスしたときに、それを使用してCIFSセッションを作成できます。つまり、キーリングのキーを_cifscreds update ..._で変更すると、古いユーザー（！）でログオンしたままになります。

ステップ7：最後に、キーリングを供給するステップを自動化できます。 rootとして、PAM設定に次の行を追加します（例：_/etc/pam.d/login_）：

_...
auth optional pam_cifscreds.so debug
...
session optional pam_cifscreds.so domain=<AD Domain> debug
...
_

最初の行は、ログイン時のパスワードをキャプチャします。パスワードは、セッションが作成されるまで保存されます。セッションが作成されると、2行目でレコードがキーリングに配置されます。 cifscredsを呼び出す必要はなく、共有はログイン後すぐにアクセスできる必要があります。

注意と落とし穴：

  • ログの冗長性を減らすために、テスト後にdebugオプションを削除することができます。
  • PAMスタックのすべてのケースで両方の行が実行されることを確認してください。 （設定ファイルのエントリのシーケンス）
  • optionalをrequiredに置き換えて、ファイルサーバーでの認証を強制できます。
  • 2行目の前に、永続的なセッションキーリングの存在を確認する必要があります。疑問がある場合は、2行目の直前に次の行を追加してください：_session required pam_keyinit.so_
  • debugオプションを使用すると、両方の行でシステムログにメッセージが残るはずです。
  • 同じ変更を他のPAM対応ログインプログラムの構成にも行う必要があります。 _/etc/pam.d/sshd_、_/etc/pam.d/xdm_、...

この時点まで、共有上のファイルとフォルダへのアクセス許可はFILESERVERによって実施されています。 Linux側に表示される権限、ユーザー名、グループ名は完全に間違っています。それらを適切に取得するには、マウントオプションcifsaclを追加し、IDマッピングを設定します。ただし、これには、おそらくWinbindサービスのセットアップが特に必要です。追加情報はマンページmount.cifs(8)にあります。

1
ManuelAtWork