#2870 AD GPO fails if the machine account belongs to a domain controller
Closed: Fixed None Opened 3 years ago by mdeaudelin.

Suppose you have a setup such as this:

  • a Microsoft Windows Server machine running the Active Directory Domain Controller role (server A).
  • a Linux (Fedora 22 or Debian 8) machine running Samba 4 in domain controller mode, acting as a secondary DC for the domain (server B).

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.

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:

 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.

I would suggest fixing this as follows:

  • Adding the following line after line 69: #define UAC_SERVER_TRUST_ACCOUNT 0x00002000
  • Changing line 1844 to: 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

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

Fields changed

rhbz: => 0

Metadata Update from @mdeaudelin:
- Issue assigned to mdeaudelin
- Issue set to the milestone: SSSD 1.14 alpha

2 years ago

Login to comment on this ticket.

Metadata