[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
[sssd PR#5370][opened] nss: Use posix_fallocate() to alloc memcache file
by deastoe
URL: https://github.com/SSSD/sssd/pull/5370
Author: deastoe
Title: #5370: nss: Use posix_fallocate() to alloc memcache file
Action: opened
PR body:
"""
If sssd_nss starts up while the filesystem where the memcache files
will reside (SSS_NSS_MCACHE_DIR) does not have sufficient space,
sssd_nss can be killed by SIGBUS while attempting to write to the
mmap()'d address space.
Replace the ftruncate() call with posix_fallocate(), which will fail
in this scenario, so we can detect the condition and continue startup
without the memcache functionality.
Fixes #5369
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5370/head:pr5370
git checkout pr5370
3 years, 5 months
[sssd PR#5352][opened] AD: do not override LDAP data during GC lookups
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/5352
Author: sumit-bose
Title: #5352: AD: do not override LDAP data during GC lookups
Action: opened
PR body:
"""
The Global Catalog contains user and group information of the whole
forest and hence any Global Catalog server can be used. Currently when a
Global Catalog server is looked up the data of the LDAP server is
overwritten as well. I guess the original intention was to use a single
server for both services.
However since the Global Catalog server can come from any domain in the
forest this might overwrite the LDAP data of a DC from the local domain
with the data from a AD of a remote domain and as a result lookups for
users and groups from the local domain might fail since the remote DC
does not has this information available at the LDAP port. In most cases
this overwrite is hidden by a following lookup to find a KDC for
authentication which is searched only in the local domain again where
the LDAP data is overwritten again to make sure the same DC is used for
LDAP and Kerberos communication. But depending on the connection
timeouts and lifetime of Kerberos tickets the KDC lookup might be
skipped because new credentials are not needed and as a result the wrong
LDAP data is used.
To avoid this the LDAP data is now only set if the current lookup is not
a Global Catalog lookup.
Resolves: https://github.com/SSSD/sssd/issues/5351
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5352/head:pr5352
git checkout pr5352
3 years, 5 months
[sssd PR#5300][opened] ad: use parallel cldap ping for site discovery
by pbrezina
URL: https://github.com/SSSD/sssd/pull/5300
Author: pbrezina
Title: #5300: ad: use parallel cldap ping for site discovery
Action: opened
PR body:
"""
This PR adds support for CLDAP (connectionless LDAP over UDP) and makes
use of it during site discovery.
The discovery process is improved, it now sends the CLDAP ping to all
discovered domain controllers at once to avoid potential timeouts when
some of them are unreachable (which is quite common in real environment).
The first received reply is used.
The netlogon information is now requested only when SSSD starts and when
we are recovering from offline state To avoid swamping network with many
ping. This is quite fine given the site and forest information is not
dynamic but usually stable.
Additional improvement is that if we already know client's site we ping
only in-site controllers first. We were already doing that but now we
also fallback to off-site controllers in case none in-site controller
is unreachable. Previously we would just fail.
There is a bug in openldap [1] that makes SSSD wait for timeout in-case none
of the controller is reachable, but as long as at least one is reachble
the resolution will be fast.
Resolves:
https://github.com/SSSD/sssd/issues/3743
https://github.com/SSSD/sssd/issues/5215
[1] https://bugs.openldap.org/show_bug.cgi?id=9328
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5300/head:pr5300
git checkout pr5300
3 years, 6 months