Re: [Freeipa-users] Could not update DNSSSHFP records when joining domain
On 06/05/2015 12:27 AM, nat...@nathanpeters.com wrote: I am running FreeIPA 4.1.3 on CentOS7. I am attempting to join a CentOS 6.5 client using ipa-client 3.0.0-42. The client hostname is ipaclient.login.mydomain.net. The FreeIPA domain is mydomain.net. This post here : https://www.redhat.com/archives/freeipa-users/2015-April/msg00368.html states that making all dns entries into a single zone rather than having a separate zone for login.mydomain.net is a perfectly acceptable design choice. However, an issue occurs when joining the client. It joins to the domain fine and creates the initial DNS A entry, but then according to the logs, when it goes to update the DNSSSHFP records, it fails because it tries to update the nonexistent zone login.mydomain.net instead of just updating mydomain.net. To be clear, the SSH host keys are in the client record so the only issue is with adding them to DNS Here are the relevant log entries generated with ipa-client-install: 2015-06-03T16:11:12Z DEBUG stderr= 2015-06-03T16:11:12Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt: 2015-06-03T16:11:12Z DEBUG zone login.mydomain.net. update delete ipaclient.login.mydomain.net. IN SSHFP send update add ipaclient.login.mydomain.net. 1200 IN SSHFP 1 1 1D17A1B7DCB75242AEBBBFEF7CE68844B530AE60 update add ipaclient.login.mydomain.net. 1200 IN SSHFP 2 1 11D3F076F616F02AD74BFF4D48E8BBA239063E8F send 2015-06-03T16:11:13Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt 2015-06-03T16:11:13Z DEBUG stdout= 2015-06-03T16:11:13Z DEBUG stderr=update failed: NOTAUTH update failed: NOTAUTH 2015-06-03T16:11:13Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 2 2015-06-03T16:11:13Z WARNING Could not update DNS SSHFP records. -- 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 Here are some more entries from /var/named/data/named.run. You'll notice in the first set of entries, I added the hosts with the incorrect subdomain set and it worked fine. In the second set, I gave the correct hostnames and even though it claims it's still trying to update the mydomain.net file it says it's not authorized. I am thoroughly confused by this behavior. successful -- 01-Jun-2015 18:36:04.580 client 10.21.5.206#40096/key host/ipaclient.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': deleting rrset at 'ipaclient.mydomain.net' A 01-Jun-2015 18:36:04.590 client 10.21.5.206#34641/key host/ipaclient.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': adding an RR at 'ipaclient.mydomain.net' A 01-Jun-2015 18:36:25.582 client 10.21.5.206#49800/key host/ipaclient.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': deleting rrset at 'ipaclient.mydomain.net' SSHFP 01-Jun-2015 18:36:25.595 client 10.21.5.206#34081/key host/ipaclient.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': adding an RR at 'ipaclient.mydomain.net' SSHFP 01-Jun-2015 18:36:26.363 client 10.21.5.206#34081/key host/ipaclient.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': adding an RR at 'ipaclient.mydomain.net' SSHFP unsuccessful 03-Jun-2015 16:10:56.407 client 10.21.5.206#52739/key host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': update failed: not authoritative for update zone (NOTAUTH) 03-Jun-2015 16:10:56.420 client 10.21.5.206#50551/key host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': update failed: not authoritative for update zone (NOTAUTH) 03-Jun-2015 16:11:12.993 client 10.21.5.206#39633/key host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': update failed: not authoritative for update zone (NOTAUTH) 03-Jun-2015 16:11:13.005 client 10.21.5.206#50415/key host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone 'mydomain.net/IN': update failed: not authoritative for update zone (NOTAUTH) So can anyone at least tell me whether it is intended that you have to create a separate DNS subdomain rather than one big domain file in order to get DNSSSHFP records to save or is that a bug and you should be able to just have one large domain and not break out the subdomains? I thought it is not needed to create subdomains in order for nsupdate to work. Maybe it is a Update policy thing? Petr, do you know? -- 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] Fw: ssh problem with migrated FreeIPA client on EL7.1 -->Solved
On 06/04/2015 07:34 PM, Christopher Lamb wrote:
Hi All
I can now report back success (at least on my throwaway EL7.1 test VM).
To switch an EL 7.1 + ipa-client 4.1 host from an old FreeIPA 3.3.3 KDC to
a new FreeIPA 4.1 KDC 3 steps are required:
1) ipa-client-install --uninstall
2) rm -f /var/lib/sss/db/*
3) ipa-client-install --server ldap.my.example.com --domain my.example.com
-N
Having done this, my free-ipa user successfully authenticates (e.g. ssh
remote login with free-ipa user / password
To switch EL 6.5 + ipa-client 3.3.3 hosts step 2) was not required.
Kudos and thanks go to Rob C for suggesting step 2. (Note that the
directory to be purged is /var/lib/sss/db/, not /var/lib/sssd/db/ as
suggested earlier in this thread.
Cool! Thanks for reaching back. I added this advice to the FreeIPA
Troubleshooting guide too:
http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_on_client
Cheers
Chris
From: Martin Kosek
To: Christopher Lamb/Switzerland/IBM@IBMCH,
freeipa-users@redhat.com
Cc: Jakub Hrozek , Rob Crittenden
Date: 03.06.2015 10:39
Subject:Re: [Freeipa-users] Fw: ssh problem with migrated FreeIPA
client on EL7.1 -->Not Solved
On 06/03/2015 10:30 AM, Christopher Lamb wrote:
Hi all
This is a quick(ish) note to bring everybody up to speed on this issue.
Yesterday we had some private mail exchange on this issue as I did not
wish
to broadcast the krb5 and ipa install logs to the user list.
The basic situation is that we are in the process of migrating from an
FreeIPA 3.3.3 Server (KDC) to a new FreeIPA 4.1 Server (KDC). As
discussed
in a thread some weeks ago we did not do this by replicating (as perhaps
we
should have done). Instead we migrated the users across.
We have 30+ servers that are IPA clients ("Hosts" in ipa-speak) joined to
the old KDC. We are now in the process of migrating these hosts to the
new
4.1 KDC.
Most of the hosts run EL 6.5 + ipa-client 3.3.3. For all of these
joining
to the new KDC was trouble free, taking a few minutes each. After joining
the new KDC FreeIPA users authenticated properly.
We also had a small number of new EL 7.1 + ipa-client 4.1 hosts that were
joined direct to the new 4.1 KDC, never having been joined of the 3.3.3
KDC. These were also trouble free.
The problem occurs with a handful of existing EL 7.1 +ipa-client 4.1
hosts
that were originally joined to the 3.3.3 KDC, and must be moved to join
the
4.1 KDC. These machines no longer authenticate valid FreeIPA users. I
have
been able to reproduce this behaviour with a freshly setup VM joined
first
to the 3.3.3 KDC, then moved to the 4.1 KDC.
While the errors show in the krb5 child logs indicate that the password
is
incorrect, the same user / password is happily accepted by all the other
hosts.
It seems that in the process of moving / migrating the EL 7.1 /
ipa-client
4.1 from the old KDC to the new KDC, "something" is left behind that
causes
problems. We have seen indications in the install logs that the kinit
steps
called during ipa-client install are getting responses from the wrong
(old)
KDC, and not from the new KDC.
Frustratingly. over the weekend i managed to get one of the problem EL
7.1
boxes to work. However I can't work out exactly what I was that I did
that
did the trick. However it seems that some kind of major de-install /
cleanup + reinstall of the ipa-client may be needed.
Rob has suggested that as part of such a cleanup I should do "rm
-f /var/lib/sssd/db/*". I will test this later today and report back.
Thanks to Rob, Jakub, Martin, Alexander et al for their help and
suggestions so far.
Chris
Thanks for the background. The pain you are getting is exactly the reason
why
migration via replication to RHEL-7.1 is a better choice :-) Please let us
know
the result, I am curious how this works out.
From:Martin Kosek
To: Christopher Lamb/Switzerland/IBM@IBMCH,
freeipa-users@redhat.com, Jakub Hrozek
Date:03.06.2015 09:34
Subject: Re: [Freeipa-users] Fw: ssh problem with migrated
FreeIPA
client on EL7.1 -->Not Solved
On 06/02/2015 06:15 PM, Christopher Lamb wrote:
Hi
Earlier today I setup 2 throwaway EL7.1 VMs to help narrow down the
cause
of this problem. Let's call them HOST09 and HOST10
Both are mimimum installs of EL7.1, with NTPD installed and configured.
HOST09 had ipa-client 4.1 installed via yum, and was configured to use
our
new FreeIPA 4.1 server, right from the start. --> My FreeIPA user
authenticates successfully against this machine.
HOST10 had ipa-client 4.1 installed as a dependency of one of our
standard
config packages, and was first set to use our old FreeIPA 3.3.3 server.
-->
My FreeIPA user authenticates successfully. against this machine.
I then de-registered HOST10 from the FreeIPA 3.1 server, and registered
against the new FreeIPA 4.1 ser
Re: [Freeipa-users] How to handle users with multiple homedirs on different machines?
On Wed, Jun 3, 2015 at 12:29 AM, Lukas Slebodnik wrote: > However sssd is available just on linux (or FreeBSD) > I'm not sure which clients do you use on Solaris or other Solaris would be configured via LDAP. RedHat appears to have a pretty good guide for doing this. Same goes for any other systems lacking sssd client or so I hope. > > >As an example, I have user Bob. > >On a Linux box Bob has homedir at /home/b/bob > ^ > Unfortunatelly, there's no way how to say > sssd to use just first letter from name. > Hmmm. Is time for a feature request? Should this be directed to SSSD or FreeIPA group? override_homedir appears to have plenty of substitution options. This wouldn't be a major change request. For more flexibility, I think it would be nice to refer to an output of a script for determining homedir overrides. > >On a Solaris this is likely /export/home/bob > >While on some other odd system it could be /mnt/nas/users/bob > Different "prefix" for homedir "/export/home", "/home", "/mnt/nas/users" > could be addresed with the option homedir_substring in sssd conf. > https://fedorahosted.org/sssd/ticket/1853 > So you could store "%H" in ldap attribute, > but clients need to understand such value. > (sssd >= 1.11.6). I'm not sure about other clients. > As there is no sssd client for Solaris, I think I may have found a workaround via automounter as suggested by Coy Hile. But that only solves the Solaris specific homdir paths. In any case, I'm further today than I was yesterday. Thank you. -- 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] Could not update DNSSSHFP records when joining domain
>> I am running FreeIPA 4.1.3 on CentOS7. >> >> I am attempting to join a CentOS 6.5 client using ipa-client 3.0.0-42. >> >> The client hostname is ipaclient.login.mydomain.net. >> >> The FreeIPA domain is mydomain.net. >> >> This post here : >> https://www.redhat.com/archives/freeipa-users/2015-April/msg00368.html >> states that making all dns entries into a single zone rather than having >> a >> separate zone for login.mydomain.net is a perfectly acceptable design >> choice. >> >> However, an issue occurs when joining the client. It joins to the >> domain >> fine and creates the initial DNS A entry, but then according to the >> logs, >> when it goes to update the DNSSSHFP records, it fails because it tries >> to >> update the nonexistent zone login.mydomain.net instead of just updating >> mydomain.net. To be clear, the SSH host keys are in the client record so >> the only issue is with adding them to DNS >> >> Here are the relevant log entries generated with ipa-client-install: >> >> 2015-06-03T16:11:12Z DEBUG stderr= >> 2015-06-03T16:11:12Z DEBUG Writing nsupdate commands to >> /etc/ipa/.dns_update.txt: >> 2015-06-03T16:11:12Z DEBUG zone login.mydomain.net. >> update delete ipaclient.login.mydomain.net. IN SSHFP >> send >> update add ipaclient.login.mydomain.net. 1200 IN SSHFP 1 1 >> 1D17A1B7DCB75242AEBBBFEF7CE68844B530AE60 >> update add ipaclient.login.mydomain.net. 1200 IN SSHFP 2 1 >> 11D3F076F616F02AD74BFF4D48E8BBA239063E8F >> send >> >> 2015-06-03T16:11:13Z DEBUG args=/usr/bin/nsupdate -g >> /etc/ipa/.dns_update.txt >> 2015-06-03T16:11:13Z DEBUG stdout= >> 2015-06-03T16:11:13Z DEBUG stderr=update failed: NOTAUTH >> update failed: NOTAUTH >> >> 2015-06-03T16:11:13Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate >> -g >> /etc/ipa/.dns_update.txt' returned non-zero exit status 2 >> 2015-06-03T16:11:13Z WARNING Could not update DNS SSHFP records. >> >> >> >> -- >> 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 >> > > Here are some more entries from /var/named/data/named.run. > > You'll notice in the first set of entries, I added the hosts with the > incorrect subdomain set and it worked fine. > > In the second set, I gave the correct hostnames and even though it claims > it's still trying to update the mydomain.net file it says it's not > authorized. I am thoroughly confused by this behavior. > > successful > -- > 01-Jun-2015 18:36:04.580 client 10.21.5.206#40096/key > host/ipaclient.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': deleting rrset at 'ipaclient.mydomain.net' A > 01-Jun-2015 18:36:04.590 client 10.21.5.206#34641/key > host/ipaclient.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': adding an RR at 'ipaclient.mydomain.net' A > 01-Jun-2015 18:36:25.582 client 10.21.5.206#49800/key > host/ipaclient.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': deleting rrset at 'ipaclient.mydomain.net' SSHFP > 01-Jun-2015 18:36:25.595 client 10.21.5.206#34081/key > host/ipaclient.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': adding an RR at 'ipaclient.mydomain.net' SSHFP > 01-Jun-2015 18:36:26.363 client 10.21.5.206#34081/key > host/ipaclient.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': adding an RR at 'ipaclient.mydomain.net' SSHFP > > unsuccessful > > 03-Jun-2015 16:10:56.407 client 10.21.5.206#52739/key > host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': update failed: not authoritative for update zone > (NOTAUTH) > 03-Jun-2015 16:10:56.420 client 10.21.5.206#50551/key > host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': update failed: not authoritative for update zone > (NOTAUTH) > 03-Jun-2015 16:11:12.993 client 10.21.5.206#39633/key > host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': update failed: not authoritative for update zone > (NOTAUTH) > 03-Jun-2015 16:11:13.005 client 10.21.5.206#50415/key > host/ipaclient.login.mydomain.net\@mydomain.NET: updating zone > 'mydomain.net/IN': update failed: not authoritative for update zone > (NOTAUTH) > > > So can anyone at least tell me whether it is intended that you have to create a separate DNS subdomain rather than one big domain file in order to get DNSSSHFP records to save or is that a bug and you should be able to just have one large domain and not break out the subdomains? -- 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 spamming radius with otp token?
Someone higher up decided that there was no time for me to resolve this and I’ve been forced to implement a different method for now. I can still continue to work on this, I'll just need to find different hardware to troubleshoot with. I have set up a kerberos.xml in /etc/firewalld/services restricting to tcp 88. I have restricted the service to the specific interface via zone and rich rule. …….. …. ….. Same for kpasswd on port 464. I’m also made sure that the krb5.conf has a line for udp_preference_limit = 1 I’ve also made sure to turn caching off in sssd.conf and restarted that. I set a 30 second timeout and 0 retries. Attempting to SSH from the firewall/gateway as a user to the idm server itself. I’ve managed to get things down to just 2 copies with maybe 1 second difference: Fri May 15 15:23:05 Packet-Type = Access-Request NAS-Identifier = “idm2.manage.monitor.net” Service-Type = Authenticate-Only User-Name = “bahmer” User-Password = “123-4567" On the Idm server /var/log/secure: May 15 15:23:03 idm2 unix_chkpwd[15103]: check pass; user unknown May 15 15:23:03 idm2 unix_chkpwd[15103]: password check failed for user (bahmer) May 15 15:23:03 idm2 sshd[15101]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=gate1.manage.monitor.net user=bahmer May 15 15:23:07 idm2 sshd[15101]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=gate1.manage.monitor.net user=bahmer May 15 15:23:07 idm2 sshd[15101]: pam_sss(sshd:auth): received for user bahmer: 17 (Failure setting user credentials) May 15 15:23:09 idm2 sshd[15101]: Failed password for bahmer from 10.6.0.41 port 44347 ssh2 I’ve collected some tcpdump information, most of the kerberos traffic is on the loopback interface and nothing stands out. I can see the two requests in the tcpdump on the interface the idm server should be using to talk to radius. I probably need permission in order to send the captures after sanitizing them for security policy reasons. Is it possible that sssd is the culprit trying to do a pre-auth before the real auth? > >On 5/13/15, 12:00 PM, "Nathaniel McCallum" wrote: > >>On Wed, 2015-05-13 at 14:44 +, Bahmer, Eric Vaughn wrote: >>> Institutionally we have a hardware token set up, you use a pin to >>> unlock the device and it spits out a passcode. >>> The passcode allows access through kerberos, radius, or ldap binds >>> to linux servers, or with a custom apache module to websites. >>> >>> I have an out-of-band private network set up that attaches to our >>> intranet using a firewall/gateway server which does some port >>> forwarding for various things like SSH, RDP. >>> I¹m attempting to set up RADIUS on this firewall/gateway to be used >>> as a proxy for freeipa to our token system which I¹d like to be able >>> to use behind the firewall. >>> However I seem to be getting nearly a dozen requests into the radius >>> server, about half are dropped as duplicate, but usually 3-6 get >>> through and since it¹s a single use token the first attempt >>> succeeds, but the rest fail and cause the hardware token to be >>> blacklisted. >>> Is there a way to specify that the user radius login is a one-time >>> token or is this something that sssd or pam is causing? >>> Or does the OTP support just not work in the way I need it to? >>> I have this issue with both the inbox 4.1.0 in RHEL7.1 or the >>> upstream 4.1.4 rpms. >>> >>> My only alternative is probably to set up a KDC on the firewall to >>> trust the institutional realm and have the IdM kerberos realm trust >>> that. >>> This is also a mixed linux/windows environment behind the firewall, >>> I¹ve enabled unix attributes in my AD and I¹m using a script to sync >>> uid/gid with the external ldap. >> >>I do think a cross realm trust is the right way to set this up. >> >>However, let's look more closely at the RADIUS issue. >> >>First, I want to ensure that you are using TCP for your kerberos >>connections. If you are using UDP for kerberos, then the kerberos >>client will send a new packet which will cause the KDC to fire off a >>new set of RADIUS messages. The use of TCP should be enforced with >>kerberos when using OTP. >> >> >>How long does it take for the hardware token RADIUS server to respond? >>Have you tried adjusting the number of retries and timeout for the >>RADIUS server in FreeIPA? A longer timeout or fewer retries will >>reduce the number of packets transmitted. >> >>If you are able to setup a test user with fake credentials and could >>perform a packet capture of kerberos and RADIUS traffic it would help >>me understand what is going on here. >> >>Nathaniel >> >>PS - If I had to take a guess based on what I know now, I would >>suspect that the real culprit is kinit sending too many requests. This >>is based on your statement that the RADIUS server is dropping *some
Re: [Freeipa-users] IPA Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Hi Rob, Sorry, my original message had the information: FreeIPA server running on CentOS 6.6 server. (ipa-server-3.0.0-42.el6.centos.x86_64 and ipa-client-3.0.0-42.el6.centos.x86_64) Once again your advice is perfect. I did the "ipactl restart" and now everything in the web page appears to be working without error. I will let you know if I see anything else, but it looks like this is solved. Thank you for all your help. -Chris Tobey -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: June-04-15 3:20 PM To: Chris Tobey; 'Martin Kosek'; freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Chris Tobey wrote: > Hi Rob, > > Thanks for taking the time to look at this. > > I have services in /etc/init.d/ named tomcat6 and pki-cad. > > I tried the following: > - > [Thu Jun 04 14:38:16:/etc/init.d]$ service tomcat6 status > tomcat6 is stopped [ OK ] > [Thu Jun 04 14:38:23:/etc/init.d]$ service tomcat6 start > Starting tomcat6: [ OK ] > [Thu Jun 04 14:38:29:/etc/init.d]$ service tomcat6 status > tomcat6 (pid 10853) is running... [ OK ] > [Thu Jun 04 14:38:40:/etc/init.d]$ service pki-cad status > pki-ca (pid 1793) is running...[ OK ] > Unsecure Port = http://chimera.server.com:9180/ca/ee/ca > Secure Agent Port = https://chimera.server.com:9443/ca/agent/ca > Secure EE Port = https://chimera.server.com:9444/ca/ee/ca > Secure Admin Port = https://chimera.server.com:9445/ca/services > EE Client Auth Port = https://chimera.server.com:9446/ca/eeca/ca > PKI Console Port= pkiconsole https://chimera.server.com:9445/ca > Tomcat Port = 9701 (for shutdown) > > PKI Instance Name: pki-ca > > PKI Subsystem Type: Root CA (Security Domain) > > Registered PKI Security Domain Information: > > == > Name: IPA > URL: https://chimera.server.com:443 > > == > Ok, you didn't specify a version so I took a stab in the dark on the service name. So I gather you're running 3.0.0? You'll need to dive into the catalina.log and debug logs in /var/log/pki-ca. This means that tomcat started but the webapp didn't. This is usually the audit subsystem kicking in but recently someone else had this issue and a simple ipactl restart fixed it for him. rob > - > > After this I am able to create new hosts on my Foreman server! > > There are now a few questions: > 1. I am not sure why the tomcat6 service was stopped, if it is > required to be running. > 2. I am not sure why a reboot of the server did not auto-start tomcat6. > 3. When navigating the web GUI for FreeIPA and clicking on a host, I > still see the popup message in the subject of this thread. > > I have not yet tried rebooting the FreeIPA (chimera) and > Puppet/Foreman > (puppetmaster) servers yet. When I have some downtime I will try that > and see what happens in regards to questions 2 and 3. > > Thanks, > -Chris Tobey > > -Original Message- > From: Rob Crittenden [mailto:rcrit...@redhat.com] > Sent: June-04-15 10:35 AM > To: Chris Tobey; 'Martin Kosek'; freeipa-users@redhat.com > Subject: Re: [Freeipa-users] IPA Error 4301: Certificate operation > cannot be > completed: Unable to communicate with CMS (Not Found) > > Apache proxies to dogtag, so a Not Found means that dogtag either > isn't running or its webapp wasn't loaded. > > I'd start by restarting pki-tomcatd@pki-tomcat.service and see if that > helps. > > Otherwise you'll need to poke around in the debug long in > /var/lib/pki-ca/ > > 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 Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Chris Tobey wrote: Hi Rob, Thanks for taking the time to look at this. I have services in /etc/init.d/ named tomcat6 and pki-cad. I tried the following: - [Thu Jun 04 14:38:16:/etc/init.d]$ service tomcat6 status tomcat6 is stopped [ OK ] [Thu Jun 04 14:38:23:/etc/init.d]$ service tomcat6 start Starting tomcat6: [ OK ] [Thu Jun 04 14:38:29:/etc/init.d]$ service tomcat6 status tomcat6 (pid 10853) is running... [ OK ] [Thu Jun 04 14:38:40:/etc/init.d]$ service pki-cad status pki-ca (pid 1793) is running...[ OK ] Unsecure Port = http://chimera.server.com:9180/ca/ee/ca Secure Agent Port = https://chimera.server.com:9443/ca/agent/ca Secure EE Port = https://chimera.server.com:9444/ca/ee/ca Secure Admin Port = https://chimera.server.com:9445/ca/services EE Client Auth Port = https://chimera.server.com:9446/ca/eeca/ca PKI Console Port= pkiconsole https://chimera.server.com:9445/ca Tomcat Port = 9701 (for shutdown) PKI Instance Name: pki-ca PKI Subsystem Type: Root CA (Security Domain) Registered PKI Security Domain Information: == Name: IPA URL: https://chimera.server.com:443 == Ok, you didn't specify a version so I took a stab in the dark on the service name. So I gather you're running 3.0.0? You'll need to dive into the catalina.log and debug logs in /var/log/pki-ca. This means that tomcat started but the webapp didn't. This is usually the audit subsystem kicking in but recently someone else had this issue and a simple ipactl restart fixed it for him. rob - After this I am able to create new hosts on my Foreman server! There are now a few questions: 1. I am not sure why the tomcat6 service was stopped, if it is required to be running. 2. I am not sure why a reboot of the server did not auto-start tomcat6. 3. When navigating the web GUI for FreeIPA and clicking on a host, I still see the popup message in the subject of this thread. I have not yet tried rebooting the FreeIPA (chimera) and Puppet/Foreman (puppetmaster) servers yet. When I have some downtime I will try that and see what happens in regards to questions 2 and 3. Thanks, -Chris Tobey -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: June-04-15 10:35 AM To: Chris Tobey; 'Martin Kosek'; freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Apache proxies to dogtag, so a Not Found means that dogtag either isn't running or its webapp wasn't loaded. I'd start by restarting pki-tomcatd@pki-tomcat.service and see if that helps. Otherwise you'll need to poke around in the debug long in /var/lib/pki-ca/ 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 Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Hi Rob, Thanks for taking the time to look at this. I have services in /etc/init.d/ named tomcat6 and pki-cad. I tried the following: - [Thu Jun 04 14:38:16:/etc/init.d]$ service tomcat6 status tomcat6 is stopped [ OK ] [Thu Jun 04 14:38:23:/etc/init.d]$ service tomcat6 start Starting tomcat6: [ OK ] [Thu Jun 04 14:38:29:/etc/init.d]$ service tomcat6 status tomcat6 (pid 10853) is running... [ OK ] [Thu Jun 04 14:38:40:/etc/init.d]$ service pki-cad status pki-ca (pid 1793) is running...[ OK ] Unsecure Port = http://chimera.server.com:9180/ca/ee/ca Secure Agent Port = https://chimera.server.com:9443/ca/agent/ca Secure EE Port = https://chimera.server.com:9444/ca/ee/ca Secure Admin Port = https://chimera.server.com:9445/ca/services EE Client Auth Port = https://chimera.server.com:9446/ca/eeca/ca PKI Console Port= pkiconsole https://chimera.server.com:9445/ca Tomcat Port = 9701 (for shutdown) PKI Instance Name: pki-ca PKI Subsystem Type: Root CA (Security Domain) Registered PKI Security Domain Information: == Name: IPA URL: https://chimera.server.com:443 == - After this I am able to create new hosts on my Foreman server! There are now a few questions: 1. I am not sure why the tomcat6 service was stopped, if it is required to be running. 2. I am not sure why a reboot of the server did not auto-start tomcat6. 3. When navigating the web GUI for FreeIPA and clicking on a host, I still see the popup message in the subject of this thread. I have not yet tried rebooting the FreeIPA (chimera) and Puppet/Foreman (puppetmaster) servers yet. When I have some downtime I will try that and see what happens in regards to questions 2 and 3. Thanks, -Chris Tobey -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: June-04-15 10:35 AM To: Chris Tobey; 'Martin Kosek'; freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Apache proxies to dogtag, so a Not Found means that dogtag either isn't running or its webapp wasn't loaded. I'd start by restarting pki-tomcatd@pki-tomcat.service and see if that helps. Otherwise you'll need to poke around in the debug long in /var/lib/pki-ca/ 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] Sudo hangs after reenrollment of some servers in fresh IPA domain
Hi, please put the following line to /etc/sudo.conf to obtain sudo logs and send us the file: Debug sudo /var/log/sudo_debug all@trace - Original Message - > From: "Martin Kosek" > To: "Sina Owolabi" > Cc: "Cory Carlton" , freeipa-users@redhat.com, "Pavel > Brezina" , "Jakub > Hrozek" > Sent: Thursday, June 4, 2015 5:15:04 PM > Subject: Re: [Freeipa-users] Sudo hangs after reenrollment of some servers in > fresh IPA domain > > On 06/04/2015 05:13 PM, Sina Owolabi wrote: > > Hi Martin > > > > I have deleted everything in /var/lib/sss/db/ and restarted sssd, > > no luck. > > In that case, I am afraid you might need to enable sudo and SSSD debug > (https://fedorahosted.org/sssd/wiki/Troubleshooting) and see where it hans. > Also CCing sudo/sssd SMEs to be aware. > > > > > On Thu, Jun 4, 2015 at 4:10 PM, Martin Kosek wrote: > >> On 06/04/2015 05:06 PM, Cory Carlton wrote: > >>> I would check for DNS resolution from the machine executing the sudo, to > >>> the IPA server. > >> > >> I would also suggest cleaning SSSD caches, since you reinstalled against > >> the > >> same domain, but actually different server (/var/lib/sss/db/) > >> > >>> On Thu, Jun 4, 2015 at 9:54 AM, Sina Owolabi > >>> wrote: > >>> > Hi > > I recently had to remove and reinstall a fresh IPA server. I am > currently re-enrolling all the ipa clients to the recently refreshed > domain (same name as the previous realm and domain). The new IPA > master is RHEL7.1 with IPA 4.1.3. > > All client servers are running RHEL6.6. > > I also have sudorule that allows a group to have access to run all > commands on all servers: > > Rule name: All > Enabled: TRUE > Host category: all > Command category: all > User Groups: superusers > Sudo Option: !authenticate > > > I noticed that trying to run sudo on a few of the servers makes the > command hang indefinitely. > I am not sure what is the cause and where to look. Please what can I > do to troubleshoot and fix this? > > -- > 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] Fw: ssh problem with migrated FreeIPA client on EL7.1 -->Solved
Hi All
I can now report back success (at least on my throwaway EL7.1 test VM).
To switch an EL 7.1 + ipa-client 4.1 host from an old FreeIPA 3.3.3 KDC to
a new FreeIPA 4.1 KDC 3 steps are required:
1) ipa-client-install --uninstall
2) rm -f /var/lib/sss/db/*
3) ipa-client-install --server ldap.my.example.com --domain my.example.com
-N
Having done this, my free-ipa user successfully authenticates (e.g. ssh
remote login with free-ipa user / password
To switch EL 6.5 + ipa-client 3.3.3 hosts step 2) was not required.
Kudos and thanks go to Rob C for suggesting step 2. (Note that the
directory to be purged is /var/lib/sss/db/, not /var/lib/sssd/db/ as
suggested earlier in this thread.
Cheers
Chris
From: Martin Kosek
To: Christopher Lamb/Switzerland/IBM@IBMCH,
freeipa-users@redhat.com
Cc: Jakub Hrozek , Rob Crittenden
Date: 03.06.2015 10:39
Subject:Re: [Freeipa-users] Fw: ssh problem with migrated FreeIPA
client on EL7.1 -->Not Solved
On 06/03/2015 10:30 AM, Christopher Lamb wrote:
> Hi all
>
> This is a quick(ish) note to bring everybody up to speed on this issue.
> Yesterday we had some private mail exchange on this issue as I did not
wish
> to broadcast the krb5 and ipa install logs to the user list.
>
> The basic situation is that we are in the process of migrating from an
> FreeIPA 3.3.3 Server (KDC) to a new FreeIPA 4.1 Server (KDC). As
discussed
> in a thread some weeks ago we did not do this by replicating (as perhaps
we
> should have done). Instead we migrated the users across.
>
> We have 30+ servers that are IPA clients ("Hosts" in ipa-speak) joined to
> the old KDC. We are now in the process of migrating these hosts to the
new
> 4.1 KDC.
>
> Most of the hosts run EL 6.5 + ipa-client 3.3.3. For all of these
joining
> to the new KDC was trouble free, taking a few minutes each. After joining
> the new KDC FreeIPA users authenticated properly.
>
> We also had a small number of new EL 7.1 + ipa-client 4.1 hosts that were
> joined direct to the new 4.1 KDC, never having been joined of the 3.3.3
> KDC. These were also trouble free.
>
> The problem occurs with a handful of existing EL 7.1 +ipa-client 4.1
hosts
> that were originally joined to the 3.3.3 KDC, and must be moved to join
the
> 4.1 KDC. These machines no longer authenticate valid FreeIPA users. I
have
> been able to reproduce this behaviour with a freshly setup VM joined
first
> to the 3.3.3 KDC, then moved to the 4.1 KDC.
>
> While the errors show in the krb5 child logs indicate that the password
is
> incorrect, the same user / password is happily accepted by all the other
> hosts.
>
> It seems that in the process of moving / migrating the EL 7.1 /
ipa-client
> 4.1 from the old KDC to the new KDC, "something" is left behind that
causes
> problems. We have seen indications in the install logs that the kinit
steps
> called during ipa-client install are getting responses from the wrong
(old)
> KDC, and not from the new KDC.
>
> Frustratingly. over the weekend i managed to get one of the problem EL
7.1
> boxes to work. However I can't work out exactly what I was that I did
that
> did the trick. However it seems that some kind of major de-install /
> cleanup + reinstall of the ipa-client may be needed.
>
> Rob has suggested that as part of such a cleanup I should do "rm
> -f /var/lib/sssd/db/*". I will test this later today and report back.
>
> Thanks to Rob, Jakub, Martin, Alexander et al for their help and
> suggestions so far.
>
> Chris
Thanks for the background. The pain you are getting is exactly the reason
why
migration via replication to RHEL-7.1 is a better choice :-) Please let us
know
the result, I am curious how this works out.
>
>
>
>
> From: Martin Kosek
> To:Christopher Lamb/Switzerland/IBM@IBMCH,
> freeipa-users@redhat.com, Jakub Hrozek
> Date: 03.06.2015 09:34
> Subject: Re: [Freeipa-users] Fw: ssh problem with migrated
FreeIPA
> client on EL7.1 -->Not Solved
>
>
>
> On 06/02/2015 06:15 PM, Christopher Lamb wrote:
>>
>> Hi
>>
>> Earlier today I setup 2 throwaway EL7.1 VMs to help narrow down the
cause
>> of this problem. Let's call them HOST09 and HOST10
>>
>> Both are mimimum installs of EL7.1, with NTPD installed and configured.
>>
>> HOST09 had ipa-client 4.1 installed via yum, and was configured to use
> our
>> new FreeIPA 4.1 server, right from the start. --> My FreeIPA user
>> authenticates successfully against this machine.
>>
>> HOST10 had ipa-client 4.1 installed as a dependency of one of our
> standard
>> config packages, and was first set to use our old FreeIPA 3.3.3 server.
> -->
>> My FreeIPA user authenticates successfully. against this machine.
>>
>> I then de-registered HOST10 from the FreeIPA 3.1 server, and registered
>> against the new FreeIPA 4.1 server --> My FreeIPA users does NOT
>> authenticate successfully.
>>
>> This replicates well the behaviour I saw with my
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
On 06/04/2015 04:33 PM, Rob Crittenden wrote:
Thomas Sailer wrote:
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.
This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0x...
An entry with nsuniqueid is a replication conflict entry. You want to
resolve this.
See
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
Yes I know, and I have already fixed that.
The question is is it justified if the presence of such a group breaks
login. If yes, shouldn't there be a more obvious error message than ssh
telling you that login failed for UNKNOWN reasons...
If login would still work, it would buy you time for fixing the problem.
The way it is now, you have people filling your office complaining login
doesn't work anymore while you frantically try to figure out why.
My biggest wish for IPA is for it to become more robust. It consists of
many software components with complex interdependencies, so some
fragility is to be expected. But still, it would be nice if it was as
robust as possible and if it fails that it fails in more obvious ways...
2) I cannot change ssh keys, neither in the web gui nor on the cli.
# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xserver.x.com/ipa/json
ipa: INFO: Request: {
"id": 0,
"method": "ping",
"params": [
[],
{}
]
}
ipa: INFO: Response: {
"error": null,
"id": 0,
"principal": "ad...@x.com",
"result": {
"messages": [
{
"code": 13001,
"message": "API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114",
"name": "VersionMissing",
"type": "warning"
}
],
"summary": "IPA server version 4.1.4. API version 2.114"
},
"version": "4.1.4"
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xserver.x.com/ipa/json'
ipa: INFO: Request: {
"id": 0,
"method": "user_mod",
"params": [
[
"t.sailer"
],
{
"all": true,
"ipasshpubkey": null,
"no_members": false,
"random": false,
"raw": false,
"rights": false,
"version": "2.114"
}
]
}
ipa: INFO: Response: {
"error": {
"code": 4203,
"message": "Type or value exists: ",
"name": "DatabaseError"
},
"id": 0,
"principal": "ad...@x.com",
"result": null,
"version": "4.1.4"
}
ipa: ERROR: Type or value exists:
I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...
Hmm, curious. What is the current state of the entry? The 389-ds
access log might have more details (though I'm stretching here).
[04/Jun/2015:17:43:21 +0200] conn=3391 fd=70 slot=70 connection from
a.b.c.d to a.b.c.d
[04/Jun/2015:17:43:21 +0200] conn=3391 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[04/Jun/2015:17:43:21 +0200] conn=3391 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[04/Jun/2015:17:43:21 +0200] conn=3391 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=2 RESULT err=0 tag=97
nentries=0 etime=0 dn="uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com"
[04/Jun/2015:17:43:21 +0200] conn=3391 op=3 SRCH
base="cn=ipaconfig,cn=etc,dc=x,dc=com" scope=0
filter="(objectClass=*)" attrs=ALL
[04/Jun/2015:17:43:21 +0200] conn=3391 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=4 SRCH
base="uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com" scope=0
filter="(objectClass=*)" attrs="objectClass"
[04/Jun/2015:17:43:21 +0200] conn=3391 op=4 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=5 SRCH
base="uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com" scope=0
filter="(objectClass=*)" attrs="objectClass ipaSshPubKey"
[04/Jun/2015:17:43:21 +0200] conn=3391 op=5 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=6 MOD
dn="uid=t.sailer,cn=users,cn=a
Re: [Freeipa-users] IPA v3 Certificate not renewed
Hi Rob, i have only add NSSEnforceValidCerts off" to nss.conf. ipa run last 2 years without problem since the certificate expired. I loaded all the proxy modules in apache and restart httpd and certmonger. Yeah, the certificates are renew root@be-ipasrv httpd]# getcert list | grep status status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING [root@be-ipasrv httpd]# getcert list | grep expir expires: 2017-04-29 08:14:24 UTC expires: 2017-04-29 08:13:24 UTC expires: 2017-04-29 08:13:24 UTC expires: 2017-04-29 08:13:24 UTC expires: 2017-04-29 08:13:24 UTC expires: 2017-05-26 08:21:01 UTC expires: 2017-05-26 08:20:43 UTC expires: 2017-05-26 08:21:08 UTC the other server with centos 6.6 and ipa-server-3.0.0-42.el6.centos.x86_64 I get error Request ID '20130528090822': status: CA_UNREACHABLE ca-error: Server at https://EXAMPLE.de/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://EXAMPLE.de:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLEDE',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLEDE/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLEDE',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.DE subject: CN=EXAMPLE.de,O=EXAMPLE.DE expires: 2015-05-29 09:08:22 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130528090849': status: CA_UNREACHABLE ca-error: Server at https://EXAMPLE.de/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.DE subject: CN=EXAMPLE.de,O=EXAMPLE.DE expires: 2015-05-29 09:08:49 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130528090923': status: CA_UNREACHABLE ca-error: Server at https://EXAMPLE.de/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.DE subject: CN=EXAMPLE.de,O=EXAMPLE.DE expires: 2015-05-29 09:09:23 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes and http error log if i resubmit the id [Tue May 26 10:01:31 2015] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_ r:httpd_t:s0 [Tue May 26 10:01:31 2015] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue May 26 10:01:32 2015] [notice] ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) configured . [Tue May 26 10:01:32 2015] [notice] ModSecurity: APR compiled version="1.3.9"; loaded version="1.3.9" [Tue May 26 10:01:32 2015] [notice] ModSecurity: PCRE compiled version="7.8 "; loaded version="7.8 2008-0 9-05" [Tue May 26 10:01:32 2015] [notice] ModSecurity: LUA compiled version="Lua 5.1" [Tue May 26 10:01:32 2015] [notice] ModSecurity: LIBXML compiled version="2.7.6" [Tue May 26 10:01:32 2015] [notice] Digest: generating secret for digest authentication ... [Tue May 26 10:01:32 2015] [notice] Digest: done [Tue May 26 10:01:33 2015] [notice] Apache/2.2.15 (Unix) mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.16.1 Basi c ECC PHP/5.3.25 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations [Tue May 26 10:01:34 2015] [
Re: [Freeipa-users] Sudo hangs after reenrollment of some servers in fresh IPA domain
Hi Cory, DNS is fine. The IPA server is the internal domains DNS server, and the affected servers use it as easily as the other ipa clients. On Thu, Jun 4, 2015 at 4:06 PM, Cory Carlton wrote: > I would check for DNS resolution from the machine executing the sudo, to the > IPA server. > > On Thu, Jun 4, 2015 at 9:54 AM, Sina Owolabi wrote: >> >> Hi >> >> I recently had to remove and reinstall a fresh IPA server. I am >> currently re-enrolling all the ipa clients to the recently refreshed >> domain (same name as the previous realm and domain). The new IPA >> master is RHEL7.1 with IPA 4.1.3. >> >> All client servers are running RHEL6.6. >> >> I also have sudorule that allows a group to have access to run all >> commands on all servers: >> >> Rule name: All >> Enabled: TRUE >> Host category: all >> Command category: all >> User Groups: superusers >> Sudo Option: !authenticate >> >> >> I noticed that trying to run sudo on a few of the servers makes the >> command hang indefinitely. >> I am not sure what is the cause and where to look. Please what can I >> do to troubleshoot and fix this? >> >> -- >> 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] Sudo hangs after reenrollment of some servers in fresh IPA domain
On 06/04/2015 05:13 PM, Sina Owolabi wrote: > Hi Martin > > I have deleted everything in /var/lib/sss/db/ and restarted sssd, > no luck. In that case, I am afraid you might need to enable sudo and SSSD debug (https://fedorahosted.org/sssd/wiki/Troubleshooting) and see where it hans. Also CCing sudo/sssd SMEs to be aware. > > On Thu, Jun 4, 2015 at 4:10 PM, Martin Kosek wrote: >> On 06/04/2015 05:06 PM, Cory Carlton wrote: >>> I would check for DNS resolution from the machine executing the sudo, to >>> the IPA server. >> >> I would also suggest cleaning SSSD caches, since you reinstalled against the >> same domain, but actually different server (/var/lib/sss/db/) >> >>> On Thu, Jun 4, 2015 at 9:54 AM, Sina Owolabi wrote: >>> Hi I recently had to remove and reinstall a fresh IPA server. I am currently re-enrolling all the ipa clients to the recently refreshed domain (same name as the previous realm and domain). The new IPA master is RHEL7.1 with IPA 4.1.3. All client servers are running RHEL6.6. I also have sudorule that allows a group to have access to run all commands on all servers: Rule name: All Enabled: TRUE Host category: all Command category: all User Groups: superusers Sudo Option: !authenticate I noticed that trying to run sudo on a few of the servers makes the command hang indefinitely. I am not sure what is the cause and where to look. Please what can I do to troubleshoot and fix this? -- 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] Sudo hangs after reenrollment of some servers in fresh IPA domain
Hi Martin I have deleted everything in /var/lib/sss/db/ and restarted sssd, no luck. On Thu, Jun 4, 2015 at 4:10 PM, Martin Kosek wrote: > On 06/04/2015 05:06 PM, Cory Carlton wrote: >> I would check for DNS resolution from the machine executing the sudo, to >> the IPA server. > > I would also suggest cleaning SSSD caches, since you reinstalled against the > same domain, but actually different server (/var/lib/sss/db/) > >> On Thu, Jun 4, 2015 at 9:54 AM, Sina Owolabi wrote: >> >>> Hi >>> >>> I recently had to remove and reinstall a fresh IPA server. I am >>> currently re-enrolling all the ipa clients to the recently refreshed >>> domain (same name as the previous realm and domain). The new IPA >>> master is RHEL7.1 with IPA 4.1.3. >>> >>> All client servers are running RHEL6.6. >>> >>> I also have sudorule that allows a group to have access to run all >>> commands on all servers: >>> >>> Rule name: All >>> Enabled: TRUE >>> Host category: all >>> Command category: all >>> User Groups: superusers >>> Sudo Option: !authenticate >>> >>> >>> I noticed that trying to run sudo on a few of the servers makes the >>> command hang indefinitely. >>> I am not sure what is the cause and where to look. Please what can I >>> do to troubleshoot and fix this? >>> >>> -- >>> 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] Sudo hangs after reenrollment of some servers in fresh IPA domain
On 06/04/2015 05:06 PM, Cory Carlton wrote: > I would check for DNS resolution from the machine executing the sudo, to > the IPA server. I would also suggest cleaning SSSD caches, since you reinstalled against the same domain, but actually different server (/var/lib/sss/db/) > On Thu, Jun 4, 2015 at 9:54 AM, Sina Owolabi wrote: > >> Hi >> >> I recently had to remove and reinstall a fresh IPA server. I am >> currently re-enrolling all the ipa clients to the recently refreshed >> domain (same name as the previous realm and domain). The new IPA >> master is RHEL7.1 with IPA 4.1.3. >> >> All client servers are running RHEL6.6. >> >> I also have sudorule that allows a group to have access to run all >> commands on all servers: >> >> Rule name: All >> Enabled: TRUE >> Host category: all >> Command category: all >> User Groups: superusers >> Sudo Option: !authenticate >> >> >> I noticed that trying to run sudo on a few of the servers makes the >> command hang indefinitely. >> I am not sure what is the cause and where to look. Please what can I >> do to troubleshoot and fix this? >> >> -- >> 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] Sudo hangs after reenrollment of some servers in fresh IPA domain
I would check for DNS resolution from the machine executing the sudo, to the IPA server. On Thu, Jun 4, 2015 at 9:54 AM, Sina Owolabi wrote: > Hi > > I recently had to remove and reinstall a fresh IPA server. I am > currently re-enrolling all the ipa clients to the recently refreshed > domain (same name as the previous realm and domain). The new IPA > master is RHEL7.1 with IPA 4.1.3. > > All client servers are running RHEL6.6. > > I also have sudorule that allows a group to have access to run all > commands on all servers: > > Rule name: All > Enabled: TRUE > Host category: all > Command category: all > User Groups: superusers > Sudo Option: !authenticate > > > I noticed that trying to run sudo on a few of the servers makes the > command hang indefinitely. > I am not sure what is the cause and where to look. Please what can I > do to troubleshoot and fix this? > > -- > 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] IPA v3 Certificate not renewed
Junhe Jian wrote: Hi Rob, i set the date in past "26 MAY 2015" and add "NSSEnforceValidCerts off" to nss.conf and resubmit the 3 ID [root@be-ipasrv httpd]# getcert resubmit -i 20130528090822 Resubmitting "20130528090822" to "IPA". [root@be-ipasrv httpd]# getcert resubmit -i 20130528090849 Resubmitting "20130528090849" to "IPA". [root@be-ipasrv httpd]# getcert resubmit -i 20130528090923 Resubmitting "20130528090923" to "IPA". Restart ipa and certmonger now I get error in http_error [Tue May 26 10:00:30 2015] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Tue May 26 10:00:30 2015] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue May 26 10:00:31 2015] [notice] ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) configured. [Tue May 26 10:00:31 2015] [notice] ModSecurity: APR compiled version="1.3.9"; loaded version="1.3.9" [Tue May 26 10:00:31 2015] [notice] ModSecurity: PCRE compiled version="7.8 "; loaded version="7.8 2008-09-05" [Tue May 26 10:00:31 2015] [notice] ModSecurity: LUA compiled version="Lua 5.1" [Tue May 26 10:00:31 2015] [notice] ModSecurity: LIBXML compiled version="2.7.6" [Tue May 26 10:00:31 2015] [notice] Digest: generating secret for digest authentication ... [Tue May 26 10:00:31 2015] [notice] Digest: done [Tue May 26 10:00:32 2015] [notice] Apache/2.2.15 (Unix) mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.14.0.0 Basic ECC PHP/5.3.25 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations [Tue May 26 10:00:33 2015] [error] ipa: INFO: *** PROCESS START *** [Tue May 26 10:00:33 2015] [error] ipa: INFO: *** PROCESS START *** [Tue May 26 10:01:23 2015] [warn] proxy: No protocol handler was valid for the URL /ca/agent/ca/displayBySerial. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. [Tue May 26 10:01:23 2015] [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to communicate with CMS (Internal Server Error) Have you changed your apache configuration? It looks that way. You need the proxy modules loaded. 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 v3 Certificate not renewed
Hi Rob, i set the date in past "26 MAY 2015" and add "NSSEnforceValidCerts off" to nss.conf and resubmit the 3 ID [root@be-ipasrv httpd]# getcert resubmit -i 20130528090822 Resubmitting "20130528090822" to "IPA". [root@be-ipasrv httpd]# getcert resubmit -i 20130528090849 Resubmitting "20130528090849" to "IPA". [root@be-ipasrv httpd]# getcert resubmit -i 20130528090923 Resubmitting "20130528090923" to "IPA". Restart ipa and certmonger now I get error in http_error [Tue May 26 10:00:30 2015] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Tue May 26 10:00:30 2015] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue May 26 10:00:31 2015] [notice] ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) configured. [Tue May 26 10:00:31 2015] [notice] ModSecurity: APR compiled version="1.3.9"; loaded version="1.3.9" [Tue May 26 10:00:31 2015] [notice] ModSecurity: PCRE compiled version="7.8 "; loaded version="7.8 2008-09-05" [Tue May 26 10:00:31 2015] [notice] ModSecurity: LUA compiled version="Lua 5.1" [Tue May 26 10:00:31 2015] [notice] ModSecurity: LIBXML compiled version="2.7.6" [Tue May 26 10:00:31 2015] [notice] Digest: generating secret for digest authentication ... [Tue May 26 10:00:31 2015] [notice] Digest: done [Tue May 26 10:00:32 2015] [notice] Apache/2.2.15 (Unix) mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.14.0.0 Basic ECC PHP/5.3.25 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations [Tue May 26 10:00:33 2015] [error] ipa: INFO: *** PROCESS START *** [Tue May 26 10:00:33 2015] [error] ipa: INFO: *** PROCESS START *** [Tue May 26 10:01:23 2015] [warn] proxy: No protocol handler was valid for the URL /ca/agent/ca/displayBySerial. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. [Tue May 26 10:01:23 2015] [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to communicate with CMS (Internal Server Error) [Tue May 26 10:01:23 2015] [error] ipa: INFO: host/example...@example.de: cert_request(u'MIIDvjCCAqYCAQAwUDEhMB8GA1UEChMYVElCRVQuVFJBRkZJQ1MtU1dJVENILkRFMSswKQYDVQQDEyJiZS1pcGFzcnYudGliZXQudHJhZmZpY3Mtc3dpdGNoLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshxjlzWHlUYC262eB9BKIYu5mwTM2ncvHIibZwD+wrCp879Z+o6FRuV4jIg8iWo0gHqusuVSpRaGtHpKIXCwYcWU+ESYFZsPiuSXjjs9VmbgEmuM9Dz/4jIfVQXDAecGfcpDfLQxkMcRhaVaOHXwEGeM19xUig6s2kWa81T+TNwEKItNXmovQSpE+6cxpcT3rH00b89F/Z2vUIXagEJnJMuXEdqz3XpaXr6ahcYXgCSDq7L8VSd7zbguEpWZmD0lZ8857+tVXz6LBHryko3n5qyTpwFJ5M/hd6FoJyWTDulCKaF20sHsOBp+P18YcLUmR8pHjA9LQ4m/4dd5cG9yBwIDAQABoIIBJzAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwggEHBgkqhkiG9w0BCQ4xgfkwgfYwDgYDVR0PAQEABAQDAgTwMIHBBgNVHREBAQAEgbYwgbOgUAYKKwYBBAGCNxQCA6BCDEBsZGFwL2JlLWlwYXNydi50aWJldC50cmFmZmljcy1zd2l0Y2guZGVAVElCRVQuVFJBRkZJQ1MtU1dJVENILkRFoF8GBisGAQUCAqBVMFOgGhsYVElCRVQuVFJBRkZJQ1MtU1dJVENILkRFoTUwM6ADAgEBoSwwKhsEbGRhcBsiYmUtaXBhc3J2LnRpYmV0LnRyYWZmaWNzLXN3aXRjaC5kZTAgBgNVHSUBAQAEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAIX+XKk/Mxa0KN+rYikYjoaX6/VVj2eOI+O+nUe2CoFNz2r+r2HUb/lkl6+zOZpO3Stq+Qx/Bk8M230OFCigycz19Uxkmz5n5r8nxxtifWZUcC7wO+ZdEURUcDIfeg8lraBOsBWjiId+0TCVtuFJxbuNQkmy3lpt6uQoiDB4XB3/DbEYi9jWrXrtT4XpKrzaj6wsoxVJi1M2JsywFrzio7yhDLtUsXVmycwm5Kw1kQPELBQgCpkzpba85u2uvD2z9DZ/AykXcd0DLRmbNaFAKdg5E+8dN6IySp30Dqyfkoldhi4zKtMCurn2WBDO3A19BP52iwOXOgKKReiGJd2X0eM=', principal=u'ldap/example...@example.de', add=True): CertificateOperationError [Tue May 26 10:01:29 2015] [warn] proxy: No protocol handler was valid for the URL /ca/agent/ca/displayBySerial. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. [Tue May 26 10:01:29 2015] [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to communicate with CMS (Internal Server Error) [Tue May 26 10:01:29 2015] [error] ipa: INFO: host/example...@example.de: cert_request(u'MIIDzDCCArQCAQAwUDEhMB8GA1UEChMYVElCRVQuVFJBRkZJQ1MtU1dJVENILkRFMSswKQYDVQQDEyJiZS1pcGFzcnYudGliZXQudHJhZmZpY3Mtc3dpdGNoLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwb1hNjym7KUoL5Sdv5xsx1tn8W65DghiDdY9RKmqQik1QanWXVvhVCmvNgUeOmXkQBBRwZHRqKvV5JiZfnm1qvk/eHbujzzocmJITktP8uxDgugCe4XzBdNYckrFKvwRVkZVfv0vUuYtCoVTUOo9yH17pwvzywUTwCO0PXRcy+9Ch1NViLbuFrhynNXrNBf9s62nyRBgrexcHPU6QXZoFSmu75QKqh7pqddG9ngPdi+PTW+1RwOnGFSVStrb0KGfLBPY9yX8OaRbqCt0PmLlGW3jnzBm+UT4yiHeudGa2bt/LXRmGsaIz6uIJL4Gxdcx4eQJMUwSU3hApuEuObdplwIDAQABoIIBNTAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwggEVBgkqhkiG9w0BCQ4xggEGMIIBAjAOBgNVHQ8BAQAEBAMCBPAwgc0GA1UdEQEBAASBwjCBv6BWBgorBgEEAYI3FAIDoEgMRmRvZ3RhZ2xkYXAvYmUtaXBhc3J2LnRpYmV0LnRyYWZmaWNzLXN3aXRjaC5kZUBUSUJFVC5UUkFGRklDUy1TV0lUQ0guREWgZQYGKwYBBQICoFswWaAaGxhUSUJFVC5UUkFGRklDUy1TV0lUQ0guREWhOzA5oAMCAQGhMjAwGwpkb2d0YWdsZGFwGyJiZS1pcGFzcnYudGliZXQudHJhZmZpY3Mtc3dpdGNoLmRlMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAUl4xz38rDD1ocOtoRvv+y+SNkLONmgLtPgy3U7KFmsySEWkfwNrGIpgJg/RGgsRnNF
[Freeipa-users] Sudo hangs after reenrollment of some servers in fresh IPA domain
Hi I recently had to remove and reinstall a fresh IPA server. I am currently re-enrolling all the ipa clients to the recently refreshed domain (same name as the previous realm and domain). The new IPA master is RHEL7.1 with IPA 4.1.3. All client servers are running RHEL6.6. I also have sudorule that allows a group to have access to run all commands on all servers: Rule name: All Enabled: TRUE Host category: all Command category: all User Groups: superusers Sudo Option: !authenticate I noticed that trying to run sudo on a few of the servers makes the command hang indefinitely. I am not sure what is the cause and where to look. Please what can I do to troubleshoot and fix this? -- 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 v3 Certificate not renewed
Junhe Jian wrote: Hello everyone, I’m new here and have problem with IPA Server our single IPA Server all Certificate was expired. Autorenewal not worked, so I read the docu http://www.freeipa.org/page/IPA_2x_Certificate_Renewal and do manually my server is centos 6.4 [root@be-ipasrv ~]# rpm -qa | grep ipa ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-26.el6_4.4.x86_64 libipa_hbac-1.9.2-82.7.el6_4.x86_64 libipa_hbac-python-1.9.2-82.7.el6_4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 I change the Domain name to EXAMPLE The 5 CAs: dogtag-ipa-renew-agent get new certificate and has status MONITORING. Only the last 3 CA: IPA (dirv-slapd-PKI-IPA, dirv-slapd-EXAMPLE, /etc/httpd/alias) not renew, hab Status CA_UNREACHABLE Number of certificates and requests being tracked: 8. Request ID '20130528090810': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=CA Audit,O= EXAMPLE.DE expires: 2017-04-29 08:14:24 UTC pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130528090811': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=OCSP Subsystem,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130528090812': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=CA Subsystem,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130528090813': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=IPA RA,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20130528090814': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN= EXAMPLE.de,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130528090822': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicat
Re: [Freeipa-users] vSphere and freeIPA
Rees wrote:
If I applied the original vsphere_groupmod.ldif (with the %regsub()) is
there anything special I have to do to reapply the modification?
When I attempt to apply this ldif i just get an error message telling me
"type or value exists" and then when I run the steps you have, (creating
users, groups, assigning them to the group and then doing the search) i
don't get the uniqueMember attribute.
Only after I remove all but one users from the group does the ldapsearch
returns a uniqueMember attribute.
The ldif is for _adding_ values. You need to modify one, so you'll need
to tweak the ldif.
rob
Cheers,
Rees
On 2/06/2015 5:55 pm, Alexander Bokovoy wrote:
On Tue, 02 Jun 2015, Martin Kosek wrote:
CCing Nalin and Alexander. This sounds like the slapi-nis
configuration for generating uniqueMember attribute does not work
with multi-valued "member" attribute:
schema-compat-entry-attribute:
uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")
No, this should work just fine. The original wiki page had just
%regsub() which is indeed a single element replacement. %mregsub()
processes multiple possible expression matching.
--
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 Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Chris Tobey wrote: Hi Martin, Thank you for the response. Here is what I can see on my FreeIPA server (I replaced my server name with server.com): [Wed Jun 03 10:05:36:..//var/lib/pki-ca]$ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) [Wed Jun 03 10:05:47:..//var/lib/pki-ca]$ getcert list Number of certificates and requests being tracked: 8. Request ID '20150407214802': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='303912620731' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=SERVER.COM subject: CN=CA Audit,O=SERVER.COM expires: 2017-03-27 21:47:14 UTC key usage: digitalSignature,nonRepudiation pre-save command: post-save command: track: yes auto-renew: yes Apache proxies to dogtag, so a Not Found means that dogtag either isn't running or its webapp wasn't loaded. I'd start by restarting pki-tomcatd@pki-tomcat.service and see if that helps. Otherwise you'll need to poke around in the debug long in /var/lib/pki-ca/ 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] freeipa server upgrade from fedora 20 to fedora 22 glitches
Thomas Sailer wrote:
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.
This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0x...
An entry with nsuniqueid is a replication conflict entry. You want to
resolve this.
See
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
2) I cannot change ssh keys, neither in the web gui nor on the cli.
# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xserver.x.com/ipa/json
ipa: INFO: Request: {
"id": 0,
"method": "ping",
"params": [
[],
{}
]
}
ipa: INFO: Response: {
"error": null,
"id": 0,
"principal": "ad...@x.com",
"result": {
"messages": [
{
"code": 13001,
"message": "API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114",
"name": "VersionMissing",
"type": "warning"
}
],
"summary": "IPA server version 4.1.4. API version 2.114"
},
"version": "4.1.4"
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xserver.x.com/ipa/json'
ipa: INFO: Request: {
"id": 0,
"method": "user_mod",
"params": [
[
"t.sailer"
],
{
"all": true,
"ipasshpubkey": null,
"no_members": false,
"random": false,
"raw": false,
"rights": false,
"version": "2.114"
}
]
}
ipa: INFO: Response: {
"error": {
"code": 4203,
"message": "Type or value exists: ",
"name": "DatabaseError"
},
"id": 0,
"principal": "ad...@x.com",
"result": null,
"version": "4.1.4"
}
ipa: ERROR: Type or value exists:
I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...
Hmm, curious. What is the current state of the entry? The 389-ds access
log might have more details (though I'm stretching here).
3) Is
[global]
debug=True
in /etc/ipa/ipa.conf supposed to change /var/log/httpd/error_log output?
I cannot see any change...
No, there is no /etc/ipa/ipa.conf.
You can create /etc/ipa/server.conf to only change configuration for the
server, or /etc/ipa/client.conf to only change configuration for the client.
default.conf is loaded first, then server/client.conf is loaded and
changes override the default.
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
[Freeipa-users] IPA v3 Certificate not renewed
Hello everyone, I'm new here and have problem with IPA Server our single IPA Server all Certificate was expired. Autorenewal not worked, so I read the docu http://www.freeipa.org/page/IPA_2x_Certificate_Renewal and do manually my server is centos 6.4 [root@be-ipasrv ~]# rpm -qa | grep ipa ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-26.el6_4.4.x86_64 libipa_hbac-1.9.2-82.7.el6_4.x86_64 libipa_hbac-python-1.9.2-82.7.el6_4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 I change the Domain name to EXAMPLE The 5 CAs: dogtag-ipa-renew-agent get new certificate and has status MONITORING. Only the last 3 CA: IPA (dirv-slapd-PKI-IPA, dirv-slapd-EXAMPLE, /etc/httpd/alias) not renew, hab Status CA_UNREACHABLE Number of certificates and requests being tracked: 8. Request ID '20130528090810': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=CA Audit,O= EXAMPLE.DE expires: 2017-04-29 08:14:24 UTC pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130528090811': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=OCSP Subsystem,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130528090812': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=CA Subsystem,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130528090813': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN=IPA RA,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20130528090814': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='379816045864' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O= EXAMPLE.DE subject: CN= EXAMPLE.de,O= EXAMPLE.DE expires: 2017-04-29 08:13:24 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130528090822': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd- EXAMPLE -DE',nickname='S
[Freeipa-users] FreeIPA clean removal and re-install on replacement VM.
Hi everyone, I've taken over a FreeIPA 3.0.0. server (only one, no mirrors) running on Centos 6 that is incredibly broken. I've already tried a lot of troubleshooting etc and setting up a mirror, but I just can't seem to get rid of the issue. As such I have basically decided to de-commision the server and start fresh on a new VM with a clean Centos and FreeIPA install. I'm not 100% sure what would be the best way to proceed though, as we have many clients that are already configured to use the existing server. The config files etc are intact on the existing server, so I can reference them when doing the configuration. I just need some guidance on how to proceed so that I can achieve this with the least amount of clashes/downtime. Here is a short sample of what has been happening: sudo ipactl status Directory Service: RUNNING- Unresponsive for almost 10 minutes - then carries on - KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING ADTRUST Service: RUNNING EXTID Service: RUNNING [mbu.example@freeipa ~]$ kinit mbu.example kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials sudo ipactl restart Restarting Directory Service Shutting down dirsrv: EXAMPLE-EXAM... [FAILED] PKI-IPA... [ OK ] *** Error: 1 instance(s) unsuccessfully stopped [FAILED] Starting dirsrv: EXAMPLE-EXAM ... already running [ OK ] PKI-IPA... [ OK ] Failed to restart Directory Service: Regards, Walter -- 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] sssd not caching public keys in sss_authorized_keys file
On (03/06/15 11:48), nat...@nathanpeters.com wrote: >> On Wed, 2015-06-03 at 09:57 -0700, nat...@nathanpeters.com wrote: >>> Comments inline >>> >>> > On (02/06/15 15:25), nat...@nathanpeters.com wrote: >>> >>I am running FreeIPA 4.1.3 on CentOS 7 for the server and on the >>> client >>> >> is >>> >>CentOS 6.5 with client 3.0.0-42 (sssd 1.11.6-30). >>> >> >>> >>I have created a user in FreeIPA and he has access to a server through >>> >>HBAC rules. This user has created a public / private keypair and >>> >> uploaded >>> >>the public key from his personal machine to the IPA server so it shows >>> up >>> >>in his user record. The record was saved and he successfully logged >>> into >>> >>the IPA client using the keys. >>> >> >>> >>According to the docs here (Yes, I know it's a little old but I could >>> not >>> >>find any newer info that conflicted with this) : >>> >>https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/openssh-sssd.html >>> >> >>> > Aa you already notice it isquite old documetation. >>> > >>> >>2.Stores the user key in a custom file, .ssh/sss_authorized_keys, in >>> the >>> >>standard authorized keys format. >>> >> >>> > There's bug in documentation. >>> > >>> >>However, when he logs in, there is no sss_authorized_keys file created >>> >> and >>> >>as far as I can tell, the key is never cached in his account. >>> >> >>> > The better test would be to authenticate with ssh keys online, >>> > so they can be fetched from FreeIPA >>> > then block connection to FreeIPA (simmulate offline state) >>> > and re-test one more time. >>> >>> Ok, so I looked at the newer documentation you linked below (RH7 >>> version) >>> and it makes the exact same statement "Stores the user key in a custom >>> file, .ssh/sss_authorized_keys, in the standard authorized keys format. >>> " >>> >>> Are you saying the newer documentation is also bugged? >>> >>> Unfortunately, that type of test will not be conclusive for the people I >>> am trying to convince. They want me to actually show them the file on >>> disk where that thing is cached to prove that if the machine was >>> rebooted, >>> and the ipa connection is lost, that key was not only in memory >>> somewhere >>> but actually saved to storage. >>> >>> > >>> >>How do I get the keys to actually save on login like the manual says? >>> > Keys are already cached in different file >>> > /var/lib/sss/pubconf/known_hosts. >>> > @see rhel7 documentation [1] >>> >>> The known_hosts file does not sound like the right place, It has a >>> completely different function of caching host keys for when I make an >>> outgoing connection from the server for the purpose of verifying someone >>> is not spoofing a host, not for caching individual user keys for >>> passwordless login for when I'm trying to make an ingoing connection to >>> the server. >>> >>> In addition, you can see from my search below that there is no >>> sss_authorized_keys file anywhere on the server and that the known_hosts >>> file you referenced has no data in it because it is zero size. >>> >>> [root@ipaclient sss]# find / -name sss_authorized_keys >>> [root@ipaclient sss]# cd pubconf >>> [root@ipaclient pubconf]# ls -al >>> total 16 >>> drwxr-xr-x 3 root root 4096 Jun 3 16:42 . >>> drwxr-xr-x 6 root root 4096 May 27 22:49 .. >>> -rw-r--r-- 1 root root 11 Jun 3 16:42 kdcinfo.MYDOMAIN.NET >>> -rw-r--r-- 1 root root0 Jun 2 16:05 known_hosts >>> drwxr-xr-x 2 root root 4096 May 28 01:13 krb5.include.d >>> [root@ipaclient pubconf]# >>> >>> So... I am still looking for the actual location on disk that this is >>> apparently being cached and cannot find it. >> >> You won't find a "file" because user's public keys are not stored in a >> file. >> They are stored in the ldb cache with all other user information, and >> then extracted from the cache (or queried from the server if online and >> the cache is expired) on request. >> >> You can use the ldbsearch tool against the sssd ldb cache file and look >> for entries with the sshPublicKey attribute. >> >> HTH, >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> > >Oh this is great information. Thank you. > >It appears that the documentation should state that the user keys are >cached not in .ssh/sss_authorized_keys I didn't notice it in documentation. We fixed info about known_hosts. Thank you for a report. >but actually in >/var/lib/sss/db/cache_yourdomain.ldb as I was able to search and >successfully find the user key by running 'ldbsearch -H >cache_mydomain.net.ldb sshPublicKey' Simpler way for checking cached public ssh key is to use the same utility as sssd/sshd # go offline and run next command. sh$ sss_ssh_authorizedkeys usersssd LS -- 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
