kerberizedNFSv4自動マウントされたhomedirsでの間違ったユーザーマッピング
問題の簡単な説明
この質問は、NFSv4のIDマッピングがうまくいかないことについてです。
NFSサーバー：DSM5.2を備えたSynologyDS。
クライアント：通常のFC22マシンで、上からエクスポートされたフォルダーの1つを/ homeとして自動マウントします。
両方のマシンはfreeIPAドメインの登録済みクライアントであるため、freeIPAサーバーをDNSおよびLDAPサーバーとして使用します。
LDAPユーザーがクライアントにログインすると、マウントされたフォルダーが見つかります。したがって、マウントは機能します。ただし、ファイルの所有権はnobody:nobodyとしてマップされます。この「誰もいない問題」は新しいものではないことは知っていますが、これまでに見つけた解決策のどれも問題を解決していません。
LDAPユーザーログインとファイルタッチ
$ ssh ldapuser1@client1
ldapuser1@client1's password:
-bash-4.3$ id
uid=1172000004(ldapuser1) gid=1172000004(ldapuser1) groups=1172000004(ldapuser1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
ldapuser1は正しくログインでき、uid1172000004を持っています。
-bash-4.3$ pwd
/home/ldapuser1
-bash-4.3$ ls -lan
total 8
drwxrwxrwx. 2 1172000004 1172000004 4096 18 aug 17:34 .
drwxr-xr-x. 3 0 0 0 18 aug 18:33 ..
LDAPユーザーは、以前に作成されて割り当てられたホームディレクトリに正しく配置されます。しかし、新しいファイルは間違った所有権を取得します。
-bash-4.3$ touch a
-bash-4.3$ ls -lan
total 8
drwxrwxrwx. 2 1172000004 1172000004 4096 18 aug 18:41 .
drwxr-xr-x. 3 0 0 0 18 aug 18:33 ..
-rwxrwxrwx. 1 99 100 0 18 aug 18:42 a
99：100はサーバー上でguest:usersであることに注意してください。サーバー上のファイルidmapd.confは、nobody:nobodyをguest:usersにマップするように指示します。
サーバー構成
$ exportfs -v
/volume1/shared_homes xxx.xxx.0.0/24(rw,async,no_root_squash,no_subtree_check,insecure_locks,anonuid=1025,anongid=100,sec=krb5,rw,no_root_squash,no_all_squash)
$ klist -k /etc/nfs/krb5.keytab
Keytab name: FILE:/etc/nfs/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
5 nfs/[email protected]
5 nfs/[email protected]
5 nfs/[email protected]
5 nfs/[email protected]
$ cat /etc/idmapd.conf
[General]
Domain=hq.example.com
Verbosity=10
[Mapping]
Nobody-User=guest
Nobody-Group=users
[Translation]
Method=nsswitch
GSS-Methods=static,synomap
[Static]
$ cat /etc/nsswitch.conf
passwd: files ldap winbind
shadow: files ldap winbind
group: files ldap winbind
osts: files dns wins
bootparams: files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files
netgroup: files
publickey: nisplus
automount: files
aliases: files
クライアント構成
$ automount -s
Mount point: /home
source(s):
instance type(s): sss
map: auto.home
* | -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 nfs-server.hq.example.com:/volume1/shared_homes/&
$ df
nfs-server.hq.example.com:/volume1/shared_homes/ldapuser1 11609721368 2208608120 9400994464 20% /home/ldapuser1
$ cat /etc/idmapd.conf
[General]
Domain=hq.example.com
$ cat /etc/nsswitch.conf
passwd: files sss
shadow: files sss
group: files sss
hosts: files dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
netgroup: files sss
publickey: nisplus
automount: files sss
aliases: files nisplus
sudoers: files sss
$ cat /etc/sysconfig/nfs | egrep -v "^#"
RPCNFSDARGS=""
RPCMOUNTDOPTS=""
STATDARG=""
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
RPCGSSDARGS="-vvv"
GSS_USE_PROXY="yes"
RPCSVCGSSDARGS="-vvv"
BLKMAPDARGS=""
SECURE_NFS=yes
LOGSサーバー
Aug 18 18:50:59 nfs-server idmapd[14622]: nfsdcb: authbuf=gss/krb5 authtype=user
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: calling nsswitch->uid_to_name
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: final return value is 0
Aug 18 18:50:59 nfs-server idmapd[14622]: Server : (user) id "1173000004" -> name "[email protected]"
Aug 18 18:50:59 nfs-server idmapd[14622]: nfsdcb: authbuf=gss/krb5 authtype=group
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_gid_to_name: calling nsswitch->gid_to_name
Aug 18 18:51:00 nfs-server idmapd[14622]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
Aug 18 18:51:00 nfs-server idmapd[14622]: nfs4_gid_to_name: final return value is 0
Aug 18 18:51:00 nfs-server idmapd[14622]: Server : (group) id "1173000004" -> name "[email protected]"
正しいユーザー/ドメインに対してマッピングが要求されているように見えることに注意してください。ただし、ログには、[email protected]と[email protected]のマッピングへの参照も多数見つかりました。
LOGSクライアント
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: key: 0x274d13a5 type: uid value: [email protected] timeout 600
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: calling nsswitch->name_to_uid
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nss_getpwnam: name '[email protected]' domain 'hq.example.com': resulting localname 'ldapuser1'
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: final return value is 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: key: 0x3e28949 type: gid value: [email protected] timeout 600
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: calling nsswitch->name_to_gid
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: final return value is 0
備考と質問
- これらの場合の誤ったマッピングの最も一般的な原因は、両側の
idmapd.confのDomain設定が欠落しているか一貫していないことであると思われます。ここでは両側に正しく設定されています - 静的マッピングを使用する場合、つまり1）サーバー上にローカル
ldapuser1を作成する場合、2）idmapd.confの[Static]の下に[email protected]=ldapuser1というエントリを追加する場合に機能します。ただし、これは目標ではありません。 - Synologyサーバーは明らかにFedora/RedHatではないため、完全なfreeIPAコンパニオンではありません。特に、
SSSDを見逃しています。それでも、うまくいくはずだと思います。
私はこの時点で完全に立ち往生しています。どこに助けを求めるべきかさえわかりません。 Synologyサポートはこれがshould機能すると主張しています。 freeIPAの開発者によると、これはfreeIPA固有ではなく、「ただの」NFSと共同の問題であるため、トピックから外れています。これらすべてのテクノロジーを接続して使用する方法はfreeIPA固有であるため、これは議論の余地があります。
いずれにせよ、私はもう何を見るべきかわかりません。だからこそ、誰かが私に少なくとももう少し前進させてくれることを願ってここに尋ねます。どんな推測でも大歓迎です！
Synologyサポートとのセッションの後、DSM 5.2の制限により、現時点ではこれが機能しないことをようやく理解しました。
問題は、DSMがLDAPサーバーが Michスキーマ を使用すると想定していることです。これはNFS固有であるため、GSS要求が着信したときに属性GSSAuthNameを探します。代わりに、FreeIpaはKerberosを格納しますLDAPのプリンシパル、およびKerberosプリンシパルごとに、常にkrbPrincipalName属性を使用できます。
GSSAuthNameが見つからない場合、DSMはすべてのリクエストをnobodyにマップします。
SSSDを使用してIDマッピングを適切に処理するようにSynologyに機能リクエストを行いました。
それまで、私はsec=sysに頼りました。注：「UID/GIDシフトを有効にする」を確認してください。niSynologyLDAP構成がオフになっていることを確認してください。