Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Rob Crittenden 

Christian Hernandez wrote:

Looks like I've narrowed it down to...something...

[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage list ipa1.gln.4over.com 
Failed to get data from 'ipa1.gln.4over.com
': Invalid credentials SASL(-13):
authentication failure: GSSAPI Failure: gss_accept_sec_context
[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage list ipa1.da2.4over.com 
ipa1.gln.4over.com : replica
ipa1.la3.4over.com : replica
[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage list $(hostname)
ipa1.da2.4over.com : replica
ipa1.gln.4over.com : replica
[r...@ipa1.la3.4over.com  ~]# rpm -qa
|egrep '389|ipa'
ipa-admintools-3.0.0-26.el6_4.2.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-python-3.0.0-26.el6_4.2.x86_64
libipa_hbac-python-1.9.2-82.4.el6_4.x86_64
389-ds-base-libs-1.2.11.15-12.el6_4.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-server-selinux-3.0.0-26.el6_4.2.x86_64
libipa_hbac-1.9.2-82.4.el6_4.x86_64
ipa-client-3.0.0-26.el6_4.2.x86_64
389-ds-base-1.2.11.15-12.el6_4.x86_64
ipa-server-3.0.0-26.el6_4.2.x86_64

Although when I try to remove the replication agreement...I can't =\

[r...@ipa1.la3.4over.com  ~]#
ipa-replica-manage disconnect $(hostname) ipa1.gln.4over.com

Failed to get list of agreements from 'ipa1.gln.4over.com
': Invalid credentials SASL(-13):
authentication failure: GSSAPI Failure: gss_accept_sec_context


A couple of things to try:

- Check the KDC logs on the various hosts to see what error it is 
logging trying to get a ticket.
- kdestroy and let ipa-replica-manage prompt you for the DM password, or 
pass it via -p on the command-line


The first might tell you why you are seeing an auth failure, the second 
should show the status of replication and let you run other commands. 
I'm not sure that disconnecting is going to fix anything though. I'm not 
sure what it is you're trying to do there.


rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Christian Hernandez 
Looks like I've narrowed it down to...something...

[r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.gln.4over.com
Failed to get data from 'ipa1.gln.4over.com': Invalid credentials
SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
[r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.da2.4over.com
ipa1.gln.4over.com: replica
ipa1.la3.4over.com: replica
[r...@ipa1.la3.4over.com ~]# ipa-replica-manage list $(hostname)
ipa1.da2.4over.com: replica
ipa1.gln.4over.com: replica
[r...@ipa1.la3.4over.com ~]# rpm -qa |egrep '389|ipa'
ipa-admintools-3.0.0-26.el6_4.2.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-python-3.0.0-26.el6_4.2.x86_64
libipa_hbac-python-1.9.2-82.4.el6_4.x86_64
389-ds-base-libs-1.2.11.15-12.el6_4.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-server-selinux-3.0.0-26.el6_4.2.x86_64
libipa_hbac-1.9.2-82.4.el6_4.x86_64
ipa-client-3.0.0-26.el6_4.2.x86_64
389-ds-base-1.2.11.15-12.el6_4.x86_64
ipa-server-3.0.0-26.el6_4.2.x86_64

Although when I try to remove the replication agreement...I can't =\

[r...@ipa1.la3.4over.com ~]# ipa-replica-manage disconnect $(hostname)
ipa1.gln.4over.com
Failed to get list of agreements from 'ipa1.gln.4over.com': Invalid
credentials SASL(-13): authentication failure: GSSAPI Failure:
gss_accept_sec_context


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 6:58 PM, Christian Hernandez
wrote:

> Yes; I verified that both forward and reverse DNS match on all nodes.
>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> www.4over.com 
>
>
> On Mon, Apr 15, 2013 at 6:21 PM, Dmitri Pal  wrote:
>
>>  On 04/15/2013 08:41 PM, Christian Hernandez wrote:
>>
>> Yup, looks like replication is broken =\
>>
>> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect
>> ipa1.la3.4over.com
>> Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid
>> credentials SASL(-13): authentication failure: GSSAPI Failure:
>> gss_accept_sec_context
>>
>> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com
>> Failed to get data from 'ipa1.la3.4over.com': Invalid credentials
>> SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
>>
>> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list
>> ipa1.la3.4over.com: master
>> ipa1.gln.4over.com: master
>> ipa1.da2.4over.com: master
>>
>>
>>
>> Do the machines resolve each other correctly?
>>
>>
>>
>>
>> Thank you,
>>
>> Christian Hernandez
>>  1225 Los Angeles Street
>> Glendale, CA 91204
>> Phone: 877-782-2737 ext. 4566
>> Fax: 818-265-3152
>> christi...@4over.com 
>> www.4over.com 
>>
>>
>> On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez <
>> christi...@4over.com> wrote:
>>
>>>  Okay,
>>>
>>> So I tried to update to the newest version. Update went okay and users
>>> can authenticate (as far as I can tell)...
>>>
>>> But I think may be replication broke?
>>>
>>> [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
>>> ipa1.gln.4over.com
>>> Invalid password
>>>
>>>  Any ideas?
>>>
>>>
>>> Thank you,
>>>
>>> Christian Hernandez
>>>  1225 Los Angeles Street
>>> Glendale, CA 91204
>>> Phone: 877-782-2737 ext. 4566
>>> Fax: 818-265-3152
>>> christi...@4over.com 
>>> www.4over.com 
>>>
>>>
>>>   On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek wrote:
>>>
 On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
 > There are some odd errors in ldap_child.log but it seems to cover a
 > later period than the other logs (not being able to bind using its
 > keytab is a bad thing).
 >
 > I think what you'll want to do, and this may be relatively tough, is
 > try to correlate these failures with the 389-ds access log and the
 > KDC logs to see if there are equivalent failures at around the same
 > times.

  I agree, the ldap_child failing usually indicates an issue with the
 keytab and/or the KDC. The ldap_child functionality is roughly
 equivalent to
 "kinit -k".

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

>>>
>>>
>>
>>
>> ___
>> Freeipa-users mailing 
>> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> ---
>> Looking to carve out IT costs?www.redha

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Christian Hernandez 
Yes; I verified that both forward and reverse DNS match on all nodes.


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 6:21 PM, Dmitri Pal  wrote:

>  On 04/15/2013 08:41 PM, Christian Hernandez wrote:
>
> Yup, looks like replication is broken =\
>
> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect
> ipa1.la3.4over.com
> Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid
> credentials SASL(-13): authentication failure: GSSAPI Failure:
> gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com
> Failed to get data from 'ipa1.la3.4over.com': Invalid credentials
> SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list
> ipa1.la3.4over.com: master
> ipa1.gln.4over.com: master
> ipa1.da2.4over.com: master
>
>
>
> Do the machines resolve each other correctly?
>
>
>
>
> Thank you,
>
> Christian Hernandez
>  1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> www.4over.com 
>
>
> On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez  > wrote:
>
>>  Okay,
>>
>> So I tried to update to the newest version. Update went okay and users
>> can authenticate (as far as I can tell)...
>>
>> But I think may be replication broke?
>>
>> [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
>> ipa1.gln.4over.com
>> Invalid password
>>
>>  Any ideas?
>>
>>
>> Thank you,
>>
>> Christian Hernandez
>>  1225 Los Angeles Street
>> Glendale, CA 91204
>> Phone: 877-782-2737 ext. 4566
>> Fax: 818-265-3152
>> christi...@4over.com 
>> www.4over.com 
>>
>>
>>   On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek wrote:
>>
>>> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
>>> > There are some odd errors in ldap_child.log but it seems to cover a
>>> > later period than the other logs (not being able to bind using its
>>> > keytab is a bad thing).
>>> >
>>> > I think what you'll want to do, and this may be relatively tough, is
>>> > try to correlate these failures with the 389-ds access log and the
>>> > KDC logs to see if there are equivalent failures at around the same
>>> > times.
>>>
>>>  I agree, the ldap_child failing usually indicates an issue with the
>>> keytab and/or the KDC. The ldap_child functionality is roughly
>>> equivalent to
>>> "kinit -k".
>>>
>>> ___
>>> Freeipa-users mailing list
>>> Freeipa-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>
>>
>
>
> ___
> Freeipa-users mailing 
> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to carve out IT costs?www.redhat.com/carveoutcosts/
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Dmitri Pal 
On 04/15/2013 08:41 PM, Christian Hernandez wrote:
> Yup, looks like replication is broken =\
>
> [r...@ipa1.gln.4over.com  ipa]#
> ipa-replica-manage disconnect ipa1.la3.4over.com
> 
> Failed to get list of agreements from 'ipa1.la3.4over.com
> ': Invalid credentials SASL(-13):
> authentication failure: GSSAPI Failure: gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com  ipa]#
> ipa-replica-manage list ipa1.la3.4over.com 
> Failed to get data from 'ipa1.la3.4over.com
> ': Invalid credentials SASL(-13):
> authentication failure: GSSAPI Failure: gss_accept_sec_context
>
> [r...@ipa1.gln.4over.com  ipa]#
> ipa-replica-manage list
> ipa1.la3.4over.com : master
> ipa1.gln.4over.com : master
> ipa1.da2.4over.com : master


Do the machines resolve each other correctly?

>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> >
> www.4over.com   >
>
>
> On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez
> mailto:christi...@4over.com>> wrote:
>
> Okay,
>
> So I tried to update to the newest version. Update went okay and
> users can authenticate (as far as I can tell)...
>
> But I think may be replication broke?
>
> [r...@ipa1.da2.4over.com  log]#
> ipa-replica-manage force-sync  --from=ipa1.gln.4over.com
>  
> Invalid password
>
> Any ideas?
>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> >
> www.4over.com   >
>
>
> On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek  > wrote:
>
> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
> > There are some odd errors in ldap_child.log but it seems to
> cover a
> > later period than the other logs (not being able to bind
> using its
> > keytab is a bad thing).
> >
> > I think what you'll want to do, and this may be relatively
> tough, is
> > try to correlate these failures with the 389-ds access log
> and the
> > KDC logs to see if there are equivalent failures at around
> the same
> > times.
>
> I agree, the ldap_child failing usually indicates an issue
> with the
> keytab and/or the KDC. The ldap_child functionality is roughly
> equivalent to
> "kinit -k".
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com 
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Christian Hernandez 
Yup, looks like replication is broken =\

[r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect
ipa1.la3.4over.com
Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid
credentials SASL(-13): authentication failure: GSSAPI Failure:
gss_accept_sec_context

[r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com
Failed to get data from 'ipa1.la3.4over.com': Invalid credentials
SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

[r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list
ipa1.la3.4over.com: master
ipa1.gln.4over.com: master
ipa1.da2.4over.com: master


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez
wrote:

> Okay,
>
> So I tried to update to the newest version. Update went okay and users can
> authenticate (as far as I can tell)...
>
> But I think may be replication broke?
>
> [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
> ipa1.gln.4over.com
> Invalid password
>
> Any ideas?
>
>
> Thank you,
>
> Christian Hernandez
> 1225 Los Angeles Street
> Glendale, CA 91204
> Phone: 877-782-2737 ext. 4566
> Fax: 818-265-3152
> christi...@4over.com 
> www.4over.com 
>
>
> On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek  wrote:
>
>> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
>> > There are some odd errors in ldap_child.log but it seems to cover a
>> > later period than the other logs (not being able to bind using its
>> > keytab is a bad thing).
>> >
>> > I think what you'll want to do, and this may be relatively tough, is
>> > try to correlate these failures with the 389-ds access log and the
>> > KDC logs to see if there are equivalent failures at around the same
>> > times.
>>
>> I agree, the ldap_child failing usually indicates an issue with the
>> keytab and/or the KDC. The ldap_child functionality is roughly equivalent
>> to
>> "kinit -k".
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Christian Hernandez 
Okay,

So I tried to update to the newest version. Update went okay and users can
authenticate (as far as I can tell)...

But I think may be replication broke?

[r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync  --from=
ipa1.gln.4over.com
Invalid password

Any ideas?


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek  wrote:

> On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
> > There are some odd errors in ldap_child.log but it seems to cover a
> > later period than the other logs (not being able to bind using its
> > keytab is a bad thing).
> >
> > I think what you'll want to do, and this may be relatively tough, is
> > try to correlate these failures with the 389-ds access log and the
> > KDC logs to see if there are equivalent failures at around the same
> > times.
>
> I agree, the ldap_child failing usually indicates an issue with the
> keytab and/or the KDC. The ldap_child functionality is roughly equivalent
> to
> "kinit -k".
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Jakub Hrozek 
On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote:
> There are some odd errors in ldap_child.log but it seems to cover a
> later period than the other logs (not being able to bind using its
> keytab is a bad thing).
> 
> I think what you'll want to do, and this may be relatively tough, is
> try to correlate these failures with the 389-ds access log and the
> KDC logs to see if there are equivalent failures at around the same
> times.

I agree, the ldap_child failing usually indicates an issue with the
keytab and/or the KDC. The ldap_child functionality is roughly equivalent to
"kinit -k".

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Christian Hernandez 
We are running 1.9.2

Looks like 3.0 is available for my build of CentOS ~ Any suggestions on how
to proceed to updating? Is Multimaster replication "sustained" during
updating?


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Apr 15, 2013 at 11:29 AM, Rob Crittenden wrote:

> Christian Hernandez wrote:
>
>> Hello,
>>
>>  From time to time we are getting complaints that I can sum up as "I
>> cannot log in to server X"
>>
>> Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ...
>>
>> /(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler] (0x0100): Got request with the following data
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): command: PAM_ACCT_MGMT
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): domain: 4OVER.COM 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): user: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): service: vsftpd
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): tty: ftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): ruser: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): rhost: mammoth.4over.com
>> 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): priv: 1
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): cli_pid: 17841
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule
>> [allow_all]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, )
>> [Success]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success)
>> [Success]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Sending result [0][4OVER.COM
>> ]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler_callback] (0x0100): Sent result [0][4OVER.COM
>> ]
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [be_pam_handler] (0x0100): Got request with the following data
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): command: PAM_SETCRED
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): domain: 4OVER.COM 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): user: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): service: vsftpd
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): tty: ftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): ruser: tradeftp
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): rhost: mammoth.4over.com
>> 
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): authtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok type: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>>
>> [pam_print_data] (0x0100): newauthtok size: 0
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): priv: 1
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [pam_print_data] (0x0100): cli_pid: 17841
>> (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
>> [be_pam_h

Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe

2013-04-15 Thread Rob Crittenden 

Christian Hernandez wrote:

Hello,

 From time to time we are getting complaints that I can sum up as "I
cannot log in to server X"

Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ...

/(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler] (0x0100): Got request with the following data
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): command: PAM_ACCT_MGMT
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): domain: 4OVER.COM 
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): user: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): service: vsftpd
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): tty: ftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): ruser: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): rhost: mammoth.4over.com

(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): priv: 1
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): cli_pid: 17841
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, )
[Success]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success)
[Success]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Sending result [0][4OVER.COM
]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler_callback] (0x0100): Sent result [0][4OVER.COM
]
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler] (0x0100): Got request with the following data
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): command: PAM_SETCRED
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): domain: 4OVER.COM 
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): user: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): service: vsftpd
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): tty: ftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): ruser: tradeftp
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): rhost: mammoth.4over.com

(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): authtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok type: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): newauthtok size: 0
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): priv: 1
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[pam_print_data] (0x0100): cli_pid: 17841
(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM ]]]
[be_pam_handler] (0x0100): Sending result [0][4OVER.COM ]
(Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM ]]]
[be_get_account_info] (0x0100): Got request for [3][1][name=tradeftp]
(Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM ]]]
[sdap_initgr_nested_search] (0x0040): Search for group
cn=ipausers,cn=groups,cn=accounts,dc=4over,dc=com, returned 0 results.
Skipping
/

Here (more interesting) is the krb log file


/(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer]
(0x0100): cmd [241] uid [6676] gid [104] validate [true] offline [false]
UPN [trade...@4over.com ]
(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer]
(0x0100): ccna