sssd-ldap build failing on ubuntu 20.04
by burnmydread
Hello,
I am working on building sssd-ldap on ubuntu and I am hitting a failure that I don't see documented anywhere. Here is my setup:
Distro: ubuntu-20.04
sssd: sssd-2.2.3
automake: autoconf (GNU Autoconf) 2.69
(I got the dependencies via apt build-dep sssd-ldap.)
This is the configure command I am using: ./configure --with-samba=no --without-python2-bindings --with-selinux=no
Which fails with:
checking for CHECK... yes
checking check.h usability... no
checking check.h presence... yes
configure: WARNING: check.h: present but cannot be compiled
configure: WARNING: check.h: check for missing prerequisite headers?
configure: WARNING: check.h: see the Autoconf documentation
configure: WARNING: check.h: section "Present But Cannot Be Compiled"
configure: WARNING: check.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------------------------ ##
configure: WARNING: ## Report this to sssd-devel(a)lists.fedorahosted.org ##
configure: WARNING: ## ------------------------------------------------ ##
checking for check.h... no
configure: error: Could not find CHECK headers
I could not find and issue in github nor could I find an ubuntu package with that header. Any hints as to what is going on would be most helpful.
Thanks,
Zachary Joyner
2 years, 10 months
Announcing SSSD 2.5.1
by Pavel Březina
# SSSD 2.5.01
The SSSD team is proud to announce the release of version 2.5.1 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.5.1
See the full release notes at:
https://sssd.io/release-notes/sssd-2.5.1.html
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### New features
* `auto_private_groups` option can be set centrally through ID range
setting in IPA (see `ipa idrange` commands family). This feature
requires SSSD update on both client and server. This feature also
requires `freeipa 4.9.4` and newer.
### Important fixes
* Fix `getsidbyname` issues with IPA users with a user-private-group
### Configuration changes
* Default value of `ldap_sudo_random_offset` changed to `0` (disabled).
This makes sure that sudo rules are available as soon as possible after
SSSD start in default configuration.
2 years, 10 months
[sssd PR#5647][opened] krb5_child: Honor Kerberos keytab location
by elkoniu
URL: https://github.com/SSSD/sssd/pull/5647
Author: elkoniu
Title: #5647: krb5_child: Honor Kerberos keytab location
Action: opened
PR body:
"""
Kerberos keytab location can be specified per domain in sssd.conf.
If it is not specified - default path is used: /etc/krb5.keytab
The problem is that default path itself can be redefined for kerberos
by adding entry in krb5.conf:
[libdefaults]
default_keytab_name = /<PATH>/krb5.keytab
krb5_child will still use /etc/krb5.keytab as default value which
will cause an error.
This patch adds config checking to krb5_child.
If keytab parameter will be set to /etc/krb5.keytab,
krb5_child will validate it against krb5.conf and eventually
overwritte with value presented there.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5647/head:pr5647
git checkout pr5647
2 years, 10 months
[sssd PR#5661][opened] pam: change default for pam_response_filter
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/5661
Author: sumit-bose
Title: #5661: pam: change default for pam_response_filter
Action: opened
PR body:
"""
So far pam_response_filter didn't had any default. It turned out that it
would be useful to filter the environment variable KRB5CCANME by default
for sudo. The reason is the e.g. in contrast to su the calling user is
authenticated and hence only the Kerberos credentials of the calling user
are available. But this causes a couple of inconsistencies. E.g. depending
on the credential cache type the target user might not have access to the
credential cache and even if the credential cache can be accessed it will
contain credentials which different privileges than the target user. As a
result it seems better to not make KRB5CCANME in the environment of the
target user and let him pick the matching default credential cache.
Resolves: https://github.com/SSSD/sssd/issues/5660
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5661/head:pr5661
git checkout pr5661
2 years, 10 months