Thanks Ondrej for the suggestion.
I believe I have a correctly configured rpc.idmapd, but I'm unsure how I can test and
confirm that other than showing the config files I included in my original post. I do
notice a difference in /var/log/messages on the client and server, when doing an
'ls' as a Kerberos authenticated user on the client system, 'ls'ing the
mounted NFSv4 export.
Any suggestions?
CLIENT:
Jul 14 08:59:42 client nfsidmap[2188]: key: 0x33747100 type: uid value:
sfg@nebula.pw(a)nebula.pw timeout 600
Jul 14 08:59:42 client nfsidmap[2188]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Jul 14 08:59:42 client nfsidmap[2188]: nss_getpwnam: name
'sfg@nebula.pw(a)nebula.pw' domain 'nebula.pw': resulting localname
'sfg(a)nebula.pw'
Jul 14 08:59:42 client nfsidmap[2188]: nfs4_name_to_uid: nsswitch->name_to_uid returned
0
Jul 14 08:59:42 client nfsidmap[2188]: nfs4_name_to_uid: final return value is 0
Jul 14 08:59:42 client nfsidmap[2190]: key: 0x161ed748 type: gid value:
datausers@nebula.pw(a)nebula.pw timeout 600
Jul 14 08:59:42 client nfsidmap[2190]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Jul 14 08:59:42 client nfsidmap[2190]: nfs4_name_to_gid: nsswitch->name_to_gid returned
0
Jul 14 08:59:42 client nfsidmap[2190]: nfs4_name_to_gid: final return value is 0
Jul 14 08:59:42 client nfsidmap[2192]: key: 0xe877f14 type: uid value: nfsnobody(a)nebula.pw
timeout 600
Jul 14 08:59:42 client nfsidmap[2192]: nfs4_name_to_uid: calling nsswitch->name_to_uid
Jul 14 08:59:42 client nfsidmap[2192]: nss_getpwnam: name 'nfsnobody(a)nebula.pw'
domain 'nebula.pw': resulting localname 'nfsnobody'
Jul 14 08:59:42 client nfsidmap[2192]: nfs4_name_to_uid: nsswitch->name_to_uid returned
0
Jul 14 08:59:42 client nfsidmap[2192]: nfs4_name_to_uid: final return value is 0
Jul 14 08:59:42 client nfsidmap[2194]: key: 0x3efd228b type: gid value:
nfsnobody(a)nebula.pw timeout 600
Jul 14 08:59:42 client nfsidmap[2194]: nfs4_name_to_gid: calling nsswitch->name_to_gid
Jul 14 08:59:42 client nfsidmap[2194]: nfs4_name_to_gid: nsswitch->name_to_gid returned
0
Jul 14 08:59:42 client nfsidmap[2194]: nfs4_name_to_gid: final return value is 0
SERVER:
Jul 14 08:59:42 fs rpc.idmapd[683]: nfsdcb: authbuf=gss/krb5p authtype=user
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_uid_to_name: calling nsswitch->uid_to_name
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_uid_to_name: final return value is 0
Jul 14 08:59:42 fs rpc.idmapd[683]: Server : (user) id "1360001159" -> name
"sfg@nebula.pw(a)nebula.pw"
Jul 14 08:59:42 fs rpc.idmapd[683]: nfsdcb: authbuf=gss/krb5p authtype=group
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_gid_to_name: calling nsswitch->gid_to_name
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_gid_to_name: final return value is 0
Jul 14 08:59:42 fs rpc.idmapd[683]: Server : (group) id "1360001156" -> name
"datausers@nebula.pw(a)nebula.pw"
Jul 14 08:59:42 fs rpc.idmapd[683]: nfsdcb: authbuf=gss/krb5p authtype=user
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_uid_to_name: calling nsswitch->uid_to_name
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_uid_to_name: final return value is 0
Jul 14 08:59:42 fs rpc.idmapd[683]: Server : (user) id "65534" -> name
"nfsnobody(a)nebula.pw"
Jul 14 08:59:42 fs rpc.idmapd[683]: nfsdcb: authbuf=gss/krb5p authtype=group
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_gid_to_name: calling nsswitch->gid_to_name
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
Jul 14 08:59:42 fs rpc.idmapd[683]: nfs4_gid_to_name: final return value is 0
Jul 14 08:59:42 fs rpc.idmapd[683]: Server : (group) id "65534" -> name
"nfsnobody(a)nebula.pw"
John Delisle | Solution Architecture | Ceridian HCM | w: 204.975.5909 / 204.414.1285 |c:
204.294.5529
Ceridian. Makes Work Life Better(tm)
From: sssd-users-bounces(a)lists.fedorahosted.org
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek
Sent: Tuesday, July 14, 2015 1:38 AM
To: End-user discussions about the System Security Services Daemon
Subject: Re: [SSSD-users] ID mapping issue with Linux NFS client and server with AD DC
KDC
Hi,
You are most probably using numeric UIDs in nfs upcalls (i.e. not using ID mapper).
Whilst this is quite OK with auth_sys (well..., it is not documented, but say, silently
accepted), with auth_gss it is forbidden.
Make sure ID mapper correctly configured on both sides (client and server) and running.
You can also run it in foreground to see if it does not like something.
Ondrej
From:
sssd-users-bounces@lists.fedorahosted.org<mailto:sssd-users-bounces@lists.fedorahosted.org>
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Delisle, John
Sent: 14 July 2015 04:26
To: sssd-users@lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org>
Subject: [SSSD-users] ID mapping issue with Linux NFS client and server with AD DC KDC
Hello,
I'm working to get an NFSv4 client/server configuration working where the client and
server are both CentOS 7.1, using Kerberos krb5p for encryption, and Windows Server 2012
R2 AD DC as the KDC.
- Both client and server are successfully joined to the domain using "realm
join nebula.pw"
- Two users were added to AD: clientnfs and fsnfs, with UPNs like
"nfs/client.nebula.pw" and "nfs/fs.nebula.pw"
- SPNs were added for bare hostnames via setspn.
- Both clientnfs and fsnfs have "require pre-auth disabled", and AES
128 and 256 enabled
- The keytabs for clientnfs and fsnfs were exported with ktpass and merged into
/etc/krb5.keytab on the respective systems
- Users were created in AD (no special settings on them). I can SSH into both
client and server using eg: "ssh
someone@nebula.pw@client.nebula.pw<mailto:someone@nebula.pw@client.nebula.pw>"
Now, onto the problem..
- Using just AUTH_SYS, NFSv4 is working great with sssd correctly mapping IDs
etc. between the client and server. Files have large-number UID/GID, belonging to the
correct users. It appears sssd works great here. I SSH in as an AD user, cd to the
mount, and can work as expected.
- Changing nothing but adding "sec=krb5p" to the exports and mounts, I
run into issues. All users are assigned to nfsnobody. I'm not sure what is breaking
down where. To elaborate, I am running "kinit -k nfs/client.nebula.pw" and
"kinit -k nfs/fs.nebula.pw" on the client and server as root prior to mounting.
If there are other logs or debugging info that would be helpful please let me know.
"fs.nebula.pw" is the NFS server, "client.nebula.pw" is the NFS
client, "dc.nebula.pw" is the ADDC, NEBULA.PW is the realm.
[root@fs /]# cat /etc/exports
/exports *(fsid=0,rw,insecure,no_subtree_check,no_root_squash,sec=krb5p)
/exports/data *(rw,sync,nohide,insecure,no_subtree_check,no_root_squash,sec=krb5p)
------------
[root@client ~]# history | grep mount
6 mount -tnfs4 -overs=4.1,sec=krb5p fs.nebula.pw:/data /data
----------
The following config files are identical on client and server, so I'm just including
them once here:
[root@client ~]# grep -v -e '^ $' -e '^$' -e '^#' /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = NEBULA.PW
[realms]
NEBULA.PW = {
}
[domain_realm]
nebula.pw = NEBULA.PW
.nebula.pw = NEBULA.PW
----------
[root@client ~]# cat /etc/sssd/sssd.conf
[sssd]
domains = nebula.pw
config_file_version = 2
services = nss, pam
debug_level = 10
[domain/nebula.pw]
debug_level = 10
ad_domain = nebula.pw
krb5_realm = NEBULA.PW
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = ad
----------------
[root@client ~]# grep -v -e '^$' -e '^#' /etc/idmapd.conf
[General]
Verbosity = 10
Domain = nebula.pw
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
Method = sss
[Static]
[UMICH_SCHEMA]
LDAP_server =
ldap-server.local.domain.edu
LDAP_base = dc=local,dc=domain,dc=edu
--------------
[root@client ~]# grep -v -e '^$' -e '^#' /etc/sysconfig/nfs
RPCNFSDARGS="-d -s"
RPCMOUNTDOPTS="-d all"
STATDARG=""
SMNOTIFYARGS=""
RPCIDMAPDARGS="-vvvv"
RPCGSSDARGS="-vvvv -n"
GSS_USE_PROXY="yes"
RPCSVCGSSDARGS="-vvvv"
BLKMAPDARGS=""
SECURE_NFS="yes"
RPCNFSDCOUNT=64
-----------
[root@client ~]# grep -v -e '^ $' -e '^$' -e '^#'
/etc/request-key.d/id_resolver.conf
create id_resolver * * /usr/sbin/nfsidmap -vvvv %k %d
---------
Thanks!
John Delisle | Solution Architecture | Ceridian HCM | w: 204.975.5909 / 204.414.1285 |c:
204.294.5529
Ceridian. Makes Work Life Better(tm)
This communication is intended to be received only by the individual[s] or entity[s] to
whom or to which it is addressed, and contains information which is confidential,
privileged and subject to copyright. Any unauthorized use, copying, review or disclosure
is prohibited. Please notify the sender immediately if you have received this
communication in error [by calling collect, if necessary] so that we can arrange for its
return at our expense. Thank you in advance for your anticipated assistance and
cooperation.
Cette communication est destinée uniquement à la personne ou à la personne morale à qui
elle est adressée. Elle contient de l'information confidentielle, protégée par le
secret professionnel et sujette à des droits d'auteurs. Toute utilisation,
reproduction, consultation ou divulgation non autorisées sont interdites. Nous vous prions
d'aviser immédiatement l'expéditeur si vous avez reçu cette communication par
erreur (en appelant à frais virés, si nécessaire), afin que nous puissions prendre des
dispositions pour en assurer le renvoi à nos frais. Nous vous remercions à l'avance de
votre coopération.
-----
The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to:
communications@s3group.com<mailto:communications@s3group.com>. Thank You. Silicon
and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered
Office: South County Business Park, Leopardstown, Dublin 18.