Неправильное сопоставление пользователей в доменных папках с автоматическим подключением NFSv4
Краткое описание проблемы
Этот вопрос о неправильном отображении идентификатора в NFSv4.
Сервер NFS: Synology DS, с DSM 5.2.
Клиент: Обычный компьютер FC22, который автоматически монтирует как /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
может войти в систему правильно и имеет UID 1172000004.
-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/nfs-server.hq.example.com@HQ.EXAMPLE.COM
5 nfs/nfs-server.hq.example.com@HQ.EXAMPLE.COM
5 nfs/nfs-server.hq.example.com@HQ.EXAMPLE.COM
5 nfs/nfs-server.hq.example.com@HQ.EXAMPLE.COM
$ 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
ЛОГИ Сервер
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 "ldapuser1@hq.example.com"
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 "ldapuser1@hq.example.com"
Обратите внимание, что сопоставления, по-видимому, запрашиваются для правильного пользователя / домена. В журнале, однако, я также нашел много ссылок на отображения root@hq.example.com
а также guest@hq.example.com
,
LOGS Client
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: key: 0x274d13a5 type: uid value: ldapuser1@hq.example.com 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 'ldapuser1@hq.example.com' 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: ldapuser1@hq.example.com 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
Замечания и вопросы
- Наиболее распространенной причиной неправильного отображения в этих случаях является отсутствие или непоследовательность
Domain
установка вidmapd.conf
с обеих сторон. Здесь он правильно установлен с обеих сторон - Это работает, если я использую статические сопоставления, то есть 1) создать локальный
ldapuser1
на сервере 2) добавить запись под [Static] вidmapd.conf
, который говоритldapuser1@HQ.EXAMPLE.COM=ldapuser1
, Однако это не цель. - Сервер Synology явно не Fedora/RedHat, так что это не идеальный компаньон freeIPA. В частности, он пропускает
SSSD
, Тем не менее, я думаю, что это должно работать.
Я полностью застрял в этой точке. Я даже не уверен, куда обратиться за помощью. Служба поддержки Synology утверждает, что это должно работать. По словам разработчиков freeIPA, это даже не по теме, потому что не специфичные для freeIPA, а "просто" проблемы NFS & co. Это спорно, как способ связаны и используются все эти технологии является freeIPA специфична.
В любом случае, я больше не знаю, на что смотреть. Вот почему я спрашиваю здесь, надеясь, что кто-то может заставить меня сделать хотя бы еще один шаг вперед. Любая догадка приветствуется!
1 ответ
После сеанса с поддержкой Synology я наконец понял, что это не может работать в данный момент из-за ограничений DSM 5.2.
Проблема в том, что DSM предполагает, что сервер LDAP использует схему UMich, которая специфична для NFS, поэтому ищет атрибут GSSAuthName
когда приходит запрос GSS. Вместо этого FreeIpa хранит принципалы Kerberos в LDAP, и для каждого принципала Kerberos всегда есть krbPrincipalName
атрибут доступен.
Не найти GSSAuthName
DSM отображает каждый запрос на nobody
,
Я сделал особый запрос к Synology, чтобы использовать SSSD для правильной обработки идентификаторов.
До этого я прибегал к sec=sys
, Примечание: убедитесь, что "Включить смещение UID/GID" ni Конфигурация Synology LDAP не отмечена!