Active Directory - MMCUG Blogs

5/17/2009

As consultants, we are constantly using remote desktop to connect to servers and workstations in a remote fashion. If the boxes we're trying to connect to are Microsoft servers or workstations, then using Microsoft's Remote Desktop is a breeze. (In Windows 2000 days the feature was called Terminal Services in Remote Administration mode.)

My problem with the RDP (Remote Desktop Protocol) process was connecting to a remote machine if the server was deployed without having the little checkbox checked next to the option Enable Remote Desktop on this Computer. See this dialog box below – this is from looking at the Properties of my server and choosing the Remote tab.

So, if a server is deployed like this, you can't remotely connect to it via the RDP protocol with the remote desktop application. Now, you can physically connect to the server to enable the checkbox option, but sometimes that's inconvenient or impossible.

Attempting to connect to a machine using Microsoft's remote desktop connection when the remote feature has been left off (by default the remote desktop box is not checked) reveals this error message:

So, in this article I'll show you how to remotely enable this checkbox. Once the box has been "checked" so-to-speak, then you can remotely connect using Microsoft's remote desktop application.

The solution is to use a different machine to connect to the "un-touchable" machine's registry to "enable" this checkbox. Let's say I'm sitting at my XP Pro workstation and I need to remotely administer the Windows Server 2003 machine at 10.0.0.10. This is the scenario.

First, I need to open the registry editor on my local workstation. So I click Start and type REGEDIT on the run line. I now need to select the Connect Network Registry option from the File menu like you see me doing below.

This menu opens the Select Computer search dialog box. Now, I need to either browse Active Directory to locate the remote server, or simply type its name in the textbox labeled Enter the object name to select.

After clicking OK, a node will be displayed in the Registry Editor tool for this remote server I'm trying to connect to.

Now I browse to the location listed below from the node just added to the Editor:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server

From the Terminal Server key, I look for the REG_DWORD value named fDenyTSConnection.

I Double-click on that value to open the Edit DWORD Value box and change the data from a 1 to a 0. The default value of 1 means that Terminal Services is in fact being denied – hence the reason I couldn't connect. Changing the value to a 0 means to NOT deny Terminal Services.

Choosing OK will complete this process of not denying Terminal Services which in effect "checks the box" I spoke of earlier.

But, I'm not done yet. One last step to perform to complete this process is I need to reboot the server I'm trying to connect to. Obviously this cannot be performed during critical times the server is needed. But, when the time is right I can remotely reboot the box using Microsoft's Shutdown command. This command will – when switches are used correctly – will allow me to remotely reboot the server. When the server comes back up again, I can now successfully connect to this server.

The command to remotely reboot the server is:

Shutdown –m \\server_name –r

I enter the correct server name in place of my "server_name" text, or I can enter it's IP address instead. If I enter it's name, I will not enter it's fully-qualified domain name – just its NetBIOS name. The –r switch tells the tool to restart the server instead of truly shutting it down. This switch is critical for obvious reasons. There are tons of options I can use with this command. One nice switch is the switch to have the shutdown process start in a value of time. The –t xxx switch will allow me to schedule the shutdown in xxx number of seconds. Usually a value of 30 for 30 seconds works well.

Once the server is back up and running, I'll have no problem using Microsoft's remote desktop to access the server. Of course, I must have proper permissions to do so.

One last observation I've noticed using this handy trick – the process I've described here works exactly as described when the server I'm trying to remotely connect to has never had its remote connectivity options enabled – such as on a brand-new machine. A reboot is required to fully complete this process. However, once the server has been restarted, you can always remotely connect to the server using REGEDIT in the same manner I've described here to remotely change the fDenyTSConnection option back to a value of 1. This will once again render the server so no one can remotely connect using remote desktop software. Once this value is set back to a 1 – and even when you later come back and change the value again back to a 0 from the 1 value – you will no longer have to reboot the server. It's only the very first time a change is made to the registry keys will you have to reboot the server. Therefore, after the first time you can easily switch back and forth with the 0 or 1 values to turn on or off the remote connectivity and not have to affect the operation of the server.

Mark Myers

Senior Consultant

Posted at 9:49 AM by Mark Myers | Category: Active Directory | Permalink | Email this Post | Comments (0)

11/30/2008

Troubleshooting Account Lockouts

Problem:

You have created a Service Account which continues to lockout and you are unable to determine the location of account lockout.

So what is happening?

Abandoned Terminal Services Client (TSC or TS) or Remote Desktop Protocol (RDP) Session:

Many times we see accounts unexplainably get locked out with no rhyme or reason. So what is the deal with this? Well as many of you may have experienced, a log onto an RDP / TS session on a computer remotely followed by a closeout of the session without a logoff can eventually lead to account lockout of the authenticated account once you are challenged by your Domain's security policy to change your password. Essentially your account is logged on the TS session with the old password. Post you changing the account's password the account get's locked out from the terminated but logged on TS session. Changing your password again only leads to the account locking out again until you track down the offending TS / RDP session and properly close it.

Service Account logged on as old password on another computer:

How else can this happen? I was recently challenged to find why a service account was continuously locking out. I immediately inquired as to whether or not the account was logged onto any other machine via RDP / TS session. The account was stated as having just been created and did not exist prior to its recent creation. This left me somewhat perplexed as it made no sense as to why the account was getting locked, but there of course is another cause for this. If someone authenticates with a Service Account on a Server and then changes that password followed by authentication of the same Service Account on a different server the two Service Accounts are now in conflict on their password. Eventually the previous service account will re-authenticate with the legacy password locking out the account. The changing of the Service Account password in and of itself in Active Directory can of course lockout the account without using the Service Account in another location because the logon credentials on which the Service Account is used are now wrong.

The primary issue now is finding the offending Service account and the server to which it is authenticated.

Resolving the problem:

Finding the password lockout and the offending computer having the wrong password:

Well the next issue is finding the offending computer where the account may be. The first issue I had here is not trusting my original suspicion that there was another offending account with the same account name using the wrong password. In order to easily accomplish your search you need to be able to find the computer which is hosting the account with the wrong password. Logging into each server and searching for the Service Account with the wrong password is like searching for a needle in a hay stack. Good luck if this is the method you use. A better solution is to go to the Primary Domain Controller Emulator (PDCE) which is one of five Flexible Single Master Operation (FSMO) roles. The PDCE is responsible to immediately know about account lockouts, and bypasses the normal replication interval and schedule, which is a topic for a different blog. As a result any account lockout which occurs will be immediately recorded on the PDCE in the security event log under the Event ID of 644. Such a lockout will appear similar to the following. Note from the Event ID: 644 you can determine the following key bits of information.

The Description reflects that the User Account has been "Locked Out"
The "Target Account Name" shows the offending service account
The "Caller Machine Name" is key to showing us the computer from which the offending Service Account in locking us out
The "Caller User Name" may reflect the Domain Controller against which the account was locked out.

So what now, log onto the offending computer and change the offending Service Account password under Services to the correct one. Consider a restart of the Service on both computers to validate the problem has been resolved and ensure the account does not lockout.

Unable to find the offending computer?

Ok so what if you cannot find the offending computer once it is identified using NSLOOKUP, DNS, Active Directory or ping the machine? This happened to me. So where is it? Try searching for Event ID 529 on the PDCE by using a filter on the security event log. As you look at the filtered Event ID's search for the same offending Service Account matching the time of the Event ID: 644 or simply off by a few hundredths of a second. In this instance there is an offending account on the same network likely under a different domain / forest that can actually be locking out your account. This odd behavior is addressed under the article "Security Event 529 is logged for local user accounts" http://support.microsoft.com/kb/811082 and fixed by applying the associated patch to the offending "Workstation Name" identified as the Offending Computer. This behavior was seen caused by a Service Account with the same name hosted on a distinct Active Directory Forest on the same Network and was resolved once the patch was applied to the offending computer and rebooted.

Forrest McDuffie
Senior Consultant
Project Leadership Associates

Posted at 4:26 PM by Forrest McDuffie | Category: Active Directory | Permalink | Email this Post | Comments (0)