1:58 p.m.
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
5:49 a.m.
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 -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
11:18 a.m.
Attached are the logs. It seems that even after removing the GPO’s, it is still being
blocked from logging in.
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]
On May 28, 2018, at 6:49 AM, Michal Židek <mzidek(a)redhat.com>
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 -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorahost...
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
9:08 a.m.
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.
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.
On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com>
wrote:
Attached are the logs. It seems that even after removing the GPO’s, it is still being
blocked from logging in.
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 <mzidek(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedorahost...
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorahost...
9:16 a.m.
In my testing, I found that it does not appear that Access control GPOs are cumulative.
So, the GPO on the OU closest to the computer object will win. So I put a general GPO at
the top of the structure and have just instructed down-OU admins that when they write GPOs
for their OUs they have to include what the top level one has in it, in addition to what
they need to add, to ensure global access continues for the "uber admins" and
they can add access to service accounts and other service level users. It's a drag,
but it seems to work.
-----Original Message-----
From: Max DiOrio <mdiorio(a)gmail.com>
Sent: Wednesday, June 20, 2018 9:08 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
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.
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.
On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com>
wrote:
Attached are the logs. It seems that even after removing the GPO’s, it is still being
blocked from logging in.
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 <mzidek(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org To
>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedor
>> ahosted.org/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedora
> hosted.org/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
6:08 a.m.
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 <mdiorio(a)gmail.com> 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 <mzidek(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>>> 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/sssd-users@lists.fedorahost...
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedorahost...
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
6:21 a.m.
On 06/20/2018 04:16 PM, Mote, Todd wrote:
In my testing, I found that it does not appear that Access control
GPOs are cumulative. So, the GPO on the OU closest to the computer object will win. So I
put a general GPO at the top of the structure and have just instructed down-OU admins that
when they write GPOs for their OUs they have to include what the top level one has in it,
in addition to what they need to add, to ensure global access continues for the "uber
admins" and they can add access to service accounts and other service level users.
It's a drag, but it seems to work.
This is true. And it is also very confusing for many admins.
But you actually do not need to copy the entire GPO from
the above OU/Domain level. Only rules that are specified
again in the GPOs (for example adding a user to "Allow log
on locally" rule, you need to copy the whole "Allow log
on locally" list from the GPO from above level and then
add a user to the list, but if the "Deny log on locally"
does not change in the new GPO than you do not need to
copy it from the above GPO). So the GPOs are "sort of"
cumulative.
But I agree that copying te whole GPO and expanding/changing
it for the lower level OUs is better, because it is much
easier to debug.
-----Original Message-----
From: Max DiOrio <mdiorio(a)gmail.com>
Sent: Wednesday, June 20, 2018 9:08 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
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.
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.
> On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com> wrote:
>
> Attached are the logs. It seems that even after removing the GPO’s, it is still
being blocked from logging in.
>
> 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 <mzidek(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org To
>>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>>> 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/sssd-users@lists.fedor
>>> ahosted.org/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedora
>> hosted.org/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
8:46 a.m.
Ah, I never had occasion to find that little gem out. But I agree better to just say copy
it. Easier to debug as you say and less complex for folks to understand.
All of the settings fall down from every policy, for conflicts, it's replace rather
than merge from the last policy applied. That's not too bad an explanation.
-----Original Message-----
From: Michal Židek <mzidek(a)redhat.com>
Sent: Thursday, June 21, 2018 6:22 AM
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
On 06/20/2018 04:16 PM, Mote, Todd wrote:
In my testing, I found that it does not appear that Access control
GPOs are cumulative. So, the GPO on the OU closest to the computer object will win. So I
put a general GPO at the top of the structure and have just instructed down-OU admins that
when they write GPOs for their OUs they have to include what the top level one has in it,
in addition to what they need to add, to ensure global access continues for the "uber
admins" and they can add access to service accounts and other service level users.
It's a drag, but it seems to work.
This is true. And it is also very confusing for many admins.
But you actually do not need to copy the entire GPO from the above OU/Domain level. Only
rules that are specified again in the GPOs (for example adding a user to "Allow log
on locally" rule, you need to copy the whole "Allow log on locally" list
from the GPO from above level and then add a user to the list, but if the "Deny log
on locally"
does not change in the new GPO than you do not need to copy it from the above GPO). So the
GPOs are "sort of"
cumulative.
But I agree that copying te whole GPO and expanding/changing it for the lower level OUs is
better, because it is much easier to debug.
-----Original Message-----
From: Max DiOrio <mdiorio(a)gmail.com>
Sent: Wednesday, June 20, 2018 9:08 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
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.
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.
> On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com> wrote:
>
> Attached are the logs. It seems that even after removing the GPO’s, it is still
being blocked from logging in.
>
> 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 <mzidek(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org To
>>> unsubscribe send an email to
>>> sssd-users-leave(a)lists.fedorahosted.org
>>> 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/sssd-users@lists.fedo
>>> r ahosted.org/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedor
>> a hosted.org/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorah
osted.org/message/DBUXCJ74BEF6FLLWJ5GXVD74GJ6KH3PJ/
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorah
osted.org/message/R2T56NNWO7ZMALDMFM72S7P3UQMCVW4Z/
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
9:28 a.m.
This isn’t quite what I’m talking about.
I’m talking about multiple policies in a single OU. This OU contains 10 servers.
Case 1)
We have one policy for Technology User access, which defines that our Technology Users are
able to log in through terminal services, so that they can SSH into the server.
We have a second policy for Domain Admins, which allows all domain admins rights to Log on
Locally and Log on through Terminal Services, so that we can access via console and SSH.
With both polices linked to the OU, our domain admins are being rejected. If I remove the
Domain Admins policy and move the authentication into a single group policy, it works
fine. This tells me that SSSD isn’t checking multiple policies, but only the first one it
searches.
Case 2)
We have an OU for infrastructure servers. This OU has about a dozen systems in it.
We have the domain admin access policy as defined in Case 1 that should apply to all
servers in this OU.
We have a second policy for serverA that has a security group set to Log on as a service,
since that will be used to define a group allowed to access an Apache web site based
access using PAM.
We have a third policy for ServerB that has a few users defined for Log on Through
Terminal Services as these are remote access that need SSH access.
For the second and third policies, we use security filtering and specify the specific
server it needs to apply to since it shouldn’t apply to ALL servers in the OU.
Once this is done, the domain admins can no longer log in, however the policy for ServerA
web access work perfectly as does the policy for ServerB.
I would expect BOTH policies to apply to the server in question.
It appears based on this that I would need a separate OU for each server where “custom”
policies need to be applied and roll up all the GPO objects required into a single
policy.
On Jun 21, 2018, at 9:46 AM, Mote, Todd
<moter(a)austin.utexas.edu> wrote:
Ah, I never had occasion to find that little gem out. But I agree better to just say
copy it. Easier to debug as you say and less complex for folks to understand.
All of the settings fall down from every policy, for conflicts, it's replace rather
than merge from the last policy applied. That's not too bad an explanation.
-----Original Message-----
From: Michal Židek <mzidek(a)redhat.com>
Sent: Thursday, June 21, 2018 6:22 AM
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
On 06/20/2018 04:16 PM, Mote, Todd wrote:
> In my testing, I found that it does not appear that Access control GPOs are
cumulative. So, the GPO on the OU closest to the computer object will win. So I put a
general GPO at the top of the structure and have just instructed down-OU admins that when
they write GPOs for their OUs they have to include what the top level one has in it, in
addition to what they need to add, to ensure global access continues for the "uber
admins" and they can add access to service accounts and other service level users.
It's a drag, but it seems to work.
This is true. And it is also very confusing for many admins.
But you actually do not need to copy the entire GPO from the above OU/Domain level. Only
rules that are specified again in the GPOs (for example adding a user to "Allow log
on locally" rule, you need to copy the whole "Allow log on locally" list
from the GPO from above level and then add a user to the list, but if the "Deny log
on locally"
does not change in the new GPO than you do not need to copy it from the above GPO). So
the GPOs are "sort of"
cumulative.
But I agree that copying te whole GPO and expanding/changing it for the lower level OUs
is better, because it is much easier to debug.
>
> -----Original Message-----
> From: Max DiOrio <mdiorio(a)gmail.com>
> Sent: Wednesday, June 20, 2018 9:08 AM
> To: End-user discussions about the System Security Services Daemon
> <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
>
> 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.
>
> 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.
>
>
>> On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com> wrote:
>>
>> Attached are the logs. It seems that even after removing the GPO’s, it is still
being blocked from logging in.
>>
>> 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 <mzidek(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org To
>>>> unsubscribe send an email to
>>>> sssd-users-leave(a)lists.fedorahosted.org
>>>> 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/sssd-users@lists.fedo
>>>> r ahosted.org/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
>>> _______________________________________________
>>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>>> 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/sssd-users@lists.fedor
>>> a hosted.org/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
>>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorah
> osted.org/message/DBUXCJ74BEF6FLLWJ5GXVD74GJ6KH3PJ/
>
>
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorah
> osted.org/message/R2T56NNWO7ZMALDMFM72S7P3UQMCVW4Z/
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
9:51 a.m.
On 06/21/2018 04:28 PM, Max DiOrio wrote:
This isn’t quite what I’m talking about.
I’m talking about multiple policies in a single OU. This OU contains 10 servers.
Case 1)
We have one policy for Technology User access, which defines that our Technology Users
are able to log in through terminal services, so that they can SSH into the server.
We have a second policy for Domain Admins, which allows all domain admins rights to Log
on Locally and Log on through Terminal Services, so that we can access via console and
SSH.
With both polices linked to the OU, our domain admins are being rejected. If I remove
the Domain Admins policy and move the authentication into a single group policy, it works
fine. This tells me that SSSD isn’t checking multiple policies, but only the first one it
searches.
Even if there is multiple GPOs for one OU, there is still
deterministic order how the GPOs are being applied.
The order can be checked in the Group Policy Management
console, by clicking on the OU/Domain where you want
to check what GPOs are applied and then clicking
on the "Group Policy Inheritance" tab.
The problem with your two GPOs is that they both specify
"Allow log on through terminal services" so the one that
is applied later overrides this rule (as if the previous
one was not specified at all).
So if you want to split the GPOs on one OU level it is better
to split them based on what policy they specify
(for example one for "Log on locally" and another one for
"Log on through terminal services"). But IMO it is better
to have just one GPO that specifies all access control rules
(all allow/deny log on types). IMO it is just easier to
manage that way.
Case 2)
We have an OU for infrastructure servers. This OU has about a dozen systems in it.
We have the domain admin access policy as defined in Case 1 that should apply to all
servers in this OU.
We have a second policy for serverA that has a security group set to Log on as a service,
since that will be used to define a group allowed to access an Apache web site based
access using PAM.
We have a third policy for ServerB that has a few users defined for Log on Through
Terminal Services as these are remote access that need SSH access.
For the second and third policies, we use security filtering and specify the specific
server it needs to apply to since it shouldn’t apply to ALL servers in the OU.
I think you are hitting known limitation of SSSD. We do not support
hosts in the security filter. See this issue and BZ:
https://pagure.io/SSSD/sssd/issue/3443
https://bugzilla.redhat.com/show_bug.cgi?id=1462348
Unfortunately parts of the conversation in tha BZ is private and the
description may be confusing, but the point is that SSSD ignores
host entries in the security filter and (for now) only supports
users and groups.
Once this is done, the domain admins can no longer log in, however the policy for ServerA
web access work perfectly as does the policy for ServerB.
I would expect BOTH policies to apply to the server in question.
It appears based on this that I would need a separate OU for each server where “custom”
policies need to be applied and roll up all the GPO objects required into a single
policy.
> On Jun 21, 2018, at 9:46 AM, Mote, Todd <moter(a)austin.utexas.edu> wrote:
>
> Ah, I never had occasion to find that little gem out. But I agree better to just say
copy it. Easier to debug as you say and less complex for folks to understand.
>
> All of the settings fall down from every policy, for conflicts, it's replace
rather than merge from the last policy applied. That's not too bad an explanation.
>
>
> -----Original Message-----
> From: Michal Židek <mzidek(a)redhat.com>
> Sent: Thursday, June 21, 2018 6:22 AM
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
>
> On 06/20/2018 04:16 PM, Mote, Todd wrote:
>> In my testing, I found that it does not appear that Access control GPOs are
cumulative. So, the GPO on the OU closest to the computer object will win. So I put a
general GPO at the top of the structure and have just instructed down-OU admins that when
they write GPOs for their OUs they have to include what the top level one has in it, in
addition to what they need to add, to ensure global access continues for the "uber
admins" and they can add access to service accounts and other service level users.
It's a drag, but it seems to work.
>
> This is true. And it is also very confusing for many admins.
> But you actually do not need to copy the entire GPO from the above OU/Domain level.
Only rules that are specified again in the GPOs (for example adding a user to "Allow
log on locally" rule, you need to copy the whole "Allow log on locally"
list from the GPO from above level and then add a user to the list, but if the "Deny
log on locally"
> does not change in the new GPO than you do not need to copy it from the above GPO).
So the GPOs are "sort of"
> cumulative.
>
> But I agree that copying te whole GPO and expanding/changing it for the lower level
OUs is better, because it is much easier to debug.
>
>>
>> -----Original Message-----
>> From: Max DiOrio <mdiorio(a)gmail.com>
>> Sent: Wednesday, June 20, 2018 9:08 AM
>> To: End-user discussions about the System Security Services Daemon
>> <sssd-users(a)lists.fedorahosted.org>
>> Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
>>
>> 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.
>>
>> 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.
>>
>>
>>> On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com> wrote:
>>>
>>> Attached are the logs. It seems that even after removing the GPO’s, it is
still being blocked from logging in.
>>>
>>> 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 <mzidek(a)redhat.com>
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 -- sssd-users(a)lists.fedorahosted.org To
>>>>> unsubscribe send an email to
>>>>> sssd-users-leave(a)lists.fedorahosted.org
>>>>> 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/sssd-users@lists.fedo
>>>>> r ahosted.org/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
>>>> _______________________________________________
>>>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>>>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>>>> 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/sssd-users@lists.fedor
>>>> a hosted.org/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
>>>
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedorah
>> osted.org/message/DBUXCJ74BEF6FLLWJ5GXVD74GJ6KH3PJ/
>>
>>
>>
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedorah
>> osted.org/message/R2T56NNWO7ZMALDMFM72S7P3UQMCVW4Z/
>>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an
email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorahost...
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorahost...
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
9:53 a.m.
It seems in both cases, it's likely GPO link order on the OU. The Domain Admin policy
is probably processed first and the other policy processed after it. You can see link
order in GPMC if you click on the OU itself. It's a tab on the right side after that.
Once processing gets to the last OU, there still has to be some order in which they
apply, so the same "replace" not "merge" applies even here. If you
move the links around I bet you can get your Domain Admins to log in and your Technology
Users to not.
The policy for server A works because it's the only setting in the whole list of
applied GPOs that is "Log on as a service", nothing to replace from any other
policy on that one, and/or it's the last policy with that setting.
The others is something else I've run into, though you've just reminded me of it.
There is something about filtering and read access, and being able to apply GPs. Though I
can't recall specifically. I'd have to spin up my test. I had thought that I
could parse Windows firewall policy and apply it to IPtables, so I made a bunch of
policies and tried to apply them just to a group of linux machines and used security
filtering, it messed up other polices applying. I can't remember the specifics now
though.
Todd
-----Original Message-----
From: Max DiOrio <mdiorio(a)gmail.com>
Sent: Thursday, June 21, 2018 9:29 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
This isn’t quite what I’m talking about.
I’m talking about multiple policies in a single OU. This OU contains 10 servers.
Case 1)
We have one policy for Technology User access, which defines that our Technology Users are
able to log in through terminal services, so that they can SSH into the server.
We have a second policy for Domain Admins, which allows all domain admins rights to Log on
Locally and Log on through Terminal Services, so that we can access via console and SSH.
With both polices linked to the OU, our domain admins are being rejected. If I remove the
Domain Admins policy and move the authentication into a single group policy, it works
fine. This tells me that SSSD isn’t checking multiple policies, but only the first one it
searches.
Case 2)
We have an OU for infrastructure servers. This OU has about a dozen systems in it.
We have the domain admin access policy as defined in Case 1 that should apply to all
servers in this OU.
We have a second policy for serverA that has a security group set to Log on as a service,
since that will be used to define a group allowed to access an Apache web site based
access using PAM.
We have a third policy for ServerB that has a few users defined for Log on Through
Terminal Services as these are remote access that need SSH access.
For the second and third policies, we use security filtering and specify the specific
server it needs to apply to since it shouldn’t apply to ALL servers in the OU.
Once this is done, the domain admins can no longer log in, however the policy for ServerA
web access work perfectly as does the policy for ServerB.
I would expect BOTH policies to apply to the server in question.
It appears based on this that I would need a separate OU for each server where “custom”
policies need to be applied and roll up all the GPO objects required into a single
policy.
On Jun 21, 2018, at 9:46 AM, Mote, Todd
<moter(a)austin.utexas.edu> wrote:
Ah, I never had occasion to find that little gem out. But I agree better to just say
copy it. Easier to debug as you say and less complex for folks to understand.
All of the settings fall down from every policy, for conflicts, it's replace rather
than merge from the last policy applied. That's not too bad an explanation.
-----Original Message-----
From: Michal Židek <mzidek(a)redhat.com>
Sent: Thursday, June 21, 2018 6:22 AM
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
On 06/20/2018 04:16 PM, Mote, Todd wrote:
> In my testing, I found that it does not appear that Access control GPOs are
cumulative. So, the GPO on the OU closest to the computer object will win. So I put a
general GPO at the top of the structure and have just instructed down-OU admins that when
they write GPOs for their OUs they have to include what the top level one has in it, in
addition to what they need to add, to ensure global access continues for the "uber
admins" and they can add access to service accounts and other service level users.
It's a drag, but it seems to work.
This is true. And it is also very confusing for many admins.
But you actually do not need to copy the entire GPO from the above OU/Domain level. Only
rules that are specified again in the GPOs (for example adding a user to "Allow log
on locally" rule, you need to copy the whole "Allow log on locally" list
from the GPO from above level and then add a user to the list, but if the "Deny log
on locally"
does not change in the new GPO than you do not need to copy it from the above GPO). So
the GPOs are "sort of"
cumulative.
But I agree that copying te whole GPO and expanding/changing it for the lower level OUs
is better, because it is much easier to debug.
>
> -----Original Message-----
> From: Max DiOrio <mdiorio(a)gmail.com>
> Sent: Wednesday, June 20, 2018 9:08 AM
> To: End-user discussions about the System Security Services Daemon
> <sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
>
> 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.
>
> 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.
>
>
>> On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com> wrote:
>>
>> Attached are the logs. It seems that even after removing the GPO’s, it is still
being blocked from logging in.
>>
>> 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 <mzidek(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org To
>>>> unsubscribe send an email to
>>>> sssd-users-leave(a)lists.fedorahosted.org
>>>> 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/sssd-users@lists.fed
>>>> o r ahosted.org/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
>>> _______________________________________________
>>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>>> unsubscribe send an email to
>>> sssd-users-leave(a)lists.fedorahosted.org
>>> 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/sssd-users@lists.fedo
>>> r a hosted.org/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
>>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedora
> h osted.org/message/DBUXCJ74BEF6FLLWJ5GXVD74GJ6KH3PJ/
>
>
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedora
> h osted.org/message/R2T56NNWO7ZMALDMFM72S7P3UQMCVW4Z/
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorah
osted.org/message/AVXE73LJEWALT3PD34V4ZYA6EC4UQS3W/
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorah
osted.org/message/A5VZWKLFULADQP7QXR4HX7BD4UCCAFYJ/
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
12:06 p.m.
I’ll have to look into the GPO order processing I guess. Still not sure about case 2 then
and how to support security filtering short of moving the servers into their own
sub-ou's
On Jun 21, 2018, at 10:53 AM, Mote, Todd
<moter(a)austin.utexas.edu> wrote:
It seems in both cases, it's likely GPO link order on the OU. The Domain Admin
policy is probably processed first and the other policy processed after it. You can see
link order in GPMC if you click on the OU itself. It's a tab on the right side after
that. Once processing gets to the last OU, there still has to be some order in which they
apply, so the same "replace" not "merge" applies even here. If you
move the links around I bet you can get your Domain Admins to log in and your Technology
Users to not.
The policy for server A works because it's the only setting in the whole list of
applied GPOs that is "Log on as a service", nothing to replace from any other
policy on that one, and/or it's the last policy with that setting.
The others is something else I've run into, though you've just reminded me of it.
There is something about filtering and read access, and being able to apply GPs. Though
I can't recall specifically. I'd have to spin up my test. I had thought that I
could parse Windows firewall policy and apply it to IPtables, so I made a bunch of
policies and tried to apply them just to a group of linux machines and used security
filtering, it messed up other polices applying. I can't remember the specifics now
though.
Todd
-----Original Message-----
From: Max DiOrio <mdiorio(a)gmail.com>
Sent: Thursday, June 21, 2018 9:29 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
This isn’t quite what I’m talking about.
I’m talking about multiple policies in a single OU. This OU contains 10 servers.
Case 1)
We have one policy for Technology User access, which defines that our Technology Users
are able to log in through terminal services, so that they can SSH into the server.
We have a second policy for Domain Admins, which allows all domain admins rights to Log
on Locally and Log on through Terminal Services, so that we can access via console and
SSH.
With both polices linked to the OU, our domain admins are being rejected. If I remove
the Domain Admins policy and move the authentication into a single group policy, it works
fine. This tells me that SSSD isn’t checking multiple policies, but only the first one it
searches.
Case 2)
We have an OU for infrastructure servers. This OU has about a dozen systems in it.
We have the domain admin access policy as defined in Case 1 that should apply to all
servers in this OU.
We have a second policy for serverA that has a security group set to Log on as a service,
since that will be used to define a group allowed to access an Apache web site based
access using PAM.
We have a third policy for ServerB that has a few users defined for Log on Through
Terminal Services as these are remote access that need SSH access.
For the second and third policies, we use security filtering and specify the specific
server it needs to apply to since it shouldn’t apply to ALL servers in the OU.
Once this is done, the domain admins can no longer log in, however the policy for ServerA
web access work perfectly as does the policy for ServerB.
I would expect BOTH policies to apply to the server in question.
It appears based on this that I would need a separate OU for each server where “custom”
policies need to be applied and roll up all the GPO objects required into a single
policy.
> On Jun 21, 2018, at 9:46 AM, Mote, Todd <moter(a)austin.utexas.edu> wrote:
>
> Ah, I never had occasion to find that little gem out. But I agree better to just say
copy it. Easier to debug as you say and less complex for folks to understand.
>
> All of the settings fall down from every policy, for conflicts, it's replace
rather than merge from the last policy applied. That's not too bad an explanation.
>
>
> -----Original Message-----
> From: Michal Židek <mzidek(a)redhat.com>
> Sent: Thursday, June 21, 2018 6:22 AM
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
>
> On 06/20/2018 04:16 PM, Mote, Todd wrote:
>> In my testing, I found that it does not appear that Access control GPOs are
cumulative. So, the GPO on the OU closest to the computer object will win. So I put a
general GPO at the top of the structure and have just instructed down-OU admins that when
they write GPOs for their OUs they have to include what the top level one has in it, in
addition to what they need to add, to ensure global access continues for the "uber
admins" and they can add access to service accounts and other service level users.
It's a drag, but it seems to work.
>
> This is true. And it is also very confusing for many admins.
> But you actually do not need to copy the entire GPO from the above OU/Domain level.
Only rules that are specified again in the GPOs (for example adding a user to "Allow
log on locally" rule, you need to copy the whole "Allow log on locally"
list from the GPO from above level and then add a user to the list, but if the "Deny
log on locally"
> does not change in the new GPO than you do not need to copy it from the above GPO).
So the GPOs are "sort of"
> cumulative.
>
> But I agree that copying te whole GPO and expanding/changing it for the lower level
OUs is better, because it is much easier to debug.
>
>>
>> -----Original Message-----
>> From: Max DiOrio <mdiorio(a)gmail.com>
>> Sent: Wednesday, June 20, 2018 9:08 AM
>> To: End-user discussions about the System Security Services Daemon
>> <sssd-users(a)lists.fedorahosted.org>
>> Subject: [SSSD-users] Re: Multiple GPOs and order processing issue
>>
>> 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.
>>
>> 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.
>>
>>
>>> On May 29, 2018, at 12:18 PM, Max DiOrio <mdiorio(a)gmail.com> wrote:
>>>
>>> Attached are the logs. It seems that even after removing the GPO’s, it is
still being blocked from logging in.
>>>
>>> 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 <mzidek(a)redhat.com>
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 -- sssd-users(a)lists.fedorahosted.org To
>>>>> unsubscribe send an email to
>>>>> sssd-users-leave(a)lists.fedorahosted.org
>>>>> 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/sssd-users@lists.fed
>>>>> o r ahosted.org/message/JJFCF6EEUAHUYUVPEUUPWSJUEQP65R6B/
>>>> _______________________________________________
>>>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>>>> unsubscribe send an email to
>>>> sssd-users-leave(a)lists.fedorahosted.org
>>>> 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/sssd-users@lists.fedo
>>>> r a hosted.org/message/JXSLOZTYNKPD3Z3RT5BP5EQVEAD45ZRS/
>>>
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedora
>> h osted.org/message/DBUXCJ74BEF6FLLWJ5GXVD74GJ6KH3PJ/
>>
>>
>>
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
>> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>> 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/sssd-users@lists.fedora
>> h osted.org/message/R2T56NNWO7ZMALDMFM72S7P3UQMCVW4Z/
>>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorah
> osted.org/message/AVXE73LJEWALT3PD34V4ZYA6EC4UQS3W/
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorah
> osted.org/message/A5VZWKLFULADQP7QXR4HX7BD4UCCAFYJ/
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahost...
2135
days inactive
2162
days old
sssd-users@lists.fedorahosted.org
11 comments
3 participants
participants (3)
-
Max DiOrio -
Michal Židek -
Mote, Todd