Intermittent failure to authenticate using NTLM with NT_STATUS_ACCESS_DENIED

[Stefan Metzmacher]

Hi Richard,

> We are intermittently seeing NTLM auth failing with
> NT_STATUS_ACCESS_DENIED and we see this message in winbindd.log:
> 
> [2015/10/08 15:34:33.393987,  3, pid=3549, effective(0, 0), real(0,
> 0), class=winbind]
> ../source3/winbindd/winbindd_pam.c:1426(winbind_samlogon_retry_loop)
>   winbind_samlogon_retry_loop: sam_logon returned ACCESS_DENIED.
> Maybe the trust account password was changed and we didn't know it.
> Killing connections to domain SOMEDOM
> 
> Now, the real reason seems to be that one of the DCs in that domain
> disallows NTLM authentication and whenever winbindd finds that DC we
> get this problem.

I just come across something similar.

Are you should really sure the disabled NTLM authentication was the
reason here. As far as I remember a DC would return
NT_STATUS_NTLM_BLOCKED instead of NT_STATUS_ACCESS_DENIED in such
a situation.

See [MS-APDS] 3.1.5 Message Processing Events and Sequencing Rules:

  ...

  If NTLMServerDomainBlocked == TRUE, the NTLM server SHOULD<7> return
  STATUS_NTLM_BLOCKED to the NTLM client.

  If the DC is of the resource domain:
  * If ResourceDCBlocked == TRUE, and the NTLM server's name is not
    equal to any of the DCBlockExceptions server names, the DC SHOULD<8>
    return STATUS_NTLM_BLOCKED.

  If the DC is of the account domain:
  * If AccountDCBlocked == TRUE, the APDS server SHOULD<9> return
    STATUS_NTLM_BLOCKED.
  * If the domainControllerFunctionality attribute
    ([MS-ADTS] section 3.1.1.3.2.25) returns a value that is >= 6,
    the account is not also the NTLM server's account, and the APDS
    server determines that an authentication policy setting ([MS-KILE]
    section 3.3.5.5) applies, then:
    * If AllowedToAuthenticateTo is not NULL, an access check SHOULD<10>
      be performed to determine whether the user has the ACL granting
      ACTRL_DS_CONTROL_ACCESS ([MS-SAMR] section 2.2.1.17). If the
      access check fails, APDS MUST return
      STATUS_AUTHENTICATION_FIREWALL_FAILED.

  ...

The only situation I saw NT_STATUS_ACCESS_DENIED from
NetrLogonSamLogonEx was when the DC was installed correctly
and still had SYSVOLReady = 0. See
https://lists.samba.org/archive/cifs-protocol/2017-September/003075.html

And I think this is a situation where we should ban that DC.

Also with our current netlogon_cli_creds.tdb infrastructure
I can't see how we could ever get NT_STATUS_ACCESS_DENIED
from NetrLogonSamLogon[WithFlags]() when using the credential
chain.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170910/9419860d/signature.sig>