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 <[email protected]> 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 <[email protected]> > Sent: Thursday, June 21, 2018 9:29 AM > To: End-user discussions about the System Security Services Daemon > <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> Sent: Thursday, June 21, 2018 6:22 AM >> To: [email protected] >> 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 <[email protected]> >>> Sent: Wednesday, June 20, 2018 9:08 AM >>> To: End-user discussions about the System Security Services Daemon >>> <[email protected]> >>> 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 <[email protected]> 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 <[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] >>>>>> o r ahosted.org/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] >>>>> r a hosted.org/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] >>> h osted.org/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] >>> h osted.org/message/R2T56NNWO7ZMALDMFM72S7P3UQMCVW4Z/ >>> >> _______________________________________________ >> 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] >> osted.org/message/AVXE73LJEWALT3PD34V4ZYA6EC4UQS3W/ >> _______________________________________________ >> 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] >> osted.org/message/A5VZWKLFULADQP7QXR4HX7BD4UCCAFYJ/ > _______________________________________________ > 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/4SQIDTROQCJJEPUNFQSF6CIN2W3YOYYG/ > _______________________________________________ > 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/5MVMH5LQSPQY5G4EWAMJRIFIWERSWCUT/ _______________________________________________ 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/OMH72J4F4ADK77DAMJKV4OZM36J4PHVH/
