Hi,
the attached patches fix https://fedorahosted.org/sssd/ticket/2639
The first patches always retry fetching the keytab on lookup failure.
For the last two patches, I used Sumit's idea to check the last connection
time of the AD LDAP connection and compare it with the TDO modifyTimestamp
to only fetch the keytab and retry if there is a newer trust.
Testing is a bit tricky, but what I did is pretty much:
$ getent passwd administrator(a)win.trust.test
administrator@win.trust.test:*:962400500:962400500:Administrator:/home/win.trust.test/administrator:
# Make sure sssd doesn't reuse already established and working
# connection. Somewhat simulates GSSAPI connection expiring
$ sudo pkill -USR1 sssd
$ sudo pkill -USR2 sssd
$ ipa trust-add --type=ad win.trust.test --admin Administrator --password
# Make sure a wrong keytab is in place for the next connection
# attempt
$ sudo cp old.keytab /var/lib/sss/keytabs/win.trust.test.keytab
$ sudo sss_cache -E
$ getent passwd administrator(a)win.trust.test
administrator@win.trust.test:*:962400500:962400500:Administrator:/home/win.trust.test/administrator:
ehlo,
attached is alternative version for ticket 2744.
The unit test passed but there is a performance improvement.
If we compare 3rd patch to current master than
there is a 10 less invocation of malloc (an also other functions) per group.
and we saved allocation of 1091 per group.
There was a comment[1] in old thread about a possibility of double sanitized dn.
I was not able to find such case. I would be glad if someone
can extend unit test which will pass with master and fail with attached patch.
LS
[1] https://lists.fedorahosted.org/pipermail/sssd-devel/2015-August/024346.html
Hi,
reverting this commit "5e9bc89b28f1ac3ce573ecdece74fe9623580c28" fixed
the problem for me. So is the original commit no longer valid?
Regards,
Petr
Hi,
the attached patches implement https://fedorahosted.org/sssd/ticket/2637
There are two main use-cases:
1) If AD DCs are not reachable on the IPA server itself, we should
avoid going offline completely, at least the IPA domain should be
still reachable.
2) If SSSD is connected to a non-root AD DC, we still try to contact
the forest root because only the forest root normally knows all the
subdomains. But in many setups, the forest root is not reachable
due to network restrictions.
The full design is described here:
https://fedorahosted.org/sssd/wiki/DesignDocs/OneWayTrusts#Subdomainoffline…
There is one area that I'm not sure about myself -- in the
ad_subdomains.c changes, I always set ignore_mark_offline to true for
the root DC. I think it's safe because in this case the root domain is a
subdomain and we don't want a subdomain to allow marking the be as
offline, but I would like to ask that this change is double-checked.
I mostly checked by pausing AD DC VMs in my test setups and making sure
that the backend stays offline after lookup error, a subsequent lookup
is answered as if we were online on the backend side and that the
inactive status is reset. Also, main domain failures still must mark
sssd as offline.