nsswitch sudoers sssd vs files priority
by Nathanaël Blanchet
Hello,
I noticed that "sudoers files" was default prior over "sudoers sssd"
into "/usr/share/authselect/default/sssd/nsswitch.conf" when registering
a client.
Sudoers is the only item to be files prior, all other items are sssd prior:
passwd: sss files systemd {exclude if "with-custom-passwd"}
group: sss files systemd {exclude if "with-custom-group"}
netgroup: sss files {exclude if "with-custom-netgroup"}
automount: sss files {exclude if "with-custom-automount"}
services: sss files {exclude if "with-custom-services"}
sudoers: files sss {include if "with-sudo"}
Is there a reason to keep files priority for sudoers while the client is
registered to a domain, and is intended to be first controlled by sssd?
--
Nathanaël Blanchet
Supervision réseau
SIRE
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet(a)abes.fr
1 year, 11 months
User in AD not found by IPA
by Marc Boorshtein
We added a new account to AD that has a domain trust with FreeIPA. This
one user is having an issue where IPA can't find him. The user is in the
same OU as other users that work fine. The user is unlocked
(userAccountControl is 512) and the userprincipalname is set. When I try
to add the user to an id view or an external group IPA gives me the error
"trusted domain object not found" . Not really sure where to look next to
figure out what's wrong. We see the user when we make LDAP calls to AD.
Thanks
Marc
1 year, 11 months
Freeipa-client not available for debian bullseye
by ahmed zakraoui
Hello,
OK I know that there were an old discussion about this but still today, after the release of bullseye 11.1 the freeipa-client package is still not available.
We are using Centos 8 as FreeIPA masters so my question here is only about freeipa-client.
From what I can see here, Freeipa-client is only available for buster & sid
https://packages.debian.org/search?keywords=freeipa-client
To be honest with you this is the first time I see something like this.
What to do if our servers are using buster instead of bullseye? When the freeipa-client will be available for bullseye? (And will it be available for bullseye)
Thanks !
1 year, 11 months
[SSSD] Announcing SSSD 2.5.2
by Pavel Březina
# SSSD 2.6.0
The SSSD team is proud to announce the release of version 2.6.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.6.0
See the full release notes at:
https://sssd.io/release-notes/sssd-2.6.0.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
### General information
* Support of legacy json format for ccaches was dropped
* Support of long time deprecated `secrets` responder was dropped.
* Support of long time deprecated `local` provider was dropped.
* This release drops support of `--with-unicode-lib` configure option.
`libunistring` will be used unconditionally for Unicode processing.
* This release removes pcre1 support. pcre2 is used unconditionally.
* p11_child does not stop at the first empty slot when searching for tokens
* A flaw was found in SSSD, where the sssctl command was vulnerable to
shell command injection via the logs-fetch and cache-expire subcommands.
This flaw allows an attacker to trick the root user into running a
specially crafted sssctl command, such as via sudo, to gain root access.
The highest threat from this vulnerability is to confidentiality,
integrity, as well as system availability. This patch fixes a flaw by
replacing `system()` with `execvp()`.
### New features
* Basic support of user's 'subuid and subgid ranges' for IPA provider
and corresponding plugin for shadow-utils were introduced. Limitations:
- single subid interval pair (subuid+subgid) per user - idviews aren't
supported - only forward lookup (user -> subid ranges) Take a note, this
is MVP of experimental feature. Significant changes might be required
later, after initial feedback. Corresponding support in shadow-utils was
merged upstream, but since there is no upstream release available yet,
SSSD feature isn't built by default. Build can be enabled with
`--with-subid` configure option. Plugin's install path can be configured
with `--with-subid-lib-path=` (`${libdir}` by default)
### Important fixes
* KCM now replace the old credential with new one when storing an
updated credential that is however already present in the ccache to
avoid unnecessary growth of the ccache.
* Improve mpg search filter to be more reliable with id-overrides and
the new auto_private_groups options.
* Even if the forest root is disabled for lookups all required internal
data is initialized to be able to refresh the list of trusted domains in
the forest from a DC of the forest root.
* ccache files are created with the right ownership during offline
Smartcard authentication
* AD ping is now sent over `ldap` if `cldap` support is not available
during build. This helps to build SSSD on distributions without `cldap`
support in `libldap`.
* CVE-2021-3621
### Configuration changes
* New IPA provider's option `ipa_subid_ranges_search_base` allows
configuration of search base for user's subid ranges. Default:
`cn=subids,%basedn`
1 year, 11 months
[SSSD] Announcing SSSD 2.6.0
by Pavel Březina
# SSSD 2.6.0
The SSSD team is proud to announce the release of version 2.6.0 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/2.6.0
See the full release notes at:
https://sssd.io/release-notes/sssd-2.6.0.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
### General information
* Support of legacy json format for ccaches was dropped
* Support of long time deprecated `secrets` responder was dropped.
* Support of long time deprecated `local` provider was dropped.
* This release drops support of `--with-unicode-lib` configure option.
`libunistring` will be used unconditionally for Unicode processing.
* This release removes pcre1 support. pcre2 is used unconditionally.
* p11_child does not stop at the first empty slot when searching for tokens
* A flaw was found in SSSD, where the sssctl command was vulnerable to
shell command injection via the logs-fetch and cache-expire subcommands.
This flaw allows an attacker to trick the root user into running a
specially crafted sssctl command, such as via sudo, to gain root access.
The highest threat from this vulnerability is to confidentiality,
integrity, as well as system availability. This patch fixes a flaw by
replacing `system()` with `execvp()`.
### New features
* Basic support of user's 'subuid and subgid ranges' for IPA provider
and corresponding plugin for shadow-utils were introduced. Limitations:
- single subid interval pair (subuid+subgid) per user - idviews aren't
supported - only forward lookup (user -> subid ranges) Take a note, this
is MVP of experimental feature. Significant changes might be required
later, after initial feedback. Corresponding support in shadow-utils was
merged upstream, but since there is no upstream release available yet,
SSSD feature isn't built by default. Build can be enabled with
`--with-subid` configure option. Plugin's install path can be configured
with `--with-subid-lib-path=` (`${libdir}` by default)
### Important fixes
* KCM now replace the old credential with new one when storing an
updated credential that is however already present in the ccache to
avoid unnecessary growth of the ccache.
* Improve mpg search filter to be more reliable with id-overrides and
the new auto_private_groups options.
* Even if the forest root is disabled for lookups all required internal
data is initialized to be able to refresh the list of trusted domains in
the forest from a DC of the forest root.
* ccache files are created with the right ownership during offline
Smartcard authentication
* AD ping is now sent over `ldap` if `cldap` support is not available
during build. This helps to build SSSD on distributions without `cldap`
support in `libldap`.
* CVE-2021-3621
### Configuration changes
* New IPA provider's option `ipa_subid_ranges_search_base` allows
configuration of search base for user's subid ranges. Default:
`cn=subids,%basedn`
1 year, 11 months
ansible freeipa get info
by Nathanaël Blanchet
Hello,
I'm used to get informations/facts from any API based product such as
ovirt or awx with either a module (ovirt_vm_info ) or either a lookup
plugin (awx).
But I can't find anyway to do such a thing with the freeipa collection,
except directly calling the API with curl as this
curl \
-H referer:https://$HOSTNAME/ipa \
-H "Content-Type:application/json" \
-H "Accept:applicaton/json"\
--negotiate -u : \
--cacert /etc/ipa/ca.crt \
-d '{"method":"host_find","params":[[""],{}],"id":0}' \
-X POST https://`hostname`/ipa/json \
My question is to verify if I miss something, and how other users manage
to get json objects as variables so as to use them in a full ansible
context ( maybe uri module???)
--
Nathanaël Blanchet
Supervision réseau
SIRE
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet(a)abes.fr
1 year, 11 months
Re: [SOLVED] New IPA server and unable to sudo from client
by Sam Morris
> If my memory serves me correctly, I think it was ipa-server-trust-ad. Maybe I had
> wrongfully assumed that it got installed as part of the replica setup process? After all,
> the master already had that running.
FYI, 'yum history list' will show you the packages you installed & in what order. :)
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
1 year, 11 months
Transporting Identity Metadata from Apache proxy to backend web application
by Plotters
Hi,
Using the Kerberos and the Apache plugins mod_auth_gssapi and mod_lookup_identity the following flow is working:
1. User is authenticated using kinit
2. Apache authenticates the user
3. The proxy transports the meta data of the user (SSSD provides the user info)
4. The meta data is added to the header and proxied to the backend server.
The Apache configuration looks like this:
<LocationMatch "/private">
ProxyPass http://localhost:2001/
ProxyPassReverse http://localhost:2001/
RequestHeader set X-SSSD-REMOTE_USER expr=%{REMOTE_USER}
RequestHeader set X-SSSD-AUTH_TYPE expr=%{AUTH_TYPE}
RequestHeader set X-SSSD-REMOTE_HOST expr=%{REMOTE_HOST}
RequestHeader set X-SSSD-REMOTE_ADDR expr=%{REMOTE_ADDR}
LookupUserAttr givenname REMOTE_USER_FIRSTNAME
RequestHeader set X-SSSD-REMOTE_USER_FIRSTNAME %{REMOTE_USER_FIRSTNAME}e
LookupUserAttr sn REMOTE_USER_LASTNAME
RequestHeader set X-SSSD-REMOTE_USER_LASTNAME %{REMOTE_USER_LASTNAME}e
LookupUserAttr preferredLanguage REMOTE_USER_LANGUAGE
RequestHeader set X-SSSD-REMOTE_USER_LANGUAGE %{REMOTE_USER_LANGUAGE}e
LookupUserGroups REMOTE_USER_GROUPS ","
RequestHeader set X-SSSD-REMOTE_USER_GROUPS %{REMOTE_USER_GROUPS}e
</LocationMatch>
This works fine, but not all meta data is retrieved:
x-sssd-auth_type : [Negotiate]
x-sssd-remote_user : [plotters(a)EXAMPLE.COM]
x-sssd-remote_user_firstname : [(null)]
x-sssd-remote_user_groups : [ipausers]
x-sssd-remote_user_language : [(null)]
x-sssd-remote_user_lastname : [(null)]
Is there a ACL in FreeIPA which has to be adapted to use this meta data? I added preferredLanguage in the SSSD.conf file like this:
[ifp]
allowed_uids = ipaapi, root
user_attributes = +preferredLanguage, +firstName, +lastName
And the log shows this works:
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added allowed attr preferredLanguage to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added allowed attr firstName to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added allowed attr lastName to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr name to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr uidNumber to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr gidNumber to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr gecos to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr homeDirectory to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr loginShell to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr groups to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr domain to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr domainname to whitelist
* (2021-10-11 20:18:33): [ifp] [parse_attr_list_ex] (0x2000): Added default attr extraAttributes to whitelist
Thanks in advance for any pointers to solve this. Or where to look for ACL in the ipa logging. LDAP doesn't show anything.
Best regards, Bart
1 year, 11 months
[SOLVED] New IPA server and unable to sudo from client
by Jeremy Tourville
I had two IPA servers setup - my master and the replica. When performing the HBAC test (which includes a sudo rules test as a component of the HBAC test) the test would say access granted from the master. I had not tried to run the same test from the replica until this weekend when I did so by accident. The test told me access denied. For a moment I was puzzled until I realized I was running the test from the replica. Then I tried the same test again from the master and the test passed. This made me realize something was wrong and needed to be investigated further. I decided to install the ipa healthcheck tool on both servers and see what it told me. I read the documentation and ran all available healthchecks. Sure enough, one of the healthchecks failed. It didn't have just one failure though, there were many failures for the same test. I learned that even though the replica install logs showed installation success I was still missing a package that needed to be installed
separately. Once I installed the correct ipa package and ran the healthcheck again all tests passed. Now, when running the HBAC test in the GUI, both servers showed access granted. A last test from the client still didn't work. I cleared the sssd cache and tried again. Now sudo worked! It certainly underscored how important it is to have a healthy system status. Also, the problem appeared to be one thing in my mind but turned out being totally different when actually resolved. Keep your mind open to all possibilities.
1 year, 11 months
FreeIPA letsencrypt certificate problems after recent expiration of DST Root CA X3
by Stefan Fleischmann
Hi! I've been using FreeIPA (installed without CA --no-pkinit) with letsencrypt certificate. Whenever the certificate gets renewed I install it with
ipa-server-certinstall for both the LDAP and web server and that has been working just fine. Recently the root certificate (DST Root CA X3)
expired as mentioned here https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
Now when I try to install the new certificate I get this error:
---
CA certificate CN=DST Root CA X3,O=Digital Signature Trust Co. in /etc/letsencrypt/live/XXX/cert.pem, /etc/letsencrypt/live/XXX/privkey.pem is not valid: certutil: certificate is invalid: The certificate issuer's certificate has expired. Check your system date and time.
The ipa-server-certinstall command failed.
---
I don't understand this error message at all since the `cert.pem` file does not contain any reference to the X3 CA, so I suppose it must come from somewhere else. Does someone have an idea how to fix this?
I've already removed the root certificate with ipa-cacert-manage and added the self-signed X1 root cert, yet the same error message above keeps showing up.
1 year, 11 months
