On 06/20/2018 04:08 PM, Max DiOrio wrote:
Haven’t heard back from anyone on this issue, I know it’s been a while, but
we’re still seeing it, and it’s getting to be much more of an issue as we start
migrating production servers over to the AD domain.
Sorry, I accidentally marked this thread as read. Will look at the
logs later today.
How can we use multiple group policies to define security rights? Or do I need
to do a single group policy per server, which seems awful.
Not sure if I understand you question. If it is about how to set the
scope of the GPO then it depends on what OU the GPO is linked to
and what is set in the "Security filtering" list.
On May 29, 2018, at 12:18 PM, Max DiOrio <[email protected]> wrote:
Attached are the logs. It seems that even after removing the GPO’s, it is
still being blocked from logging in.
Have not checked the logs yet, but if this is the case, have you tried
the
ad_gpo_access_control = disabled
and see if you can login then? Maybe it is not GPO related after all.
I will let you know if there is something interesting in the logs
later today or tomorrow.
From secure.
May 29 12:17:24 la-1potpap01 sshd[8292]: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.85.144.87 user=a-mdiorio
May 29 12:17:25 la-1potpap01 sshd[8292]: pam_sss(sshd:account): Access denied
for user a-mdiorio: 4 (System error)
May 29 12:17:25 la-1potpap01 sshd[8292]: Failed password for a-mdiorio from
10.85.144.87 port 60267 ssh2
May 29 12:17:25 la-1potpap01 sshd[8292]: fatal: Access denied for user
a-mdiorio by PAM account configuration [preauth]
<Archive.zip>
On May 28, 2018, at 6:49 AM, Michal Židek <[email protected]> wrote:
Hi!
From your description the setup should work. Can you send full (sanitized)
logs? Mostly the domain and gpo_child logs are interesting
here, but for simplicity you can send all logs:
- stop sssd
- remove cached files in:
rm -r /var/lib/sss/gpo_cache/*
rm -r /var/lib/sss/db/*
- set debug_level in domain section in /etc/sssd/sssd.conf to 10
- reproduce issue
- send logs from /var/log/sssd/
Additional questions:
- if you remove the single computer policy, does the "generic" policy
apply as expected to the affected computer in question?
Michal
On 05/25/2018 08:58 PM, Max DiOrio wrote:
Hi!
So it seems that I’m having an issue with GPO processing. I have an OU
(Servers/Infrastructure) that contains a few servers. In this OU, I have a few
GPO’s applied.
Once is “generic” that should applied to every server in this OU - which allows
Remote Interactive Login and Logon Locally to Domain Admins.
I also have a GPO that applies to a specific server in this out that grants
access to a service account to log on to terminal services and log on as a
service. For this GPO, I have a security filter to the specific computer
object it is supposed to apply to - and I think this is the root of my issue.
The GPOs are listed
1) Infrastructure servers Access Control (that should apply to them all)
2) Single Computer policy for service account
When looking at the sssd_domain logs, I can see that it’s processing both
GPO’s, but only adding the account from policy 2 to the ad_gpo_access_check,
meaning domain admins can’t log in to either server, only the service account
can to both of them.
So we have multiple issues:
1) It’s not combining the GPO access policies, but only taking the last one
found
2) It’s not abiding by the Security Filtering on the GPO
So in my case - how would I go about making this work? Would I need a separate
GPO for each server I want to apply individual rights to and explicitly include
the domain admins group in it, then using delegation allow the single computer
read and deny read of every other computer?
Seems like this also means you can’t do GPO inheritance if it only takes the
last found GPO and ignores the settings configured in previous GPO’s it checked.
Any ideas?
Thanks!
Max
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]/message/DBUXCJ74BEF6FLLWJ5GXVD74GJ6KH3PJ/
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]/message/YEYSUCA6GLYG22Q2OBTN6SUVK6VO5R7F/
