The authentication request was rejected due to NTLM authentication error: : Reading winbind reply failed! (0xc0000001)

[Yogakrisnanda]

Hi everyone,

I have some project to deploy Extreme NAC server and the client is bind user via AD (Active Directory) using NTLM authentication. I have configured AAA configuration on NAC for AD and tested users (via wireless) on NAC and it seems error state description "The authentication request was rejected due to NTLM authentication error: : Reading winbind reply failed! (0xc0000001)" and reason "Rejected by NTLM authentication". Please advice for this problem. Thank you.

[Gabriel_Bagita]

Hi guys,

thanks for your recommendations. My problem was I wasn’t able to join the NAC GW to the AD. The LDAP authentication was working perfectly to authenticate users to XMC’s GUI, but we need to authenticate users for 802.1x as well and it requires NAC GW to be joined to AD.

I made some troubleshooting based on yours recommendations but it didn’t help. Finally I opened a ticket and the problem was, we had the binding user identity filled out as a CN, not as a DOMAIN\sAMAccountName.

Gabriel

[Ryan_Yacobucci]

Hello,

The domain join has many pieces that need to be in place in order for it to be functional. I can’t say I know all in detail but I can give you a run down of my functional knowledge of the process.

1. Configure appropriate local files:
   When you configure the LDAP schema in NAC the system looks at your search roots, administrator username, password, Authentication type and LDAP URLs to build an smb.conf on enforce. AAA must be set to use a specific LDAP configuration that has NTLM set as the authentication type. In 8.2 and higher we can join multiple domains.
   
   We will concentrate on joining of one domain.
   
    
2. Identify a suitable DC.
   Once the appliance has been enforced the following things occur:
   
   NAC will attempt to contact the “Password server” defined in the smb.conf (We pull this from the “LDAP URLs” in the LDAP configuraiton)
   
   It will perform a CLDAP request to attempt to obtain domain forest information, including workgroup (NetBios Domain), as well as if the DC can perform netlogon functionality. NAC can potentially use this to reconfigure it’s SMB conf if the work group it automatically generated is not the same as configured on the DC. 
   
   NAC will then attempt to do a dns lookup for an LDAP srv record. It will attempt to query different records based on the result of the previous CLDAP request.
   
   SRV _ldap._tcp.WORKGROUP._sites.dc.msdcs.DOMAIN
   SRV _ldap_tcp.dc._msdcs.WORKGROUP
   
   This is a mechanism to try and identify domain controllers that it can bind to, and in the case of a distributed network DNS records can be leveraged to have it attempt to bind to a more geographically friendly DC (Local).  
   
   If the DC doesn’t respond to the CLDAP request the DNS query may query for an incorrect record. If this occurs the system will fail to identify a DC and you’ll see the “domain not found” error. 
   
   In my experience as long as the CLDAP quest OR the DNS request is successful we will have a suitable DC for joining. 
   
    
3. Negotiating with the identified DC and creating a computer object.
   We must first negotiate and authenticate the provided user. 
   
   First we will negotiate for SMB/SMBv2. Earlier versions of NAC didn’t support SMBv2. SMB will be the vehicle we use to authenticate and join a computer to the domain. 
   
   The server must also be set to use NTLM. This is also negotiated. 
   
   NAC will attempt to authenticate the administrator/password using kerberos. The administrator username must have kerberos permissions. 
   
   Once authenticated NAC will attempt to create itself as a computer object in the “computers” OU and perform a DNS update.
   
   The “NAC” computer object must be created so that all users can authenticate to it.
   When a user authenticates on their end system the NAC uses their credentials to perform a remote kerberos authentication, as if they were logging into the NAC itself.
   
    
4. Things that go wrong; 
   NAC can’t find the domain controller (DNS/CLDAP)
   Kerberos permissions aren’t allocated to the supplied “administrator” account
   Netlogon is not enabled as a service
   Supplied “administrator” account does not have create/delete objects or reset password permissions
   NTLM not enabled 
   Users not configured to have access to “NAC” computer object
   
    

Here is an example of a successful bind to a DC:

SuccessfulBind

Generally what we do is perform a NACCTL restart and see what error is thrown during the attempt to join, from there you can get an idea of what may be going wrong, take a trace and try to fix.

Thanks

-Ryan

[Tomasz]

Hi Gabriel,

The authentication issue or even domain join issue?

What do you see in EAC engine logs? (could be looked at https://<NAC IP>:8444 if not directly under Linux CLI)

AFAIR once I had this and it turned out to be an LDAP search root issue (semicolon instead of comma in e.g. ‘DC=something, DC=else, DC=com’), XMC-based LDAP test was successful but in EAC engine logs I could see that it parsed the string in a way that it was looking for a glitchy domain name.

As a last resort, call GTAC.

Hope that helps,

Tomasz

[Gabriel_Bagita]

Hi guys,

did you solved the problem? We’ve a same one. We set the privileges according to the GTAC knowledge recommendation, but it’s not working. I tried to put the bindig account the the Domain Administrators group, but it didn’t help. I’ve tried to set it in two different environments,  but I have the same results at both. So I think, I’m doing something in a wrong way, or there is some other dependency, which is not described in the GTAC manual. When you have a solution publish it, please.

Thanks

Gabriel