On Wed, Dec 02, 2015 at 09:29:46AM -0000, Edouard Guigné wrote:

Hello sssd users,

I configured several fedora 22 x64 workstation with success with sssd against a AD domain. I followed the tutorial at https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server ("Joining the Linux client to the AD domain manually" part).

Last week, I upgrraded my workstation from fedora 22 to fedora 23 x64 (using fedup). I did not change the sssd.conf, krb5.conf and krb5.keytab from fedora 22 to 23.

In all upgraded fedora 23 workstations, users cannot loging anymore. Here is the error i get : sshd[9313]: pam_sss(sshd:account): Access denied for user xxxxx: 4 (System error) sshd[9313]: Failed password for xxxxx from x.x.x.x port 49459 ssh2 audit[9313]: USER_ACCT pid=9313 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=? acct="xxxxx" exe="/usr/sbin/sshd" hostname=x.x.x.x addr=x.x.x.x terminal=ssh res=failed' sshd[9313]: fatal: Access denied for user xxxxx by PAM account configuration [preauth] ...

Although, users can still loging in fedora 22 workstations.

System Error means something like "an unhandled exception" in the sssd code. The best way would be to take a look into the SSSD logs, in particular the domain logs and krb5_child.log.

Here is a document that describes how to obtain the logs: https://fedorahosted.org/sssd/wiki/Troubleshooting

Feel free to send them privately if you are concerned about sensitive data.

On Wed, Dec 02, 2015 at 11:00:51AM -0000, Edouard Guigné wrote:

Well, I activated debug_log=6 in sssd.conf

I added ad_gpo_access_control = disabled in domain section and users loging is restablished.

In fedora 22, ad_gpo_access_control was not necessary to enable loging. This should be added to the tutorial https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server

No, I think it's a bug in GPO processing we should fix. Can you attach or send the logs?

The apparent change in ad_gpo_access_control in sssd-1.13.2 in Fedora 22 broke my setup as well --- although for me it was a "permission denied" failure in the "account" PAM module which only occurred when logging in with xscreensaver (not when logging in at a virtual console).

Is this possibly an SSSD bug, or is it a broken AD setup? What's the best way to debug this type of problem?

On (02/12/15 20:42), Eric Biggers wrote:

The apparent change in ad_gpo_access_control in sssd-1.13.2 in Fedora 22 broke my setup as well --- although for me it was a "permission denied" failure in the "account" PAM module which only occurred when logging in with xscreensaver (not when logging in at a virtual console).

Is this possibly an SSSD bug, or is it a broken AD setup? What's the best way to debug this type of problem?

Eric, Edouard,

Could you provide sssd logfiles with enabled verbose logging and gpo in permissive or enforcing mode?

As Jakub wrote in different mail. we will need to see gpo_child.log and sssd_${domain}.log (with debug_level = 9)

If you do not want to send them to mailing list You can attach them to ticket https://fedorahosted.org/sssd/ticket/2889 or you can send them privately.

LS

Today, I am facing the same issue now on my fedora 22 workstations (I am running cron dnf update each night) But to bypass the problem, I had to set ad_gpo_access_control = permissive for fedora 22 workstations (disabled does not work on fed 22)...

My sssd version on both fedora 22 & 23 is 1.13.2

Hello, I am also using sssd with other linux like Scientifc Linux 6.5 On this linux, sssd is 1.12.4, I set "ad_gpo_access_control = disabled" in order to not get "Warning: user would have been denied GPO-based logon access if the ad_gpo_access_control option were set to enforcing mode." in /var/log/secure

If I set "ad_gpo_access_control = permissive", I still get this warning. In others red-hat clone linux, what will be the correct configuration if sssd is upgrade in 1.13.2 ? Why on fed 22, users cannot login if I set "ad_gpo_access_control = disabled", and can login if I set "ad_gpo_access_control = permissive" In fed 23, users can login with both "ad_gpo_access_control = disabled" and "ad_gpo_access_control = permissive".

EG

I tried to get logs, but it is working today with both "ad_gpo_access_control = disabled" and "ad_gpo_access_control = permissive" on fed 22. I do not know what happen yesterday after sssd update in 1.13.2

What about other linux distro centos 6.x / scientific linux 6.x, is an update in 1.13.2 planned ?

On (04/12/15 11:30), Edouard Guigné wrote:

I tried to get logs, but it is working today with both "ad_gpo_access_control = disabled" and "ad_gpo_access_control = permissive" on fed 22. I do not know what happen yesterday after sssd update in 1.13.2

What about other linux distro centos 6.x / scientific linux 6.x, is an update in 1.13.2 planned ?

GPO feature is already in CentOS 6.7 7.1+. (sssd-1.12.x_ But it is in permissive mode by default.

LS

On (23/01/16 01:50), Eric Biggers wrote:

Hi Lukas,

Sorry for the late response. Similar to the report on ticket 2889, my issue ultimately turned out to be that I was using lightdm as my display manager and it was not included in sssd's default list of "interactive services". The solution was to add +lightdm to the ad_gpo_map_remote_interactive setting in sssd.conf.

I think it should be part of ad_gpo_map_interactive and not ad_gpo_map_remote_interactive. If you have enabled the InteractiveLogonRight and/or DenyInteractiveLogonRight in GPO

I realize that this can be considered a configuration problem, but I find it quite unintuitive that sssd would have a hardcoded list of display managers etc. hidden behind the scenes. Is there any alternative way this could have been implemented?

ad_gpo_map_interactive already has default PAM servides for gnome and KDE. We might consider to add lightdm to defualt list. Feel free to file a ticket. https://fedorahosted.org/sssd/newticket

LS

On Sun, Jan 24, 2016 at 05:03:22PM -0000, Eric Biggers wrote:

Yes, ad_gpo_map_interactive is the right one.

I understand that the Gnome and KDE display managers are already included in the hardcoded default list. My question was more along the lines of why sssd needs to have such a hardcoded list at all. It seems like a poor design as it will invariably create headaches for people who choose to use software that isn't in the default list, whether that is lightdm or something else. Would it be possible for services to identify themselves as "interactive" or not, rather than placing the responsibility on sssd?

I'm not sure how..in the end, it's the service that calls pam_service to select which PAM service configuration to use during the conversation..there's nothing preventing you to create a completely custom service of yours.

It would be nice to provide a configure-time option so that distributions that ship a different display manager by default could override the list of services sssd has compiled in.

And does the whole "interactive" vs "noninteractive" mechanism actually provide any real security?

It's not about security as much as about mapping Windows GPO logon rights to UNIX PAM services.