| 2016-11-10 14:06:04 |
Florin Baca |
bug |
|
|
added bug |
| 2016-11-11 08:08:49 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server Team |
| 2016-11-11 08:37:35 |
Christian Ehrhardt |
bug |
|
|
added subscriber ChristianEhrhardt |
| 2016-11-11 08:38:04 |
Christian Ehrhardt |
bug |
|
|
added subscriber Timo Aaltonen |
| 2016-11-11 08:38:20 |
Christian Ehrhardt |
sssd (Ubuntu): status |
New |
Triaged |
|
| 2016-11-11 08:38:22 |
Christian Ehrhardt |
sssd (Ubuntu): importance |
Undecided |
High |
|
| 2016-11-11 08:38:46 |
Christian Ehrhardt |
bug watch added |
|
https://fedorahosted.org/sssd/ticket/2519 |
|
| 2016-11-11 08:38:46 |
Christian Ehrhardt |
bug task added |
|
sssd |
|
| 2016-11-11 21:28:45 |
Bug Watch Updater |
sssd: status |
Unknown |
Fix Released |
|
| 2016-11-14 06:56:19 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-11-14 07:24:24 |
Christian Ehrhardt |
description |
During the first half of September, the Ubuntu sssd package has been updated from 1.11.5-1ubuntu3 to 1.11.8-0ubuntu0.2. We use sssd for authentication on a few dev servers and all our Ubuntu workstations. After the first systems began upgrading we noticed people are no longer able to login. Using the ui you're simply redirected to the login screen. With ssh the connection is closed right away:
$ ssh username@nv-hostname04
username@nv-hostname04's password:
Connection closed by x.x.x.244
In the auth log we can see the following:
Nov 9 09:33:10 nv-hostname04 sshd[5397]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.250 user=username
Nov 9 09:33:10 nv-hostname04 sshd[5397]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.250 user=username
Nov 9 09:33:10 nv-hostname04 sshd[5397]: pam_sss(sshd:account): Access denied for user username: 4 (System error)
Nov 9 09:33:10 nv-hostname04 sshd[5397]: Failed password for username from x.x.x.250 port 54210 ssh2
Nov 9 09:33:10 nv-hostname04 sshd[5397]: fatal: Access denied for user username by PAM account configuration [preauth]
Once I have downgraded the packages to the previous version everything works fine again:
apt-get install -y --force-yes sssd=1.11.5-1ubuntu3 sssd-common=1.11.5-1ubuntu3 sssd-ad=1.11.5-1ubuntu3 sssd-ipa=1.11.5-1ubuntu3 sssd-krb5=1.11.5-1ubuntu3 sssd-ldap=1.11.5-1ubuntu3 sssd-proxy=1.11.5-1ubuntu3 python-sss=1.11.5-1ubuntu3 libsss-idmap0=1.11.5-1ubuntu3 sssd-ad-common=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3 libipa-hbac0=1.11.5-1ubuntu3 sssd-ad-common=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3 libsss-idmap0=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3
echo 'sssd hold' | dpkg --set-selections
I started enabling sssd debug logs, starting from 3 up to 7. It seems the problem is directly related to the fact that sssd cannot resolve the name of a few groups. The users are part of different mailing lists which we don't want listed on our Linux pcs.
(Wed Nov 9 09:33:10 2016) [sssd[be[ads.domain.com]]] [simple_resolve_group_done] (0x0040): Refresh failed
(Wed Nov 9 09:33:10 2016) [sssd[be[ads.domain.com]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 2099314
(Wed Nov 9 09:33:10 2016) [sssd[be[ads.domain.com]]] [simple_access_check_done] (0x0040): Could not collect groups of user username
I also noticed this is directly related to the simple_allow_groups module that we use to allow login for specific groups. Here's what I have tried and confirmed it fixes the issue:
1. comment out the line "simple_allow_groups = ", restart sssd => authentication works
2. change the "ldap_group_search_base" to include all un-resolvable groups, restart sssd => authentication works.
For the sake of testing, I used the sssd/updates ppa to install version 1.12.5-1~trusty1 of the sssd. I can confirm in this version everything works as expected. So basically:
broken: 1.11.8-0ubuntu0.2
good: 1.11.5-1ubuntu3
good: 1.12.5-1~trusty1
I looked at the upstream merges Ubuntu has done for 1.11.8, there are around 5-6 changes but I cannot figure out which one introduced the error.
The direct issue from sssd which describes the exact same issue is found at: https://fedorahosted.org/sssd/ticket/2519 . |
[Impact]
* sssd authentication fails if only allow rules are used and
simple_allow_groups is set but group verification fails.
* That is a regression to the status before the last SRU update.
* The fix is a backport of the upstream fix for
https://fedorahosted.org/sssd/ticket/2519
[Test Case]
* Set up sssd (can be quite complex) with only allow rules and
simple_allow_rules config being set.
* Then authenticate a user/group combo where the group verification fails
* This should succeed, but does no more since last update
[Regression Potential]
* Since this is a backport of a single fix, but lacks the other changes
that got upstream in-between there is the chance we missed in
code-review that there is more context needed to be backported that
could now cause other authentication issues.
[Other Info]
* Setup is so complex we likely have to rely on the reporter for
verification.
* Reporter tested with various config options for his issue - it would be
kind if he could do so as well for the proposed verification.
---
During the first half of September, the Ubuntu sssd package has been updated from 1.11.5-1ubuntu3 to 1.11.8-0ubuntu0.2. We use sssd for authentication on a few dev servers and all our Ubuntu workstations. After the first systems began upgrading we noticed people are no longer able to login. Using the ui you're simply redirected to the login screen. With ssh the connection is closed right away:
$ ssh username@nv-hostname04
username@nv-hostname04's password:
Connection closed by x.x.x.244
In the auth log we can see the following:
Nov 9 09:33:10 nv-hostname04 sshd[5397]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.250 user=username
Nov 9 09:33:10 nv-hostname04 sshd[5397]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.250 user=username
Nov 9 09:33:10 nv-hostname04 sshd[5397]: pam_sss(sshd:account): Access denied for user username: 4 (System error)
Nov 9 09:33:10 nv-hostname04 sshd[5397]: Failed password for username from x.x.x.250 port 54210 ssh2
Nov 9 09:33:10 nv-hostname04 sshd[5397]: fatal: Access denied for user username by PAM account configuration [preauth]
Once I have downgraded the packages to the previous version everything works fine again:
apt-get install -y --force-yes sssd=1.11.5-1ubuntu3 sssd-common=1.11.5-1ubuntu3 sssd-ad=1.11.5-1ubuntu3 sssd-ipa=1.11.5-1ubuntu3 sssd-krb5=1.11.5-1ubuntu3 sssd-ldap=1.11.5-1ubuntu3 sssd-proxy=1.11.5-1ubuntu3 python-sss=1.11.5-1ubuntu3 libsss-idmap0=1.11.5-1ubuntu3 sssd-ad-common=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3 libipa-hbac0=1.11.5-1ubuntu3 sssd-ad-common=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3 libsss-idmap0=1.11.5-1ubuntu3 sssd-krb5-common=1.11.5-1ubuntu3
echo 'sssd hold' | dpkg --set-selections
I started enabling sssd debug logs, starting from 3 up to 7. It seems the problem is directly related to the fact that sssd cannot resolve the name of a few groups. The users are part of different mailing lists which we don't want listed on our Linux pcs.
(Wed Nov 9 09:33:10 2016) [sssd[be[ads.domain.com]]] [simple_resolve_group_done] (0x0040): Refresh failed
(Wed Nov 9 09:33:10 2016) [sssd[be[ads.domain.com]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 2099314
(Wed Nov 9 09:33:10 2016) [sssd[be[ads.domain.com]]] [simple_access_check_done] (0x0040): Could not collect groups of user username
I also noticed this is directly related to the simple_allow_groups module that we use to allow login for specific groups. Here's what I have tried and confirmed it fixes the issue:
1. comment out the line "simple_allow_groups = ", restart sssd => authentication works
2. change the "ldap_group_search_base" to include all un-resolvable groups, restart sssd => authentication works.
For the sake of testing, I used the sssd/updates ppa to install version 1.12.5-1~trusty1 of the sssd. I can confirm in this version everything works as expected. So basically:
broken: 1.11.8-0ubuntu0.2
good: 1.11.5-1ubuntu3
good: 1.12.5-1~trusty1
I looked at the upstream merges Ubuntu has done for 1.11.8, there are around 5-6 changes but I cannot figure out which one introduced the error.
The direct issue from sssd which describes the exact same issue is found at: https://fedorahosted.org/sssd/ticket/2519 . |
|
| 2016-11-14 07:27:26 |
Christian Ehrhardt |
sssd (Ubuntu): status |
Triaged |
Fix Released |
|
| 2016-11-14 08:30:34 |
Christian Ehrhardt |
attachment added |
|
debdiff fix for this issue https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1640805/+attachment/4777117/+files/fix-bug-1640805.debdiff |
|
| 2016-11-14 08:38:11 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2016-11-22 08:03:27 |
Timo Aaltonen |
removed subscriber Ubuntu Server Team |
|
|
|
| 2016-11-22 08:03:59 |
Timo Aaltonen |
bug task added |
|
sssd (Ubuntu Trusty) |
|
| 2016-11-22 08:04:27 |
Timo Aaltonen |
sssd (Ubuntu Trusty): status |
New |
In Progress |
|
| 2016-11-22 11:33:13 |
Sebastien Bacher |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2016-11-23 14:00:01 |
Robie Basak |
sssd (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2016-11-23 14:00:02 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-11-23 14:00:05 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2016-11-23 14:00:09 |
Robie Basak |
tags |
|
verification-needed |
|
| 2016-11-24 16:11:13 |
Christian Ehrhardt |
tags |
verification-needed |
verification-done |
|
| 2016-12-01 17:18:48 |
Launchpad Janitor |
sssd (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2016-12-01 17:18:57 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
