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@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@nebula.pw' domain 'nebula.pw': resulting localname 'sfg@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@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@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@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@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@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@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@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@nebula.pw"

 

 

 

 

 

 

John Delisle | Solution Architecture | Ceridian HCM | w: 204.975.5909 / 204.414.1285 |c: 204.294.5529
Ceridian. Makes Work Life Better™

 

From: sssd-users-bounces@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] On Behalf Of Delisle, John
Sent: 14 July 2015 04:26
To: 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

 

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™

 

 

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. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.