We found out the user was logoning on the the RAS server with Cached creditals. We found out that he had a broken secure channel, with netdom and nltest, we was unable to get it back with the computer name of Proxy. This event was followed by event id 20049.
The following troubleshooting strategy could help:
Check for the group policy setting under Domain Security policy as well as under the Local Security Policy on the machine where user is getting authenticated (The machine where RRAS is installed)
Check the Local Security settings GPO under LOCAL POLICIES | SECURITY OPTIONS | LAN MANAGER AUTHENTICATION LEVEL. Make sure it is set to "send LM and NTLM responses."
Refresh the Group policy using Gpupdate from command prompt.
After changing the above setting try to establish the connection. To isolate the problem it would be better to disjoin and rejoin the RRAS server from the domain.
In our case I tested as follows:
NLTEST /Query is successful.
NLTEST /dsgetsite is successful.
PING to internal server is successful.
NSLOOKUP to internal server fails. (but it works on the W2K/Proxy2.0)
I changed the Name to RAS and moved the Ras server to a workgroup, rebooted, and then joined the domain with the new name and it worked and stayed on the Domain, and the clients was able to Ras into the server and get authenicated. Since this was a Proxy machine and Exchange was behind it we had to redo the proxy client and reboot the exchange server. I set the AUTHENTICATION LEVEL to "send LM and NTLM responses."
Also see: ME191854