Learn more about these different git repos.
Other Git URLs
In an active directory setting: If the domain controller that serves the GPOs is a Samba domain controller everyone with a domain account can login, even if GPOs are in place that should prevent the login of certain users.
Ubuntu 16.4 sssd 1.13.4 vs. samba 4.4.5 Domain Controller sssd.conf: ad_server = samba-dc.domain.local id_provider = ad access_provider = ad auth_provider = ad enumerate = false ldap_id_mapping = true ad_gpo_access_control = enforcing GPO: Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies/User Rights Assignments Policy: Deny log on through Terminal Services Setting: DOMAIN\test-denyuser
login attempt from user "test-denyuser".
test-denyuser can login using ssh.
test-denyuser is denied ssh access.
sssd domain log during ssh login (vs. samba dc) sssd_DOMAIN.log-gpo-all-get-in-obfus.txt
sssd domain log during ssh login (vs. windows dc) sssd_DOMAIN.log-gpo-denied-correct-obfus.txt
Against a Windows Server 2008 R2 Domain Controller the same GPOs are honored by sssd.
Ubuntu 16.4 sssd 1.13.4 vs Windows Server 2008 R2 AD only friends can log in, denies forbidden user [domain/DOMAIN.LOCAL] debug_level = 9 ad_server = windows-dc.domain.local id_provider = ad auth_provider = ad access_provider = ad enumerate = false ldap_id_mapping = true ad_gpo_access_control = enforcing GPO: Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies/User Rights Assignments Policy: Deny log on through Terminal Services Setting: DOMAIN\test-denyuser
sssd domain log attached: https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-gpo-denied-correct-obfus.txt
Hello!
This may be a server side issue. It is not possible to tell exactly what is going on from the logs. If it was possible to capture logs with the following SSSD builds, it may give us some hints.
Here are centos 7 and fedora copr repos with sssd version that contains more debug logging. https://copr.fedorainfracloud.org/coprs/mzidek/gpo-gPCFunc-debug/
And here is a git branch on github containing the same code for other distributions: https://github.com/mzidek-rh/sssd/tree/gpo-gpcFunctionalityVersion-missing
Michal
Hi, any luck testing those packages Michal provided?
I'm working on setting things up. (So far I have installed CentOS 7, installed EPEL, added mzidek's gpo-gPCFunc-debug EPEL repository to a new .repo file and installed this sssd version.) I'm now integrating this machine now to my domain. So far I am a bit startled: I can only connect with a Domain user if I use kerberos credentials "ssh domainuser@sambadomainclient -K". Password based authentication does not work, with an error in sssd_DOMAIN-log: "The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information". Anyhow, this should not prevent debugging the GPO parsing.
sssd domain log of a special debug version of sssd during ssh login of a user that should be denied entry (vs. samba dc) sssd_DOMAIN.log-sssdDebugVersion01-vsSambaDC-allows-all(deny-user).txt
sssd domain log of a special debug version of sssd during ssh login of a user that should be allowed entry (vs. samba dc) sssd_DOMAIN.log-sssdDebugVersion01-vsSambaDC-allows-all(allowed-user).txt
centos 7 with sssd 1.14.9 (debug version from https://copr.fedorainfracloud.org/coprs/mzidek/gpo-gPCFunc-debug/ ) vs. samba 4.4.5 Domain Controller
sssd.conf:
ad_server = samba-dc.domain.local id_provider = ad access_provider = ad auth_provider = ad enumerate = false ldap_id_mapping = true ad_gpo_access_control = enforcing
GPO:
Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies/User Rights Assignments Policy: Deny log on through Terminal Services Setting: DOMAIN\test-denyuser
https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsSambaDC-allows-all(deny-user).txt
gpo_child.log is empty.
_comment0: == Setup: == centos 7 with sssd 1.14.9 (debug version from https://copr.fedorainfracloud.org/coprs/mzidek/gpo-gPCFunc-debug/ ) vs. samba 4.4.5 Domain Controller
{{{ ad_server = samba-dc.domain.local id_provider = ad access_provider = ad auth_provider = ad enumerate = false ldap_id_mapping = true ad_gpo_access_control = enforcing }}}
{{{ Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies/User Rights Assignments Policy: Deny log on through Terminal Services Setting: DOMAIN\test-denyuser }}}
== Test: == login attempt from user "test-denyuser".
== Expected Result: == test-denyuser is denied ssh access.
== Result: == test-denyuser can login using ssh.
== Log: == https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsSambaDC-allows-all(deny-user).txt
=> 1486140121969073
login attempt from user "allowed-user".
"allowed-user" can login using ssh.
https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsSambaDC-allows-all(allowed-user).txt
== Test: == login attempt from user "allowed-user".
== Expected Result: == "allowed-user" can login using ssh.
== Result: == "allowed-user" can login using ssh.
== Log: == https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsSambaDC-allows-all(allowed-user).txt
=> 1486140204067576
The behavior running sssd against a windows server 2008 R2 domain controller changed from my Ubuntu 16.4 sssd 1.13.4 to Centos 7 with 1.14.0 (or 1.14.9-debug). Against the same windows domain controller now nobody can log in. Whereas running sssd against the samba 4.4.5 kept its behavior: everybody can log in. In both cases the group policy is not honored.
sssd domain log of a special debug version of sssd during ssh login of a user that should be allowed entry (vs. windows dc) but is denied sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(allow-user).txt
centos 7 with sssd 1.14.9 (debug version from https://copr.fedorainfracloud.org/coprs/mzidek/gpo-gPCFunc-debug/ ) vs. windows server 2008 R2 Domain Controller
ad_server = windows-dc.domain.local id_provider = ad access_provider = ad auth_provider = ad enumerate = false ldap_id_mapping = true ad_gpo_access_control = enforcing
"allowed-user" is denied to login using ssh.
https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(allow-user).txt
gpo_child.log: https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(allow-user)_gpo_child.log
_comment0: == Setup: == centos 7 with sssd 1.14.9 (debug version from https://copr.fedorainfracloud.org/coprs/mzidek/gpo-gPCFunc-debug/ ) vs. windows server 2008 R2 Domain Controller
{{{ ad_server = windows-dc.domain.local id_provider = ad access_provider = ad auth_provider = ad enumerate = false ldap_id_mapping = true ad_gpo_access_control = enforcing }}}
== Result: == "allowed-user" is denied to login using ssh.
== Log: == https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(allow-user).txt
=> 1486140573725539
sssd domain log of a special debug version of sssd during ssh login of a user that should be denied entry (vs. windows dc) sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(deny-user).txt
"test-denyuser" is denied to login using ssh.
https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(deny-user).txt
gpo_child.log https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(deny-user)_gpo_child.log
== Expected Result: == "test-denyuser" is denied to login using ssh.
== Result: == "test-denyuser" is denied to login using ssh.
== Log: == https://fedorahosted.org/sssd/attachment/ticket/3279/sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(deny-user).txt
=> 1486140891920959
gpo_child.log for sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(allow-user).txt sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(allow-user)_gpo_child.log
gpo_child.log for sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(deny-user).txt sssd_DOMAIN.log-sssdDebugVersion01-vsWindowsDC-denies-all(deny-user)_gpo_child.log
Hi!
Thanks a lot for the logs.
It looks like server side misconfiguration in all the cases.
This debug log sssd_DOMAIN.log-sssdDebugVersion01-vsSambaDC-allows-all(deny-user).txt shows the following debug messages:
(Fri Feb 3 15:12:14 2017) [sssd[be[DOMAIN.LOCAL]]] [ad_gpo_filter_gpos_by_dacl] (0x4000): GPO not applicable to target per security filtering: result of DACL evaluation 1205 (Fri Feb 3 15:12:14 2017) [sssd[be[DOMAIN.LOCAL]]] [ad_gpo_process_gpo_done] (0x0400): no applicable gpos found after dacl filtering
The first message is printed after each GPO. All GPOs failed this filtering (see point 3): https://msdn.microsoft.com/en-us/library/cc232538.aspx
I do not know how to set the security filtering in samba, but with AD it can be set up in the Group Policy Management Window. I would recommend checking the security filtering even in your AD test environment. If ALL GPOs are filtered out then there is no policy to enforce and SSSD allows access.
In the AD there is another issues (also server side):
13 (Fri Feb 3 14:55:47 2017) [[sssd[gpo_child[3706]]]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://windows-dc.domain.local/SysVol/domain.local/Policies/{C6B7B92C-0535-4A25-B1C5-BD4AA3DA55DC}/GPT.INI 14 (Fri Feb 3 14:55:52 2017) [[sssd[gpo_child[3706]]]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied] 15 (Fri Feb 3 14:55:52 2017) [[sssd[gpo_child[3706]]]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied] 16 (Fri Feb 3 14:55:52 2017) [[sssd[gpo_child[3706]]]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
The above means that SSSD does not have access to the Group policy templates. Try to add read permissions for "Athenticated users" for the directory that is named the same way as the GUID of the GPO and try again if that helps. Becase SSSD was not able to read the policy it acts conservatively and denies access to all users (this is different than in the first case where we had no policy to enforce, because all GPOs were filtered out).
Because I do not see any SSSD issue in the logs, I will close this ticket soon. Feel free to contact me directly on IRC or email if you need help. I can help with AD setup (I do not have samba dc experience).
Fields changed
owner: somebody => mzidek
I had a look at the file permissions of the sysvol share on the windows dc:[[BR]] "Authenticated Users" was "Read, List folder contents, read & execute". In a desperate move I added the same rights to "Everyone". gpo_child.log was not impressed:
(Thu Feb 16 15:13:55 2017) [[sssd[gpo_child[16915]]]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://windows-dc.domain.local/SysVol/scimatec.local/Policies/{C6B7B92C-0535-4A25-B1C5-BD4AA3DA55DC}/GPT.INI (Thu Feb 16 15:13:55 2017) [[sssd[gpo_child[16915]]]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied] (Thu Feb 16 15:13:55 2017) [[sssd[gpo_child[16915]]]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
Side note (as your comment about security filtering was targeted at the samba dc): Security Filtering has only the "Authenticated Users" listed. If I remove them, GPOs are not applied and everyone can log in as it is expected when no applicable GPOs are found.
A very quick try against the samba dc now also yielded the same gpo_child.log error "Permission denied". So either I have not wiped my sssd-cache/database appropriately, or I now have a general permission question which was replicated from the windows dc to the samba dc. I'll spent more time cleaning the sssd client system next week and look at the security filtering on the samba dc. (This is usually managed with the same "Group Policy Management" console from the RSAT tools as it is done with a windows dc.)
I also serve GPOs to windows clients from the samba dc. This works(auto mount file shares, firewall settings, deploy software, ...). So I assumed the rights on the sysvol share must be somehow correct. That is part of the reasoning why I opened this ticket at the sssd bug tracker.
Hi,
the reason why the windows client work and the sssd clients do not is because the sssd machines use different credentials (kerberos UPN) to comminicate with AD.
To check what kerberos principals are there on the hosts use can use klist -kt. SSSD uses the one wihout the host/ prefix. In my test environment it is IPACLIENT31$@ADDOMAIN.TEST . This is the principal that needs to have permissions to download the gpos from.
Btw. feel free to contact me directly using email or IRC. This ticket may be around for a while but I would prefer to close it soon. Also if you will not be able to respond here it may be because this track will be soon switched to read only mode as we are migrating to pagure.
Metadata Update from @kraus: - Issue assigned to mzidek - Issue set to the milestone: NEEDS_TRIAGE
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue close_status updated to: None - Issue set to the milestone: None (was: NEEDS_TRIAGE)
Since there is no activity, I'm closing this ticket. But please note issue #3324, another person submitted a large patch to fix several issues in the GPO support, perhaps those would help.
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue close_status updated to: worksforme - Issue status updated to: Closed (was: Open)
Or it can be a bug in libsmbclient/ wrong usage of libsmblient-4.6 by sssd https://bugzilla.redhat.com/show_bug.cgi?id=1431870
Metadata Update from @lslebodn: - Custom field design_review reset - Custom field mark reset - Custom field patch reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset
I think the unwanted behavior against a Windows Domain Controller I described in comments https://pagure.io/SSSD/sssd/issue/3279#comment-228930 and https://pagure.io/SSSD/sssd/issue/3279#comment-228932 can be attributed to the case sensitivity described in #3324. In both associated logs I find the mentioned "[sssd[be[DOMAIN.LOCAL]]] [gpo_cse_done] (0x0020): ad_gpo_parse_gpo_child_response failed: [22][Invalid argument]" line. On the Windows Domain Controller the share is called "SYSVOL" whereas on Ubuntu it is "sysvol".
On the other hand on Ubuntu and Windows 2008, in my case, the spelling is identical for "Machine" and "User".
Maybe I'll revisit GPOs for login right management at a later point in time, when the patches of #3324 are included in distribution packages. Thanks for looking into this.
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4312
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.