Yes. I had modified sssd.conf on the server in pursuit of the solution to
proposed change and that is what caused this issue. I reverted the config and
authentication/lookups are now working as expected. I'd forgotten that I made
that change and since clients with in-tact caches were still
On Fri, Feb 12, 2021 at 10:43:18PM -, Mike Conner via FreeIPA-users wrote:
> More logs. This is from another broken client during an attempt to login as
> an AD user:
>
> (Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
> (0x1000): Domain domain.edu is Active
More logs. This is from another broken client during an attempt to login as an
AD user:
(Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
(0x1000): Domain domain.edu is Active
(Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_id_op_connect_step]
Thank you for the clarification. I ran in on the IPA server and the keytab was
successfully retrieved.
`Keytab successfully retrieved and stored in:
/var/lib/sss/keytabs/domain.edu.keytab-test`
-Mike
___
FreeIPA-users mailing list --
On pe, 12 helmi 2021, Mike Conner via FreeIPA-users wrote:
Thank you. I've run the following command on the broken client. In this
instance 'ipa.ipa.domain.edu' is the IPA server. 'IPA$@DOMAIN.EDU' was
used simply because it's what I saw in the logs.
Thank you. I've run the following command on the broken client. In this
instance 'ipa.ipa.domain.edu' is the IPA server. 'IPA$@DOMAIN.EDU' was used
simply because it's what I saw in the logs.
KRB5CCNAME=/var/lib/sss/db/ccache_IPA.DOMAIN.EDU /usr/sbin/ipa-getkeytab -r -s
ipa.ipa.domain.edu -p
Mike Conner via FreeIPA-users wrote:
> The following is a portion of the sssd log on the client reflecting the same
> inability to retrieve keytab:
> ***
> (Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
> (0x1000): Domain domain.edu is Active
> (Fri Feb 12 10:11:54
This may be useful information: Clients are still able to lookup and
authenticate AD users as long as they have an in-tact cache. If I empty the
sssd cache, that client will no longer be able to perform AD lookups or
authentications.
___
FreeIPA-users
On Fri, Feb 12, 2021 at 02:10:09PM -, Mike Conner via FreeIPA-users wrote:
> I'm afraid I don't know how to construct the right ipa-getkeytab command to
> test. Do I run ipa-getkeytab on the client or on the ipa server? For the
> IPA$@DOMAIN.EDU principal?
Hi,
SSSD calls
The following is a portion of the sssd log on the client reflecting the same
inability to retrieve keytab:
***
(Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
(0x1000): Domain domain.edu is Active
(Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]]
Mike Conner via FreeIPA-users wrote:
> The certificate for the AD secure ldap server is also current
> (ad.domain.edu:636).
It would only be binding to IPA for ipa-getkeytab. I don't know how sssd
invokes it.
But you should be able to see a failed TLS connection in the 389-ds logs
which could
The certificate for the AD secure ldap server is also current
(ad.domain.edu:636).
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
I'm afraid I don't know how to construct the right ipa-getkeytab command to
test. Do I run ipa-getkeytab on the client or on the ipa server? For the
IPA$@DOMAIN.EDU principal?
I thought about STARTTLS pointing to a certificate issue. The certs on the ipa
server are not expired:
getcert list |
On Thu, Feb 11, 2021 at 10:20:45PM -, Mike Conner via FreeIPA-users wrote:
> This additional bit from the logs indicates a failure to retireve a keytab:
>
> (Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [main] (0x0400):
> Backend provider (ipa.domain.edu) started!
> (Thu Feb 11
This additional bit from the logs indicates a failure to retireve a keytab:
(Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [main] (0x0400): Backend
provider (ipa.domain.edu) started!
(Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
(0x1000): Domain
15 matches
Mail list logo