[sssd PR#122][opened] Port integration tests to python3
by fidencio
URL: https://github.com/SSSD/sssd/pull/122
Author: lslebodn
Title: #122: Port integration tests to python3
Action: opened
PR body:
"""
Attached patches fixed python 2/3 compatibility of integration tests.
You will need to install following packages in fedora: python3-ldb, python3-pyldap, python3-requests
And for testing purposes you can use
```
make intgcheck-run PYTHON2=/usr/bin/python2
make intgcheck-run PYTHON2=/usr/bin/python3
```
I will need to figure out how to incorporate it into CI script.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/122/head:pr122
git checkout pr122
7 years, 3 months
[sssd PR#110][opened] Add more DEBUG messages to help admins diagnose Kerberos login failures
by fidencio
URL: https://github.com/SSSD/sssd/pull/110
Author: jhrozek
Title: #110: Add more DEBUG messages to help admins diagnose Kerberos login failures
Action: opened
PR body:
"""
This PR contains two trivial (code-wise) patches that just add one DEBUG
message each. It's quite common for admins to get stuck diagnosing issues
where the krb5_child process exists with system error. Moreover, many
system errors are caused by issues during Kerberos ticket validation where
the second patch tries to help to give some tips.
I hope the first patch should be OK to merge. With the second one, I was
struggling a bit to find some useful debug message. If anyone can think
about a better one, I'm all ears. Also, if the DEBUG message would be too
misleading in the general case, I'm equally fine with dropping the second
patch. At least the first one would help to avoid admins asking for help if all
we would tell them is to go and look into the krb5_child.log anyway -- so IMO it
makes sense to just put that info to a debug message.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/110/head:pr110
git checkout pr110
7 years, 3 months
Question about tevent request flow in ipa_add_ad_memberships_get_next()
by Justin Stephenson
Hello all,
I was able to reproduce a customer issue with IPA - AD trust external
memberships group processing caused by replication conflicts, in this
case it is related to a permission that is tied to the IDM trust group
through RBAC(sorry, I have not raised a ticket for it just yet). This
issue is evident in the logs here:
[add_ad_user_to_cached_groups] (0x4000): Group
[cn=custompermission+nsuniqueid=92931c98-d84011e6-9a0896c1-71a1e36a,cn=permissions,cn=pbac,dc=jstephen,dc=local]
not in the cache.
<snip>
[ipa_add_ad_memberships_get_next] (0x0040): Invalid group DN
[cn=custompermission+nsuniqueid=92931c98-d84011e6-9a0896c1-71a1e36a,cn=permissions,cn=pbac,dc=jstephen,dc=local].
[ipa_add_ad_memberships_done] (0x0040): ipa_add_ad_memberships request
failed.
It is clear the problem occurs here
val = ldb_dn_get_rdn_val(group_dn);
if (val == NULL || val->data == NULL) {
DEBUG(SSSDBG_OP_FAILURE,
"Invalid group DN [%s].\n", state->groups[state->iter]);
ret = EINVAL;
goto fail;
}
I was looking at writing a patch which skips this group instead of
failing the operation, though perhaps this is not the best method to
solve this issue.
I see that ipa_add_ad_memberships_get_next() sets a callback to
ipa_add_ad_memberships_get_group_done() which then calls
ipa_add_ad_memberships_get_next() again for the next group to be
processed. I tried the following patch based on this, but it does not
work and causes a major failure which results in SSSD restarting the
backend entirely:
diff --git a/src/providers/ipa/ipa_subdomains_ext_groups.c
b/src/providers/ipa/ipa_subdomains_ext_groups.c
index 90460bc..1e2e0c2 100644
--- a/src/providers/ipa/ipa_subdomains_ext_groups.c
+++ b/src/providers/ipa/ipa_subdomains_ext_groups.c
@@ -867,9 +867,9 @@ static void ipa_add_ad_memberships_get_next(struct
tevent_req *req)
val = ldb_dn_get_rdn_val(group_dn);
if (val == NULL || val->data == NULL) {
DEBUG(SSSDBG_OP_FAILURE,
- "Invalid group DN [%s].\n", state->groups[state->iter]);
- ret = EINVAL;
- goto fail;
+ "Invalid group DN [%s]. Skipping\n",
state->groups[state->iter]);
+ state->iter++;
+ ipa_add_ad_memberships_get_next(req);
}
fq_name = (const char *) val->data;
I suspect I am missing something obvious with the tevent flow occurring
here, I was hoping for some guidance on this.
Kind regards,
Justin Stephenson
7 years, 3 months
Handling of offline requests in sssd-1-13 and older
by Jakub Hrozek
Hi,
there was a customer complaining about fail over not reconnecting as
fast with sssd-1-13 as it did with sssd-1-14. The issue they were seeing
was that if sssd was offline, but the server came back up, it still took
sssd the full offline timeout cycle to attempt to reconnect, even though
we say that auth attempts are always done against the server.
I traced it to the difference in handling the offline state in the
providers themselves. With sssd-1-14, the only place that decides
whether to contact the providers is the DP itself. If the fast flag is
set and the provider is offline, we always return the offline error, if
the fast flag is unset, we ask the provider.
Now, the difference is that in sssd-1-13, we also have this code:
https://github.com/jhrozek/sssd/commit/397f956365dd320194c792c372625cdfda...
that would shortcut the request w/o trying to connect if the back end
was offline. I think this code is wrong and what sssd-1-14 does is
correct.
Therefore, I would like to just nuke the code that checks if the back
end is offline from the providers and let them always reconnect -- but
I'm not sure if this is safe to do in the LTM branch. In theory, laptop
users could complain about too frequent reconnects, however, I haven't
seen any complains with sssd-1-14 so far.
Opinions?
7 years, 3 months
Group renaming issue when "id_provider = ldap" is set.
by Fabiano Fidêncio
I've been working on rhbz#1401241
(https://bugzilla.redhat.com/show_bug.cgi?id=1401241) and I'd like to
clarify some doubts that showed up.
So, let's consider that there's a group called "foo" and user "user"
is part of this group. Group "foo" gets renamed to "bar'. Now. let me
describe what I've found out considering "id_provider = ldap" and
"id_provider = ad"
- id_provider = ldap:
cache has "foo" entry
After renaming "foo" to "bar"
cache has entry "bar" added
both entries have the same gid
- id_provider = ad
cache has "foo" entry
After renaming "foo" to "bar"
nothing is changed in the cache
Any of these situation look exactly right for me (and here I'm
probably wrong). My expectations are that we should, for both cases:
- check for the gid in the cache
- update the entry
So in the ldap case we would avoid having two entries with the same
gid and in the ad case we would be able to properly the updated name
of the group that the user is part of. Does it make sense?
Summing up the questions:
- When a group has its name changed, shall we update the entry that
contains its name (and then all memberOf that contains the old name?)?
- In case not, following what "id_provider = ad" does would be a good
fix for the issue?
Looking forward to hearing your opinion!
Best Regards,
--
Fabiano Fidêncio
7 years, 3 months