In my case, to fix this, I only changed the order of network cards (LAN and WAN) of my MS ISA server.
We recently upgraded our PDC to 2012 and out the blue our 2003 servers started receiving this error. This registry modification worked for me: EV100522
(Event id 1219).
In my case it was a DNS issue. The Windows 2003 Server with the problem had the wrong IP address cached for the DC. Running ipconfig /flushdns resolved the issue.
The Netlogon service was paused for some reason. I resumed it and was able to logon.
On Windows 2003 R2 I had the same issue (could log on with local admin but any domain account failed with this error). In my case it ended up being an app had taken all the UDP ports. From this article EV100370
(Unable to obtain Terminal Server User Configuration. Error: Access is denied) suggestions I ran netstat -ano and found that Java had taken all of them (it was part of IBM Websphere). I killed the process, started the service and without rebooting the server was working again.
I accidently disabled the "Client for Microsoft Networks" on the front-end NIC Team. Enabling it corrected the issue.
Access to user's domain was prohibited by a firewall. This solved the problem for me
1.) Open up regedit on the server (Start-Run-Regedit)
2.) Follow this string: HLM\System\CCS\Control\Terminal Server
3.) Go to Edit/New Dword
4.) Name the new Dword the following: IgnoreRegUserConfigErrors
5.) Right click on IgnoreRegUserConfigErrors and choose modify
6.) Make the value data=1
I had set the TCP/IP NetBIOS Helper Service to Manual. I set to Automatic and restarted and I was able to connect via RDP.
In my case the Terminal Services server time was not synchronized with the domain controller. Adjusting the time fixed the problem.
In my case, I could log in via the console with my domain credentials, but RDP would error out with "Logon rejected for <user> Unable to obtain Terminal Server User Configuration. Error: The RPC server is unavailable."
I could browse to other computers via Network Places, but was getting Access Denied when I'd try to browse to the problem machine from another box. I was also getting Event ID 11167 from DNSAPI, Event ID 5719 from Netlogon, and Event ID 18 from W32Time. I tried every fix out there from all of the different sites (including Eventid.net) with no success. Finally, I looked at Winsock2 and noticed that it was corrupt! The server was a Windows 2003 Enterprise SP2 and I ran "netsh winsock reset" at the command prompt, which fixed the issue. In my case, I had to re-add the server to the domain, but that's only because I''d just removed it to troubleshoot. You may be able to get away with just resetting winsock and rebooting the server. You can find more information about troubleshooting Winsock problems at ME811259
I noticed this problem on my PDC, I could not login remotely to other servers using the domain, the event log was also posting many DNS related errors. I added "everyone" to the sysvol/policies folder as permissions with only read and execute permissions, also domain admins, I had also earlier removed and added the DNS component, now everything is fine... It appears that it was permissions related and possibly also wrong DNS entries.
I had the same problem on a Windows Server 2003 R2 Box. In my case, after checking all mentioned solutions, it turned out the "Terminal Server" component was not enabled (Start -> All Programs -> Control Panel -> Add/Remove Software -> Add/Remove Windows Components). After I enabled the "Terminal Server" component and restarted the server, everything was working properly.
This event happened after doing a DCPromo on a remote server to remove AD. The event was tied with EventID 1053 from source Userenv. After rebooting we could no longer get in using the domain profile but could log on to the local profile. To correct this, we created a temporary DNS zone pointing to the main office domain controller so when logging on it would check with the main office for credentials.
In my case, restarting the Netlogon service solved the problem.
In my case, the domain controller was no longer authenticating clients. The terminal server was unable to log in users for the local site through terminal services but the workstations were already authenticated to the domain. Clearing the domain controller logs and restarting the DC fixed the problem.
- Error: "The RPC server is unavailable" - This problem occurs when users with the same user name are hosted in different domains and one of those users has logged on to the terminal server and has created a roaming profile. See ME821929
for a hotfix applicable to Microsoft Windows Server 2003.
- Error: "The network address is invalid" - In our case, the problem was solved by adding a DNS address to the local network card.
In my case, a simple Group Policy Update on both (all) servers solved this problem. From a command prompt, type "gpupdate".
I experienced this error on a W2K3 server with Active directory. The DNS service was starting after the Netlogon service. Forcing Netlogon to wait for DNS cured this problem. Modify the HKLM\system\CurrentControlSet\services\netlogon registry key and add "DNS to the DependOnService value. See ME193888
We received this event along with event 40960, 40961, and 1053 in the application log. The server lost connection to the DC and all accounts in the admin group showed just as their SIDs. We found that restarting the Site Server Content Deployment (CRS) service fixed the problem.
In my case, Client for Microsoft Networks was not enabled. Enabling it solved the problem.
In my case, disjoining the machine from the domain and re-joining it solved the problem.
See "Veritas Support Document ID: 238210" if this error appears when you try to backup a remote Windows NT machine.
provides a hotfix that might resolve this problem.
My AD environment is as follows:
All DCs for domain.com in Site1.
All DCs for child.domain.com in Site2.
Comp1 is a Win2k3 SP1+latest hotfixes member server of domain.com. Comp1 is located in Site1. User1 is a member of child.domain.com.
User1 is trying to logon via Remote Desktop to Comp1 and is getting an Access Denied error (Error code 5
The System log contains EventID 40960 from source LsaSrv, message “No authority could be contacted for authentication. (0x80090311)”.
The Application log contains EventID 1219 from source Winlogon, message “Logon rejected for <user name>. Unable to obtain Terminal Server User Configuration. Error: Access Denied”.
It turns out that the error was caused by a PIX configuration on the Site1 side. We had class-map defined as class_http, and this class contained ports TCP 88 and 80 to inspect as http traffic. Removing Kerberos (TCP 88) port from http inspection resolved problem.
I had this error exactly as Peter Hayden described. In my case, the cause of this error was related to SMB signing. See ME839499
for more details. You should disable signing on all DCs in the enterprise, or enable it and implement CA (Certificate Authority).
I resolved this issue by changing the Terminal Server Licensing Mode from per Device to per User using Group Policy Editor. (Computer Configuration -> Administrative Templates ->Windows Components -> Terminal Services -> Set Terminal Server Licensing Mode).
In one case, this event appeared when I could not connect to a Windows 2003 SP1 computer via Remote Desktop Connection. This is believed to be due to Group Policy changes. I could ping this computer from other computers in the domain, but when I tried to browse it through My Network Places, I got an "Access Denied" dialog box. When I tried to browse other computers through My Network Places from the computer with the problem, I was prompted for a user name and password, which were never accepted.
In order to fix all of these problems, it was necessary to remove and re-add the computer to the NT domain. I could not add it to the NT domain until I had reset computer security.
To reset security from a command prompt type:
cd /d %windir%\system32
secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose
Check the results in: %windir%\security\logs\scesrv.log.
This takes quite a while to run. It also works on Windows 2000/XP. Errors due to missing files can normally be ignored. Restart the computer.
In usrmgr of the terminal server check if the group of users can logon locally on this server (Policy User Right).
This problem began when SP1 was installed on a 2003 Terminal Server. Any user authenticating to a MIT Kerberos realm (not AD) will see the error. The workaround described in ME815266
corrects the problem, but the available hotfix does not.
I found that this was a problem for me when I was accessing a multihomed box with NetBIOS removed from one of the NICs (even though it was not the interface I was connecting to). I added the Windows Networking stuff back on to said NIC and I was able to log on with TS ok again.
Check to see if the TCP/IP NetBIOS Helper Service is started. If the service is not started, then start it and check to see if the problem is fixed. In my case, this solved the problem.
This problem occurs if the server is multihomed (a box in a DMZ also attached to a service network) and the NIC bound to terminal services is not the first adapter in the binding / provider order. Open Network connections and go to Advanced Settings. Examine the connections window on the Adapters and Bindings tab. Ensure that the NIC you have set RDP to answer on is the top NIC in the order.
- Error: "The specified domain either does not exist or could not be contacted" (Error code 1355
) - There is an additional error message about not being able to retrieve the Terminal Services User Configuration. We found this problem on a member server in a trusting domain that was behind the firewall. All the necessary ports were open to allow domain authentication (SWISS CHEESE MODE ON). When logging into the console, no problem. When logging in through a terminal session that crossed the firewall (using account from the trusted domain in both cases) either unable to authenticate at all or long time and logged on with Cached credentials. For whatever reason, the new PIX firewall that we just installed was denying protocols that were explicitly allowed. The only way to get it to work was allow everything. We will be trying to call Cisco to work out the issue, but right now, we are having to have an open pipe from the DMZ to the Internal network effectively to get it to work as the management thinks it needs to work.
This is also a permissions/access violation error. Check the permissions on the local drive of the Terminal Server. Drive “C” must have read/list/execute for Users.
. It could be that the Terminal Server cannot access the user profiles and there is a policy restricting their access to terminal services if that is the case. The error description specified in the event may provide additional clues on why the profile could not be accessed.
Error: "Access is denied" - For generic information about "Access denied" see the link to Error code 5