[Freeipa-users] IPA+AD trust and NFS nobody issue
Hi, Environment: RHEL 7 IPA Server 3.3 with a trust to a Windows 2012 Server AD RHEL 7 NFS Server RHEL 7 Client I have found one problem when using a NFS 4 shared Home Directory for AD users logging in to IPA. I have created a NFS share /home/adexample.org and use autofs map in IPA. All wbinfo tests works as well as id. I can login fine through SSH and Shell with adt...@adexample.org The problem is that I can add the AD user as owner of his Home Directory and if I log in to the NFS Server locally or through ssh permissions are correct but when logging in to any other computer i get "nobody" as owner. Groups are no problem since AD groups can be mapped to Posix groups. Idmap.conf domain is set to the IPA Domain. Is there some way to get NFS working with the AD user as owner of his Home Directory? Thanks for any help. This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 06/03/2014 09:07 AM, Johan Petersson wrote: Hi, Environment: RHEL 7 IPA Server 3.3 with a trust to a Windows 2012 Server AD RHEL 7 NFS Server RHEL 7 Client I have found one problem when using a NFS 4 shared Home Directory for AD users logging in to IPA. I have created a NFS share /home/adexample.org and use autofs map in IPA. All wbinfo tests works as well as id. I can login fine through SSH and Shell with adt...@adexample.org The problem is that I can add the AD user as owner of his Home Directory and if I log in to the NFS Server locally or through ssh permissions are correct but when logging in to any other computer i get "nobody" as owner. Are those computers RHEL7 NFS clients with SSSD? Can you describe them in more details please? Groups are no problem since AD groups can be mapped to Posix groups. Idmap.conf domain is set to the IPA Domain. Is there some way to get NFS working with the AD user as owner of his Home Directory? Thanks for any help. /This e-mail is private and confidential between the sender and the addressee. / /In the event of misdirection, the recipient is prohibited from using, copying or / /disseminating it or any information in it. Please notify the above if any misdirection./ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Yes Client is default RHEL 7 and both IPA and NFS Server is aswell. server.ad.home = AD Server share.linux.home = NFS Server ipa.linux.home = IPA Server client.linux.home = Client NFS with automounted krb5p Home Directories work for IPA users. sssd-1.11.2-65.el7.x86_64 id adt...@ad.home uid=497801107(adt...@ad.home) gid=497801107(adt...@ad.home) groups=497801107(adt...@ad.home),497800513(domain us...@ad.home) getent passwd adt...@ad.home adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest: klist after kinit adt...@ad.home [root@client ~]# klist -e Ticket cache: KEYRING:persistent:0:0 Default principal: adt...@ad.home Valid starting ExpiresService principal 06/04/14 11:28:35 06/04/14 21:28:35 krbtgt/ad.h...@ad.home renew until 06/05/14 11:28:30, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 klist after ssh adt...@ad.home@ipa.linux.home klist Ticket cache: KEYRING:persistent:497801107:krb_ccache_y5TW1kB Default principal: adt...@ad.home Valid starting ExpiresService principal 06/04/14 11:35:16 06/04/14 21:35:16 nfs/share.linux.h...@linux.home renew until 06/05/14 11:28:30 06/04/14 11:35:16 06/04/14 21:35:16 krbtgt/linux.h...@ad.home renew until 06/05/14 11:28:30 06/04/14 11:28:35 06/04/14 21:35:16 krbtgt/ad.h...@ad.home renew until 06/05/14 11:28:30 Home Directory gets mounted by autofs through sssd but user:group is both nobody. The Client's sssd.conf: [domain/linux.home] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.home id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.linux.home chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa.linux.home ldap_tls_cacert = /etc/ipa/ca.crt autofs_provider = ipa ipa_automount_location = default subdomains_provider = ipa [sssd] services = nss, pam, autofs, ssh config_file_version = 2 domains = linux.home [nss] [pam] [sudo] [autofs] [ssh] [pac] From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, June 03, 2014 6:48 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue On 06/03/2014 09:07 AM, Johan Petersson wrote: Hi, Environment: RHEL 7 IPA Server 3.3 with a trust to a Windows 2012 Server AD RHEL 7 NFS Server RHEL 7 Client I have found one problem when using a NFS 4 shared Home Directory for AD users logging in to IPA. I have created a NFS share /home/adexample.org and use autofs map in IPA. All wbinfo tests works as well as id. I can login fine through SSH and Shell with adt...@adexample.org<mailto:adt...@adexample.org> The problem is that I can add the AD user as owner of his Home Directory and if I log in to the NFS Server locally or through ssh permissions are correct but when logging in to any other computer i get "nobody" as owner. Are those computers RHEL7 NFS clients with SSSD? Can you describe them in more details please? Groups are no problem since AD groups can be mapped to Posix groups. Idmap.conf domain is set to the IPA Domain. Is there some way to get NFS working with the AD user as owner of his Home Directory? Thanks for any help. This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. ___ Freeipa-users mailing list Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
I found one clue to the issue and as i thought it has to do with m From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Johan Petersson Sent: Wednesday, June 04, 2014 12:02 PM To: d...@redhat.com; freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue Yes Client is default RHEL 7 and both IPA and NFS Server is aswell. server.ad.home = AD Server share.linux.home = NFS Server ipa.linux.home = IPA Server client.linux.home = Client NFS with automounted krb5p Home Directories work for IPA users. sssd-1.11.2-65.el7.x86_64 id adt...@ad.home<mailto:adt...@ad.home> uid=497801107(adt...@ad.home<mailto:adt...@ad.home>) gid=497801107(adt...@ad.home<mailto:adt...@ad.home>) groups=497801107(adt...@ad.home),497800513(domain<mailto:adt...@ad.home),497800513(domain> us...@ad.home<mailto:us...@ad.home>) getent passwd adt...@ad.home<mailto:adt...@ad.home> adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest<mailto:adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest>: klist after kinit adt...@ad.home<mailto:adt...@ad.home> [root@client ~]# klist -e Ticket cache: KEYRING:persistent:0:0 Default principal: adt...@ad.home<mailto:adt...@ad.home> Valid starting ExpiresService principal 06/04/14 11:28:35 06/04/14 21:28:35 krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home> renew until 06/05/14 11:28:30, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 klist after ssh adt...@ad.home@ipa.linux.home<mailto:adt...@ad.home@ipa.linux.home> klist Ticket cache: KEYRING:persistent:497801107:krb_ccache_y5TW1kB Default principal: adt...@ad.home<mailto:adt...@ad.home> Valid starting ExpiresService principal 06/04/14 11:35:16 06/04/14 21:35:16 nfs/share.linux.h...@linux.home<mailto:nfs/share.linux.h...@linux.home> renew until 06/05/14 11:28:30 06/04/14 11:35:16 06/04/14 21:35:16 krbtgt/linux.h...@ad.home<mailto:krbtgt/linux.h...@ad.home> renew until 06/05/14 11:28:30 06/04/14 11:28:35 06/04/14 21:35:16 krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home> renew until 06/05/14 11:28:30 Home Directory gets mounted by autofs through sssd but user:group is both nobody. The Client's sssd.conf: [domain/linux.home] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.home id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.linux.home chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa.linux.home ldap_tls_cacert = /etc/ipa/ca.crt autofs_provider = ipa ipa_automount_location = default subdomains_provider = ipa [sssd] services = nss, pam, autofs, ssh config_file_version = 2 domains = linux.home [nss] [pam] [sudo] [autofs] [ssh] [pac] From: freeipa-users-boun...@redhat.com<mailto:freeipa-users-boun...@redhat.com> [mailto:freeipa-users-boun...@redhat.com]<mailto:[mailto:freeipa-users-boun...@redhat.com]> On Behalf Of Dmitri Pal Sent: Tuesday, June 03, 2014 6:48 PM To: freeipa-users@redhat.com<mailto:freeipa-users@redhat.com> Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue On 06/03/2014 09:07 AM, Johan Petersson wrote: Hi, Environment: RHEL 7 IPA Server 3.3 with a trust to a Windows 2012 Server AD RHEL 7 NFS Server RHEL 7 Client I have found one problem when using a NFS 4 shared Home Directory for AD users logging in to IPA. I have created a NFS share /home/adexample.org and use autofs map in IPA. All wbinfo tests works as well as id. I can login fine through SSH and Shell with adt...@adexample.org<mailto:adt...@adexample.org> The problem is that I can add the AD user as owner of his Home Directory and if I log in to the NFS Server locally or through ssh permissions are correct but when logging in to any other computer i get "nobody" as owner. Are those computers RHEL7 NFS clients with SSSD? Can you describe them in more details please? Groups are no problem since AD groups can be mapped to Posix groups. Idmap.conf domain is set to the IPA Domain. Is there some way to get NFS working with the AD user as owner of his Home Directory? Thanks for any help. This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. ___ Freeipa-users mailing list Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Mail got posted before I was finished sorry. I found one clue to the issue after increasing autofs logging to debug and as i thought it has to do with id-mapping. >From /var/log/messages: Nfsidmap[1696]: nss_getpwnam: name 'adt...@ad.home@linux.home,' does not map into domain 'linux.home,' From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Johan Petersson Sent: Wednesday, June 04, 2014 12:02 PM To: d...@redhat.com; freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue Yes Client is default RHEL 7 and both IPA and NFS Server is aswell. server.ad.home = AD Server share.linux.home = NFS Server ipa.linux.home = IPA Server client.linux.home = Client NFS with automounted krb5p Home Directories work for IPA users. sssd-1.11.2-65.el7.x86_64 id adt...@ad.home<mailto:adt...@ad.home> uid=497801107(adt...@ad.home<mailto:adt...@ad.home>) gid=497801107(adt...@ad.home<mailto:adt...@ad.home>) groups=497801107(adt...@ad.home),497800513(domain<mailto:adt...@ad.home),497800513(domain> us...@ad.home<mailto:us...@ad.home>) getent passwd adt...@ad.home<mailto:adt...@ad.home> adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest<mailto:adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest>: klist after kinit adt...@ad.home<mailto:adt...@ad.home> [root@client ~]# klist -e Ticket cache: KEYRING:persistent:0:0 Default principal: adt...@ad.home<mailto:adt...@ad.home> Valid starting ExpiresService principal 06/04/14 11:28:35 06/04/14 21:28:35 krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home> renew until 06/05/14 11:28:30, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 klist after ssh adt...@ad.home@ipa.linux.home<mailto:adt...@ad.home@ipa.linux.home> klist Ticket cache: KEYRING:persistent:497801107:krb_ccache_y5TW1kB Default principal: adt...@ad.home<mailto:adt...@ad.home> Valid starting ExpiresService principal 06/04/14 11:35:16 06/04/14 21:35:16 nfs/share.linux.h...@linux.home<mailto:nfs/share.linux.h...@linux.home> renew until 06/05/14 11:28:30 06/04/14 11:35:16 06/04/14 21:35:16 krbtgt/linux.h...@ad.home<mailto:krbtgt/linux.h...@ad.home> renew until 06/05/14 11:28:30 06/04/14 11:28:35 06/04/14 21:35:16 krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home> renew until 06/05/14 11:28:30 Home Directory gets mounted by autofs through sssd but user:group is both nobody. The Client's sssd.conf: [domain/linux.home] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.home id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.linux.home chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa.linux.home ldap_tls_cacert = /etc/ipa/ca.crt autofs_provider = ipa ipa_automount_location = default subdomains_provider = ipa [sssd] services = nss, pam, autofs, ssh config_file_version = 2 domains = linux.home [nss] [pam] [sudo] [autofs] [ssh] [pac] From: freeipa-users-boun...@redhat.com<mailto:freeipa-users-boun...@redhat.com> [mailto:freeipa-users-boun...@redhat.com]<mailto:[mailto:freeipa-users-boun...@redhat.com]> On Behalf Of Dmitri Pal Sent: Tuesday, June 03, 2014 6:48 PM To: freeipa-users@redhat.com<mailto:freeipa-users@redhat.com> Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue On 06/03/2014 09:07 AM, Johan Petersson wrote: Hi, Environment: RHEL 7 IPA Server 3.3 with a trust to a Windows 2012 Server AD RHEL 7 NFS Server RHEL 7 Client I have found one problem when using a NFS 4 shared Home Directory for AD users logging in to IPA. I have created a NFS share /home/adexample.org and use autofs map in IPA. All wbinfo tests works as well as id. I can login fine through SSH and Shell with adt...@adexample.org<mailto:adt...@adexample.org> The problem is that I can add the AD user as owner of his Home Directory and if I log in to the NFS Server locally or through ssh permissions are correct but when logging in to any other computer i get "nobody" as owner. Are those computers RHEL7 NFS clients with SSSD? Can you describe them in more details please? Groups are no problem since AD groups can be mapped to Posix groups. Idmap.conf domain is set to the IPA Domain. Is there some way to get NFS working with the AD user as owner of his Home Directory? Thanks for any help. This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. ___ Freeipa-users mailing list Freeipa-users@redhat.com<mailto:Freeipa-us
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Wed, Jun 04, 2014 at 12:24:11PM +, Johan Petersson wrote: > Mail got posted before I was finished sorry. > > I found one clue to the issue after increasing autofs logging to debug and as > i thought it has to do with id-mapping. > > >From /var/log/messages: > > Nfsidmap[1696]: nss_getpwnam: name 'adt...@ad.home@linux.home,' does not map > into domain 'linux.home,' Maybe adding 'linux.home' and 'ad.home' to Local-Realms in idmap.conf might help? I'll check the nfsidmap code to see how/if it can handle trusted domains. bye, Sumit > > > From: freeipa-users-boun...@redhat.com > [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Johan Petersson > Sent: Wednesday, June 04, 2014 12:02 PM > To: d...@redhat.com; freeipa-users@redhat.com > Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue > > Yes Client is default RHEL 7 and both IPA and NFS Server is aswell. > > > server.ad.home = AD Server > share.linux.home = NFS Server > ipa.linux.home = IPA Server > client.linux.home = Client > > NFS with automounted krb5p Home Directories work for IPA users. > > sssd-1.11.2-65.el7.x86_64 > > id adt...@ad.home<mailto:adt...@ad.home> > uid=497801107(adt...@ad.home<mailto:adt...@ad.home>) > gid=497801107(adt...@ad.home<mailto:adt...@ad.home>) > groups=497801107(adt...@ad.home),497800513(domain<mailto:adt...@ad.home),497800513(domain> > us...@ad.home<mailto:us...@ad.home>) > > getent passwd adt...@ad.home<mailto:adt...@ad.home> > adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest<mailto:adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest>: > > klist after kinit adt...@ad.home<mailto:adt...@ad.home> > > [root@client ~]# klist -e > Ticket cache: KEYRING:persistent:0:0 > Default principal: adt...@ad.home<mailto:adt...@ad.home> > > Valid starting ExpiresService principal > 06/04/14 11:28:35 06/04/14 21:28:35 > krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home> > renew until 06/05/14 11:28:30, Etype (skey, tkt): > aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 > > klist after ssh > adt...@ad.home@ipa.linux.home<mailto:adt...@ad.home@ipa.linux.home> > > klist > Ticket cache: KEYRING:persistent:497801107:krb_ccache_y5TW1kB > Default principal: adt...@ad.home<mailto:adt...@ad.home> > > Valid starting ExpiresService principal > 06/04/14 11:35:16 06/04/14 21:35:16 > nfs/share.linux.h...@linux.home<mailto:nfs/share.linux.h...@linux.home> > renew until 06/05/14 11:28:30 > 06/04/14 11:35:16 06/04/14 21:35:16 > krbtgt/linux.h...@ad.home<mailto:krbtgt/linux.h...@ad.home> > renew until 06/05/14 11:28:30 > 06/04/14 11:28:35 06/04/14 21:35:16 > krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home> > renew until 06/05/14 11:28:30 > > Home Directory gets mounted by autofs through sssd but user:group is both > nobody. > > The Client's sssd.conf: > > [domain/linux.home] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = linux.home > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = client.linux.home > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, ipa.linux.home > ldap_tls_cacert = /etc/ipa/ca.crt > autofs_provider = ipa > ipa_automount_location = default > subdomains_provider = ipa > [sssd] > services = nss, pam, autofs, ssh > config_file_version = 2 > > domains = linux.home > [nss] > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > > From: > freeipa-users-boun...@redhat.com<mailto:freeipa-users-boun...@redhat.com> > [mailto:freeipa-users-boun...@redhat.com]<mailto:[mailto:freeipa-users-boun...@redhat.com]> > On Behalf Of Dmitri Pal > Sent: Tuesday, June 03, 2014 6:48 PM > To: freeipa-users@redhat.com<mailto:freeipa-users@redhat.com> > Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue > > On 06/03/2014 09:07 AM, Johan Petersson wrote: > Hi, > > Environment: > > RHEL 7 IPA Server 3.3 with a trust to a Windows 2012 Server AD > RHEL 7 NFS Server > RHEL 7 Client > > I have found one problem when using a NFS 4 shared Home Directory for AD > users logging in to IPA. > I have created a NFS share /home/adexample.org and use autofs map in IPA. > All wbinfo tests works as well as id. > I can login fine through SSH and Shell with > adt...@adexample.org<mailto:adt...@adexample.org> > The problem is that I can add the AD user a
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Wed, 04 Jun 2014, Johan Petersson wrote:
Mail got posted before I was finished sorry.
I found one clue to the issue after increasing autofs logging to debug and as i
thought it has to do with id-mapping.
From /var/log/messages:
Nfsidmap[1696]: nss_getpwnam: name 'adt...@ad.home@linux.home,' does not map
into domain 'linux.home,'
Are you sure the message is exactly like this, with a comma after linux.home?
The reason I'm asking is because the code that prints the message looks
like this:
localname = strip_domain(name, domain);
IDMAP_LOG(4, ("nss_getpwnam: name '%s' domain '%s': "
"resulting localname '%s'\n", name, domain, localname));
if (localname == NULL) {
IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map "
"into domain '%s'\n", name,
domain ? domain : ""));
goto err_free_buf;
}
note that it doesn't have comma anywhere in the string printed.
Can you please increase the log level to 4 so that we can see the first
string (nss_getpwnam: name '' domain '...': resulting localname
...)? it would be
[general]
Verbosity = 4
in /etc/idmapd.conf
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Johan Petersson
Sent: Wednesday, June 04, 2014 12:02 PM
To: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Yes Client is default RHEL 7 and both IPA and NFS Server is aswell.
server.ad.home = AD Server
share.linux.home = NFS Server
ipa.linux.home = IPA Server
client.linux.home = Client
NFS with automounted krb5p Home Directories work for IPA users.
sssd-1.11.2-65.el7.x86_64
id adt...@ad.home<mailto:adt...@ad.home>
uid=497801107(adt...@ad.home<mailto:adt...@ad.home>)
gid=497801107(adt...@ad.home<mailto:adt...@ad.home>)
groups=497801107(adt...@ad.home),497800513(domain<mailto:adt...@ad.home),497800513(domain>
us...@ad.home<mailto:us...@ad.home>)
getent passwd adt...@ad.home<mailto:adt...@ad.home>
adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest<mailto:adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest>:
klist after kinit adt...@ad.home<mailto:adt...@ad.home>
[root@client ~]# klist -e
Ticket cache: KEYRING:persistent:0:0
Default principal: adt...@ad.home<mailto:adt...@ad.home>
Valid starting ExpiresService principal
06/04/14 11:28:35 06/04/14 21:28:35
krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home>
renew until 06/05/14 11:28:30, Etype (skey, tkt):
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
klist after ssh
adt...@ad.home@ipa.linux.home<mailto:adt...@ad.home@ipa.linux.home>
klist
Ticket cache: KEYRING:persistent:497801107:krb_ccache_y5TW1kB
Default principal: adt...@ad.home<mailto:adt...@ad.home>
Valid starting ExpiresService principal
06/04/14 11:35:16 06/04/14 21:35:16
nfs/share.linux.h...@linux.home<mailto:nfs/share.linux.h...@linux.home>
renew until 06/05/14 11:28:30
06/04/14 11:35:16 06/04/14 21:35:16
krbtgt/linux.h...@ad.home<mailto:krbtgt/linux.h...@ad.home>
renew until 06/05/14 11:28:30
06/04/14 11:28:35 06/04/14 21:35:16
krbtgt/ad.h...@ad.home<mailto:krbtgt/ad.h...@ad.home>
renew until 06/05/14 11:28:30
Home Directory gets mounted by autofs through sssd but user:group is both
nobody.
The Client's sssd.conf:
[domain/linux.home]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = linux.home
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = client.linux.home
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, ipa.linux.home
ldap_tls_cacert = /etc/ipa/ca.crt
autofs_provider = ipa
ipa_automount_location = default
subdomains_provider = ipa
[sssd]
services = nss, pam, autofs, ssh
config_file_version = 2
domains = linux.home
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
From: freeipa-users-boun...@redhat.com<mailto:freeipa-users-boun...@redhat.com>
[mailto:freeipa-users-boun...@redhat.com]<mailto:[mailto:freeipa-users-boun...@redhat.com]>
On Behalf Of Dmitri Pal
Sent: Tuesday, June 03, 2014 6:48 PM
To: freeipa-users@redhat.com<mailto:freeipa-users@redhat.com>
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 06/03/2014 09:07 AM, Johan Petersson wrote:
Hi,
Environment:
RHEL 7 IPA Server 3.3 with a trust to a Windows 2012 Server AD
RHEL 7 NFS Server
RHEL 7 Client
I have found one problem when using a NFS 4 shared Home Directory for AD users
logging in to IPA.
I have created a NFS share /home/adexample.org and use autofs map in IPA.
All wbinfo tests works as well as id.
I can login fine through SSH and Sh
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Yes the message is exactly like that with commas, I double checked.
To anser Sumit's question: Maybe adding 'linux.home' and 'ad.home' to
Local-Realms in idmap.conf might help?
I did on all machines and got rid of that specific message but I still get user
nobody unfortunately.
Here are logs from when I did a su - adt...@ad.home@linux.home with both
AD.HOME and LINUX.HOME added to Local_realms in idmap.conf.
Client:
Jun 4 15:30:13 client su: (to adt...@ad.home) linux on pts/0
Jun 4 15:30:13 client nfsidmap[3602]: key: 0x35965a5f type: gid value:
adt...@ad.home@linux.home timeout 600
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
nsswitch->name_to_gid
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: nsswitch->name_to_gid
returned -22
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value is
-22
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
nsswitch->name_to_gid
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: nsswitch->name_to_gid
returned 0
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value is 0
NFS Server:
Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p authtype=user
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: calling
nsswitch->uid_to_name
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: nsswitch->uid_to_name
returned 0
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: final return value is 0
Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (user) id "497801107" -> name
"adt...@ad.home@linux.home"
Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p authtype=group
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: calling
nsswitch->gid_to_name
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: nsswitch->gid_to_name
returned 0
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: final return value is 0
Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (group) id "112005" ->
name "ad_us...@linux.home"
The group ad_users is a IPA group with external maps from AD Domain users.
-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Wednesday, June 04, 2014 3:14 PM
To: Johan Petersson
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Wed, 04 Jun 2014, Johan Petersson wrote:
>Mail got posted before I was finished sorry.
>
>I found one clue to the issue after increasing autofs logging to debug and as
>i thought it has to do with id-mapping.
>
>>From /var/log/messages:
>
>Nfsidmap[1696]: nss_getpwnam: name 'adt...@ad.home@linux.home,' does not map
>into domain 'linux.home,'
Are you sure the message is exactly like this, with a comma after linux.home?
The reason I'm asking is because the code that prints the message looks like
this:
localname = strip_domain(name, domain);
IDMAP_LOG(4, ("nss_getpwnam: name '%s' domain '%s': "
"resulting localname '%s'\n", name, domain, localname));
if (localname == NULL) {
IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map "
"into domain '%s'\n", name,
domain ? domain : ""));
goto err_free_buf;
}
note that it doesn't have comma anywhere in the string printed.
Can you please increase the log level to 4 so that we can see the first string
(nss_getpwnam: name '' domain '...': resulting localname ...)? it would be
[general]
Verbosity = 4
in /etc/idmapd.conf
>
>
>From: freeipa-users-boun...@redhat.com
>[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Johan Petersson
>Sent: Wednesday, June 04, 2014 12:02 PM
>To: d...@redhat.com; freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
>
>Yes Client is default RHEL 7 and both IPA and NFS Server is aswell.
>
>
>server.ad.home = AD Server
>share.linux.home = NFS Server
>ipa.linux.home = IPA Server
>client.linux.home = Client
>
>NFS with automounted krb5p Home Directories work for IPA users.
>
>sssd-1.11.2-65.el7.x86_64
>
>id adt...@ad.home<mailto:adt...@ad.home>
>uid=497801107(adt...@ad.home<mailto:adt...@ad.home>)
>gid=497801107(adt...@ad.home<mailto:adt...@ad.home>)
>groups=497801107(adt...@ad.home),497800513(domain<mailto:adt...@ad.home
>),497800513(domain> us...@ad.home<mailto:us...@ad.home>)
>
>getent passwd adt...@ad.home<mailto:adt...@ad.home>
>adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest<mailto:adt...@ad.home:*:497801107:497801107::/home/ad.
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 06/04/2014 09:57 AM, Johan Petersson wrote:
Yes the message is exactly like that with commas, I double checked.
To anser Sumit's question: Maybe adding 'linux.home' and 'ad.home' to
Local-Realms in idmap.conf might help?
I did on all machines and got rid of that specific message but I still get user
nobody unfortunately.
Here are logs from when I did a su - adt...@ad.home@linux.home with both
AD.HOME and LINUX.HOME added to Local_realms in idmap.conf.
Client:
Jun 4 15:30:13 client su: (to adt...@ad.home) linux on pts/0
Jun 4 15:30:13 client nfsidmap[3602]: key: 0x35965a5f type: gid value:
adt...@ad.home@linux.home timeout 600
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
nsswitch->name_to_gid
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: nsswitch->name_to_gid
returned -22
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value is
-22
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
nsswitch->name_to_gid
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: nsswitch->name_to_gid
returned 0
Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value is 0
Do we have a corresponding SSSD trace that shows the actual process of
the resolution?
NFS Server:
Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p authtype=user
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: calling
nsswitch->uid_to_name
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: nsswitch->uid_to_name
returned 0
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: final return value is 0
Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (user) id "497801107" -> name
"adt...@ad.home@linux.home"
Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p authtype=group
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: calling
nsswitch->gid_to_name
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: nsswitch->gid_to_name
returned 0
Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: final return value is 0
Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (group) id "112005" -> name
"ad_us...@linux.home"
The group ad_users is a IPA group with external maps from AD Domain users.
-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Wednesday, June 04, 2014 3:14 PM
To: Johan Petersson
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Wed, 04 Jun 2014, Johan Petersson wrote:
Mail got posted before I was finished sorry.
I found one clue to the issue after increasing autofs logging to debug and as i
thought it has to do with id-mapping.
>From /var/log/messages:
Nfsidmap[1696]: nss_getpwnam: name 'adt...@ad.home@linux.home,' does not map
into domain 'linux.home,'
Are you sure the message is exactly like this, with a comma after linux.home?
The reason I'm asking is because the code that prints the message looks like
this:
localname = strip_domain(name, domain);
IDMAP_LOG(4, ("nss_getpwnam: name '%s' domain '%s': "
"resulting localname '%s'\n", name, domain, localname));
if (localname == NULL) {
IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map "
"into domain '%s'\n", name,
domain ? domain : ""));
goto err_free_buf;
}
note that it doesn't have comma anywhere in the string printed.
Can you please increase the log level to 4 so that we can see the first string
(nss_getpwnam: name '' domain '...': resulting localname ...)? it would be
[general]
Verbosity = 4
in /etc/idmapd.conf
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Johan Petersson
Sent: Wednesday, June 04, 2014 12:02 PM
To: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Yes Client is default RHEL 7 and both IPA and NFS Server is aswell.
server.ad.home = AD Server
share.linux.home = NFS Server
ipa.linux.home = IPA Server
client.linux.home = Client
NFS with automounted krb5p Home Directories work for IPA users.
sssd-1.11.2-65.el7.x86_64
id adt...@ad.home<mailto:adt...@ad.home>
uid=497801107(adt...@ad.home<mailto:adt...@ad.home>)
gid=497801107(adt...@ad.home<mailto:adt...@ad.home>)
groups=497801107(adt...@ad.home),497800513(domain<mailto:adt...@ad.home
),497800513(domain> us...@ad.home<mailto:us...@ad.home>)
getent passwd adt...@ad.home<mailto:adt...@ad.home>
adt...@ad.home:*:497801107:497801107::/home/ad.home/adtest<mailto:adt...@ad.home:*:497801107:497801107::/home/a
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Hi,
First i wish to thank everybody that helped me out trying to solve this issue
and i also wish to inform that NFS 4 does not work with AD users through an AD
and IPA trust at the moment for RHEL 6 and 7.
The reason is that rpcidmapd` does not parse fully-qualified usernames
so"adt...@ad.example.org@IPA.EXAMPLE.ORG" does not work.
The client-side code is stripping the domain off based on the location of the
first "@" character in the value returned by the server. This results in
UID/GID mappings failing and resulting in ownership on the clients of "nobody".
Regards,
Johan
From: Dmitri Pal [d...@redhat.com]
Sent: Thursday, June 05, 2014 21:03
To: Johan Petersson; Alexander Bokovoy
Cc: Sumit Bose; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 06/04/2014 09:57 AM, Johan Petersson wrote:
> Yes the message is exactly like that with commas, I double checked.
>
> To anser Sumit's question: Maybe adding 'linux.home' and 'ad.home' to
> Local-Realms in idmap.conf might help?
>
> I did on all machines and got rid of that specific message but I still get
> user nobody unfortunately.
>
> Here are logs from when I did a su - adt...@ad.home@linux.home with both
> AD.HOME and LINUX.HOME added to Local_realms in idmap.conf.
>
> Client:
> Jun 4 15:30:13 client su: (to adt...@ad.home) linux on pts/0
> Jun 4 15:30:13 client nfsidmap[3602]: key: 0x35965a5f type: gid value:
> adt...@ad.home@linux.home timeout 600
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
> nsswitch->name_to_gid
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
> nsswitch->name_to_gid returned -22
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
> is -22
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
> nsswitch->name_to_gid
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
> nsswitch->name_to_gid returned 0
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
> is 0
Do we have a corresponding SSSD trace that shows the actual process of
the resolution?
>
> NFS Server:
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p
> authtype=user
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: calling
> nsswitch->uid_to_name
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name:
> nsswitch->uid_to_name returned 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: final return value
> is 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (user) id "497801107" ->
> name "adt...@ad.home@linux.home"
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p
> authtype=group
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: calling
> nsswitch->gid_to_name
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name:
> nsswitch->gid_to_name returned 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: final return value
> is 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (group) id "112005" ->
> name "ad_us...@linux.home"
>
> The group ad_users is a IPA group with external maps from AD Domain users.
>
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Wednesday, June 04, 2014 3:14 PM
> To: Johan Petersson
> Cc: d...@redhat.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
>
> On Wed, 04 Jun 2014, Johan Petersson wrote:
>> Mail got posted before I was finished sorry.
>>
>> I found one clue to the issue after increasing autofs logging to debug and
>> as i thought it has to do with id-mapping.
>>
>> >From /var/log/messages:
>>
>> Nfsidmap[1696]: nss_getpwnam: name 'adt...@ad.home@linux.home,' does not map
>> into domain 'linux.home,'
> Are you sure the message is exactly like this, with a comma after linux.home?
>
> The reason I'm asking is because the code that prints the message looks like
> this:
>
> localname = strip_domain(name, domain);
> IDMAP_LOG(4, ("nss_getpwnam: name '%s' domain '%s': "
>"resulting localname '%s'\n", name, domain, localname));
> if (localname == NULL) {
> IDMAP_LOG(0, ("nss_getpwnam: name '%s' does not map "
> "into domain '%s'\n", name,
> domain ? domain : ""));
> goto err_free_buf;
> }
>
> note that it doesn't have comma
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
> The reason is that rpcidmapd` does not parse fully-qualified usernames > so"adt...@ad.example.org@IPA.EXAMPLE.ORG" does not work. If someone can educate me as to why there are two @ signs in the above, I can fix the wiki page (http://www.freeipa.org/page/Collaboration_with_Kerberos#Mechanism_1:_Kerberos_cross-realm_trusts) I know about individual cross-realm principals, adtest/ad.example@ipa.example.org And I know about cross-realm trust principals: krbtgt/ad.example@ipa.example.org But I was under the impression that if a user traversed a trust, their client principal name would still be adt...@ad.example.org . I am not aware of any circumstances which would produce a client principal with two "@" signs in it. Pls fix my ignorance. Thanks, Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Thu, 2014-06-26 at 22:02 +, Nordgren, Bryce L -FS wrote: > > The reason is that rpcidmapd` does not parse fully-qualified usernames > > so"adt...@ad.example.org@IPA.EXAMPLE.ORG" does not work. > > If someone can educate me as to why there are two @ signs in the above, I can > fix the wiki page > (http://www.freeipa.org/page/Collaboration_with_Kerberos#Mechanism_1:_Kerberos_cross-realm_trusts) > > I know about individual cross-realm principals, > > adtest/ad.example@ipa.example.org > > And I know about cross-realm trust principals: > > krbtgt/ad.example@ipa.example.org > > But I was under the impression that if a user traversed a trust, their client > principal name would still be adt...@ad.example.org . I am not aware of any > circumstances which would produce a client principal with two "@" signs in > it. Pls fix my ignorance. The second @ is not provided by kerberos, it is rpcimapd making false assumptions, it does a getpwuid and gets back adt...@ad.example.org as the username, to which it decides to slap on the local REALM name with an @ sign in between. I think this is something that may be handled with imapd.conf configuration. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
> The second @ is not provided by kerberos, it is rpcimapd making false > assumptions, it does a getpwuid and gets back adt...@ad.example.org as > the username, to which it decides to slap on the local REALM name with an @ > sign in between. > > I think this is something that may be handled with imapd.conf configuration. Muchas gracias. This makes sense. Found an old presentation on the topic [1]. Slide 15 is particularly relevant. Slide 4, however, taught me something I didn't know: NFS wants to deal with NFSv4 domain names (slide 3), which can be different than GSS principal names (Kerberos principals). There is only one NFS domain, but there can be multiple security realms and multiple DNS domains (slide 2). The crux of this is on slide 14: "Need to add posixAccount with GSSAuthName for UID/GID mapping of remote user". Is this another use case for views? What I'm not quite clear on is the interaction between idmapd and ldap (slides 15,16,18). Does idmapd want to see this "NFSv4RemoteUser" schema on the LDAP server? Is this schema something that FreeIPA would have to support for NFS to work with cross-realm trusts? Or has the landscape changed since this 2005 presentation? Bryce [1] http://www.citi.umich.edu/projects/nfsv4/crossrealm/ASC_NFSv4_WKSHP_X_DOMAIN_N2ID.pdf This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Also: http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-access-04 Never became an RFC, but cites Simo's I-D on a Kerberos PAC. I like the CITI approach better (also approach 2 of section 6 in the above I-D). I have no use for the groups defined in my active directory. Also, for the external collaboration case, my AD may not be accessible to an NFS server outside the firewall. However, if (?) support for an NFSRemoteUser schema is lacking in FreeIPA, and if AD is accessible to both client and server, it seems that approach 3 of section 6 above would be the answer? Somehow configure idmap.conf (on NFS clients and servers) to directly query AD? Does that seem correct? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Thu, Jun 26, 2014 at 06:42:37PM -0400, Simo Sorce wrote: > On Thu, 2014-06-26 at 22:02 +, Nordgren, Bryce L -FS wrote: > > > The reason is that rpcidmapd` does not parse fully-qualified usernames > > > so"adt...@ad.example.org@IPA.EXAMPLE.ORG" does not work. > > > > If someone can educate me as to why there are two @ signs in the above, I > > can fix the wiki page > > (http://www.freeipa.org/page/Collaboration_with_Kerberos#Mechanism_1:_Kerberos_cross-realm_trusts) > > > > I know about individual cross-realm principals, > > > > adtest/ad.example@ipa.example.org > > > > And I know about cross-realm trust principals: > > > > krbtgt/ad.example@ipa.example.org > > > > But I was under the impression that if a user traversed a trust, their > > client principal name would still be adt...@ad.example.org . I am not aware > > of any circumstances which would produce a client principal with two "@" > > signs in it. Pls fix my ignorance. > > The second @ is not provided by kerberos, it is rpcimapd making false > assumptions, it does a getpwuid and gets back adt...@ad.example.org as > the username, to which it decides to slap on the local REALM name with > an @ sign in between. > > I think this is something that may be handled with imapd.conf > configuration. > > Simo. Would the idmap sss module we have on the list pending review help here? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Thu, Jun 26, 2014 at 09:04:41PM +, Johan Petersson wrote: > Hi, > > First i wish to thank everybody that helped me out trying to solve this issue > and i also wish to inform that NFS 4 does not work with AD users through an > AD and IPA trust at the moment for RHEL 6 and 7. > > The reason is that rpcidmapd` does not parse fully-qualified usernames > so"adt...@ad.example.org@IPA.EXAMPLE.ORG" does not work. > The client-side code is stripping the domain off based on the location of > the first "@" character in the value returned by the server. This results in > UID/GID mappings failing and resulting in ownership on the clients of > "nobody". Thank you for the feedback. FYI there is a rpc.idmapd plugin for SSSD (https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin) currently under review (https://lists.fedorahosted.org/pipermail/sssd-devel/2014-June/020384.html) I'll try to find some time early next week to test if this will help with your use-case. bye, Sumit > > Regards, > Johan > > From: Dmitri Pal [d...@redhat.com] > Sent: Thursday, June 05, 2014 21:03 > To: Johan Petersson; Alexander Bokovoy > Cc: Sumit Bose; freeipa-users@redhat.com > Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue > > On 06/04/2014 09:57 AM, Johan Petersson wrote: > > Yes the message is exactly like that with commas, I double checked. > > > > To anser Sumit's question: Maybe adding 'linux.home' and 'ad.home' to > > Local-Realms in idmap.conf might help? > > > > I did on all machines and got rid of that specific message but I still get > > user nobody unfortunately. > > > > Here are logs from when I did a su - adt...@ad.home@linux.home with both > > AD.HOME and LINUX.HOME added to Local_realms in idmap.conf. > > > > Client: > > Jun 4 15:30:13 client su: (to adt...@ad.home) linux on pts/0 > > Jun 4 15:30:13 client nfsidmap[3602]: key: 0x35965a5f type: gid value: > > adt...@ad.home@linux.home timeout 600 > > Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling > > nsswitch->name_to_gid > > Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: > > nsswitch->name_to_gid returned -22 > > Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value > > is -22 > > Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling > > nsswitch->name_to_gid > > Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: > > nsswitch->name_to_gid returned 0 > > Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value > > is 0 > > Do we have a corresponding SSSD trace that shows the actual process of > the resolution? > > > > > > NFS Server: > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p > > authtype=user > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: calling > > nsswitch->uid_to_name > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: > > nsswitch->uid_to_name returned 0 > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: final return > > value is 0 > > Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (user) id "497801107" -> > > name "adt...@ad.home@linux.home" > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p > > authtype=group > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: calling > > nsswitch->gid_to_name > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: > > nsswitch->gid_to_name returned 0 > > Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: final return > > value is 0 > > Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (group) id "112005" -> > > name "ad_us...@linux.home" > > > > The group ad_users is a IPA group with external maps from AD Domain users. > > > > -Original Message- > > From: Alexander Bokovoy [mailto:aboko...@redhat.com] > > Sent: Wednesday, June 04, 2014 3:14 PM > > To: Johan Petersson > > Cc: d...@redhat.com; freeipa-users@redhat.com > > Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue > > > > On Wed, 04 Jun 2014, Johan Petersson wrote: > >> Mail got posted before I was finished sorry. > >> > >> I found one clue to the issue after increasing autofs logging to debug and > >> as i thought it has to do with id-mapping. > >> > >> >From /var/log/messages: > >> > >> Nfsidmap[1696]: nss_getpwnam: name 'adt...@ad.home@linux
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Fri, 2014-06-27 at 00:10 +, Nordgren, Bryce L -FS wrote: > Also: > http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-access-04 > > Never became an RFC, but cites Simo's I-D on a Kerberos PAC. > > I like the CITI approach better (also approach 2 of section 6 in the > above I-D). I have no use for the groups defined in my active > directory. Also, for the external collaboration case, my AD may not be > accessible to an NFS server outside the firewall. > > However, if (?) support for an NFSRemoteUser schema is lacking in > FreeIPA, and if AD is accessible to both client and server, it seems > that approach 3 of section 6 above would be the answer? Somehow > configure idmap.conf (on NFS clients and servers) to directly query > AD? Does that seem correct? I honestly think (and gave this feedback to the authors in the past) that trying to standardize on LDAP in an NFS document is wrong, it should be implementation specific. I think NFS should define roughly how a mapping service should behave, but should not try to dictate how Directory services can/should be used, the variation and modes of use is just too big in the real world, and keeps changing. Moreover it is already incorrect to believe all identities can be resolved by contacting a single LDAP server (AD trusted forests as an example), and that the LDAP server can actually fully resolve group memberships (again AD, and even FreeIPA when trusting AD forests) without using custom operations possible only fully correct when run by the KDC (or other RPC service, again see AD). In the FreeIPA case for example we do not (normally) convey AD groups to the service and instead map (some of) them into FreeIPA external groups, a client that tries to query directly the AD service (assuming you have direct access which is often not true) would not get cross-realm group memberships as defined in the IPA server and would therefore cause issues. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Thu, 2014-06-26 at 23:21 +, Nordgren, Bryce L -FS wrote: > > The second @ is not provided by kerberos, it is rpcimapd making false > > assumptions, it does a getpwuid and gets back adt...@ad.example.org as > > the username, to which it decides to slap on the local REALM name with an @ > > sign in between. > > > > I think this is something that may be handled with imapd.conf configuration. > > Muchas gracias. This makes sense. > > Found an old presentation on the topic [1]. Slide 15 is particularly > relevant. Slide 4, however, taught me something I didn't know: NFS > wants to deal with NFSv4 domain names (slide 3), which can be > different than GSS principal names (Kerberos principals). There is > only one NFS domain, but there can be multiple security realms and > multiple DNS domains (slide 2). > > The crux of this is on slide 14: "Need to add posixAccount with > GSSAuthName for UID/GID mapping of remote user". Is this another use > case for views? Yes, it *may* be. > What I'm not quite clear on is the interaction between idmapd and ldap > (slides 15,16,18). Does idmapd want to see this "NFSv4RemoteUser" > schema on the LDAP server? Is this schema something that FreeIPA would > have to support for NFS to work with cross-realm trusts? Or has the > landscape changed since this 2005 presentation? The landscape has changed and evolved, and I never really saw adoption of this CITI proposal myself. It may have happened somewhere I guess, but I do not think it is prevalent. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
> Would the idmap sss module we have on the list pending review help here? My read of the design page suggests that the plugin is 66% of a solution. There are three types of identities which need to be related: * local machine accounts/identities (meaningful to the filesystem) * security principals (Kerberos or pki) * NFSv4 identities (the u...@example.com string NFS sends over the wire) I see the first two represented on the design, but not the last. I suspect that this means that the plugin regards security principals and NFSv4 identities as the same thing, which may mean it won't work for multiple domains? Let me turn the question on its head: according to the OP, the NFS server and client is in Kerberos realm FREEIPA.EXAMPLE.ORG, and the user principals are from realm AD.EXAMPLE.ORG. Would your plugin work? What happens to your plugin if either the client or the server (but only one) moves to AD.EXAMPLE.ORG? Can the plugin consistently map security principals to NFS principals regardless of where it is running? I have a more basic confusion though: I can't tell from the design page whether rpc.idmapd is using sssd to get ids or vice versa... Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
> -Original Message- > > What I'm not quite clear on is the interaction between idmapd and ldap > > (slides 15,16,18). Does idmapd want to see this "NFSv4RemoteUser" > > schema on the LDAP server? Is this schema something that FreeIPA would > > have to support for NFS to work with cross-realm trusts? Or has the > > landscape changed since this 2005 presentation? > > The landscape has changed and evolved, and I never really saw adoption of > this CITI proposal myself. It may have happened somewhere I guess, but I do > not think it is prevalent. Poking a little more, I'm seeing something pretty similar to this proposal in the UMICH_SCHEMA section here: http://linux.die.net/man/5/idmapd.conf This appears to be the same man page which ships with Fedora 20. It looks like it's configurable, with the defaults being more or less the attributes mentioned in the 2005 powerpoint... If views were to support these attributes, external security principals could have a nice centralized mapping to NFS for the freeipa managed linux environment... Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 27 Jun 2014, at 22:22, Nordgren, Bryce L -FS wrote: > >> Would the idmap sss module we have on the list pending review help here? > > My read of the design page suggests that the plugin is 66% of a solution. > There are three types of identities which need to be related: > > * local machine accounts/identities (meaningful to the filesystem) > * security principals (Kerberos or pki) > * NFSv4 identities (the u...@example.com string NFS sends over the wire) > > I see the first two represented on the design, but not the last. I suspect > that this means that the plugin regards security principals and NFSv4 > identities as the same thing, which may mean it won't work for multiple > domains? Let me turn the question on its head: according to the OP, the NFS > server and client is in Kerberos realm FREEIPA.EXAMPLE.ORG, and the user > principals are from realm AD.EXAMPLE.ORG. Would your plugin work? I haven’t tested this scenario yet, but I assume it would as long as sssd was able to resolve usern...@ad.example.org and there was a trust relationship between FREEIPA.EXAMPLE.ORG and AD.EXAMPLE.ORG. But again, this is something that needs more testing. > What happens to your plugin if either the client or the server (but only one) > moves to AD.EXAMPLE.ORG? Can the plugin consistently map security principals > to NFS principals regardless of where it is running? > > I have a more basic confusion though: I can't tell from the design page > whether rpc.idmapd is using sssd to get ids or vice versa… > yes, rpc.idmapd is calling an sssd plugin to resolve identities. > Bryce > > > > > This electronic message contains information generated by the USDA solely for > the intended recipients. Any unauthorized interception of this message or the > use or disclosure of the information it contains may violate the law and > subject the violator to civil or criminal penalties. If you believe you have > received this message in error, please notify the sender and delete the email > immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
> > I see the first two represented on the design, but not the last. I suspect > that this means that the plugin regards security principals and NFSv4 > identities as the same thing, which may mean it won't work for multiple > domains? Let me turn the question on its head: according to the OP, the NFS > server and client is in Kerberos realm FREEIPA.EXAMPLE.ORG, and the user > principals are from realm AD.EXAMPLE.ORG. Would your plugin work? > > I haven't tested this scenario yet, but I assume it would as long as sssd was > able to resolve usern...@ad.example.org and there was a trust > relationship between FREEIPA.EXAMPLE.ORG and AD.EXAMPLE.ORG. But > again, this is something that needs more testing. The OP said the reason for the failure was that the principal was "usern...@ad.example.org@FREEIPA.EXAMPLE.ORG", which Simo said was due to rpc.idmapd constructing the principal incorrectly. Does your plugin have the ability to alter how rpc.idmapd constructs principals? This may be the key. > yes, rpc.idmapd is calling an sssd plugin to resolve identities. As I understand it, the NFS identities sent over the wire serve much the same purpose as a Kerberos NT_Enterprise name. That is, NFS ids over the wire should all be "usern...@example.org" regardless of whether the user is defined in FREEIPA.EXAMPLE.ORG or AD.EXAMPLE.ORG. This makes rpc.idmapd responsible for two things: 1] Mapping usern...@example.org to UID/GID and vice versa; 2] Mapping usern...@example.org to the exact Kerberos security principal used for authentication (usern...@ad.example.org) (and vice versa). SSSD can do #1. Can it do #2? Can it do #2 if there's no connection to the domain in which the user is defined? I suspect there is some value in endowing sssd with capability #2 which reaches well beyond NFS. For instance, people would no longer need to type their username as "usern...@ad.example.org" at login prompts (web or ssh). The people I deal with don't know their Kerberos principal name. OTOH, if the "plugin" went the other direction, allowing sssd to resolve ids using an rpc.idmapd configured to point to a local ldap server with a passable facsimile of the umich schema, that might add the most functionality with the least new code. The local mappings bind an external security principal to a local username/uid/gid, and give the local admins a tool to manage/resolve conflicts with externally managed domains. This removes the need to contact a foreign realm which may be protected by a firewall. Local conflict resolution and not contacting servers you don't control are probably the biggest reasons to add these mappings to freeipa once views are up. It helps me to remember that a trust and connectivity are not the same thing. From within my firewall, I can kinit (@AD.EXAMPLE.ORG), walk an authentication path which terminates outside my firewall, and obtain a ticket for a "collaboration" server (@FREEIPA.EXAMPLE.ORG). This may exclude using sssd, since it seems predicated on configuring contactable domains. It does not exclude using a future umich-schema-view-enabled freeipa. Thinking out loud, In the near term, a viable solution for manual conflict management may be to stand up a separate ldap server to contain just the umich schema elements for external users + those defined in freeipa. Poor man's views. :) Or just put it somewhere in the 389ds dit that freeipa will ignore... I may have to try this if I can work it in Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
I ran into this issue last fall and have been running with a patched
libnfsidmap since November while our support case with Red Hat waits on a
resolution (pretty much have given up hope at this point). It's a trivial
patch and removes the assumption that only one @ can be present in a username.
With this patch applied, we have hundreds of sssd 1.11 clients on EL5, EL6 and
EL7 in multiple environments all using NFSv4 mounts with ID mapping enabled.
We have experienced zero issues with this patch applied. Without it, the AD
trust setup is a no-go in any sort of real environment since NFSv4 is broken.
If you'd like to reference our support case, it's #00983906. Patch is included
below.
/aron
>From 305930bded0d377ebda858e8772ebf6527ba3f03 Mon Sep 17 00:00:00 2001
From: Aron Parsons
Date: Fri, 15 Nov 2013 14:43:10 -0500
Subject: [PATCH] account for usernames with @ in them
---
libnfsidmap/nss.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libnfsidmap/nss.c b/libnfsidmap/nss.c
index 04aff19..f9ad4be 100644
--- a/libnfsidmap/nss.c
+++ b/libnfsidmap/nss.c
@@ -135,7 +135,7 @@ static char *strip_domain(const char *name, const char
*domain)
char *l = NULL;
int len;
- c = strchr(name, '@');
+ c = strrchr(name, '@');
if (c == NULL && domain != NULL)
goto out;
if (c == NULL && domain == NULL) {
--
1.7.1
-
Hi,
First i wish to thank everybody that helped me out trying to solve this issue
and i also wish to inform that NFS 4 does not work with AD users through an AD
and IPA trust at the moment for RHEL 6 and 7.
The reason is that rpcidmapd` does not parse fully-qualified usernames
so"adtest AD EXAMPLE o...@ipa.example.org" does not work.
The client-side code is stripping the domain off based on the location of the
first "@" character in the value returned by the server. This results in
UID/GID mappings failing and resulting in ownership on the clients of "nobody".
Regards,
Johan
From: Dmitri Pal [dpal redhat com]
Sent: Thursday, June 05, 2014 21:03
To: Johan Petersson; Alexander Bokovoy
Cc: Sumit Bose; freeipa-users redhat com
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 06/04/2014 09:57 AM, Johan Petersson wrote:
> Yes the message is exactly like that with commas, I double checked.
>
> To anser Sumit's question: Maybe adding 'linux.home' and 'ad.home' to
> Local-Realms in idmap.conf might help?
>
> I did on all machines and got rid of that specific message but I still get
> user nobody unfortunately.
>
> Here are logs from when I did a su - adtest AD h...@linux.home with both
> AD.HOME and LINUX.HOME added to Local_realms in idmap.conf.
>
> Client:
> Jun 4 15:30:13 client su: (to adtest ad home) linux on pts/0
> Jun 4 15:30:13 client nfsidmap[3602]: key: 0x35965a5f type: gid value:
> adtest ad h...@linux.home timeout 600
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
> nsswitch->name_to_gid
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
> nsswitch->name_to_gid returned -22
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
> is -22
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
> nsswitch->name_to_gid
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
> nsswitch->name_to_gid returned 0
> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
> is 0
Do we have a corresponding SSSD trace that shows the actual process of
the resolution?
>
> NFS Server:
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p
> authtype=user
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: calling
> nsswitch->uid_to_name
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name:
> nsswitch->uid_to_name returned 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: final return value
> is 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (user) id "497801107" ->
> name "adtest ad h...@linux.home"
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p
> authtype=group
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: calling
> nsswitch->gid_to_name
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name:
> nsswitch->gid_to_name returned 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_gid_to_name: final return value
> is 0
> Jun 4 15:33:48 share rpc.idmapd[1908]: Server : (group) id "112005" ->
> name "ad_users linux home"
>
> The group ad_users is a IPA group with external maps from AD Domain users.
>
> -Original Message-
> From: Alexander Bokovoy [mailto:abok
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 16 Jul 2014, at 03:29, Parsons, Aron wrote:
> I ran into this issue last fall and have been running with a patched
> libnfsidmap since November while our support case with Red Hat waits on a
> resolution (pretty much have given up hope at this point). It's a trivial
> patch and removes the assumption that only one @ can be present in a username.
>
> With this patch applied, we have hundreds of sssd 1.11 clients on EL5, EL6
> and EL7 in multiple environments all using NFSv4 mounts with ID mapping
> enabled. We have experienced zero issues with this patch applied. Without
> it, the AD trust setup is a no-go in any sort of real environment since NFSv4
> is broken.
>
> If you'd like to reference our support case, it's #00983906. Patch is
> included below.
>
> /aron
>
Hi Aron,
the support case you referenced is linked to bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1066153 which is fully acked for
RHEL-6.6, the state of the bugzilla is ON_QA, so currently it looks the patch
will be released in 6.6..
>
>> From 305930bded0d377ebda858e8772ebf6527ba3f03 Mon Sep 17 00:00:00 2001
> From: Aron Parsons
> Date: Fri, 15 Nov 2013 14:43:10 -0500
> Subject: [PATCH] account for usernames with @ in them
>
> ---
> libnfsidmap/nss.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libnfsidmap/nss.c b/libnfsidmap/nss.c
> index 04aff19..f9ad4be 100644
> --- a/libnfsidmap/nss.c
> +++ b/libnfsidmap/nss.c
> @@ -135,7 +135,7 @@ static char *strip_domain(const char *name, const char
> *domain)
> char *l = NULL;
> int len;
>
> - c = strchr(name, '@');
> + c = strrchr(name, '@');
> if (c == NULL && domain != NULL)
>goto out;
> if (c == NULL && domain == NULL) {
> --
> 1.7.1
>
> -
> Hi,
>
> First i wish to thank everybody that helped me out trying to solve this issue
> and i also wish to inform that NFS 4 does not work with AD users through an
> AD and IPA trust at the moment for RHEL 6 and 7.
>
> The reason is that rpcidmapd` does not parse fully-qualified usernames
> so"adtest AD EXAMPLE o...@ipa.example.org" does not work.
> The client-side code is stripping the domain off based on the location of the
> first "@" character in the value returned by the server. This results in
> UID/GID mappings failing and resulting in ownership on the clients of
> "nobody".
>
> Regards,
> Johan
>
> From: Dmitri Pal [dpal redhat com]
> Sent: Thursday, June 05, 2014 21:03
> To: Johan Petersson; Alexander Bokovoy
> Cc: Sumit Bose; freeipa-users redhat com
> Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
>
> On 06/04/2014 09:57 AM, Johan Petersson wrote:
>> Yes the message is exactly like that with commas, I double checked.
>>
>> To anser Sumit's question: Maybe adding 'linux.home' and 'ad.home' to
>> Local-Realms in idmap.conf might help?
>>
>> I did on all machines and got rid of that specific message but I still get
>> user nobody unfortunately.
>>
>> Here are logs from when I did a su - adtest AD h...@linux.home with both
>> AD.HOME and LINUX.HOME added to Local_realms in idmap.conf.
>>
>> Client:
>> Jun 4 15:30:13 client su: (to adtest ad home) linux on pts/0
>> Jun 4 15:30:13 client nfsidmap[3602]: key: 0x35965a5f type: gid value:
>> adtest ad h...@linux.home timeout 600
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
>> nsswitch->name_to_gid
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
>> nsswitch->name_to_gid returned -22
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
>> is -22
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
>> nsswitch->name_to_gid
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
>> nsswitch->name_to_gid returned 0
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
>> is 0
>
> Do we have a corresponding SSSD trace that shows the actual process of
> the resolution?
>
>
>>
>> NFS Server:
>> Jun 4 15:33:48 share rpc.idmapd[1908]: nfsdcb: authbuf=gss/krb5p
>> authtype=user
>> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: calling
>> nsswitch->uid_to_name
>> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name:
>> nsswitch->uid_to_name returned 0
>> Jun 4 15:33:48 share rpc.idmapd[1908]: nfs4_uid_to_name: final return value
>> is 0
>> Jun 4 15:33:48 sh
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
> Hi Aron, > > the support case you referenced is linked to bugzilla > https://bugzilla.redhat.com/show_bug.cgi?id=1066153 which is fully acked > for RHEL-6.6, the state of the bugzilla is ON_QA, so currently it looks the > patch will be released in 6.6.. username@domain is coded in the NFS spec as an NFS id which goes over the wire. It's unclear what allowing two "@" signs means (which "@" separates username from doman, and which is part of one of these components?) While I'm sure this patch is trivial and I'm certain the patch works, it breaks interoperability with everything not running the patch (all non-linux and any non RHEL/Centos 6.6 linux). This is probably acceptable in certain closed environments, but I can never use it here. However, patching the idmapper so that if the username already contains an "@", it doesn't add another one should also be trivial and should also work. It has the added benefit of not trashing interoperability. Conceptually, it allows sssd to convey both username and domain with no extra overhead and upgrades the linux nfs idmapper to handle living on a system which understands more than a flat namespace. To do it right, sssd always needs to supply the nfs idmapper usernames of the form "username@domain" regardless of the regex used to parse out those components at the login prompt. I'd have put that on the bugzilla, but I can't get at it. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Wed, 16 Jul 2014, Nordgren, Bryce L -FS wrote: Hi Aron, the support case you referenced is linked to bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1066153 which is fully acked for RHEL-6.6, the state of the bugzilla is ON_QA, so currently it looks the patch will be released in 6.6.. username@domain is coded in the NFS spec as an NFS id which goes over the wire. It's unclear what allowing two "@" signs means (which "@" separates username from doman, and which is part of one of these components?) While I'm sure this patch is trivial and I'm certain the patch works, it breaks interoperability with everything not running the patch (all non-linux and any non RHEL/Centos 6.6 linux). This is probably acceptable in certain closed environments, but I can never use it here. The patch went upstream already. What it does is changing lookup at last '@' instead of the first one. For traditional NFS cases it changes nothing as there is one '@' anyway, the one added by nfsidmap code. However, patching the idmapper so that if the username already contains an "@", it doesn't add another one should also be trivial and should also work. It has the added benefit of not trashing interoperability. Conceptually, it allows sssd to convey both username and domain with no extra overhead and upgrades the linux nfs idmapper to handle living on a system which understands more than a flat namespace. To do it right, sssd always needs to supply the nfs idmapper usernames of the form "username@domain" regardless of the regex used to parse out those components at the login prompt. Thing is, nfsidmap always adds and then substracts '@' plus domain, assuming that the part prior to '@' is what going to be mapped by the domain-specific idmap mapper. What you get here by not adding the '@' to the name which contains '@' already is that wrong domain will be classified and then wrong name is passed to the system to ask for. Current implementation (with the patch) survives both cases better than what you propose. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
> Thing is, nfsidmap always adds and then substracts '@' plus domain,
> assuming that the part prior to '@' is what going to be mapped by the
> domain-specific idmap mapper.
That's the crux of the problem right there. Sssd is not a domain-specific
idmap mapper. Sssd is a domain-aware, multidomain idmap mapper. Hence the
first "@".
> What you get here by not adding the '@' to
> the name which contains '@' already is that wrong domain will be classified
> and then wrong name is passed to the system to ask for.
The corollary of not adding the '@' is not subtracting it either.
If sssd is the system service that deals with multidomain issues, then let it.
The NFS idmapper doesn't need to add or subtract the "@" and should pass it on
to sssd, if it's interacting with sssd. One flag to the mapper
("domain-aware-system=true"), the internal linux only problems are solved
internally, and the over the wire traffic is not broken in ways that break
other clients (e.g., your patched system emits traffic which looks _exactly_
like the "traditional"-read-"conforming" NFS case to unpatched systems and
other ground-up implementations). Breaking the protocol in a self-consistent
way which excludes other platforms is a very Microsoft-like approach and makes
me feel all dirty. Sometimes (not now) it's necessary as a band-aid/workaround,
but this time the band-aid doesn't have to break things. :)
I'd say the real solution, long term, is to point both sssd and the nfs
idmapper at something like a umich_ldap server managed by freeipa. This has
additional benefits like centralizing the idmapping in a way that's exportable
to foreign organizations so they can be clients to my servers, being able to
resolve uidNumber collisions when I'm not in control of the AD I'm trying to
use, supporting bare Kerberos trusts, allowing multiple GSSAuthNames (e.g., my
AD account, Kerberos credentials from my home network KDC, my SAML account) to
be recognized as the same user, etc. Room for growth.
This electronic message contains information generated by the USDA solely for
the intended recipients. Any unauthorized interception of this message or the
use or disclosure of the information it contains may violate the law and
subject the violator to civil or criminal penalties. If you believe you have
received this message in error, please notify the sender and delete the email
immediately.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
Hi Jakub,
Good to know about the patch. It's unfortunate I can get a faster and more
detailed answer via the mailing list than GSS. Since I can't access the
bugzilla, any idea if it's targeted at RHEL7 as well?
/aron
From: Jakub Hrozek [jhro...@redhat.com]
Sent: Wednesday, July 16, 2014 2:19 AM
To: Parsons, Aron
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 16 Jul 2014, at 03:29, Parsons, Aron wrote:
> I ran into this issue last fall and have been running with a patched
> libnfsidmap since November while our support case with Red Hat waits on a
> resolution (pretty much have given up hope at this point). It's a trivial
> patch and removes the assumption that only one @ can be present in a username.
>
> With this patch applied, we have hundreds of sssd 1.11 clients on EL5, EL6
> and EL7 in multiple environments all using NFSv4 mounts with ID mapping
> enabled. We have experienced zero issues with this patch applied. Without
> it, the AD trust setup is a no-go in any sort of real environment since NFSv4
> is broken.
>
> If you'd like to reference our support case, it's #00983906. Patch is
> included below.
>
> /aron
>
Hi Aron,
the support case you referenced is linked to bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1066153 which is fully acked for
RHEL-6.6, the state of the bugzilla is ON_QA, so currently it looks the patch
will be released in 6.6..
>
>> From 305930bded0d377ebda858e8772ebf6527ba3f03 Mon Sep 17 00:00:00 2001
> From: Aron Parsons
> Date: Fri, 15 Nov 2013 14:43:10 -0500
> Subject: [PATCH] account for usernames with @ in them
>
> ---
> libnfsidmap/nss.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libnfsidmap/nss.c b/libnfsidmap/nss.c
> index 04aff19..f9ad4be 100644
> --- a/libnfsidmap/nss.c
> +++ b/libnfsidmap/nss.c
> @@ -135,7 +135,7 @@ static char *strip_domain(const char *name, const char
> *domain)
> char *l = NULL;
> int len;
>
> - c = strchr(name, '@');
> + c = strrchr(name, '@');
> if (c == NULL && domain != NULL)
>goto out;
> if (c == NULL && domain == NULL) {
> --
> 1.7.1
>
> -
> Hi,
>
> First i wish to thank everybody that helped me out trying to solve this issue
> and i also wish to inform that NFS 4 does not work with AD users through an
> AD and IPA trust at the moment for RHEL 6 and 7.
>
> The reason is that rpcidmapd` does not parse fully-qualified usernames
> so"adtest AD EXAMPLE o...@ipa.example.org" does not work.
> The client-side code is stripping the domain off based on the location of the
> first "@" character in the value returned by the server. This results in
> UID/GID mappings failing and resulting in ownership on the clients of
> "nobody".
>
> Regards,
> Johan
>
> From: Dmitri Pal [dpal redhat com]
> Sent: Thursday, June 05, 2014 21:03
> To: Johan Petersson; Alexander Bokovoy
> Cc: Sumit Bose; freeipa-users redhat com
> Subject: Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
>
> On 06/04/2014 09:57 AM, Johan Petersson wrote:
>> Yes the message is exactly like that with commas, I double checked.
>>
>> To anser Sumit's question: Maybe adding 'linux.home' and 'ad.home' to
>> Local-Realms in idmap.conf might help?
>>
>> I did on all machines and got rid of that specific message but I still get
>> user nobody unfortunately.
>>
>> Here are logs from when I did a su - adtest AD h...@linux.home with both
>> AD.HOME and LINUX.HOME added to Local_realms in idmap.conf.
>>
>> Client:
>> Jun 4 15:30:13 client su: (to adtest ad home) linux on pts/0
>> Jun 4 15:30:13 client nfsidmap[3602]: key: 0x35965a5f type: gid value:
>> adtest ad h...@linux.home timeout 600
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
>> nsswitch->name_to_gid
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
>> nsswitch->name_to_gid returned -22
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
>> is -22
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: calling
>> nsswitch->name_to_gid
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid:
>> nsswitch->name_to_gid returned 0
>> Jun 4 15:30:13 client nfsidmap[3602]: nfs4_name_to_gid: final return value
>> is 0
>
> Do we have a corresponding SSSD trace that shows the actual process of
> the resolution?
>
>
>>
>> NFS Server:
>> Jun 4 15:
Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On Wed, 16 Jul 2014, Nordgren, Bryce L -FS wrote:
Thing is, nfsidmap always adds and then substracts '@' plus domain,
assuming that the part prior to '@' is what going to be mapped by the
domain-specific idmap mapper.
That's the crux of the problem right there. Sssd is not a
domain-specific idmap mapper. Sssd is a domain-aware, multidomain
idmap mapper. Hence the first "@".
You are mixing different mappers and different layers.
SSSD uses separator (set to '@' by default and enforced as '@' in IPA
trusts mode) to automatically qualify users from non-primary domains. In
case of IPA trusts this is enforced for trusted domains of IPA domain
which are discovered automatically by IPA-specific means. SSSD, thus,
exposes these names as normal system-wide user and group names,
available to anyone performing NSS calls of the libc.
NFS idmap layer does own optimization by internally presenting any
NFS-provided name as name@domain and passing it to internal NFS idmap
providers. idmap plugins then take this name@domain and perform own
mapping. This has nothing to do with system-wide user names and it has
nothing to do with on wire NFS protocol, it is particular NFS idmap
library implementation detail. Note that libnfsidmap actually has two
stacks of idmap modules, applied separately to NFSv4 domain names and to
GSSAPI-authenticated names. While the same plugins are used in both
cases, the use of 'nsswitch' plugin for GSSAPI-authenticated names is
debatable without applying krb5_aname_to_localname() first, which
nfs-utils doesn't even do.
In other words, we have two different layers, dealing with different
conceptual idmap approaches, and one of them is being used by the other.
The latter (NFS idmap 'nsswitch' plugin) didn't expect that system-level
names might include the same symbol '@'. Given that the NFS
idmap-internal '@' is always appended to NFS-protocol provided name,
splitting the resulting string on last '@' is the right thing to do to
avoid clashes.
What you get here by not adding the '@' to
the name which contains '@' already is that wrong domain will be classified
and then wrong name is passed to the system to ask for.
The corollary of not adding the '@' is not subtracting it either.
This would be a major change to NFS libnfsidmap library and while
technically could be superior, it serves little value in this context.
If sssd is the system service that deals with multidomain issues, then
let it. The NFS idmapper doesn't need to add or subtract the "@" and
should pass it on to sssd, if it's interacting with sssd. One flag to
the mapper ("domain-aware-system=true"), the internal linux only
problems are solved internally, and the over the wire traffic is not
broken in ways that break other clients (e.g., your patched system
emits traffic which looks _exactly_ like the
"traditional"-read-"conforming" NFS case to unpatched systems and other
ground-up implementations). Breaking the protocol in a self-consistent
way which excludes other platforms is a very Microsoft-like approach
and makes me feel all dirty. Sometimes (not now) it's necessary as a
band-aid/workaround, but this time the band-aid doesn't have to break
things. :)
As I said, there is no protocol, on wire or between libnfsidmap and
lower OS levels, that requires special '@' handling. It is purely
internal thing to libnfsidmap. The way it was treated was wrong from the
beginning so I would argue the strrchr() fix is actually the proper fix
rather than band-aid.
I'd say the real solution, long term, is to point both sssd and the nfs
idmapper at something like a umich_ldap server managed by freeipa. This
has additional benefits like centralizing the idmapping in a way that's
exportable to foreign organizations so they can be clients to my
servers, being able to resolve uidNumber collisions when I'm not in
control of the AD I'm trying to use, supporting bare Kerberos trusts,
allowing multiple GSSAuthNames (e.g., my AD account, Kerberos
credentials from my home network KDC, my SAML account) to be recognized
as the same user, etc. Room for growth.
We want to have specialized NFS idmap plugin to existing libnfsidmap
that uses specialized SSSD API internally (the patch is on review on
SSSD list, at least it was when I went to my vacation which I'm enjoying
now:). Alternatively, we want to write a complete replacement of
libnfsidmap given the knowledge we have at SSSD side.
What is lacking here is the fact that with krb5 1.13 we also have way to
dynamically plug into krb5_aname_to_localname() processing and get rid
of static auth_to_local rules in krb5.conf for whole IPA domain and its
trusted domains. In this scheme for GSSAPI-authenticated NFS names all
what is needed to be done is krb5_aname_to_localname() call prior to use
of 'nsswitch' plugin. The rest will be done by SSSD automatically and
for all applications, not only NFS idmapper.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://
