[sssd PR#74][opened] IPA/AD: check auth ctx before using it
by fidencio
URL: https://github.com/SSSD/sssd/pull/74
Author: sumit-bose
Title: #74: IPA/AD: check auth ctx before using it
Action: opened
PR body:
"""
In e6b6b9fa79c67d7d2698bc7e33d2e2f6bb53d483 a feature was introduced to
set the 'canonicalize' option in the system-wide Kerberos configuration
according to the settings in SSSD if the AD or IPA provider were used.
Unfortunately the patch implied that the auth provider is the same as
the id provider which might not always be the case. A different auth
provider caused a crash in the backend which is fixed by this patch.
Resolves https://fedorahosted.org/sssd/ticket/3234
I tried to add an integration test to see if SSSD can start with a mixed
configuration but the AD provider tries to set some SASL parameters which
requires e.g. an existing keytab which is afaik currently not available in the
integration test. Since this issue it easy to reproduce manually (start SSSD
with id_provder=ad and auth_provider=krb5) I hope it is acceptable that an
integration test can be added later when the infrastructure for AD provider
tests is available?
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/74/head:pr74
git checkout pr74
7 years, 5 months
Nested netgroups with IPA provider
by Michal Židek
Hi,
this is continuation of discussion about pull
request 51 and associated tickets.
For context, see:
https://github.com/SSSD/sssd/pull/59
https://fedorahosted.org/sssd/ticket/3159
https://fedorahosted.org/sssd/ticket/3116
The FreeIPA UQE guys added upstream test for this issue
because we do not have upstream CI tests in SSSD with
IPA provider yet and this bug is not present in the
plain LDAP.
We use hash tables to store members of netgroups while
processing netgroups (and creating the netgroup triples).
The netgroup names are lowercased before they are stored
in the hash table. The reason for this normalization is
unknown to me. FreeIPA only creates lowercased netgroup
names, so lowercasing only affects the attribute name
(that is stored as prefix to the netgroup name in the hash table,
and maybe it can happen that the attribute name can be
stored in different cases at some point, which would
explain why we lower case it, however I was not able
to confirm if this is the case).
When we read the hash table, we do not lowercase the keys,
so the nested netgroups are not found and this is the
reason why the bug appears. The patch in PR 51 lower cases
the keys before reading the hash table and the bug does not
appear after that. Lukas thinks however that this is not
good approach, because there should be no need for the lower
casing in the first place.
Patch that removes the lower casing before adding the keys
to htable should also fix the issue. I did not send the patch
with this approach, because I was not sure why the lowercasing
happens in the first place and I know that lowercasing is not
harmful for the IPA netgroups, so I find it safer to use
the approach in the PR 51 especially while we do not have good
code coverage for IPA provider, however as I mentioned in the
PR 51, I am looking for opinions on this.
Thanks,
Michal
7 years, 5 months
about letting the responder choose the sysdb optimization level
by Jakub Hrozek
Hi,
I would like to ask for opinions about:
https://fedorahosted.org/sssd/ticket/3126
The basic idea is that the responder would choose what kind of optimization
would the back end perform when saving the sysdb entries. Requests that
just return information might choose to optimize very aggressively (using
modifyTimestamp) and requests that actually authenticate or authorize the
user might choose to not optimize at all to avoid issues like the ones we saw
with virtual attributes that don't bump the modifyTimestamp attribute at all.
On the responder side, this is quite easy, just send an additional flag
during the responder request. It's the provider part I'm not so sure
about, because there the optimizations are performed at the sysdb level.
So far I can only think about extending sysdb_transaction_start() (or
providing sysdb_opt_transaction_start and letting the old
sysdb_transaction_start default to no optimization) which would
internally keep track of the active transaction and the optimization we
want to perform. Since only sssd_be is the cache writer and there is
only one cache per domain.
Additionally, we would have to keep the transaction optimization level around
in some context until the request bubbles from the data provider handler to
actually saving the transaction. I don't I hope this won't be too messy, but
since the requests are asynchronous, so far I don't see any way around
it. The only thing that might be less messy in the long term is to provide
a bit more generic structure ("request status") that would so far only
include the optimization level and later might be extended to include
e.g. intermediate data. But on the other hand, I'm not sure I have
thought about passing the data between requests hard enough to design
this properly. Should I?
Any other opinions? Thoughts?
7 years, 5 months
[Q] t3222 sssd still showing ipa user after removed from last group
by Petr Cech
Hi all,
I came back to ticket #3222 "sssd still showing ipa user after removed
from last group" [1]. And I have new knowledge. But I still do not see
the light at the end of the tunnel.
[1] https://fedorahosted.org/sssd/ticket/3222
I attached patch which enables some basic debug on using of memcache.
And two reproducers (with and without memcache) which are based on
reproducer written in ticket.
If we use memcache, the issue occurs only sometimes.
The difference between both cases is mixed state of switch after
sss_nss_mc_getgrnam() call in _nss_sss_getgrnam_r() function.
Note: code says (for default case):
/* if using the mmaped cache failed,
* fall back to socket based comms */
Could anyone help, please?
The report is:
#--- WRONG
[root@mirach sssd]# date && getent group testgroup
Wed Nov 9 16:01:05 CET 2016
>>> [A] record not found (time[1478703665])
>>> [B] record not found (time[1478703665])
testgroup:*:1703800674:
Number of members added 1
[root@mirach sssd]# sss_cache -UG && date && getent group testgroup
Wed Nov 9 16:01:07 CET 2016
>>> [A] record not found (time[1478703667])
>>> [B] default (time[1478703667])
testgroup:*:1703800674:testuser
Number of members removed 1
[root@mirach sssd]# sss_cache -UG && date && getent group testgroup
Wed Nov 9 16:01:09 CET 2016
>>> mc record expires at [1478703967] | now [1478703669]
>>> [A] MC used (time[1478703669])
testgroup:*:1703800674:testuser
[root@mirach sssd]# grep '>>>' *.log
sssd_nss.log:(Wed Nov 9 16:01:06 2016) [sssd[nss]]
[sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703966]
| now [1478703666] | delta [300]
sssd_nss.log:(Wed Nov 9 16:01:06 2016) [sssd[nss]]
[sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300]
members [0]
sssd_nss.log:(Wed Nov 9 16:01:07 2016) [sssd[nss]]
[sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703967]
| now [1478703667] | delta [300]
sssd_nss.log:(Wed Nov 9 16:01:07 2016) [sssd[nss]]
[sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300]
members [1]
#--- RIGHT
[root@mirach sssd]# date && getent group testgroup
Wed Nov 9 15:56:54 CET 2016
>>> [A] record not found (time[1478703414])
>>> [B] record not found (time[1478703414])
testgroup:*:1703800674:
Number of members added 1
[root@mirach sssd]# sss_cache -UG && date && getent group testgroup
Wed Nov 9 15:56:56 CET 2016
>>> [A] default (time[1478703416])
>>> [B] default (time[1478703416])
testgroup:*:1703800674:testuser
Number of members removed 1
[root@mirach sssd]# sss_cache -UG && date && getent group testgroup
Wed Nov 9 15:56:58 CET 2016
>>> [A] record not found (time[1478703418])
>>> [B] record not found (time[1478703418])
testgroup:*:1703800674:
[root@mirach sssd]# grep '>>>' *.log
sssd_nss.log:(Wed Nov 9 15:56:54 2016) [sssd[nss]]
[sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703714]
| now [1478703414] | delta [300]
sssd_nss.log:(Wed Nov 9 15:56:54 2016) [sssd[nss]]
[sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300]
members [0]
sssd_nss.log:(Wed Nov 9 15:56:56 2016) [sssd[nss]]
[sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703716]
| now [1478703416] | delta [300]
sssd_nss.log:(Wed Nov 9 15:56:56 2016) [sssd[nss]]
[sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300]
members [1]
sssd_nss.log:(Wed Nov 9 15:56:58 2016) [sssd[nss]]
[sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703718]
| now [1478703418] | delta [300]
sssd_nss.log:(Wed Nov 9 15:56:58 2016) [sssd[nss]]
[sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300]
members [0]
Regards
--
Petr^4 Čech
7 years, 5 months