お客様は、NetApp上にある一部のNFSエクスポートへのCIFS(SMB)経由のアクセスを整理する要件を設定しました。 簡単なように聞こえます。すでにエクスポートされたqtreeでCIFSボールを作成する必要があります。 その後、これらのボールへのアクセスをきめ細かく制御する必要があるという要件が提唱されました。 繰り返しになりますが、このタスクは解決されたようです。NetAppと共有フォルダースナップイン(共有アクセス許可)の両方で制御できます。 次に、CIFSボールの異なるサブフォルダーへのアクセスを変更する必要があることがわかりました。 これはすでに重要なタスクであることが判明しています。 CIFSとNFSの両方のアクセス制御リスト(ACL)を同じデータに構成する必要があったため。
一見すると、クラシックLinuxの許可を使用できます。 各フォルダーとファイルには、所有者、所有者グループ、およびその他(その他すべて)の属性があります。 以下は、従来のLinux許可の例です。
>$ ls -lrt drwxr-xr-x. 2 root root 4096 May 8 15:47 nfsv4_test
しかし、よりきめ細かなアクセス制御が必要な場合はどうでしょうか? POSIX ACL? NetAppではサポートされていません。 最終的に、唯一のソリューションはNFSv4 ACLでした。
この記事では、Windowsユーザー向けにNFSv4 ACLを変換する方法について説明します。 セットアップを段階的に実行します。 スタイルは可能な限り簡潔で容量があります。 各項目について詳しくは説明しません。また、すべてのチームの詳細なリストは提供しません。 それでは始めましょう。
NetAppをLDAPにバインドする
このインフラストラクチャには、ユーザーの承認と認証が行われるLDAPサーバーがあると想定されています。 したがって、マッピングは使用されないため、usermap.cfgファイルは修正されません。 また、passwdファイルとgroupファイルを変更する必要はありません。すべてのユーザーとグループはLDAPから取得されます。 以下は、ヒッチの通常の操作に必要なパラメーターです。
ldap.ADdomain ## , ldap.base DC=com ldap.enable on ldap.fast_timeout.enable on ldap.minimum_bind_level simple ldap.name ##, ldap.nssmap.attribute.homeDirectory unixHomeDirectory ldap.nssmap.attribute.uid sAMAccountName ldap.nssmap.objectClass.posixAccount User ldap.nssmap.objectClass.posixGroup Group ldap.port 3268 ldap.retry_delay 10 ldap.servers ## - ldap.usermap.attribute.unixaccount uid ldap.usermap.attribute.windowsaccount sAMAccountName
ターゲットvFilerで実行する必要があります。 これらの設定にはさまざまなバリエーションがあることに注意してください。 また、特定のインフラストラクチャでは、これがうまくいかない場合があります。 このケースでは、FSMOグローバルカタログの役割でAD DCにしがみつきました。 NetAppのカップリングの機能は、 getXXbyYYおよびwccコマンドで確認できます 。 これらのコマンドは、拡張モードでのみ実行できます。
getXXbyYYコマンドの正しい操作の例:
FILER0*> vfiler run VFILER03 getXXbyYY getpwbyname_r ivanov ===== VFILER03 pw_name = ivanov pw_passwd = {{******}} pw_uid = 10000, pw_gid = 10000 pw_gecos = Ivanov, Ivan pw_dir = /home/ivanov pw_shell = /bin/bash
このコマンドがそのような出力を返さない場合、何かが正しく構成されていません。
名前とグループの解決が正しく機能するためには、Unix環境で/etc/nsswitch.confファイルを変更する必要があります。 passwdおよびgroup文字列の先頭にldapを置きます:
passwd: ldap nis files
group: ldap nis files
LDAPを使用する場合のグループの正しい操作に関しては、少し注意が必要です。 Linux環境とWindows環境に同時にアクセスできるグループ内では、属性「memberUid」を入力する必要があります。 重要:小文字で入力する必要があります。 属性は、このグループの登録ユーザーでなければなりません。 以下に、グループの属性のmemberuidフィールドを強調表示します。これは、LinuxおよびWindows環境で使用可能です。
NetAppでNFSv4を構成します。
NFSv4アクセス許可(読み取りUNIX)をWindows環境に変換します。つまり、それらはメインのアクセス制御リストになります。 したがって、ボリュームには/ qtree UNIXスタイルのアクセス許可を使用します。
ボリューム/ qtreeを作成し、その上にNFSエクスポートを作成します。 ファイル/ etc / exportsに次の図が表示されます。
/vol/xxx_VFILER03_nfs_vol00/ACL_test -sec=sys,rw,root=192.168.0.1,nosuid
次のオプションを構成します。
nfs.v4.acl.enable on nfs.v4.enable on nfs.v4.id.allow_numerics on
Linux NFSv4 ACLの構成
次の設定は、NetAppからのエクスポートがマウントされる最終Linuxサーバーで実行する必要があります。
次のオプションを使用してエクスポートをマウントします。
nfs acl、デフォルト、intr、hard、bg、tcp、auto、rw 0 0
次に、エクスポート内で、必要に応じてACLを割り当てます。 NFSv4 ACLはPOSIX ACLよりも少し強力で、CIFS ACLにかなり近いです。 リストを操作するための2つのコマンドがあります:nfs4_getfaclおよびnfs4_setfacl。 1つのコマンドで利用可能なアクセスリストを読み取り、2番目のコマンドを割り当てることは簡単に推測できます。 以下は、テストフォルダーでNFSv4 ACLSを構成する例です。
>$ nfs4_getfacl test A::OWNER@:rwatTnNcCy A::alice@nfsdomain.org:rxtncy A::bob@nfsdomain.org:rwadtTnNcCy A:g:GROUP@:rtncy D:g:GROUP@:waxTC A::EVERYONE@:rtncy D::EVERYONE@:waxTC
Aが許可されている場合、Dは拒否されます。
変更を行うとき、次のコマンドを使用します。
>$nfs4_setfacl –e test
次に、構成がテキストエディターで開きます。
ご覧のとおり、各ファイルとフォルダーのアクセスを制御する多くの可能性があります。
次に、アクセスを構成する必要があります。 その後、Linuxで適切なユーザーに必要な権限があることを確認します。
NetAppでのCIFSバルーンの作成
これを行うには、cifsセットアップを使用してCIFSサービスを構成します。
その後、エクスポートがある同じ/ qtreeのファイラーでCIFSボールを作成します。
FILER0> vfiler run VFILER03 cifs shares -add ACL_test /vol/xxx_ VFILER03 _nfs_vol00/ACL_test
ボールを作成する際の権利は、全員/完全なコントロールを離れます。 これは、ボールのレベルで不必要な制限がないようにするために必要です。
FILER0> vfiler run VFILER03 cifs shares ACL_test /vol/xxx_ VFILER03 _nfs_vol00/ACL_test everyone / Full Control
ファイルシステムレベルでの権限は、NFSv4 ACLツールを使用して既に規制されています。
これが最終的なセットアップです。 これで、Linuxに接続したのと同じユーザーによって接続され、アクセスをチェックします。 NetAppには、Windows環境でのLinux許可を示す古いユーティリティがあります。 SecureShareと呼ばれます。 それを使用して確認することもできます。 以下は、SecureShareをインストールした後の追加タブのスクリーンショットです。