Why we need to keep Domain Controllers physically secure



----------------------------------------------------------------------------
I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.

----------------------------------------------------------------------------

This purpose of this post is to highlight another reason we need to keep Domain Controllers physically secure – in fact the principle here also applies to standard Windows Servers too.

My home test lab had been powered down for a few months and I’d forgotten my Domain Administrator password. I knew there was a method to log onto a Windows Server without a username and password back in Windows Server 2003 and I thought that surely this still wouldn’t work with Windows Server 2012 R2 – however to my horror it still did. Here is how I reset my Domain Administrator account password – scary stuff!

Forgotten password

Forgotten password

Forgotten password

Forgotten password

So I’d forgotten my Domain Administrator password. Time to attach the Windows Server 2012 R2 ISO to the VM.

Attach ISO

Attach ISO

Adjust the boot order to force booting from ISO first.

Boot to DVD/ISO

Restart the VM and boot to the DVD/ISO. Click Next on the first setup screen. On the following screen make sure you select “Repair your computer”.

Next

Next

Repair your computer

Repair your computer

Then click on “Troubleshoot” followed by “Command Prompt”

Troubleshoot

Troubleshoot

Command Prompt

Command Prompt

You will now be presented with a Command Prompt.  Change your directory to c:\Windows\System32.  Then rename the Utilman.exe executable by running the command “ren Utilman.exe Utilman.exe.old”.  Then make a copy of cmd.exe named Utilman.exe using the command “copy cmd.exe Utilman.exe”.  See below screenshot.

Replace Utilman

Replace Utilman

Close the command prompt and restart the machine, booting back into the regular Windows logon screen.  Once the logon screen is presented, press the “Windows Key” and “U”.  Much to your horror you will see a Command Prompt appear. If you check Task Manager, you will see that the Command Prompt (executable called Utilman.exe) is running in the SYSTEM context.  Given that this is a Domain Controller, effectively this mean the commands run within the Command Prompt are executed with the Domain Admin permission level.

SYSTEM context

SYSTEM context

To reset the Domain Administrator account password, we simply need to run the “net user Administrator password” command.

Reset password

You can now close the Command Prompt and log onto the domain with the Administrator account and the newly set password.

I have also seen this work with the Sticky Keys executable (sethc.exe) being replaced instead of Utilman.exe.

 

Once again this highlights why we need to keep our Domain Controllers physically secure – from this demo you can see that anyone with physical access to the server can have control over your entire Active Directory domain in a very short amount of time!

 



----------------------------------------------------------------------------
I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.

----------------------------------------------------------------------------

Microsoft Local Administrator Password Solution

Microsoft have released a new tool to manage local Administrator account passwords for domain joined machines. The solution automatically creates and manages the password on each managed computer so that it is unique, randomly generated and securely stored in Active Directory. ACLs are then used to allow access to view the password.

More info:

The tool is free!

Microsoft Security Advisory 3062591 – Local Administrator Password Solution (LAPS) Now Available

Limiting RPC dynamic port allocation range

From time to time, you will need limit (or ‘lock-down’) the number of ports that are used for RPC – this might be to allow traffic through firewalls or for other reasons. In Windows Server 2008/Vista and later versions the default dynamic port range is 49152-65535. For Windows 2000, Windows XP and Windows Server 2003 the default range is 1025-5000.

There is a Microsoft article – http://support.microsoft.com/kb/154596 – this outlines how to do this with some registry value changes, for example if I wanted to limit ports to between 8000-9000, then the following adjustments would be made, followed by a restart:

reg add HKLMSOFTWAREMicrosoftRpcInternet /v Ports /t REG_MULTI_SZ /f /d 8000-9000
reg add HKLMSOFTWAREMicrosoftRpcInternet /v PortsInternetAvailable /t REG_SZ /f /d Y
reg add HKLMSOFTWAREMicrosoftRpcInternet /v UseInternetPorts /t REG_SZ /f /d Y

After testing this on a Windows 2008 R2 Server and looking at Network Monitor traces, I found that the source port was still in the 49152-65535 range. After reading http://support.microsoft.com/kb/929851, I ran the following commands on both source and target servers, then restarted:

netsh int ipv4 set dynamicport tcp start=8000 num=1001
netsh int ipv4 set dynamicport udp start=8000 num=1001
netsh int ipv6 set dynamicport tcp start=8000 num=1001
netsh int ipv6 set dynamicport udp start=8000 num=1001

After looking at Network Monitor traces after making these final changes, I could then see that the RPC dynamic port allocation range (both source and destination ports) was locked down to the specified ports.

 

 

Remote WMI queries fail due to Kerberos token size

This post may be helpful for someone else having trouble in this unique scenario. The relevant points are:

  • Server01 exists in AD Site01 and Site01 is in Country01.
  • Server02 exists in AD Site01 and Site01 is in Country01.
  • Server03 exists in AD Site02 and Site02 is in Country02.
  • WMI queries from Server01 to Server02 work fine.
  • WMI queries from Server01 to Server03 fail. All methods of WMI queries fail – MMC, wbemtest, wmic and gmwi (Powershell) – the error message it either RPC server is unavailable or Call was canceled by the message filter.
  • Other calls in the RPC dynamic port range worked fine – for example remote MMC, remote event viewer.
  • Network Monitor shows no communication problems, successful RPC communication is obvious.
  • Firewalls (software and hardware) logs have been checked and traffic flowing as expected.

To cut a very long story short, the problem was that the maximum allowed Kerberos token size wasn’t big enough on both the source and destination servers – after increasing the MaxTokenSize to 65535 bytes (the maximum allowed) on both servers (plus a restart), remote WMI queries started to work.

Registry key to be updated:

reg add HKLMSYSTEMCurrentControlSetControlLsaKerberosParameters /v MaxTokenSize /t REG_DWORD /f /d 65535

More information on MaxTokenSize – http://support.microsoft.com/kb/327825/en-us.

Hopefully this helps someone out.

 

 

SCCM 2012 Programs running as 32bit on 64bit OS

I recently had a problem when I was trying to run a SCCM program (not application) that called a simple Windows command (the command was wbadmin.exe – but this is irrelevant) in SCCM 2012 on a Windows 2008 R2 64bit Operating System client. I noticed it was failing and in the execmgr.log there was a line stating “Running “C:Windows\system32\wbadmin.exe” delete systemstatebackup -keepversions:16 -quiet with 32bitLauncher” and also the Ccm32BitLauncher.log showed activity.

It was the old problem with 64bit file system redirection that I have blogged about previously.

I found a great article here – http://madluka.wordpress.com/2012/09/24/configmgr-2012-64bit-file-system-redirection-bites-again/ – that provide a batch file solution –
if the batch file is being run from within a 32bit command interpreter on a 64bit Operating System then the ‘Native’ 64bit command processor is called and re-launches the batch file. If it is already a 64bit command interpreter then the code jumps to the “:native” label and continues as usual.

So my batch file ends up looking like this, and the Program command line just calls the batch file:

IF "%PROCESSOR_ARCHITEW6432%"=="" GOTO native
  %SystemRoot%\Sysnative\cmd.exe /c %0 %* Exit
:native
wbadmin delete systemstatebackup -keepversions:16 -quiet

A bit messy but there aren’t too many other option in this scenario.