Learn more about these different git repos.
Other Git URLs
Suppose you have a setup such as this:
Suppose now that you wish for domain users to be able to authenticate to server B using sssd, rather than winbind (for uniformity reasons, since all your other servers use sssd).
You could then use a sssd.conf file such as this, in order to use the existing Samba keytab and not have to join the machine to itself:
[sssd] services = nss, pam, pac domains = DEMO.TLD default_domain_suffix = demo.tld [domain/demo.tld] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad krb5_keytab = /var/lib/samba/private/secrets.keytab
This will work fine for authentication. However, once you decide to apply GPOs to control access to the machine (ad_gpo_access_control = enforcing), you will notice that all users are denied access.
ad_gpo_access_control = enforcing
The following appears in the sssd logs after such a failed access attempt, which shows no obvious error:
(Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=SRVB,OU=Domain Controllers,DC=demo,DC=tld]. (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_parse_range] (0x2000): No sub-attributes for [userAccountControl] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_parse_range] (0x2000): No sub-attributes for [distinguishedName] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_result] (0x2000): Trace: sh[0x5582cf12fdf0], connected[1], ops[0x5582cf141020], ldap[0x5582cf125910] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://demo.tld/CN=Configuration,DC=demo,DC=tld (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_result] (0x2000): Trace: sh[0x5582cf12fdf0], connected[1], ops[0x5582cf141020], ldap[0x5582cf125910] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://demo.tld/DC=DomainDnsZones,DC=demo,DC=tld (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_result] (0x2000): Trace: sh[0x5582cf12fdf0], connected[1], ops[0x5582cf141020], ldap[0x5582cf125910] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://demo.tld/DC=ForestDnsZones,DC=demo,DC=tld (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_result] (0x2000): Trace: sh[0x5582cf12fdf0], connected[1], ops[0x5582cf141020], ldap[0x5582cf125910] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_op_destructor] (0x2000): Operation 13 finished (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [generic_ext_search_handler] (0x4000): Request included referrals which were ignored. (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [generic_ext_search_handler] (0x4000): Ref: ldap://demo.tld/CN=Configuration,DC=demo,DC=tld (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [generic_ext_search_handler] (0x4000): Ref: ldap://demo.tld/DC=DomainDnsZones,DC=demo,DC=tld (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [generic_ext_search_handler] (0x4000): Ref: ldap://demo.tld/DC=ForestDnsZones,DC=demo,DC=tld (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Nov 13 13:56:05 2015) [sssd[be[demo.tld]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
The following appears in the system log:
Nov 14 13:56:05 srvb.demo.tld sshd[16110]: pam_sss(sshd:account): Access denied for user administrator: 4 (System error)
A Wireshark trace shows that account access control fails just after requesting the userAccountControl attribute for the machine account over LDAP.
Walking through the source code, I have traced this problem back to line 1844 in file providers/ad/ad_gpo.c:
providers/ad/ad_gpo.c
if (!(uac & UAC_WORKSTATION_TRUST_ACCOUNT)) { ret = EINVAL; goto done; }
This works for all servers, but fails if the machine account belongs to a domain controller, since it has SERVER_TRUST_ACCOUNT set rather than WORKSTATION_TRUST_ACCOUNT and both are mutually exclusive.
SERVER_TRUST_ACCOUNT
WORKSTATION_TRUST_ACCOUNT
I would suggest fixing this as follows:
#define UAC_SERVER_TRUST_ACCOUNT 0x00002000
if (!(uac & UAC_WORKSTATION_TRUST_ACCOUNT || uac & UAC_SERVER_TRUST_ACCOUNT)) {
The security and compatibility impact of this change would be minimal to nonexistent, but would have a noticeable upside: allowing SSSD to provide GPO-based access control on a Samba 4 domain controller.
Since we only support GPOs for access control at the moment and the only way to target a DC running SSSD is if the DC is running Samba I don't see too much danger in adding trust account.
But I would be interested in opinions from other developers, too.
Thank you for the nice analysis. At the very least we shouldn't return System Error I think.
Although I am not sure it is a good idea to run SSSD on a Domain Controller at this time, we should definitely not artificially limit what type of machine SSSD may be perfgorming access control on. So I would made the check more generic and exclude something only if it can cause issues or introduce security risks.
Thanks Simo.
mdeaudelin, would you like to attach a patch to this ticket or send one to sssd-devel?
Triage notes - it would be better to leave the ticket in NT and wait for a bit for the reporter to submit a patch so that he is credited directly in the git history. Then target master/1.14, distributions can cherry pick this patch if needed.
As requested, I have attached a proposed patch. It implements my proposed solution and adds logging for cases where access may be denied.
Thank you very much for the patch. Can you also attach the patch in a git-formatted way? See https://fedorahosted.org/sssd/wiki/Contribute#Sendingpatchtoupstream on tips how to do that.
The patch looks OK to me, I just wonder if it makes sense to print the hexadecimal UAC value on failure, but it's not a blocker.
Fields changed
owner: somebody => mdeaudelin patch: 0 => 1
Updated patch sssd-2870.patch
I have updated the patch to follow the guidelines provided, and have modified it to include the hex value of the userAccountControl attribute in the debug message.
Thank you, I resent the patch to the list. We have some issues with our current CI setup, but after we fix it I think we can merge the patch.
Upstream should merge the patch into the current master.
milestone: NEEDS_TRIAGE => SSSD 1.14 alpha resolution: => fixed status: new => closed
rhbz: => 0
and also sssd-1-13:
Metadata Update from @mdeaudelin: - Issue assigned to mdeaudelin - Issue set to the milestone: SSSD 1.14 alpha
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/3911
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.