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.

Free Windows Admin Tool Kit Click here and download it now
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
Free Windows Admin Tool Kit Click here and download it now
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.".


Free Windows Admin Tool Kit Click here and download it now
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.

Free Windows Admin Tool Kit Click here and download it now
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 ?
Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
May 6th, 2014 1:34pm

For the time being, I have decided to use the following approach: http://4sysops.com/archives/deny-and-allow-workstation-logons-with-group-policy/
June 2nd, 2014 10:36am

Having the exact same issue. Any updates or news with regards to this? Thanks.
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2014 1:32pm

For the time being, I have decided to use the following approach: http://4sysops.com/archives/deny-and-allow-workstation-logons-with-group-policy/
June 2nd, 2014 1:36pm

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
Free Windows Admin Tool Kit Click here and download it now
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.

Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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
Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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.
Free Windows Admin Tool Kit Click here and download it now
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

Free Windows Admin Tool Kit Click here and download it now
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 :)
Free Windows Admin Tool Kit Click here and download it now
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
Free Windows Admin Tool Kit Click here and download it 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.

Free Windows Admin Tool Kit Click here and download it now
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
Free Windows Admin Tool Kit Click here and download it now
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
Free Windows Admin Tool Kit Click here and download it now
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


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
Free Windows Admin Tool Kit Click here and download it now
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
Free Windows Admin Tool Kit Click here and download it now
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.
Free Windows Admin Tool Kit Click here and download it now
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.
Free Windows Admin Tool Kit Click here and download it now
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

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics