[Freeipa-users] Centos IPA Client fails after upgrade to 6.6

Michael Lasevich mlasevich at gmail.com
Sat Nov 8 00:00:19 UTC 2014


Exactly 16 hours after reboot the problem returned on both servers. What
has a 16 hour timeout?

I set log level to 10 and got some logs, but they are long and not sure
what I am looking for. I am attaching some logs ( out of sheer paranoia I
have slightly sanitized them, 1.1.1.2 is the secondary IPA server,
username at MY.DOMAIN.COM is the principle and endserver.my.domain.com is the
IPA client this is happening on)



On Fri, Nov 7, 2014 at 1:18 AM, Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Thu, Nov 06, 2014 at 09:33:35PM -0800, Michael Lasevich wrote:
> > For what its worth, my issue was resolved when I rebooted the server.
> >
> > Restarting sssd and/or clearing it's cache did not do it, but a full
> reboot
> > seems to have done it. Something much have been cached or some temp file
> I
> > missed. Will need to look into it further as I have a number of servers
> yet
> > to be upgraded and having to reboot linux servers to do an upgrade seem
> > sacrilegious...
>
> We need to see the krb5_child.log file ideally with a very high
> debug_level (10 would enable KRB5_TRACE debugging as well..)
>
> >
> > -M
> >
> > On Thu, Nov 6, 2014 at 9:26 PM, David Taylor <david.taylor at speedcast.com
> >
> > wrote:
> >
> > >  As an add on, I’ve upgraded our Xen template to 6.6 and run up a new
> VM
> > > using that and it attaches to the IPA environment perfectly well, so
> I’m
> > > guessing it is an issue with the upgrade scripts.
> > >
> > >
> > >
> > >
> > >
> > > Best regards
> > >
> > > *David Taylor*
> > >
> > >  *From:* Michael Lasevich [mailto:mlasevich at gmail.com]
> > > *Sent:* Friday, 7 November 2014 4:00 PM
> > > *To:* Jakub Hrozek
> > > *Cc:* David Taylor; freeipa-users at redhat.com
> > > *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade to
> > > 6.6
> > >
> > >
> > >
> > > I am seeing somewhat similar behavior once upgrading from sssd 1.9 to
> 1.11
> > > (centos 6.5 to 6.6)
> > >
> > >
> > >
> > > I seem to be able to log in via ssh, but when I use http pam service, I
> > > get inconsistent behavior - seems like sometimes it works and others it
> > > errors out (success and failure can happen within a second)
> > >
> > >
> > >
> > > In the logs I see things like:
> > >
> > >
> > >
> > > [sssd[krb5_child[15410]]]: Internal credentials cache error
> > >
> > > and
> > >
> > > authentication failure; logname= uid=48 euid=48 tty= ruser= rhost=
> > > user=username
> > > received for user username: 4 (System error)
> > >
> > > Nothing in the audit.log that I can see
> > >
> > > I am guessing this is an sssd issue but I am hoping someone here knows
> how
> > > to deal with it.
> > >
> > > IN case it matters - here is the pam config:
> > >
> > > auth        required      pam_env.so
> > > auth        sufficient    pam_sss.so
> > > auth        required      pam_deny.so
> > >
> > > account     [default=bad success=ok user_unknown=ignore] pam_sss.so
> > > account     required      pam_permit.so
> > >
> > > password    requisite     pam_cracklib.so try_first_pass retry=3 type=
> > > password    sufficient    pam_sss.so use_authtok
> > > password    required      pam_deny.so
> > >
> > >
> > >
> > > session     optional      pam_keyinit.so revoke
> > > session     required      pam_limits.so
> > > session     optional      pam_oddjob_mkhomedir.so
> > > session     [success=1 default=ignore] pam_succeed_if.so service in
> crond
> > > quiet use_uid
> > > session     optional      pam_sss.so
> > >
> > > -M
> > >
> > >
> > >
> > > On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek <jhrozek at redhat.com>
> wrote:
> > >
> > >  On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote:
> > > > Thanks for the reply. The PAM file is pretty stock for a centos build
> > > >
> > > > #%PAM-1.0
> > > > # This file is auto-generated.
> > > > # User changes will be destroyed the next time authconfig is run.
> > > > auth        required      pam_env.so
> > > > auth        sufficient    pam_unix.so nullok try_first_pass
> > > > auth        requisite     pam_succeed_if.so uid >= 500 quiet
> > > > auth        sufficient    pam_sss.so use_first_pass
> > > > auth        required      pam_deny.so
> > > >
> > > > account     required      pam_unix.so
> > > > account     sufficient    pam_localuser.so
> > > > account     sufficient    pam_succeed_if.so uid < 500 quiet
> > > > account     [default=bad success=ok user_unknown=ignore] pam_sss.so
> > > > account     required      pam_permit.so
> > > >
> > > > password    requisite     pam_cracklib.so try_first_pass retry=3
> type=
> > > > password    sufficient    pam_unix.so sha512 shadow nullok
> > > try_first_pass use_authtok
> > > > password    sufficient    pam_sss.so use_authtok
> > > > password    required      pam_deny.so
> > > >
> > > > session     optional      pam_keyinit.so revoke
> > > > session     required      pam_limits.so
> > > > session     [success=1 default=ignore] pam_succeed_if.so service in
> > > crond quiet use_uid
> > > > session     required      pam_unix.so
> > > > session     optional      pam_sss.so
> > > >
> > > >
> > > > Best regards
> > > > David Taylor
> > >
> > > OK, so pam_sss is there ...
> > >
> > > And yet you see no mention of pam_sss.so in /var/log/secure ?
> > >
> > > Is this the file that was included from the service-specific PAM
> > > configuration?
> > >
> > >
> > > --
> > > 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
> > >
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141107/26604160/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_child.log
Type: application/octet-stream
Size: 364993 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141107/26604160/attachment.obj>


More information about the Freeipa-users mailing list