So I keep getting this error but I'm not sure why. Both machines are running Win 7 Ultimate using the Network Authentication Layer option for added security. I have exceptions in the firewall for remote desktop and yet it will not work.Maybe this forum post helps: http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/981a30b8-0e46-49f9-a13f-095b124328fd
Does someone know why? Is there something I need to do in local security to get this enabled?
This one works great. I disabled the check mark on the profile asking for password expires; etc.. and works great.
Then I asked the user to come to my desk and changed the password! :)
I've run in this problem after inplace upgrade of W2k3 into w2k8
What I've found is that when You set "Log On To" to the user account and add a few computers remember to add the one that user is running mstsc from.
In other case You will get "The Local Security Authority cannot be contacted"
Assuming you have RDP setup correctly on the client and server:
My solution was to UNCHECK the 'Allow connections only from computers....' in System properties , Remote tab.
Working now.
Less secure? Yes. Less frustrating? Definitely.
I had the same error on my Azure virtual machine and a local virtual machine. I resolved this error by following the under given URL:
http://www.windowstechupdates.com/an-authentication-error-has-occurred-the-local-security-authority-cannot-be-contacted/
Hi
In my humble opinion, I think the the issue comes from the local accounts
I think that the local account is set to "User must change password at next logon"
Hope it will help some folks !
I know this is a really old thread. But I *finally* figured this out with what for me is the DEFINITIVE solution. I get the "local security authority could not be contacted" error too, when attempting to connect via RDP over the internet from a computer that is NOT a member of the domain. Removing NLA is just not an option, as I am just flat out not willing to sacrifice security for convenience. So here's the solution, assuming the user is NOT authorized to log onto every computer on the domain.
That is to say, you have identified in the user's account properties the specific computers they are allowed to log on to. If you change this to "all computers" the problem goes away. But it also sacrifices your internal security by allowing the user to log on to any domain computer - probably not desired. So what to do?
If remoting in from a computer that is not a domain member (such as your personal computer at home) then on the AD DS domain server open the AD Computers and Users applet. Then in the users container select/open the specific user account being used.
In the user account dialog under the Account tab, click the "Log On To" button. Now add the name of the non-domain computer they are remoting in from, and that solves this problem without sacrificing NLA or any other security.
If you're using health policies on the NPS, that just adds another layer of security, and I highly recommend it if you're going to allow users to log into domain computers remotely, from non-domain computers.
I had the same problem which was easily mitigated by disabling NLA for the remote connection (which is a trivial workaround) but the true reason for this error message was that the server could not reach the domain controller properly and would only
log me in with the cached credentials but the server could not verify the credentials with the domain.
This is what the NLA actually is supposed to do and it worked perfectly to the detriment of functionality.
Soultion: Please check the server for full connectivity to the domain (domain controllers).
i had the same issue pop up, though mine is on a domain. The problem was the comcast router that was recently replaced, which has no ability to turn off DHCP for ipv6, handing out incorrect IPV6 addresses. I had to isolate it behind a router, which immediately resolved my issue.
Check your logs for a termDD error and it will list the IP address, that may lead you somewhere.
I starting having this issue after I updated to Windows CU 1703 from Windows 10 Anniversary edition.
The PC is NOT part of a domain.
I can't figure it out.
------ Sean J Vreeland Seattle, WA
For me I couldn't even do a reset of the password.
I had to check the box that says "Password Never Expires".
If it is checked my user can login
If it is not checked .... An authentication error has occurred the local security authority cannot be contacted.
Weird....!!!!!
It has literally taken me days to figure out my specific issue for my specific setup. First the setup.
Runnint a Server 2012 Standard domain controller with Group Policy and Hyper-V.
In AD DS some users are set up to only be allowed logon to specific computers both locally and remotely via RDP.
The Hyper-V is running a Windows 10 Pro virtual machine also joined to the domain.
Then I have another box with Server 2008 R2 that is a member server jointed to the domain. This box is running NPS and is also set up as the RD Gateway server.
Only users that are allowed to log on to specific computers locally, can also do so remotely via RDP.
When remoting in to VM01 from either the 2012 or 2008 server systems, it was no problem. However, when they tried to remote in from their home computer, the following error was generated.
An authentication error has occurred. The local security policy can not be contacted
There's no way I'm undoing the requirement for Network Level Communication. So I dug, and I dug, and I dug. I finally found the gold at the bottom of this hole.
The solution for my specific situation was to go into AD DS and add the name of the remote computer to the list of computers the user is authorized to log on to. It doesn't matter that the computer they are connecting from is not on the domain and is sitting in their living room at their house 30 miles away. Their domain login has to be authorized to log on to their personal computer at their house - even though of course, it never will. So if they try to remotely log in from another computer, they can't. If they get a new computer and it does not have the same network name as their old computer, then they can not connect to their domain computer at work over the internet via RDP with Network Level Authentication.
Of course, there is another option that for me I won't use. It's to allow the user to log on to any computer.
Hi All Osman's steps solved this issue but I will like to make it very simple.C
Right click on Computer/ This Computer,
Select Properties
On the Top Left, Select Remote SettingsThis will Take you to Remote assistance panel.
From the three Options,
uncheck the following:
Don't Allow remote connection to this Computer.
And Check: Allow Connection from Computers Running any version of Remote Desktop.(Less Secured)
Make sure the last Option is Unchecked: Allow connection only from computers running Remote Desktop with Network Level Authentication (More Secured).
Click Apply and OK.
Hope this helps.
Hi all,
For me, it was on a tiny network that had two domain controllers, but one crashed a while ago, and I had no plans to replace it. I hadn't removed it from Active Directory, though. I was working remotely and logged in to the one remaining DC, and (thankfully) also logged in to my admin workstation as the domain administrator, with RSAT.
I had to reboot the DC, and when it came back up, I got this error trying to connect with RDP. From my admin workstation, I removed the old DC from Active Directory Users and Computers, and from Sites and Services. I also inspected DNS, and found that the IP address for the old server was listed under gc._msdcs.domain, so I removed that.
The problem was instantly fixed. What had happened, was the LSA was finding the missing DC when looking for a GC/ADDS server.
Hope this helps.