[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Can no longe remote into my 2003 domain controllers

Posted on 2009-02-15
51
Medium Priority
?
491 Views
Last Modified: 2013-11-21
Several days ago I noticed that I can no longer remote into any of my dcs. I have not changed anything and do not see anything changed. Allow log on to terminal services is enable. I also enabled and allow users to connect using termianl services is also enabled. I have now made so many changes and test that it is impossible to go back. But nothing works. Originally when I noticed I couldnt log in, I trie to look at the default domain gpo but received an error about a template. I could still see the gpo and edit it but was nto sure what the error meant. So, the file that was in the error I renamed it and the error stopped. It was an adm file, a template of some sort but Im not sure if thats the problem or not.  Domain admins are the users with access and I am a part of that group. I really need to get into my dcs remotely.
0
Comment
Question by:jbell72
  • 21
  • 18
  • 6
  • +3
51 Comments
 
LVL 6

Expert Comment

by:Steven Kirkland
ID: 23645308
You can't authenticate or you can't even connect to the TS service remotely?  It sounds like the service isn't connectible.  Are you unable to connect to the DC on your immediate internal network?
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23645382
Assuming you can log on locally and the Terminal Services service is running, It might help to run a RSoP query in logging mode on one of the servers for your username.

Once done, check in Computer Config\Windows Settings\Security Settings\Local Polices\User Rights Assignments

Check the two policies Allow Log on through terminal services and Deny log through terminal services. See if this holds any clues.
0
 

Author Comment

by:jbell72
ID: 23645774
sckirklan:

No, I can not connect to the DC on my nternal network. I am using remote desktop connection like i have always been and can connect to toher servers just not the DCs.  When I type in my user name nad password it gives me the error message that "to log onto this remote computer, you must be granted  the allow log in thru ts right". Well, that is enabled for my group, which is domain admins in the default domain controller policy. I tried creating another policy that allows remote access and linked that to the dc OU as well and no luck.

bluntTony:

Its not just my username , it i
s any domain admin account. also the 2 policies u mentioned are enabled. The deny log thru terminal services is only configured for guest user accounts.

Could the default domain dc policy be corrupt?
0
[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

 
LVL 1

Expert Comment

by:William2451
ID: 23645794
On the DC itself on the under system properties on the remote tab is the remote desktop boxed checked, and is domain admins listed there?
0
 

Author Comment

by:jbell72
ID: 23645887
no it is not checked cause doman admns are supposed to have this right by default and it has never been checked before. I have 16 dcs, all across the country that I can not physically go to , to  ensure that this is done so I need to have the gpo really work.
0
 
LVL 1

Expert Comment

by:William2451
ID: 23646006
I have had this same issue and had to do that to fix it temporarly. It does sound like conflicting GPO though, if you run gpresult on one of the DC's that you can log into localy does it show that GPO being applied?
0
 
LVL 19

Expert Comment

by:lamaslany
ID: 23646248
First let's check to see if you're DCs are listening for incoming connections:

netstat -a | find "LISTENING"

You should see TCP 0.0.0.0:3389

If not then check to see if the 'Terminal Services' role is running.  Obviously if you've changed the port that the server is listening on for terminal services then you'll need to look for that port instead.

If it is try the following from a PC on the network:

telnet <Server_IP> 3389

If it cannot connect to port 3389 then telnet should report that the connection failed.  
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23647692
It can't be a connectivity issue as jbell72 is getting through but being denied due to a policy configuration.

When you say that 'Allow Log on through Terminal Sevices' is enabled, what groups are defined here? Although Domain Admins should have this right by default, it may be worth explicitly stating it here in your Default Domain Controllers Policy and see if this makes any difference.

When you say you renamed an .adm file, where was it? Was it from C:\Windows\inf on a particular DC, or was it in a particular policy in SYSVOL? What was the name of the adm file?
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23647749
From what I can see, the default right to log in thorugh TS is defined in the local security policy. This doesn't get factored in when running a RSoP query.

What groups are entered in the Computer Config\Windows Settings\Security Settings\Local Polices\User Rights Assignments\Allow log on through Terminal Services policy on a local policy? (view by running gpedit.msc on a DC). By deafult you should see the groups Domain Admins, Administrators, Remote Desktop Users.
0
 
LVL 1

Expert Comment

by:William2451
ID: 23647788
The past when I had this happen to me was when someone went and "fixed" GPO's. What they ended up doing was making conflicting GPO's about terminal services so one was applied and the other was not, thats why I reccomended running gpresult to see if that policy is being applied or being filterd out.
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23647855
Agree - although using an RSoP query will show the 'final' setting along with the GPO from which it was applied.
0
 

Author Comment

by:jbell72
ID: 23657931
OK...
 Blunttony, the group domain admins has the right. I have added my name specifcally but that didnt work either. And the policy I renamed was in the sysvol/policies folder but I have since renamed it back to its original name.

William, I have actually removed the default gp policy link from the Domain controller OU and applied a test policy and all it has is the allow users to connect via terminal services. I ran gpupdate several times and now this gpo is the only one being pushed. according to gpresult. So i tested it out and still get the same error message . It is quite baffling now. I am heading back down to my dc to check event viewer and run rsop. I am thinking that something is corrupt somewhere. I double checked and both user and computer is enabled int the gpo just in case.

0
 

Author Comment

by:jbell72
ID: 23659211
Well, no luck. I removed the default dc gpo and linked a test gpo, ensured it was enabled and still nothing. AARRGG! :)  Ran gpupdate /force and gpresult t see if the gpo made itto machine and it did. Still getting the same message. Could a sysvol folder or somethingbe corrupt or not have the correct security settinngs?
0
 
LVL 1

Expert Comment

by:William2451
ID: 23659273
If you were to enable remote desktop on it manualy are you able to get to it?
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23659343
Sorry if I'm teaching you to suck eggs, but i *think* that by default, your RSoP query for the 'Allow log on through Terminal Servers' should come back 'not defined', allowing the local policy to take precedence. So, assuming that the local policy is still allowing the Domain Admins group, nor is the local policy or any applied non-local policy defining any Deny log on through Terminal Services, then it could be possible you may have a corruption.

Remember that any OU-linked GPOs will take precedence over local, site and domain linked policies (except for Account Policies in the case of the Default Domain Policy). The RSoP should show if this is happening though.

If event logs don't yield anything, you can view a more verbose log in: %systemroot%\debug\usermode\userenv.log, after creating the following DWORD value on a DC:

Key: HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/Current Version/Winlogon
DWORD: UserenvDebugLevel
Value: 30002 (Hexidecimal)

Run a gpupdate and view the log file, although this might be overkill! (remove it again afterwards).

If you think it may be a problem with one of your policy folders, you could try and restore it from a time when you didn't have problems. Redirect a system state backup to an alternate location, copy the relevant policy folder out of SYSVOL\Policies into your live SYSVOL\Polices folder, allow for FRS to replicate the new folder around the DCs and then try after a gpupdate. I probably don't need to tell you to be very careful if doing this though!

Let us know how you get on.
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23659363
Sorry, messages crossed. Ignore the first half of my post! Look like you've confirmed it's not a GPO precedence issue.

Worth checking the log and maybe trying to restore from a backup though...
0
 

Author Comment

by:jbell72
ID: 23660708
William2451:

I enabled remote desktop via the control panel, added my name but still same message! That is what really blew my mind.
0
 
LVL 1

Expert Comment

by:William2451
ID: 23660833
Something else  to check:

open terminal services configuration

go to the connections folder

Right click the RDP-Tcp conection and go to properties. Look under remote control tab and make sure it isnt set to dont allow remote control
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23660943
What exactly do you see when you perform an RSoP query on a DC (and if there is anything defined, what GPO is applying it?) and what exactly do you see when you look at the same DC's local policy (gpedit.msc)? Exactly what groups are defined for both the Allow and Deny log on through Terminal Services policies, in Computer Config\Windows Settings\Security Settings\Local Polices\User Rights Assignments?
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23661004
William, I think this setting is to enable/disable an administrator's right to remotely control a user's open session, rather then the ability for users to connect remotely in the first place.
0
 
LVL 1

Expert Comment

by:William2451
ID: 23661171
Ya it was just something I noticed, im just confused now because manualy enabling remote desktop on system properties dosent even work
0
 

Author Comment

by:jbell72
ID: 23661253
so if the sysvol folder is corrupt nothing will work at all? IS this becasue it is a dc? What about all other dcs?
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23661437
SYSVOL holds all of the group policy files and user scripts and is replicated to all DC's so that these files are available to all computers/users on startup/login. If there is a corruption of one of your GPOs it will be here you need to replace it. Any changes made to any one of the DC's copies of SYSVOL will be replicated to all DCs via FRS.

To restore a policy you would have to determine the GUID of the policy you want to restore, and replace this folder with the same policy folder from your re-directed restore of SYSVOL. Bear in mind the changes you make will be replicated globally so be careful!

I know I keep banging on about this :) but what exactly does your RSoP query result say for the two terminal services user rights policies, and the local policy? (if only to shut me up!)
0
 

Author Comment

by:jbell72
ID: 23661438
ok, what is my worst case scenario ? a corrupt sysvol folder? How can I fix hat w/o doing a restore?
0
 

Author Comment

by:jbell72
ID: 23661518
Blunttony,

I will get you that info, my dc is about 2 miles away and I wont get to go to it anytime soon today, sorry. So if I dont have a backup of that policy Im screwed?
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23661597
I don't think it's likely your whole SYSVOL folder is corrupt. The thing is, an RSoP query simulates the actual login process by reading the GPO's as they are in SYSVOL. If your results are as you would expect, and there is no userenv errors in the event log after running a gpupdate, then it's unlikely there is a corruption as such.

It is possible to revert the two defualt policies back to there 'out of the box' state using dcgpofix but this is most definately a last resort!!

Let us know the results of the RSoP and the local policy and we can take it from there.

Thanks,

Tony
0
 

Author Comment

by:jbell72
ID: 23661697
But why doesnt any new gpo that I link to the dc OU work? It was pushed to the dc here and it was the ONLY GPO listed when I did a gpresult and an rsop earlier but it still did not work.
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23661868
Is this the message you are getting by any chance?

This message is down to not have 'User Access' right to rdp-tcp connection, but by default Adminstrators should have full access and I can't see how you would have changed this globally by accident.
Snap1.jpg
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23661885
Or this message? This is what you get if you haven't been granted through group policy.

Very similar, but it is slightly different.
Snap2.jpg
0
 

Author Comment

by:jbell72
ID: 23662150
snap 2 is my error message....
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23662895
Could you run a super-verbose gpresult to a text file and post so I could look please, with your policies back as they were and after a gpupdate /force?

gpresult /z > policy.txt.

Thanks.
0
 

Author Comment

by:jbell72
ID: 23665897
I made copies of my default gpos and ran dcprofix earlier today....still a no go. I am going to set my gpos back to how they were, and get that info for u. This is driving me crazy. Settings on other member servers are the same and I can remoteinto them just not the dcs.
0
 

Author Comment

by:jbell72
ID: 23668633
Another thing, when I click on any gpo, it resolves almost immediately. When I click on the default domain and default dc gpo, the screen is grey for several seconds then loads.
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23669063
I would say that this is just down to the number of settings defined in these policies compared to the others.

One thing I have noticed is that groups you specify in, say, the Default Domain Controllers Policy is actually writing back to the local policy on those machines. If you then set the GPO policy setting to 'Not Defined' the previous settings will remain as part of the local policy. In testing I managed to lock myself out of my DCs and had to log in locally to change the local policy back to what it should be.
0
 

Author Comment

by:jbell72
ID: 23681428
I have the results of the rsop. The result was that gpo did trinkle doen to the dc I was locally logged onto and allow log on thru terminal services was there. I cant post the results cause it is a classifed network. I just read a post of a corrupt gpttmpl.inf. I looked at my inf file and there was no line in there for remoe access/terminal services. Can someone check there inf file and see if it is supposed to be listed.
0
 
LVL 1

Expert Comment

by:gcz
ID: 23681737
I assume you are referring to the gottmpl.inf file in your Default Domain Controllers Policy, in:

\\SERVER\sysvol\DOMAIN\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit

No, in my copy there is no entry as the policy is not defined in this group policy. By *default* these rights are not assigned in group policy - they are assigned in the local policy of the DC. If it is defined, you should get an entry in gpttmpl.inf called SeRemoteInteractiveLogonRight, followed buy the SID of the user/group assigned.

When you say 'allow logon through terminal services was there' - what groups were detailed in the RSoP result, and by what GPO? By default it should say 'not defined' under policy settings, in which case rights will be granted through local policy, not group policy. If it is enabled but blank, then no-one will have access, although if this was the case you would have had a line in gpttmpl.inf showing 'SeRemoteInteractiveLogonRight =' (then nothing).

If it says 'not defined', what does your local policy say? (gpedit.msc on the local DC). If the right is granted to 'Administrators' check that Domain Admins is still in the 'Administrators' group (and that your user is in Domain Admins).
0
 
LVL 1

Expert Comment

by:gcz
ID: 23681766
This is bluntTony by the way, I was logged in under a colleagues login by mistake (doh!)
0
 

Author Comment

by:jbell72
ID: 23684282
what is the sid of the domain admion account? 'My seRemoteInteractiveLogonRight = a very long number.
0
 

Author Comment

by:jbell72
ID: 23684410
Whats the difference of "allow log on thru Terminal services" and 'allow users to connect remotely using terminal servoces" ?
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23690194
Where are you seeing the latter?

I don't think that the SID would be the same for different domains. It comprises of the combination of a unique ID from the domain and a relative ID (RID).

I'm still not clear on what your apparent resulting policy is! Before you go down the corruption route, could you confirm to me the result of the RSoP query please? What are the policy settings and what GPO applied them? Run an RSoP as follows (it doesn't have to be ran locally on the DC)

1. Start > Run > mmc
2. In the mmc, File Menu > Add/Remove Snap-in
3. Add the Resultant set of policy snap in.
4. Right click this node back in the mmc > Generate RSoP Data.
5. Make sure you select a DC as the computer (the user selected isn't too important as the settings are computer based, but select your account.)

Browse to the following policies and tell me what the 'Policy Settings' column says, and the GPO which applied them.

1. Computer Config\Windows Settings\Security Settings\Local Polices\User Rights Assignments\Allow log on through Terminal Services
2. Computer Config\Windows Settings\Security Settings\Local Polices\User Rights Assignments\Deny log on through Terminal Services

Unless you've manually changed your Default Domain Policy, they should both say 'Not Defined'

You also need the 'Allow log on locally' right but I'm assuming this isn't a problem as you can still log in locally.
0
 

Author Comment

by:jbell72
ID: 23690853
The latter setting is in the default dc policy..

admin templates/windows components/terminal services. Have to go back for the rsop info again :(
0
 
LVL 1

Expert Comment

by:gcz
ID: 23691436
You don't have to do it locally!

Just make sure you select one of your DCs as the computer object when generating the data. You can do it from any machine in the domain as long as you have the credentials to do so.
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23691486
The policy in Admin Templates is the GPO equivalent of the 'Allow users to connect remotely to this computer' which is found in Start / My Computer (right-click) / Remote Tab.

If it's enabled, the connection is allowed. If it's disabled, connections are refused. If it's 'not configured' (default), then access is controlled through the local setting in My Computer.

If you were getting denied through this, you wouldn't even make the connection in the first place so this isn't your problem.
0
 

Author Comment

by:jbell72
ID: 23692377
ok, sorry. Will do rsop right now. :)

1. Computer Config\Windows Settings\Security Settings\Local Polices\User Rights Assignments\Allow log on through Terminal Services - Enabled Domain admins thru default dc policy
 I do believe this was originally not enabled but with all the settings, it is hard to remember.


2. Computer Config\Windows Settings\Security Settings\Local Polices\User Rights Assignments\Deny log on through Terminal Services - Not defined
0
 
LVL 27

Expert Comment

by:bluntTony
ID: 23692972
OK. The first setting will override local policy. The second - double check that there isn't a deny set at the local level.

Domain Admins would have been manually entered. Ensure that is says DOMAIN\Domain Admins andnot just Domain Admins (it's possible to free-type groups that don't exist)
0
 

Author Comment

by:jbell72
ID: 23693963
the domain admins group was not types in, was selected and is domain\domain admins. As far as checking the deny at a local policy, wouldnt that have to be set on all dcs? I have 16 and some are in remote areas where it would have been impossible for someone to have set it locally.
0
 
LVL 1

Expert Comment

by:gcz
ID: 23694314
Your most likely right, but it is possible for GPO policies to remain. For example, if your GPO policy was set to deny user John, and the policies propogated around, then you change the deny policy to 'not defined', if you then checked the local policy of one of the DCs you would still see John in the 'deny log on through terminal services' policy.

I wasn't aware of this behaviour but I managed to lock myself out of TS by this method.
0
 

Author Comment

by:jbell72
ID: 23698308
I checked my dc and deny lon on e\was not defined in the local policy. This is driving me crazy. Could this not be a corrupt dc policy or maybe a security glitch or issue? Maybe dcs are not replicating or something.
0
 
LVL 27

Accepted Solution

by:
bluntTony earned 1500 total points
ID: 23699413
OK. If you are sure the following are true:

1. Your resultant GPO policy allows Domain Admins, and does not deny anyone, and your local policy also reflects this (i.e. Allow Domain Admins, no denies)
2. You are a member of Domain Admins. Domain Admins is still a member of Administrators
3. Your user has the Allow Log On Locally rights through the correct group membership, nor is there any deny.
4. Your user object in AD has the 'Allow logon to terminal Server' box checked in the 'Terminal Service Profile' tab.
5. In Terminal Services Configuration, your user has 'User Access' rights to the rdp-tcp connection.

Then by rights really you should be able to get in.

Check the Event logs on the server for 'userenv' errors when updating policy (you could also use the verbose logging I described earlier). Also check the File replication Service event log for any FRS errors - this is how SYSVOL and consequently group policy is replicated. If you're concerned about AD replication, use replmon from the Window Support Tools (download from MS and install on the server) to check that replication is occurring successfully. Also use netdiag and dcdiag to uncover any other problems in your domain. Are the DCs also Global Catalogs?

One other thing - how long have the DCs been set up? Licencing wise - if you've got the DC in 'Application Mode' rather than 'Remote Desktop for Administration' and you haven't installed TS Licencing, you'll be refused access after 120 days. You should be in the latter mode. Check Terminal Services configuration (in Server Settings). It's a bit of a long shot but you never know :0)

0
 

Author Comment

by:jbell72
ID: 23754636
I was just tired of trying to get the right settings. I restored a backup of the default domain policy and the default dc policy and it was working within minutes. I do believe they were corrupt.

Thanks everyone.
0
 

Author Comment

by:jbell72
ID: 23754709
Im going to givr blunt tony the points, he was right with all the settings, just I had a corrupt policy.
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Some time ago I faced the need to use a uniform folder structure that spanned across numerous sites of an enterprise to be used as a common repository for the Software packages of the Configuration Manager 2007 infrastructure. Because the procedu…
Remote Apps is a feature in server 2008 which allows users to run applications off Remote Desktop Servers without having to log into them to run the applications.  The user can either have a desktop shortcut installed or go through the web portal to…
Despite its rising prevalence in the business world, "the cloud" is still misunderstood. Some companies still believe common misconceptions about lack of security in cloud solutions and many misuses of cloud storage options still occur every day. …
With just a little bit of  SQL and VBA, many doors open to cool things like synchronize a list box to display data relevant to other information on a form.  If you have never written code or looked at an SQL statement before, no problem! ...  give i…

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question