3:29 a.m.
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.
Is it a known issue ? May you help me to resolve it ?
Best Regards,
Ed
4:29 a.m.
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.
5 a.m.
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
Best Regards,
Ed
5:17 a.m.
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?
6:53 a.m.
On (02/12/15 11:00), 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
gpo
access_control was changed from permissive to enforcing
with sssd-1.13.2. It's also in fedora 22.
Please file a fedora bug + attach log files.
LS
2:42 p.m.
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?
3:28 p.m.
On 02 Dec 2015, at 21:42, Eric Biggers
<ebiggers(a)fedoraproject.org> 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?
Probably a bug in SSSD. Please see tickets https://fedorahosted.org/sssd/ticket/2891 and
https://fedorahosted.org/sssd/ticket/2889.
We need the sssd logs, including the domain log and the gpo_child.log
Ticket #2891 includes a workaround.
2:24 a.m.
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
6:15 a.m.
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
6:21 a.m.
On (03/12/15 12:15), Edouard Guigné wrote:
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
As I wrote in previous mail[1], gpo access_control was changed from permissive
to enforcing with sssd-1.13.2. it was done in all versions of fedora which
contains sssd-1.13.2.
Thank you very much for log files.
LS
[1]
https://lists.fedorahosted.org/archives/list/sssd-users%40lists.fedorahos...
4 a.m.
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
4:58 a.m.
On (04/12/15 10:00), Edouard Guigné wrote:
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".
Fedora 22 and fedora 23 has the same
version of sssd.
So the issue might be caused by different configuration, different users ...
and maybe not related to GPO.
Could you provide logfiles from problematic machine with
"ad_gpo_access_control = disabled"?
LS
5:30 a.m.
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 ?
5:32 a.m.
On Fri, Dec 04, 2015 at 11:30:33AM -0000, Edouard Guigné wrote:
What about other linux distro centos 6.x / scientific linux 6.x, is
an update in 1.13.2 planned ?
Yes:
https://lists.fedorahosted.org/archives/list/sssd-users%40lists.fedorahos...
Although we won't enable GPO, the default will be permissive.
5:33 a.m.
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
7:50 p.m.
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 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?
6:21 a.m.
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
11:03 a.m.
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? And does the whole "interactive" vs "noninteractive" mechanism
actually provide any real security?
2:30 a.m.
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.
3007
days inactive
3061
days old
sssd-users@lists.fedorahosted.org
19 comments
4 participants
participants (4)
-
Edouard Guigné -
Eric Biggers -
Jakub Hrozek -
Lukas Slebodnik