[sssd PR#5251][opened] [wip] subdomains: allow to inherit case_sensitive=Preserving
by pbrezina
URL: https://github.com/SSSD/sssd/pull/5251
Author: pbrezina
Title: #5251: [wip] subdomains: allow to inherit case_sensitive=Preserving
Action: opened
PR body:
"""
The first patch is just man page update to reflect current state.
I think it makes sense to be able to show subdomain names in
their original casing. Patches 2-3 make it work for AD provider.
Patch 4 makes it work for IPA provider. There is apparantely a bug
in winbind, but there is no link the any bugzilla so I do not know
if it was already fixed. The commit is four years old. This patch
requires case_sensitive=Preserving to be set also on the server,
otherwise it does not work. It can be enabled without the server setting
but we need to make nss_cmd_getpwnam_ex (and other _ex commands) to
always return case preserving name. So before I continue the work
I'd like to ask @sumit-bose if we can do it like this.
Resolves:
https://github.com/SSSD/sssd/issues/5250
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5251/head:pr5251
git checkout pr5251
3 years, 2 months
[sssd PR#5422][opened] Logs review
by alexey-tikhonov
URL: https://github.com/SSSD/sssd/pull/5422
Author: alexey-tikhonov
Title: #5422: Logs review
Action: opened
PR body:
"""
This is a set of patches intended to enable higher log level by default.
Currently I target SSSDBG_OP_FAILURE (level 2) as a default (It seems SSSDBG_MINOR_FAILURE level contains legitimate messages that admin can deliberately ignore, and those messages can get quite spammy)
Perhaps several patches are yet missing (I'm awaiting @sumit-bose response) but those already published are ready for review.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5422/head:pr5422
git checkout pr5422
3 years, 3 months
[sssd PR#5401][opened] authtok: add label to Smartcard token
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/5401
Author: sumit-bose
Title: #5401: authtok: add label to Smartcard token
Action: opened
PR body:
"""
The key-id might not be sufficient to identify a certificate on a Smartcard
since it is possible that multiple certificates will use the same key.
This patch adds the certificate label to the Smartcard authtok item to
about the ambiguity if the key-id is used for multiple certificates.
Currently the key-id read from the Smartcard is used as key value for the
gdm choice list dialog. Since it might be possible that multiple
certificates use the same key and hence the same key-id this is not a
suitable value.
With this patch the string representation of a numerial counter is used.
Resolves: https://github.com/SSSD/sssd/issues/5400
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5401/head:pr5401
git checkout pr5401
3 years, 4 months
[sssd PR#5367][opened] pam: add pam_sss_gss module for gssapi authentication
by pbrezina
URL: https://github.com/SSSD/sssd/pull/5367
Author: pbrezina
Title: #5367: pam: add pam_sss_gss module for gssapi authentication
Action: opened
PR body:
"""
The module configuration and usage should be clear
from its manual page. Suggestions are welcome.
The main use case is to enable password-less authentication
for sudo where smartcards are not possible (because the
reader is not available in the target host).
It is not possible to set the service name or keytab at this
moment so the module relies on `host/hostname@REALM` where hostname
is provided by SSSD (based on the user's domain) and REALM
is determined by GSSAPI. This principal is already stored in
krb5_keytab location for IPA and AD providers so the functionality
is for free.
Because authorization is done by pam_sss and it is not needed
for the use case, I would implement configurable ticket names
and keytab location only when required by users.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5367/head:pr5367
git checkout pr5367
3 years, 4 months
[sssd PR#5375][opened] kcm: improve performance for large ccaches
by pbrezina
URL: https://github.com/SSSD/sssd/pull/5375
Author: pbrezina
Title: #5375: kcm: improve performance for large ccaches
Action: opened
PR body:
"""
KCM protocol is not designed for highest performance and our impelmentation
contained three huge bottle necks - encryption, json serialization and too
much cache access. These are unnecessary - the encryption is meaningless
since once you get access to the root-owned cache file you can also access
the decryption key so there is no added security. JSON is unneccessarily large,
requires base64 encoding of credentials and takes too long to parse. The cache
was accessed with each GET_CRED_BY_UUID operation. This operation is called
once for each credential when iterating over them.
The iteration over credentials in Kerberos looks like this:
```
// GET_CRED_UUID_LIST - fetch list of credentials and create a cursor
krb5_cc_start_seq_get(context, cache, &cur);
// GET_CRED_BY_UUID - get credential by uuid
while ((ret = krb5_cc_next_cred(context, cache, &cur, &creds)) == 0) {
do_something(creds);
krb5_free_cred_contents(context, &creds);
}
// destroy the cursor
krb5_cc_end_seq_get(context, cache, &cur);
```
I have addressed these bottlenecks and the performance has improved dramatically.
The test was to establish security context via GSSAPI with 200 services using
[this testing app](https://github.com/pbrezina/gssapi-auth).
```
# run gssapi server
../gssapi-auth-server -s socket -k test.keytab &
# get service tickets
for i in $(seq 1 200); do ../gssapi-auth-client -s socket -n test$i(a)master.client.vm ; done
# terminate server
pkill gssapi-auth-server
```
Here are the results:
| memory | secdb | keyring
--------------------------------------------
before | 19m59.713s | 33m41.337s |
after | 1m50.610s | 1m55.496s | 0m2.643s
It is still pretty slow in comparison with keyring. The next bottleneck is
communication over the socket. Keyring stores list of credentials directly
in the cursor so `krb5_cc_next_cred` returns data immediately without calling
to the keyring. We should do the same in KCM however this requires changes
in the KCM protocol and needs to be communicated with its upstream.
Resolves: https://github.com/SSSD/sssd/issues/5349
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5375/head:pr5375
git checkout pr5375
3 years, 4 months