@coremon
I ran into this issue this week as well. Customer had disabled LM / NTLM / SMBv1. Its not documented that NTLMv2 is supported with clearpass, and I have requested this be udpated as well.
It looks like the SMBv2 / SMBv3 patch changed the implementation of Samba and now calls to AD require RPC_NETLOGON over 135/tcp. I would need to install a new instance of clearpass without the SMBv2 / SMBv3 patch to determine exactly where the RPC call happens. When comparing to my freeradius wireshark captures, the RPC calls appear to be happening over 445/tcp (SMB).
I was recieving the same Timeout Message as you stated as well in access tracker, and spent a few hours doing a review in exported debug logs between working and non-working. Nothign seemed to be out of the ordanary.
NT_STATUS_IO_TIMEOUT: {Device Timeout} The specified I/O operation on %hs was not completed before the time-out period expired. (0xc00000b5)
Due to the strict firewall rules, we had 135/tcp open, although before updating to SMBv2 / SMBv3 patch there were never any issues of authetnicaiton, even running on 6.6.7. I do know that mschapv2 used an ntlm wrapper over samba, and this was the legacy way of performing authetnicaiton with NTLM (windows AD).
To my understanding on reviewing Samba, since the ntlm_auth binary doesn't support NTLMv2, its required to make calls directly from Samba vs using the mschap ntlm wrapper. Due to trying to get a better understanding, I had attempted to recreate this in my lab with freeradius (what I typically use as a radius server).
After I had disabled LM / NTLM / SMBv1 on my AD server, I had tested with my freeradius server, and NTLM auth was failing in the debugs. This was due to freeradius not supporting NTLMv2 nativly. I did find forums from 2012 from the Samba Implementation that if I wanted to install from source code, I could change a couple flags on a function and I should be able to get it to work. Im not going to to go that extent to test, although this proved to me that NTLM was no longer being accepted by AD.
When I tested with the clearpass patch 6.6.7 and SMBv2 / SMBv3, I was successful with passing EAP-PEAP (mschapv2) info to AD.
Im not sure exactly how this was implemented under the hood with Clearpass, although there is deffiently a change on how samba interacts with Active Directory after the patch is applied.
In my caes when you would see 135/tcp for the RPC_NETLOGON call in wireshark, the AD server would reply wiht the high end RPC port and then when clearpass would attempt to send traffic, TCP retransmits were observed.
In access tracker this is when you would see the NT_STATUS_IO_TIMEOUT error code. Depending if the customer has static RPC or dynamic, its always easiest to just add the high end range. You can never be sure if customer will change those ports.