https://bugzilla.redhat.com/show_bug.cgi?id=2351336
Bug ID: 2351336
Summary: /etc/krb5.conf.d/enable_sssd_conf_dir is mistakenly in
package sssd-krb5, not in sssd-krb5-common
Product: Fedora
Version: 41
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: hey(a)runiq.de
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
I have used realmd to join a host to an Active Directory domain. Realmd uses
sssd-ad for this, which pulls in sssd-krb5-common but _not_ sssd-krb5.
Unfortunately, sssd-krb5-common does not install the snippet
/etc/krb5.conf.d/enable_sssd_conf_dir. This results in SSH refusing
gssapi-with-mic authentication.
When I additionally install the sssd-krb5 package (which includes the snippet),
or create the snippet manually, SSH logins use my SSSD config and GSSAPI
authentication goes through.
Reproducible: Always
Steps to Reproduce:
1. Install realmd on a host
2. Join host to Active Directory domain
3. Enable SSH daemon
4. ssh -l user@realm -o preferredauthentications=gssapi-with-mic host
Actual Results:
Authentication is denied, no SSH session opened
Expected Results:
Authentication goes through, SSH session is opened
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2351336
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2325893
Bug ID: 2325893
Summary: sssd gpo_child doesn't have sufficient rights to
populate GPO policies
Product: Fedora
Version: 41
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Keywords: CommonBugs, Desktop
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: nekopilot(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
# 1. Issue
After upgrade from F39 to F41 via UI path the login to the system with AD
account is not possible. Local account works well.
# 2. Workaround
sssd service works under sssd user in Fedora 41. The folder with GPO policies
has wrong rights with owner root:
ls -lah /var/lib/sss/gpo_cache/example.com/Policies/
total 0
drwx------. 4 root root 98 Jan 10 2024 .
drwx------. 3 sssd sssd 22 Jan 10 2024 ..
drwx------. 3 root root 36 Nov 13 07:33 {31B2F332-016D-11D2-945F-00C04FBB84F9}
drwx------. 3 root root 36 Nov 13 07:33 {7E50761D-1E4D-4D2B-BD86-E667EED3DF1E}
It is possible to change the owner of the directories. After that the login
with AD account works well.
chown -R sssd:sssd /var/lib/sss/gpo_cache
Reproducible: Always
Steps to Reproduce:
1. Your F39 system must be joined to AD with sssd and you can login to the
system with AD account.
2. Upgrade from F39 to F41.
3. Try to login with AD account.
Actual Results:
Login from Gnome UI is not possible with error: "Wrong user name or password".
Expected Results:
You can login to the system with AD account.
Your F39 system must be joined to AD with sssd and you can login to the system
with AD account.
After upgrade you can't login from UI with AD account but:
1. kinit user.name(a)example.com - works well.
1. id user.name(a)example.com - works well.
1. realm list - looks good.
In logs you can find error message:
cat /var/log/sssd/gpo_child.log
```
[gpo_child[4066]] [prepare_gpo_cache] (0x0020): [RID#23]
mkdir(/var/lib/sss/gpo_cache/example.com/Policies/{31B2F332-016D-11D2-945F-…
failed: 13
```
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2325893
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2319608
Bug ID: 2319608
Summary: python3-sssdconfig packs outdated .pyc files
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: jpazdziora(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
The /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/*.cpython-313.pyc
/usr/lib/files get regenerated when SSSDConfig module is used.
Reproducible: Always
Steps to Reproduce:
1. dnf install -y python3-sssdconfig
2. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
3. python3 -c 'import SSSDConfig'
4. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Actual Results:
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 57759 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1226072 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-15 00:00:00.000000000 +0000
Modify: 2024-10-15 00:00:00.000000000 +0000
Change: 2024-10-18 09:46:42.433097566 +0000
Birth: 2024-10-18 09:46:42.432097551 +0000
[root@0890eef375bc /]# python3 -c 'import SSSDConfig'
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 59402 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1196042 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-18 09:47:14.646592272 +0000
Modify: 2024-10-18 09:47:14.646592272 +0000
Change: 2024-10-18 09:47:14.646592272 +0000
Birth: 2024-10-18 09:47:14.646592272 +0000
Expected Results:
The Size and Modify time in the second stat run should match the output from
the first one.
First found by
https://github.com/freeipa/freeipa-container/actions/runs/11397511703/job/3….
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2319608
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2361759
Bug ID: 2361759
Summary: sssd version 2.10.2 forgets group membership
information after an hour
Product: Fedora
Version: 42
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Severity: high
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: fedoraproject(a)ferree-clark.org
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
After upgrading to sssd version 2.10.2, on hosts running both Fedora 41 and 42,
sssd "forgets" group membership information after about an hour. After this
occurs, the "id" command shows the user's password information and local
(/etc/group) information but does not include groups that come from freeipa.
Likewise, the getent group <freeipa groupname> command shows the group number
and name, but does not include group members. Restarting sssd does not fix the
problem, and neither does clearing the cache, even deleting the cache files.
Forcing the sssd to switch ipa servers does cause group membership information
to return, but again it disappears after an hour. I have confirmed that group
membership information is correct when queried directly from freeipa when sssd
does not display it. Reverting to sssd version 2.10.0 fixes the problem. This
bug is causing havoc with applications that depend on particular group
membership.
Reproducible: Always
Steps to Reproduce:
1.Start sssd for the first time (or force it to switch ipa servers)
2.Wait about an hour
3.Perform group query: getent group homeassistant (or any other freeipa group)
Actual Results:
homeassistant:*:637200008:
Expected Results:
homeassistant:*:637200008:user1,user2,user3
Additional Information:
I have not been able to find errors in the logs that would explain this
behavior.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2361759
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…