Remote Desktop denies login
Hi all,
I recently upgraded a client from Windows 7 to Windows 8.1 (let's call it CLIENT_X). The computer is member of a domain.
In this domain, there is a user (let's call him RESTRICTEDUSER), which is a member of the default group Domain-Users.
The user is allowed to login only on the machine CLIENT_X by the "logon to" property in AD Users & Computers.
Before the upgrade, I was able to connect to the CLIENT_X using the username RESTRICTEDUSER and appropriate password from another machine (where I was logged in using another username):
CLIENT_A (User Admin) --> Remotedesktop --> CLIENT_X (User RESTRICTEDUSER)
Now, after the upgrade to Windows 8.1, I get the following error message from remote desktop:
"The system administrator has limited the computers you can log on with. [..]"
When I add the machine I am connecting from (CLIENT_A) to the list of machines where RESTRICTEDUSER is allowed to logon to, the connection works. Of course, the user is then also able to logon directly to CLIENT_A, which is not intended.
Therefore, I am asking for help, how to restore the old behaviour.
November 19th, 2013 11:16pm
Hi,
Sorry for my dilatory reply, From the error"The system administrator has limited the computers you can log on with", it indicates that the problem caused by the permission of the computer you log on with, CLIENT_A. Say in other words, you couldn't log to
CLIENT_X from CLIENT_A though RDP.
Firstly, I would like to suggest you follow the steps below to make a test.
1. Try to use different computer to remote CLIENT_X though RESTRICTEDUSER for test.
2. Try to use other user account log on to CLIENT_X from CLIENT_A.
Though the test above, may be we can find the root cause of this problem.
Secondly, please check CLIENT_X RDP properties, make sure the user RESTRICTEDUSER is in the list.
Thirdly, this problem also can be caused by RDP version compatibility, please check and upgrade RDP Client to be latest for test.
November 25th, 2013 5:39am
Hi,
Sorry for my dilatory reply, From the error"The system administrator has limited the computers you can log on with", it indicates that the problem caused by the permission of the computer you log on with, CLIENT_A. Say in other words, you couldn't log to
CLIENT_X from CLIENT_A though RDP.
Firstly, I would like to suggest you follow the steps below to make a test.
1. Try to use different computer to remote CLIENT_X though RESTRICTEDUSER for test.
2. Try to use other user account log on to CLIENT_X from CLIENT_A.
Though the test above, may be we can find the root cause of this problem.
Secondly, please check CLIENT_X RDP properties, make sure the user RESTRICTEDUSER is in the list.
Thirdly, this problem also can be caused by RDP version compatibility, please check and upgrade RDP Client to be latest for
November 28th, 2013 12:56am
Hello,
I am also having the same when logging into Windows 2012 R2 servers from Windows 8.1. Windows 7 behaves. We use the "log on to" permission feature in active directory to control which servers and computers users can log into. This works fine until
Server 2012 r2. Add the server name as per normal and "The system administrator has limited the computers you can log on with" continues. Allow the user log on to access to all computers and it works. Can anyone from from Microsoft confirm the behavior
and whether its a bug or a change?
-
Edited by
largechicken
Thursday, November 28, 2013 10:06 PM
November 28th, 2013 10:06pm
Hello,
I am also having the same when logging into Windows 2012 R2 servers from Windows 8.1. Windows 7 behaves. We use the "log on to" permission feature in active directory to control which servers and computers users can log into. This works fine until
Server 2012 r2. Add the server name as per normal and "The system administrator has limited the computers you can log on with" continues. Allow the user log on to access to all computers and it works. Can anyone from from Microsoft confirm the behavior
and whether its a bug or a change?
-
Edited by
largechicken
Thursday, November 28, 2013 10:06 PM
November 29th, 2013 1:06am
I tried logging on to the CLIENT_X from different platforms using the username RESTRICTEDUSER. Here is the result:
Windows 7 and Windows Server 2008 R2 give the error message "The Local Security Authority cannot be contacted.", although the password is set to never expire.
Windows 8.1 returns the already known "The system administrator has limited the computers you can log on with.".
December 2nd, 2013 5:32pm
Can someone from Microsoft confirm the problem and tell us, whether this is a bug or a new, undocumented feature?
December 11th, 2013 4:35pm
I am having the same issue and I have been doing some testing of my own.
If I set account restrictions (log on to) for a specific user (because I want him to log on only to certain servers and not others), from Windows 8.1, I am getting error message: the system administrator has limited the computers you can log on with.
The only way I have found to bypass this issue is to include in the "log on to" section the name(s) of the computer(s) "from which" the user is allowed to log on.
Of course, this behavior doesn't exist in Windows 7 or Vista on the client side and does not exist if Remote Desktop server is Windows 2008 R2. Only the combination of Windows 8.1/Windows Server 2012 R2 is having issues.
As far as I am concerned, I cannot go to production with this issue since a user may log on from several computers to a limited number of servers. The goal is to limit where a user can log on, not from where he logs on.
March 12th, 2014 9:00pm
Hello, I have the same problem with our terminal server farm 2012R2 and Windows 8.1 clients.
Is there already a solution?
Greeting Hubert
April 10th, 2014 6:55am
Could any body try with Windows 8.1 Update 1 ?
April 15th, 2014 11:29pm
Could any body try with Windows 8.1
April 15th, 2014 11:34pm
There is another thread on this, but no solution:
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2012/Q_28386816.html
May 6th, 2014 1:34pm
Having the exact same issue. Any updates or news with regards to this? Thanks.
June 2nd, 2014 1:32pm
This question is NOT answered. This is a clear bug!
Problem: Windows is applying log on rules defined for the TARGET computer to the SOURCE computer.
-
Edited by
AnguelS
Tuesday, July 08, 2014 12:30 PM
July 8th, 2014 12:14pm
This question is NOT answered. This is a clear bug!
Problem: Windows is applying log on rules defined for the TARGET computer to the SOURCE computer.
-
Edited by
AnguelS
Tuesday, July 08, 2014 12:30 PM
July 8th, 2014 3:14pm
I got the same issue as well. A lot of other sites state that it is an error on both Windows 8 and Windows Server 2012.
The only workaround that I found to have worked would be creating a GPO for the computers to restrict or allow access to a security group.
How I did it was, create the relevant security groups for the users you would either like to restrict or allow and another group for the computers. Create a new GPO in the GPM and in the Security Filter you add the computer security group. In the GPO you
go to Computer Configurations > Policies > Windows Settings > Security Settings > Local Policies/User's Rights Assignment. Then change the services either: Deny log on through Terminal Services or Allow log on through Terminal Services (depending
on if you want to deny or allow) select define these policies and then add the user's security group. Click Apply, then enforced the rule. Restart the computer and then it should resolve the issue.
I had to also remove the computers on the user's profile on they can log on to for it to work also.
July 16th, 2014 6:29pm
How about Microsoft finally fixing this stupid bug? Nobody seems to care there....
July 21st, 2014 11:50am
Hi, schalli
One of our servers is running Windows Server 2012 R2 and having exactly same issue. Although I don't have a exact solution for you, I have been using another workaround (sort of).
Basically I used an administrative login, which has remote access to many servers (so no log on restrictions), to log onto this server first. Then I can use task manager users section to connect to the other login (which has log on restriction).
Obviously this requires the restricted account is already logged in that server, which it is always the case in our situation and can also be done through vsphere console.
Hope this helps.
Ben at Tassie
July 29th, 2014 5:18am
Hi
We have same problem. I'm trying to restrict outsourced VPN users to which server can login and this "Log on to..." clearly doesn't work as it should.
Any news on this issue? Did someone report this to MS?
We have Windows 2012 R2 domain controllers.
Clients are Windows 8.1 and Windows 7 and both have same problem.
September 5th, 2014 4:21pm
Hi All,
I'm creating a case at this moment. I will add this discussion to the URL's
Kind regards,
Marcel
September 11th, 2014 2:51pm
Great, thank you!
Will you please keep us posted about Microsofts reaction to you case?
September 11th, 2014 2:55pm
I noticed an issue with the RDP files from Azure to connect to a given virtual machine
if I moved the file from my download folder to my desktop and tried to open it, it balked
so I changed my download folder to the desktop, and then downloaded it again and it work
seems that moving the RDP file has some security mode attached to it, likely to prevent it from being copied by malware etc. I have looked at this briefly, but there are lot of posts says Google
September 11th, 2014 3:08pm
Hi,
could you specify "balked"? What happened exactly? Did you get the same error message as we did, i.e. "The
system administrator has limited the computers you can log on with [..]"?
September 11th, 2014 3:12pm
Hi,
could you specify "balked"? What happened exactly? Did you get the same error message as we did, i.e. "The
system administrator has limited the computers you can log on with [..]"?
my credentials were refused
September 11th, 2014 3:16pm
Hi Vegan Fanatic,
I think you are mixing another issue into this thread. We are talking about on-premise solutions. It has nothing to do with .rdp files. I for one am using mstsc.exe and just configure the connection manually. Also there are no TS Gateways anywhere in my
environment. As schalli asked, Did you receive the following error?:
"The system administrator has limited the computers you can log on with. Try logging on at a different computer. If the problem continues, contact your
system administrator or technical support."
Or something else?
Kind regards,
Marcel
September 11th, 2014 4:02pm
Will do that. Create a B case so I should be contacted in 1,5 hour from now.
Kind Regards,
Marcel
September 11th, 2014 4:03pm
The OP did not make that clear, and this is the only issue I have encountered with remote desktop
using a local server etc, I have not experienced problems
if you are not using an administrator account, you will have to fiddle with policies
September 11th, 2014 4:04pm
All,
From http://mobile.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2012/Q_28386816.html I found another workaround than the one I am using right now (Allow logons from all computers). It seems that if you add the source server
(where MSTSC.exe is run from) to the LogonTo attribute you can connect. This is working in my environment. This is a bad solution which is imho not in line with wat the attribute should do. You should be able to log on to the server stated without checking
the source for this access. Our users log on with a desktop account on the Terminal Server and use admin credentials to connect to an application server for management.
Our TS's are quite elastic so we cannot use some sort of scanner which checks every admin accounts LogonTo attribute if there is a new TS which may be used to launch connections. Also I see VPN as a use case in this thread. This van come from any computer
in the world, we cannot add all those names to the LogonTo attribute, 8192 limit for one ;)
Kind regards,
Marcel
September 11th, 2014 4:11pm
All,
Just got contacted by a Dutch Support Engineer (which is no problem, I'm dutch too) and explained the situation. He said it was a clear story and he will start investigating. Just waiting for the scope agreement...
Cheers,
Marcel
September 11th, 2014 4:47pm
Marcel excellent!, i hope they fix this nasty bug by next month patch schedule :)
-
Edited by
ilukeberry
Friday, September 12, 2014 1:23 PM
September 12th, 2014 1:23pm
Marcel excellent!, i hope they fix this nasty bug by next month patch schedule :)
-
Edited by
ilukeberry
Friday, September 12, 2014 1:23 PM
September 12th, 2014 4:23pm
All,
At the moment Microsoft seems to be moving into the 'This behavior is by design' corner of the playing field. I'm still asking questions as to find what decision has made the LogonTo field also needs to be populated with the clients name.
Can you guys please give me use cases where this behavior is unwanted? I have:
- External Consultant connecting over RDP to a server from his own laptop.
- Using seperate desktop and administrative accounts.
I also tested the RDP connection with and without NLA, this made no difference on Win2012R2.
Kind regards,
Marcel
September 12th, 2014 5:04pm
Hi, thank you for reporting, it would be awesome having it fixed.
My use case is the following:
We have several virtual servers, where only a restricted group of users should login to.
Users are logging in to these machines using a username that is NOT the same as the one they logged on to the machine locally.
They are not allowed to logon locally on any other system. This has to do with security issues and access restrictions.
In the past, this worked great by setting "LogonTo" accordingly.
Anyway, iff we have to include the source machine into the LogonTo list, it undermines the approach to restrict users to certain systems.
It might be possible to use a workaround here, but what would be the use of LogonTo now?
Besides, that change in behaviour was never documented..
September 12th, 2014 5:14pm
If you want my opinion, this is not by design. It makes absolutely no sense. Clearly a bug.
September 12th, 2014 5:19pm
All,
Just a quick update. The case has been escalated internally by Microsoft. The Escalation Engineer has been able to reproduce the behavior. Logfiles have been created and are being analyzed. I hope to get a definitive answer within a few days. I will keep
you guys posted.
Cheers Marcel
September 18th, 2014 4:15pm
Hi Marcel,
Is anything new in this case.
Thx Pete
October 21st, 2014 11:56am
Hi Pete and others,
I've been told that this is indeed identified as a bug. There will be a bugreport and my case will be linked to that. Also the case has been marked 'free of charge' which makes my Dutch heart happy ;).
There is also a workaround presented, however that does not fix the issue for my environment.
On the RDP server side set HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer"
Default is 1 (SSL). Set this to 0.
Investigation will still continue.
Kind regards,
Marcel
October 23rd, 2014 10:50am
AWESOME!!!! :) i hope they will fix this and patch it ASAP :)
October 27th, 2014 5:36pm
This is really starting to annoy me as we bring more Windows 8 machines on line.
Has anyone had an update on when Microsoft might get around to fixing the issue
January 23rd, 2015 9:18am
I haven't finalized my testing but was able to reproduce this on my win 8.1 PC RDP into 2012R2 inside my domain. I added the server to the list of computers I can log on to and got the exact error message. I went and added the pc to the list I am
using to RDP to the server and bang was able to log on. I just need to test external VPN users now
February 5th, 2015 2:12pm
You gotta love Microsoft... read this...
I had this problem. Used MSDN support. After 9 weeks they told me "it is a bug, but we don't have the resources to fix it". They told me "maybe MS premier support can do something for you" Me: "how much" - MSDN: "15,000
euros per year at least" - Me "*gulp*"
So I asked a befriended admin who happens to have a premier support contract to have them work on it... after (you gessed right) another 9 weeks, MS told me: "this is expected behavior, it is by design". To quote the engineers:
The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP it is more secure.
Previous behaviour is that it allowed fallback to no NLA when NLA failed.
If NLA is set to required on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which cares about where you log on from as per above attribute.
In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!.
Available options here:
1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL). -> Set this to 0.
2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
3. Add the source server that the user is connecting to into the LogonTo field.
Ain't that cute? So it's been no bug all the way. Win7 and Server 2008R2 are the systems with buggy/insecure behavior... LOOL. So I had him tell them the following:
"Dear Support,
thank you, it seems there is no easy way out. Either we reduce the security one way or the other.
Let's recapitulate: After all this time you found out, it's expected behavior and call it more secure than with previous versions.
I see the point, but for the use case of users remoting in to our terminalserver ("TS") from different workstations at a remote location/remote company that we don't know the name of, this is actually less secure than before.
Why do I see it this way? Because the check that is performed (->may the user log on from this workstation?) can be easily overcome. The check just looks at the name of the machine, not even does that machine need to be a member of our domain. So if
someone knows, he can easily overcome that check by renaming his machine to an already allowed machine so that restriction is pretty useless in this case. It cannot be used to limit the user to use a set of known machines to connect *from* as we don't even
know those machines in the first place, they are not members of our domain but of a remote domain, another company. They logon to their machines using User A and logon to ours using user B, only B is a member of our domain.There isn't and never will be a domain
trust.
So instead of using your proposed workarounds of which 1 and 2 reduce the security and 3 is not possible since we do not know the names of the machines that will be used in the future (but we only know the username), we will stick with our workaround and
allow that users' accounts to logon anywhere (which is most undesirable!). To get back some security, we applied policies that disallow the logon to any system but the TS via GPO. And we applied firewall policies at the TS that won't let him get anywhere.
Conclusion: The "workstations allowed" list has its use case: limiting it, you can keep people away from logging on *to* machines so they cannot influence or spy on these systems. However, from what we have here, from the perspective of a TS, limiting
what machines a user can connect *from* is not beneficial for security, in the end, quite the contrary is the case. Do me a favor and reconsider!"
They have not answered so far. maybe in another 9 weeks, maybe never? My guess is "never".
February 11th, 2015 11:50pm
I have news for you. Yesterday, I already wrote a huge text. After submitting it, it read "your contribution is being reviewed" - for whatever reason...it did never appear although I can see it in my activity list...
That's why I'll keep it short and sweet this time.
Folks, this is by design. MS premier support told me that after weeks of reviewing the problem. I know it makes no sense at all, but it is how network level authentication is supposed to work after they enhanced it in win8.x/2012.
--
Let's see if this contribution get's listed. If so, I'll add more.
February 12th, 2015 6:20pm
Ok, it got listed. Then I'll add what MS premier support had to say:
The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP it is more secure.
Previous behaviour is that it allowed fallback to no NLA when NLA failed.
If NLA is set to required on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which cares about where you log on from as per above attribute.
In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!.
Available options here:
1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL). -> Set this to 0.
2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
3. Add the source server that the user is connecting to into the LogonTo field.
February 12th, 2015 6:24pm
Ok, it got listed. Then I'll add what MS premier support had to say:
The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP it is more secure.
Previous behaviour is that it allowed fallback to no NLA when NLA failed.
If NLA is set to required on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which cares about where you log on from as per above attribute.
In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!.
Available options here:
1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL). -> Set this to 0.
2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
3. Add the source server that the user is connecting to into the LogonTo field.
-
Proposed as answer by
AnguelS
Tuesday, February 24, 2015 11:03 AM
February 12th, 2015 11:18pm
Ok, it got listed. Then I'll add what MS premier support had to say:
The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP it is more secure.
Previous behaviour is that it allowed fallback to no NLA when NLA failed.
If NLA is set to required on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which cares about where you log on from as per above attribute.
In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!.
Available options here:
1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL). -> Set this to 0.
2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
3. Add the source server that the user is connecting to into the LogonTo field.
-
Proposed as answer by
AnguelS
42 minutes ago
February 13th, 2015 2:18am
Ok, it got listed. Then I'll add what MS premier support had to say:
The RDP client behaviour is changed in 8.1 and it now it enforces NLA which uses CREDSSP it is more secure.
Previous behaviour is that it allowed fallback to no NLA when NLA failed.
If NLA is set to required on the RDP server side then it is expected that the client connection will fail due to the workstation not being in the list. NLA is using Kerberos or NTLM authentication which cares about where you log on from as per above attribute.
In addition if you take RDP out of the loop and browse to a share, for example, on the same RDP server from any OS workstation which is not in the <log onto> list it will also fail with the same error STATUS_INVALID_WORKSTATION!.
Available options here:
1. Use this setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-tcp "SecurityLayer", Default is 1 (SSL). -> Set this to 0.
2. On the client workstation, open the RDP file with Notepad and add the string enablecredsspsupport:i:0
3. Add the source server that the user is connecting to into the LogonTo field.
-
Proposed as answer by
AnguelS
Tuesday, February 24, 2015 11:03 AM
February 13th, 2015 2:18am
Many thanks, Ronald!
IMHO the best workaround is #2. Here only a single enablecredsspsupport:i:0 line has to be added to the client's Default.rdp.
#1 would require to do it on each RDP server machine.
#3 would require to do it for every account and additionally you would allow that account to log in to the source computer which is what I absolutely don't want.
Anguel
-
Edited by
AnguelS
24 minutes ago
February 24th, 2015 6:04am
Many thanks, Ronald!
IMHO the best workaround is #2. Here only a single enablecredsspsupport:i:0 line has to be added to the client's Default.rdp.
#1 would require to do it on each RDP server machine.
#3 would require to do it for every account and additionally you would allow that account to log in to the source computer which is what I absolutely don't want.
Anguel
-
Edited by
AnguelS
Tuesday, February 24, 2015 11:22 AM
February 24th, 2015 11:02am
Many thanks, Ronald!
IMHO the best workaround is #2. Here only a single enablecredsspsupport:i:0 line has to be added to the client's Default.rdp.
#1 would require to do it on each RDP server machine.
#3 would require to do it for every account and additionally you would allow that account to log in to the source computer which is what I absolutely don't want.
Anguel
-
Edited by
AnguelS
Tuesday, February 24, 2015 11:22 AM
February 24th, 2015 2:02pm
Unfortunately, the "Log on to..." account restriction does not only apply to RDP but also to
normal network shares on the server, again I get the error message saying that the user is not allowed to log on from this (source) workstation if the source workstation is not explicitly entered. Very annoying.
-
Edited by
AnguelS
Monday, March 02, 2015 2:16 PM
March 2nd, 2015 2:11pm
Unfortunately, the "Log on to..." account restriction does not only apply to RDP but also to
normal network shares on the server, again I get the error message saying that the user is not allowed to log on from this (source) workstation if the source workstation is not explicitly entered. Very annoying.
-
Edited by
AnguelS
Monday, March 02, 2015 2:16 PM
March 2nd, 2015 2:11pm
Anguel, you finally understood how it works.
March 2nd, 2015 2:16pm
Hello all.
I upgraded a few of my domain computers with Windows 10 and one of things I wanted to test was this issue on Windows 10 and guess what: it seems to be fixed!
Can someone else try it as well and report back? I will make a few more tests myself in the days to come.
Benoit
August 21st, 2015 9:56am
Benoit, this is not fixed on my win10 x64 enterprise.
August 31st, 2015 6:55am
False hope... I just realized that I had set the account I was testing with to bypass the problem and as soon as I put back the restrictions, it ceased to work...
Benoit
September 1st, 2015 9:18am