Re: [Freeipa-users] IPA+AD trust and NFS nobody issue
On 16 Jul 2014, at 03:29, Parsons, Aron parso...@bit-sys.com 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 parso...@bit-sys.com
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
soadtest 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:abokovoy redhat com]
Sent:
[Freeipa-users] User auth for Samba 3 file server against IPA 3.0.0
Hi, this has been discussed on this list and elsewhere [1], but I'm still a little puzzled: I have IPA running on a CentOS 6 server. This server also acts as NFS- and Samba server. My Linux clients (openSUSE 13.1) work fine (NFS, automount, user auth for ssh and display manager). Since I also have some Windows users, I want them to be able to mount their homes via Samba using their IPA password. Just that, no AD or other fancy stuff. I read the instructions at [1], which appear to suit my case but at least the group.js UI patch is outdated. Is there a more recent howto to follow? Is patching the source at all still necessary? Will doing so break the opportunity to install a replica (a step that I have planned but not yet accomplished)? Thanks for your help. [1] http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ Mit freundlichen Gruessen/With best regards, --Daniel. -- 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
[Freeipa-users] Difference between Masters and Replicas?
Hi, I'd like some clarification on what a master and replica is please. This doc suggests you start with 1 master and a replica can be promoted to a master by changing /var/lib/pki-ca/conf/CS.cfg: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html However IPA is supposed to be multi-master replication, and replication agreements appears to be two ways when checking ipa-replica-manage list hostname on a given IPA server. So when creating a replica using: ipa-replica-install --setup-ca --setup-dns --forwarder=172.20.220.25 --forwarder=172.20.220.27 /root/replica-info-ipa01.domain.com.gpg am I creating another master replica? Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- 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] Difference between Masters and Replicas?
On 07/16/2014 02:34 PM, Choudhury, Suhail wrote: Hi, I'd like some clarification on what a master and replica is please. Once installed, all masters are identical (except some might have a CA and some not). The distinction is useful when installing a replica, where master and replica generally mean existing master and new master, respectively. This doc suggests you start with 1 master and a replica can be promoted to a master by changing /var/lib/pki-ca/conf/CS.cfg: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html That doc is ancient (Fedora 15), don't use it. However IPA is supposed to be multi-master replication, and replication agreements appears to be two ways when checking ipa-replica-manage list hostname on a given IPA server. So when creating a replica using: ipa-replica-install --setup-ca --setup-dns --forwarder=172.20.220.25 --forwarder=172.20.220.27 /root/replica-info-ipa01.domain.com.gpg am I creating another master replica? Yes, you're creating a new master; since you gave --setup-ca the two masters will be equivalent. -- Petr³ -- 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] Difference between Masters and Replicas?
On Wed, Jul 16, 2014 at 9:03 AM, Petr Viktorin pvikt...@redhat.com wrote: On 07/16/2014 02:34 PM, Choudhury, Suhail wrote: Hi, I'd like some clarification on what a master and replica is please. Once installed, all masters are identical (except some might have a CA and some not). The distinction is useful when installing a replica, where master and replica generally mean existing master and new master, respectively. This doc suggests you start with 1 master and a replica can be promoted to a master by changing /var/lib/pki-ca/conf/CS.cfg: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_ Guide/promoting-replica.html That doc is ancient (Fedora 15), don't use it. However IPA is supposed to be multi-master replication, and replication agreements appears to be two ways when checking ipa-replica-manage list hostname on a given IPA server. So when creating a replica using: ipa-replica-install --setup-ca --setup-dns --forwarder=172.20.220.25 --forwarder=172.20.220.27 /root/replica-info-ipa01.domain.com.gpg am I creating another master replica? Yes, you're creating a new master; since you gave --setup-ca the two masters will be equivalent. So you no longer need to do anything to promote a replica to be a CA master? Another way to ask the question, can I remove the original master and everything will still work? -- Petr³ -- 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 -- 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] Difference between Masters and Replicas?
Bill Peck wrote: On Wed, Jul 16, 2014 at 9:03 AM, Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com wrote: On 07/16/2014 02:34 PM, Choudhury, Suhail wrote: Hi, I'd like some clarification on what a master and replica is please. Once installed, all masters are identical (except some might have a CA and some not). The distinction is useful when installing a replica, where master and replica generally mean existing master and new master, respectively. This doc suggests you start with 1 master and a replica can be promoted to a master by changing /var/lib/pki-ca/conf/CS.cfg: http://docs.fedoraproject.org/__en-US/Fedora/15/html/FreeIPA___Guide/promoting-replica.html http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html That doc is ancient (Fedora 15), don't use it. However IPA is supposed to be multi-master replication, and replication agreements appears to be two ways when checking ipa-replica-manage list hostname on a given IPA server. So when creating a replica using: ipa-replica-install --setup-ca --setup-dns --forwarder=172.20.220.25 --forwarder=172.20.220.27 /root/replica-info-ipa01.__domain.com.gpg am I creating another master replica? Yes, you're creating a new master; since you gave --setup-ca the two masters will be equivalent. So you no longer need to do anything to promote a replica to be a CA master? Another way to ask the question, can I remove the original master and everything will still work? All masters are equal is a bit of a loaded term. From the NSS data perspective that is true, including DNS data whether a given master actually runs bind or not. The distinction comes in with the CA. It has its own replication topology and not every master needs to run one. We recommend at least two. There are two things that are only done on one IPA master with a CA: generating the CRL and managing renewal of the CA subsystem certificates. The initial IPA server installed is picked as the one to do these two tasks but it can be done by any of them. How to change it is documented at http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master rob -- 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] Difference between Masters and Replicas?
On 16.7.2014 15:03, Petr Viktorin wrote: On 07/16/2014 02:34 PM, Choudhury, Suhail wrote: Hi, I'd like some clarification on what a master and replica is please. Once installed, all masters are identical (except some might have a CA and some not). The distinction is useful when installing a replica, where master and replica generally mean existing master and new master, respectively. This doc suggests you start with 1 master and a replica can be promoted to a master by changing /var/lib/pki-ca/conf/CS.cfg: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html That doc is ancient (Fedora 15), don't use it. However IPA is supposed to be multi-master replication, and replication agreements appears to be two ways when checking ipa-replica-manage list hostname on a given IPA server. So when creating a replica using: ipa-replica-install --setup-ca --setup-dns --forwarder=172.20.220.25 --forwarder=172.20.220.27 /root/replica-info-ipa01.domain.com.gpg am I creating another master replica? Yes, you're creating a new master; since you gave --setup-ca the two masters will be equivalent. Please note that --setup-dns is also important. Use it for the new replica if you have used it for the original master. -- Petr^2 Spacek -- 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 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] Problem with IPAv2 certificate renewal
Michal Nawrocki wrote: Hello, I¹m trying to renew IPA server certificates according to this howto: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal and have problem with one of them. After starting tracking and resubmitting all 4 PKI certificates (auditSigningCert cert-pki-ca², ocspSigningCert cert-pki-ca², subsystemCert cert-pki-ca² and Server-Cert cert-pki-ca²) three of them get refreshed but ocspSigningCert cert-pki-ca gets refreshed with different values of certificate subject and extended key usage attribute. Original: Subject: CN=OCSP Subsystem,O=[REALM]² Name: Extended Key Usage OCSP Responder Certificate Afrer renewal: Subject: ³CN=[server full hostname],O=[REALM]² Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Hard to say but my guess would be the wrong profile was used at some point. It may be difficult now to figure out what happened. On testing environment every certificate got refreshed without problems. ocsp certificate got refreshed with only ³not before² and ³not after² values changed. After trying to manually delete certificate from database in /var/lib/pki-ca/alias by running: certutil -D -d /var/lib/pki-ca/alias/ -n ocspSigningCert cert-pki-ca creating request with this command: getcert request -d /var/lib/pki-ca/alias/ -n ocspSigningCert cert-pki-ca -P [PIN] -N CN=OCSP Subsystem,O=REALM -c dogtag-ipa-renew-agent -T caOCSPCert -U id-kp-OCSPSigning It is very possible you got a new private key as well when you did this. I don't know if that is harmful or not. You probably have a backup of the original certs in /root/cacert.p12. You can extract those in a temporary database and see what they looked like at install time, and what the serial #'s were. we end up with new ocsp certificate with proper subject (Subject: CN=OCSP Subsystem,O=[REALM]²), but Extended Key Usage is still set to: TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate After changing ³ca.ocsp_signing.cert² entry in /etc/pki-ca/CS.cfg with one-line version of new certificate, pki-cad daemon starts only for a few seconds and then shuts down without anything in log files. I'd check the debug and selftests.log logs carefully. Sometimes the output is subtle in the CA logs, so errors don't immediately jump out. Everything is done with accordance with howto and everything was done several times on testing environment. After some investigation we noticed that: ipa cert-show 2 shows CN=OCSP Subsystem certificate on test env but host certificate on production. It looks like there was some problems with replication of pki / dogtag and certificate with serial no #2 got replaced. There is no guaranteed ordering of serial numbers so it may be just fine. It would not be related to replication in any case. rob Anyone had similar problem? I will appreciate any help because in 2 weeks our IPA certificates will expire... Best regards Michal -- 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
[Freeipa-users] OC and FreeIPA
Hi.
Does anybody here know how to properly set up ownCloud 6.0.4 to work
with FreeIPA 3.3.5? I keep getting these messages when trying to logon
to OC with a created account in FreeIPA.
Here's a sample:
ownCloud[2182]: {user_ldap} initializing paged search for
FilterobjectClass=* base Array ([0] =
uid=jonram,cn=users,cn=compat,dc=mydomain,dc=com) attr ipauniqueid limit
9 offset 0
ownCloud[2182]: {user_ldap} Ready for a paged search
ownCloud[2182]: {user_ldap} Requested attribute ipauniqueid not found
for uid=jonram,cn=users,cn=compat,dc=mydomain,dc=com
ownCloud[2182]: {user_ldap} Could not autodetect the UUID attribute
ownCloud[2182]: {user_ldap} Cannot determine UUID for
uid=jonram,cn=users,cn=compat,dc=mydomain,dc=com. Skipping.
ownCloud[2182]: {core} Login failed: user 'jonram' , wrong password,
IP:set log_authfailip=true in conf
I'm really new to OC and IPA so I don't know where to poke to make it
work. I'll much appreciate any hint.
Thanks in advance.
--
Jonathan J. Ramirez C.
--
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 parso...@bit-sys.com 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 parso...@bit-sys.com
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
soadtest 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
Re: [Freeipa-users] OC and FreeIPA
Jonathan J. Ramirez C. wrote:
Hi.
Does anybody here know how to properly set up ownCloud 6.0.4 to work
with FreeIPA 3.3.5? I keep getting these messages when trying to logon
to OC with a created account in FreeIPA.
Here's a sample:
ownCloud[2182]: {user_ldap} initializing paged search for
FilterobjectClass=* base Array ([0] =
uid=jonram,cn=users,cn=compat,dc=mydomain,dc=com) attr ipauniqueid limit
9 offset 0
ownCloud[2182]: {user_ldap} Ready for a paged search
ownCloud[2182]: {user_ldap} Requested attribute ipauniqueid not found
for uid=jonram,cn=users,cn=compat,dc=mydomain,dc=com
ownCloud[2182]: {user_ldap} Could not autodetect the UUID attribute
ownCloud[2182]: {user_ldap} Cannot determine UUID for
uid=jonram,cn=users,cn=compat,dc=mydomain,dc=com. Skipping.
ownCloud[2182]: {core} Login failed: user 'jonram' , wrong password,
IP:set log_authfailip=true in conf
I'm really new to OC and IPA so I don't know where to poke to make it
work. I'll much appreciate any hint.
I've never dealt with OC before but I scanned the LDAP docs quickly.
You will want to set separate user and group base DNs. It is using the
compat tree and that is likely the wrong thing in this case.
Users: cn=users,cn=accounts,dc=mydomain,dc=com
Groups: cn=groups,cn=accounts,dc=mydomain,dc=com
That will fix the UUID issue at least.
Have you set a password for this user account, and have you
authenticated with it yet? IPA marks all administratively set passwords
as expired, so you need to authenticate and change the password before
it is generally usable.
IPA uses memberOf for its grouping in case you need to specify it.
rob
--
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: 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:
[Freeipa-users] FreeIPA 4.0.0 Peer's certificate issuer has been marked as not trusted by the user.
On a clean Fedora 20, minimal install, system using the netinstall iso, I'm getting an error all the way at the end of the ipa-server-install process (when it tries to run ipa-client-install). I put the fqdn of the hostname in /etc/hostname and ipaddr ipa.usfs-i2.umt.edu ipa in /etc/hosts and rebooted. Hostname returns the fqdn. DNS A, SRV, and TXT entries are in place. Reverse DNS works. Copr repository installed, and fedora-updates-testing enabled (for required version of dirsrv). Yum refused to install freeipa-server for reason of unsatisfied dependencies, but dnf succeeded. Tail end of ipa-server-install is here, followed by a successful kinit and a failed ipa command. I can fix the cert issue on the server by following http://www.iamlinux.com/2014/06/ipa-commands-fails-with-peers-certificate-issuer-has-been-marked-as-not-trusted-by-the-user-error/. This allows ipa commands on the server to work. However, ipa-client-install on the client fails with the same Peer's certificate issuer has been marked as not trusted by the user. Is this a dorky new user problem or should I file a bug? Bryce ... Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.dr0fFP.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'usfs-i2.umt.edu' '--server' 'ipa.usfs-i2.umt.edu' '--realm' 'USFS-I2.UMT.EDU' '--hostname' 'ipa.usfs-i2.umt.edu'' returned non-zero exit status 1 [root@ipa yum.repos.d]# kinit admin Password for ad...@usfs-i2.umt.edu: [root@ipa yum.repos.d]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: ad...@usfs-i2.umt.edu Valid starting Expires Service principal 07/16/2014 13:29:51 07/17/2014 13:29:45 krbtgt/usfs-i2.umt@usfs-i2.umt.edu [root@ipa yum.repos.d]# ipa user-find ipa: ERROR: cert validation failed for CN=ipa.usfs-i2.umt.edu,O=USFS-I2.UMT.EDU ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cannot connect to 'https://ipa.usfs-i2.umt.edu/ipa/json': (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. 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] FreeIPA 4.0.0 Peer's certificate issuer has been marked as not trusted by the user.
On Wed, 16 Jul 2014, Nordgren, Bryce L -FS wrote: On a clean Fedora 20, minimal install, system using the netinstall iso, I'm getting an error all the way at the end of the ipa-server-install process (when it tries to run ipa-client-install). I put the fqdn of the hostname in /etc/hostname and ipaddr ipa.usfs-i2.umt.edu ipa in /etc/hosts and rebooted. Hostname returns the fqdn. DNS A, SRV, and TXT entries are in place. Reverse DNS works. Copr repository installed, and fedora-updates-testing enabled (for required version of dirsrv). Yum refused to install freeipa-server for reason of unsatisfied dependencies, but dnf succeeded. Tail end of ipa-server-install is here, followed by a successful kinit and a failed ipa command. I can fix the cert issue on the server by following http://www.iamlinux.com/2014/06/ipa-commands-fails-with-peers-certificate-issuer-has-been-marked-as-not-trusted-by-the-user-error/. This allows ipa commands on the server to work. However, ipa-client-install on the client fails with the same Peer's certificate issuer has been marked as not trusted by the user. Is this a dorky new user problem or should I file a bug? Check /var/log/ipaclient-install.log first, as your IPA client install did not finish, thus certificates store wasn't created properly and does not contain IPA CA certificate yet. -- / 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] FreeIPA 4.0.0 Peer's certificate issuer has been marked as not trusted by the user.
On Wed, 16 Jul 2014, Nordgren, Bryce L -FS wrote: DNS A, SRV, and TXT entries are in place. Reverse DNS works. My text DNS entry is possibly hosed, as it's in lowercase. I put in a request to capitalize it. [root@ipa yum.repos.d]# host -t TXT _kerberos.usfs-i2.umt.edu _kerberos.usfs-i2.umt.edu descriptive text usfs-i2.umt.edu. Check /var/log/ipaclient-install.log first, as your IPA client install did not finish, thus certificates store wasn't created properly and does not contain IPA CA certificate yet. For someone on vacation you sure spend a lot of time geeking out. :) From the below, I think my next thing to try is to wipe the machine and ipa-server-install --realm=USFS-I2.UMT.EDU to override DNS until it gets fixed. Would you concur? Thanks for pointing me at the logfile. 2014-07-16T19:28:16Z WARNING Using existing certificate '/etc/ipa/ca.crt'. 2014-07-16T19:28:16Z DEBUG [IPA Discovery] 2014-07-16T19:28:16Z DEBUG Starting IPA discovery with domain=usfs-i2.umt.edu, servers=['ipa.usfs-i2.umt.edu'], hostname=ipa.usfs-i2.umt.edu 2014-07-16T19:28:16Z DEBUG Server and domain forced 2014-07-16T19:28:16Z DEBUG [Kerberos realm search] 2014-07-16T19:28:16Z DEBUG Search DNS for TXT record of _kerberos.usfs-i2.umt.edu 2014-07-16T19:28:16Z DEBUG DNS record found: usfs-i2.umt.edu. 2014-07-16T19:28:16Z DEBUG Search DNS for SRV record of _kerberos._udp.usfs-i2.umt.edu. 2014-07-16T19:28:16Z DEBUG DNS record found: 0 100 88 ipa.usfs-i2.umt.edu. 2014-07-16T19:28:16Z DEBUG [LDAP server check] 2014-07-16T19:28:16Z DEBUG Verifying that ipa.usfs-i2.umt.edu (realm usfs-i2.umt.edu.) is an IPA server 2014-07-16T19:28:16Z DEBUG Init LDAP connection to: ipa.usfs-i2.umt.edu 2014-07-16T19:28:16Z DEBUG Search LDAP server for IPA base DN 2014-07-16T19:28:16Z DEBUG Check if naming context 'dc=usfs-i2,dc=umt,dc=edu' is for IPA 2014-07-16T19:28:16Z DEBUG Naming context 'dc=usfs-i2,dc=umt,dc=edu' is a valid IPA context 2014-07-16T19:28:16Z DEBUG Search for (objectClass=krbRealmContainer) in dc=usfs-i2,dc=umt,dc=edu (sub) 2014-07-16T19:28:16Z DEBUG Found: cn=USFS-I2.UMT.EDU,cn=kerberos,dc=usfs-i2,dc=umt,dc=edu 2014-07-16T19:28:16Z WARNING Skip ipa.usfs-i2.umt.edu: cannot verify if this is an IPA server 2014-07-16T19:28:16Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, domain=usfs-i2.umt.edu, kdc=ipa.usfs-i2.umt.edu, basedn=dc=usfs-i2,dc=umt,dc=edu 2014-07-16T19:28:16Z DEBUG Validated servers: 2014-07-16T19:28:16Z ERROR Failed to verify that ipa.usfs-i2.umt.edu is an IPA Server. 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
