sssd user can't login and ssh to server

[Wojciech Giel]

Hello,

User can't login to machine or ssh to it using domain account. User is immediately kicked off from login or disconnected from ssh.

excerpt from auth.log
May 6 14:59:06 openmanage sshd[3967]: Connection closed by 10.10.254.254 port 51913 [preauth]
May 6 14:59:17 openmanage sshd[3970]: pam_sss(sshd:account): Access denied for user xxx: 4 (System error)
May 6 14:59:17 openmanage sshd[3970]: fatal: Access denied for user xxx by PAM account configuration [preauth]
May 6 14:59:49 openmanage sshd[3976]: pam_sss(sshd:account): Access denied for user xxx: 4 (System error)
May 6 14:59:49 openmanage sshd[3976]: fatal: Access denied for user xxx by PAM account configuration [preauth]

cat gpo_child.log
(Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [prepare_gpo_cache] (0x0400): Storing GPOs in /var/lib/sss/gpo_cache/MY_AD_DOMAIN
(Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [prepare_gpo_cache] (0x0020): mkdir(/var/lib/sss/gpo_cache/ad.lib.cam.ac.uk) failed: 2
(Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [gpo_cache_store_file] (0x0020): prepare_gpo_cache failed [2][No such file or directory]
(Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [gpo_cache_store_file] (0x0020): Error encountered: 2.
(Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [copy_smb_file_to_gpo_cache] (0x0020): gpo_cache_store_file failed [2][No such file or directory]
(Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [2][No such file or directory]
(Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [main] (0x0020): perform_smb_operations failed.[2][No such file or directory].

workaround:

to fix it run:
mkdir -pv /var/lib/sss/gpo_cache/name_of_joined_domain
chown -R sssd. /var/lib/sss/gpo_cache
systemctl restart sssd

cheers
Woj

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: sssd 1.13.4-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Fri May 6 15:08:26 2016
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: sssd
UpgradeStatus: No upgrade log present (probably fresh install)

[Stephen Gallagher (stephen-gallagherhome)]

On 05/06/2016 10:16 AM, Wojciech Giel wrote:
> Public bug reported:
>
> Hello,
>
> User can't login to machine or ssh to it using domain account. User is
> immediately kicked off from login or disconnected from ssh.
>
> excerpt from auth.log
> May 6 14:59:06 openmanage sshd[3967]: Connection closed by 10.10.254.254 port 51913 [preauth]
> May 6 14:59:17 openmanage sshd[3970]: pam_sss(sshd:account): Access denied for user xxx: 4 (System error)
> May 6 14:59:17 openmanage sshd[3970]: fatal: Access denied for user xxx by PAM account configuration [preauth]
> May 6 14:59:49 openmanage sshd[3976]: pam_sss(sshd:account): Access denied for user xxx: 4 (System error)
> May 6 14:59:49 openmanage sshd[3976]: fatal: Access denied for user xxx by PAM account configuration [preauth]
>
> cat gpo_child.log
> (Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [prepare_gpo_cache] (0x0400): Storing GPOs in /var/lib/sss/gpo_cache/MY_AD_DOMAIN
> (Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [prepare_gpo_cache] (0x0020): mkdir(/var/lib/sss/gpo_cache/ad.lib.cam.ac.uk) failed: 2
> (Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [gpo_cache_store_file] (0x0020): prepare_gpo_cache failed [2][No such file or directory]
> (Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [gpo_cache_store_file] (0x0020): Error encountered: 2.
> (Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [copy_smb_file_to_gpo_cache] (0x0020): gpo_cache_store_file failed [2][No such file or directory]
> (Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [2][No such file or directory]
> (Fri May 6 15:05:25 2016) [[sssd[gpo_child[627]]]] [main] (0x0020): perform_smb_operations failed.[2][No such file or directory].
>
>
> workaround:
>
> to fix it run:
> mkdir -pv /var/lib/sss/gpo_cache/name_of_joined_domain
> chown -R sssd. /var/lib/sss/gpo_cache
> systemctl restart sssd
>
> cheers
> Woj
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: sssd 1.13.4-1ubuntu1
> ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
> Uname: Linux 4.4.0-21-generic x86_64
> ApportVersion: 2.20.1-0ubuntu2
> Architecture: amd64
> Date: Fri May 6 15:08:26 2016
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> LANG=en_GB.UTF-8
> SHELL=/bin/bash
> SourcePackage: sssd
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> ** Affects: sssd (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: amd64 apport-bug xenial
>

The problem here is most likely that something like AppArmor is denying SSSD
permission to create the necessary directories.

[Timo Aaltonen (tjaalton)]

apparmor is not enforced, the failure here is most likely that gpo_cache directory is not created by the package.

Please test by just creating that directory and check if sssd then is able to create the domain subdir.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sssd - 1.13.4-3

---------------
sssd (1.13.4-3) unstable; urgency=medium

  * common: Add /var/lib/sss/gpo_cache. (LP: #1579092)
  * gpo-add-unity-to-ad-gpo-map-interactive.diff: Allow logging in from
    unity lockscreen. (LP: #1578415)

 -- Timo Aaltonen <email address hidden> Tue, 10 May 2016 10:39:46 +0300

[Tom Seewald (tseewald)]

Hi Timo,

I can confirm that creating just /var/lib/sss/gpo_cache and changing ownership to sssd resolves the issue.

Steps taken:

Spun up a new 16.04 server, updated all packages, installed relevant packages for realmd/sssd to work, rebooted.

Joined domain using realmd, verified it was successful. I then confirmed I was still having the same issue logging in with domain accounts.

mkdir /var/lib/sss/gpo_cache

chown -R sssd:sssd /var/lib/sss/gpo_cache

systemctl restart sssd

All issues with logging in (ssh, console, su) as a domain user have been resolved on this machine.

[Jakub Hrozek (jakub-hrozek)]

This is upstream bug https://fedorahosted.org/sssd/ticket/2962 btw.

[Tom Seewald (tseewald)]

Why is this still marked as incomplete?

[Tom Seewald (tseewald)]

From what Jakub posted, it appears that these are the patches that resolve this bug with sssd 1.13:

https://git.fedorahosted.org/cgit/sssd.git/commit/?id=df1a928455d0e5892ec129589f74e1704f66f201

https://git.fedorahosted.org/cgit/sssd.git/commit/?id=0060bfb03ae7678617accf61b45a13d625697cee

[Tom Seewald (tseewald)]

Are there plans to fix this in 16.04, or will this only be fixed in future versions of Ubuntu?

[Timo Aaltonen (tjaalton)]

uploaded to the queue

[Adam Conrad (adconrad)]

Hello Wojciech, or anyone else affected,

Accepted sssd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/1.13.4-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Tom Seewald (tseewald)]

I can verify this has fixed the issue.

After spinning up a new VM with 16.04.1 server and installing the proposed package SSSD 1.13.4-1ubuntu1.1, I can login with domain accounts.

[ake sandgren (ake-sandgren)]

It seems that sssd_nss and sssd_pam have a similar problem. The created
/var/lib/sss/pipes/nss and /var/lib/sss/pipes/pam are getting a 644 permission causing for instance "id" to fail on lookups.

The just uploaded 1.13.4-1ubuntu1.1 is still showing this specific problem here at least.

[Tom Seewald (tseewald)]

Ake have you been able to reproduce the issue on a fresh install with the proposed package?

[ake sandgren (ake-sandgren)]

Stopping the service, removing the sockets and starting the service makes them come back with 644 as permission.

And purging the packages, cleaning out /var/lib/sss, installing sssd again and starting, the permission for /var/lib/sss/pipes/{nss,pam} are still 644, root owned.

[Timo Aaltonen (tjaalton)]

ake, do you have ACLs in use? getfacl /var/lib/sss should show

[Wojciech Giel (wkg21)]

I can confirm that it fixed the problem.

thanks

On 01/08/16 17:13, Tom Seewald wrote:
> Ake have you been able to reproduce the issue on a fresh install with
> the proposed package?
>

--
Digital Services
Cambridge University Library
West Road; Cambridge; CB3 9DR
Tel: [phone]

[ake sandgren (ake-sandgren)]

We haven't set any ACLs ourselves at least.
root@b-an01:~# getfacl /var/lib/sss
getfacl: Removing leading '/' from absolute path names
# file: var/lib/sss
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

root@b-an01:~# getfacl /var/lib/sss/pipes/
getfacl: Removing leading '/' from absolute path names
# file: var/lib/sss/pipes/
# owner: sssd
# group: sssd
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

root@b-an01:~# getfacl /var/lib/sss/pipes/
nss pam private/
root@b-an01:~# getfacl /var/lib/sss/pipes/*
getfacl: Removing leading '/' from absolute path names
# file: var/lib/sss/pipes/nss
# owner: root
# group: root
user::rw-
group::r--
other::r--

# file: var/lib/sss/pipes/pam
# owner: root
# group: root
user::rw-
group::r--
other::r--

# file: var/lib/sss/pipes/private
# owner: sssd
# group: sssd
user::rwx
group::---
other::---
default:user::rwx
default:group::r-x
default:other::r-x

[Timo Aaltonen (tjaalton)]

still, not a bug on the package

[ake sandgren (ake-sandgren)]

Timo, what do you mean with "not a bug on the package"?

It is setting incorrect permissions on /var/lib/sss/pipes/{nss,pam}

[Timo Aaltonen (tjaalton)]

The package only provides /var/lib/sss/pipes with correct permissions, a running daemon creates the sockets under it and in your case the system configuration messes up the permissions for some reason. That is out of scope of this bug, and not a bug in the package but your system configuration.

[ake sandgren (ake-sandgren)]

I still say it's a bug in the sssd package.

If i remove the package (aptitude purge all-sssd-packages), do rm -rf /var/lib/sss, remove every trace of sssd then reinstall the package, they still return with 644 permission.

And doing an strace of sssd when it starts up also shows that umask is being set so the resulting sockets get 644 permission.

It is /usr/lib/x86_64-linux-gnu/sssd/sssd_nss and /usr/lib/x86_64-linux-gnu/sssd/sssd_pam that creates the sockets, both part of sssd-common.

[Jakub Hrozek (jakub-hrozek)]

Can you paste the strace that shows the pipes setting the wrong umask?

[ake sandgren (ake-sandgren)]

Sorry about that, I messed up reading the strace. It is setting umask(111) just prior to the bind() call.

The problem was that the install had (due to a bug in the version of tar used during installation) gotten a default acl set on every directory causing the incorrect permission.

So Timo was correct. Apologies (and thanks) to him.

[Tom Seewald (tseewald)]

Is there anything left to test on this package? If so, I would be happy to help.

[Tom Seewald (tseewald)]

Is there a timeline on releasing this fix for 16.04?

[fedsed (fedor-s)]

Yet do not forget to insert in file sssd.conf directive
ad_gpo_access_control = permissive
in the [domain] section.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sssd - 1.13.4-1ubuntu1.1

---------------
sssd (1.13.4-1ubuntu1.1) xenial; urgency=medium

  * Sync 1.13.4-3 changes from debian/yakkety.

sssd (1.13.4-3) unstable; urgency=medium

  * common: Add /var/lib/sss/gpo_cache. (LP: #1579092)
  * gpo-add-unity-to-ad-gpo-map-interactive.diff: Allow logging in from
    unity lockscreen. (LP: #1578415)

 -- Timo Aaltonen <email address hidden> Mon, 18 Jul 2016 05:55:56 +0300

[Martin Pitt (pitti)]

The verification of the Stable Release Update for sssd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.