Policy issues preventing access to RDP

[cbrookhart]

I have administrative access where I work. I suspect that a policy issue got pushed out that seemingly only affects me, since other admins are able to do what I am about to describe.

 

If I need to remote into the server, the normal practice was to login to my workstation with my user Common Access Card (CAC) and then insert my Domain Admin (DA) CAC. I would open RDP and insert the name of the server. This process worked each and every time up to a certain point. Now when I try to do the above, I get an error stating "Connection denied because user account is not authorized for remote connection." I think what's happening is that the certificate being passed for authentication is the one from my user CAC and not the DA CAC. When I select the more choices option in RDP, I can see my user certificate and my admin certificate.

 

If I needed to remote into another workstation, I would follow the same procedure as above, but instead use my Workstation Admin (WA) CAC. The error I get when trying to connect to another computer is "The system administrator has restricted the types of logons (network or interactive) that you may use.

 

As a workaround to connect to another workstation, I have to select the switch accounts option on the start menu and login as a WA and then run RDP.

 

I've tried using a different computer, I've tried different card readers, I've tried moving the card readers to different USB ports, I've tried forcing group policy updates, and just recently I reimaged my computer with a supposed newly updated image. I don't know if the new image is going to work or not because the card readers don't recognize the card. In other words, the light on the card reader doesn't come on when I insert the card and click sign-on options. I literally don't know what else to do at this point. How can a group policy prevent me from accessing the server or a workstation, but the same group policy doesn't affect the other admins?

[+Nik Louch Subscriber²]

Why not ask your IT department?

[cbrookhart]

  On 19/04/2018 at 14:59, NJL said:

Why not ask your IT department?

Expand  

I AM in IT. As I mentioned, I am an administrator where I work. The reason I am asking is because I am not familiar with the workings of group policy.

[+Nik Louch Subscriber²]

  On 19/04/2018 at 15:38, cbrookhart said:

I AM in IT. As I mentioned, I am an administrator where I work. The reason I am asking is because I am not familiar with the workings of group policy.

Expand  

Apologies, I read it as if you had administrator rights (for whatever reason) rather than being an actual administrator business role.

[techbeck]

Well, first I would look in to what policy settings controls RDP.

 

https://social.technet.microsoft.com/wiki/contents/articles/4980.how-to-enable-or-disable-remote-desktop-via-group-policy-windows-2008.aspx

 

Then on the machine with the issue, run a gpresult /h filename.htm to deterime what policy, if any, is controlling RDP.

[cbrookhart]

Well, since I cannot currently access group policy despite having previously been able to do, the best I can do is look at the output of group policy file.

 

Clearly it's got be something with my profiles, but they were deleted and rebuilt. That didn't fix the problem either.

[Mando]

  On 19/04/2018 at 16:06, cbrookhart said:

Well, since I cannot currently access group policy despite having previously been able to do, the best I can do is look at the output of group policy file.

 

Clearly it's got be something with my profiles, but they were deleted and rebuilt. That didn't fix the problem either.

Expand  

do a RSOP via adm cmd and then browse through the GPOS in effect via Techbecks method (it will reduce the hits to look into). I doubt its anything to do with profiles, they dont control access, but never say never, i see your angle  

 

the card not being recognised is a wierd one, ive not much exp with such luxuries, dunno if it fails that 2FA it may be like an unauthorised attempt? Is it possible to remove the user cert and just have adm one? As a test?

 

also ensure there are no cached credentials in Control Panel\Credential management on your workstation. As out the box RDP will allow a terminal via Alt creds e.g. i use domain.int\adm acc on my "normal" user account without issue. (XP - W10, 2k Server to 2k16) ive seen my adms sometimes cached in there while on my daily runner logon.

 

Also are you fully authenticating (domain\adm acc) I use this format across our entire corp forest (125 domains atm with plans for one super domain in the works) and your account is a member of "Domain Administrators" ? what happens if you add your ADM to the Server manager remote access perms as allowing RDP? (shouldnt need to but sometimes its required)

 

what happens if you run mstsc via run as admin? Before even trying to rdp? 

 

does it do it on every server resource you once had access to? Or just this one server?

 

Also speak to whoever manages your GPOS (god i hope they know their stuff and havnt edited default GPO, so common and WRONG!) and see if there has been any documented changes in this field.

 

what Server Os is it, as W7 and 10, server 2k8 & 2k12 recently had KBs pushed to restrict RDP due to vulns in the RDP stack. it would help a lot of we know OS involved so we know the version of RDP  

 

I avoid RDP at all costs tbh, RSAT ftw!  if i really must i use ESXi console instead  again using alt creds for AD authentication on my daily runner, using my domain adms.

[Jason S. Global Moderator]

i've seen those error messages when the answer is something totally unrelated. for instance, that error might occur if someone changed your access to the server in AD... you were somehow removed from having access to the particular server... or if your username password has expired and needs reset.

 

just saying - i wouldnt blame GP if youre the only one experiencing RDP issues.

[Mando]

  On 19/04/2018 at 16:49, Jason S. said:

i've seen those error messages when the answer is something totally unrelated. for instance, that error might occur if someone changed your access to the server in AD... you were somehow removed from having access to the particular server... or if your username password has expired and needs reset.

 

just saying - i wouldnt blame GP if youre the only one experiencing RDP issues.

Expand  

thats a good point Jase. when i change GPOs for users or myself for testing, I always shut my workstation down to force a gpupdate. W2k12 server is esp quirky with it, Ive seen adding users to an ACL member group play up until they shutdown and cold boot, a restart is not the same.

 

Suspect 7 n 10 are trying to be clever with a fast boot and using a cached copy of the domain GPO, tricky to prove with our locked down enterprise SCCM units, Ive passed the quirk upwards for investigation.

[cbrookhart]

  On 19/04/2018 at 16:40, Mando said:

do a RSOP via adm cmd and then browse through the GPOS in effect via Techbecks method (it will reduce the hits to look into). I doubt its anything to do with profiles, they dont control access, but never say never, i see your angle  

 

the card not being recognised is a wierd one, ive not much exp with such luxuries, dunno if it fails that 2FA it may be like an unauthorised attempt? Is it possible to remove the user cert and just have adm one? As a test?

 

also ensure there are no cached credentials in Control Panel\Credential management on your workstation. As out the box RDP will allow a terminal via Alt creds e.g. i use domain.int\adm acc on my "normal" user account without issue. (XP - W10, 2k Server to 2k16) ive seen my adms sometimes cached in there while on my daily runner logon.

 

Also are you fully authenticating (domain\adm acc) I use this format across our entire corp forest (125 domains atm with plans for one super domain in the works) and your account is a member of "Domain Administrators" ? what happens if you add your ADM to the Server manager remote access perms as allowing RDP? (shouldnt need to but sometimes its required)

 

what happens if you run mstsc via run as admin? Before even trying to rdp? 

 

does it do it on every server resource you once had access to? Or just this one server?

 

Also speak to whoever manages your GPOS (god i hope they know their stuff and havnt edited default GPO, so common and WRONG!) and see if there has been any documented changes in this field.

 

what Server Os is it, as W7 and 10, server 2k8 & 2k12 recently had KBs pushed to restrict RDP due to vulns in the RDP stack. it would help a lot of we know OS involved so we know the version of RDP  

 

I avoid RDP at all costs tbh, RSAT ftw!  if i really must i use ESXi console instead  again using alt creds for AD authentication on my daily runner, using my domain adms.

Expand  

I ran RSOP and selected my workstation admin account to see what policies are in place, but I really don't know what I'm looking at. There is a policy setting to allow remote desktop.

 

The card not being recognized was resolved. If the drivers for the card reader are not installed or are not the correct version, the card reader will not read the inserted card. Running gpupdate /force usually fixes that.

 

I am accessing the remote server/workstation simply by putting in it's name (i.e. abc12345 in the computer name field). This method previously worked, and in fact does work when I login only as a workstation admin and then enter the computer I want to connect to. I cannot login as a domain admin, so the only way to get to the server is via RDP from my user account.

 

if I type in mstc, right click and select run as admin, I get an error that app is blocked by the system administrator. I know that the cards are working because when I hit more choices, I'm presented with the certificate for my user card and my workstation admin card (or domain admin card if I have that one inserted).

 

I can only remotely connect to workstations via a workaround of switching accounts.

 

I've brought this issue to the attention of the person who manages the GPOs, but literally they say "well, it works for me. I'll have to look at something else."

 

OS is Windows 10 build 1709 on the workstation and the server is running Windows Server 2008

 

I overheard something about policies needing to be rewritten for 1709 when coming from 1607. I don't think there's been an OS update, so I think both before when RDP was working properly and up to now, it's been Windows 10 1709 that I am working with.

 

As for cached credentials, I checked in Control Panel \ credential manager, but credentials are disabled.

 

I don't know why the appropriate card doesn't get read when I actually stat the connection process to the server or other computer.

[cbrookhart]

I think I'm beginning to better understand what is happening now.

 

The profiles in use are based on 1607. As I mentioned, the workstation OS build is 1709. Apparently 1607 profiles don't work with 1709.

[Mando]

gah w10 builds, there you go  id wager the same.

[cbrookhart]

I've spoken with another admin in my department who can still successfully remote into servers and workstations. They compared my account with their account, and found no discrepancies. In other words, every group they were a part of, I was also a part of. I also found out that it's maybe not a policy issue after all, as was suggested by others in this thread. It's some sort of permission issue, but it's unknown exactly what that permission issue is especially since my account permissions supposedly match the permissions that the other admins have.

 

Apparently my regular user account needs to have the permission to use RDP, otherwise the admin credentials won't be passed to allow for a successful connection to either a workstation or server. I suppose this explains why I can login as a workstation admin and connect to another computer via RDP, but I can't do the same when logged in as a regular user and telling RDP to use the admin card that is inserted in the second card reader.

 

Either it's the 1607/1709 profile issue or some 'mysterious' permissions issue that hasn't been able to be located and corrected.

[cbrookhart]

After several attempts at rebuilding my profiles and other troubleshooting attempts, it was decided that as a test, my user account would be added to the remote desktop group. This solution worked, but my account is the only one that has the remote desktop group added. None of the other admins have this group added to their user account, and yet they can still login to the workstation using their user card and then insert their domain admin card and successfully access the server via RDP.

[satukoro]

  On 23/04/2018 at 15:50, cbrookhart said:

After several attempts at rebuilding my profiles and other troubleshooting attempts, it was decided that as a test, my user account would be added to the remote desktop group. This solution worked, but my account is the only one that has the remote desktop group added. None of the other admins have this group added to their user account, and yet they can still login to the workstation using their user card and then insert their domain admin card and successfully access the server via RDP.

Expand  

I would go ahead and compare the rest of your security groups to another admin. It sounds like a nested security group inconsitency. Check the remote desktop group membership roster and see if anything stands out.

[cbrookhart]

Adding the remote desktop group to my user account seems to be the only way I can remote into the server. Aside from that, everything else matches.

 

Unfortunately, the issue is only halfway resolved. I still cannot remotely access another workstation through RDP while logged in as a user. I have to switch accounts, login as an admin, run RDP, and connect to the remote computer. Nobody else has to do it this way. I cannot access the file share servers either, but at least now I can get into Active Directory for day to day tasks.