gabro.net

Hello folks, today I want to show you another menu item addition that will allow you to browse the C: drive (C$ administrative share) of a remote computer by selecting its computer object in ADUC.

I know many people are scared about administrative shares and disable them regularly, but in a corporate environment they are extremely useful for remote management and I can guarantee they are not unsafe if your environment is security-conscious designed and managed…. 1st commandment: use strong passwords, 2nd commandment: patch systems.
Disabling administrative share might even introduce problems as explained in KB842715.

If you haven’t done yet, I suggest to read my previous posts about "Extending ADUC for remote management" to understand how to change DisplaySpecifiers in order to add a menu item to ADUC that will run an associate piece of code such as an executable (EXE) or a Visual Basic script (VBS).

Let’s add the menu item:

1. run ADSIEDIT.MSC and browse the configuration partition at cn=409,cn=DisplaySpecifiers, cn=Configuration,<ForestRootDN>
   (Enterprise Admins privileges are required)
2. right click on “CN=computer-Display” and select “Properties”, then open the AdminContextMenu multi valued string attribute
3. add the following string: “4,&Browse C: Drive,BrowseC.vbs” as shown in the picture
   NOTE: “4” is just a sequential number incremented by +1 over the last menu item. For instance, if you have only one string, use “2” as order number: “2,&Browse C: Drive,BrowseC.vbs”.
   
4. Wait for replication, now you will see the new menu time within ADUC (right click on a computer object).
   

Now, as usual, we need a piece of code that gets the computer name from ADUC and open it’s C$ share and again I’ll use some code to translate machine Distinguished Name (passed by ADUC) into DNS host name.

To browse a remote share explorer.exe will be invoked with the right switches as explained in KB314853.

' BrowseC.vbs (c) Gabriele Scolaro
' Feb 2009. This script is invoked by a context menu in ADUC (display specifier)
' ADUC passes the full LDAP path as argument, the script retrieves the object DNS name,
' than executes explorer to open the remote share
' Tested with Windows XP SP3 ENGLISH

set shell = createobject("wscript.shell")
dim strComputerName
strLDAPHost=WScript.Arguments.Item(0)

' retrieve dnshostname from full LDAP path
Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject(strLDAPHost)
strComputerName = objComputer.dnsHostName

'execute explorer.exe and open remote share in a new single-pane window
shell.run "explorer.exe /n,/root,\\" & strComputerName & "\c$"

NOTE: copy the script to a folder that is included in the %path% system variable such as %windir% or %windir%\System32

WARNING: if you execute ADUC in the context of a different privileged user account with RUNAS (that could be a good thing!), be sure your privileged user’s Windows Explorer is configured to “Launch folder windows in a separate process”, this is because by default RUNAS first determines if an instance of Windows Explorer is already running on the system, then RUNAS passes the request to the ever existing Windows Explorer process instead of starting a new one.

This can be configured in the following ways:

1. log onto the system where ADUC is installed with your privileged user (not current user!) and check “Launch folder windows in a separate process” in Windows Explorer – Tools – Folder Options – View

   

2. Alternatively import the following registry hack into the privileged user profile (not current user!):

   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]"SeparateProcess"=dword:00000001

   Of course this can be done with RUNAS as well!

That’s it! If you liked "Extending ADUC for remote management" series, check my blog now and then, because I have some other ideas about adding new functionalities to your ADUC console!

My life has changed in better since I started using Group Policy Preferences. Period.

Group Policy Preferences (aka GPP) are a set of new 20 extremely powerful Group Policy client-side extensions (CSEs), used to be named “PolicyMaker Standard Edition” and “PolicyMaker Share Manager”, that Microsoft included in Windows Server 2008 after they acquired Desktop Standard Corporation in late 2006.

GPP dramatically improves the way you can centrally manage Windows machines, for example you can easily copy files and create folders, map network drives and printers, add/change environment variables, import registry keys and a lot of control panel settings… many settings now can be configured with a GPP rather than including settings in a monolithic OS-Image or push them with a complex logon script as you used to do in the past.

To fully understand GPP potentiality, you may look at the following two nice “Group Policy Preferences Overview” documents:
http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=42E30E3F-6F01-4610-9D6E-F6E0FB7A0790&displaylang=en
http://www.gpoguy.com/Portals/0/Group%20Policy%20Preferences%20Overview.pdf

Although GPP were released with Windows Server 2008, the very nice aspect is that they can be applied to down-level operating systems such as Windows XP and Windows Server 2003 and nothing is required to be migrated to Windows Server 2008, neither Domain Controllers, nor schema changes are needed, because GPP are a full client local process, you just need to install the following components:

• “Group Policy Preference client-side extensions” for ALL your CLIENT operating system (XP/VISTA/2003/2008).
• the new “Group Policy Management” snap-in part of “Remote Server Administration Tools” (RSAT) that have to be installed on your management computer running Windows Vista or Windows Server 2008 (RSAT can’t work on down-level Windows versions).

Note: XmlLite is required as well by GPP, but most likely it’s on your system already as it is included in SP2 for Windows Server 2003, SP3 for Windows XP and Internet Explorer 7. XmlLite is not required on Vista/2008.

Group Policy Preference client-side extensions
This setup is pretty straightforward, just download and install the GPP CSE for your CLIENT operating system from Microsoft Download center (KB943729 might help). The challenge here is that GPP CSE have to be installed on any client machine you want to manage, fortunately the new client-side extensions can be pushed via WSUS.
Alternatively you might use the deployment tool in use in your network or for future PC roll-out you may intall GPP CSE inside the OS Image or during machine build process (manual or scripted).

Remote Server Administration Tools
This new tool set is the updated version of Windows Server 2003’s “Administration Tool Pack” (%windir%\system32\adminpak.msi) and they allow Windows Server 2008 roles and features being managed remotely from a Windows Vista SP1 or later (and soon Windows 7) machine.
Personally I would recommend to setup a Windows Vista SP2 or later machine, preferably in a virtual machine that is in the same subnet as a DC or even better the PDC for better performance, solely with the purpose of managing the domain (I usually call it a “Management Station”, term that I borrowed from SNMP RFC1157). This machine must be highly trusted, so lock it down at your best.
Second, you download RSAT from Microsoft web site and install onto the Management Station (verify if a newer version has been released in the meanwhile). 
After the installation you will be surprised that RSAT won’t show up yet, don’t worry it’s expected. Because RSAT is a “feature” in the new Windows jargon, it must be enabled:

1) Open Control Panel – Select Programs – click on “Turn Windows features on or off” under the “Programs and Features area” section.
 

2) Select “Group Policy Management Tools” as highlighted in the picture or pin “Remote Server Administration Tools” if you plan to manage all roles and features from that Management Station

Now the newly installed RSAT snap-ins will be visible when you select “Add and Remove” in MMC, alternatively you may want to display the “Administrative Tools” by customizing the Start Menu as shown in the picture below:

Now you’re really ready to go! Enjoy GPP and stay tuned on gabro.net, ‘coz I have some nice ideas to show you about GPP!

I’ve seen in my blog stats that visitors are much interested in "Extending ADUC for remote management" articles, thus it’s time to give you another ADUC extension that I think you will really appreciate a lot.

Supporting users by remote controlling their desktop is one of the most recurring activities in any corporate environment, ranging from small shops to large organizations.
There’s a plethora of products that offer remote control capability:

• provided as part of Enterprise-class System Management suites (Landesk, SCCM, Altiris, etc..) mainly tailored to large orgs
• provided as stand-alone product (pcAnywhere, Dameware, UltraVNC/RealVNC, etc..)
• a 3rd no-longer-emerging category of web-based remote control tools that differ from the above two categories because they don’t need an agent/service listening on the server (the "target" computer that shares the screen), that’s the reason why they are also referred as "agent-less".

They are flexible, as a tiny software is downloaded by the user on-demand from a web link (URL) provided by the "helper", and they are firewall-friendly, as the connection is initiated by the user’s computer and the traffic goes over http/https through a connection broker that is maintained on the Internet by the service provider.
I said the category is no-longer-emerging because since two big IT players acquired the two leading web-remote-control companies – Cisco acquired WebEx in 2007 (WebEx Support Center) and Citrix acquired Expert City in 2004 (GoToAssist) – I believe that market can be considered mature and strategic.

OK, sorry for digression about remote control tools… none of the above mentioned products will be discussed today! :-)

If you come from Windows NT days you know that Microsoft had been always "stingy" with remote control tools in the past, that’s the reason why pcAnywhere became so popular in 90′s, but got almost obsolete since Microsoft introduced "Terminal Services Remote Administration Mode" in Windows 2000 Server to remotely control servers and later introduced "Remote Desktop/Remote Assistance" with Windows XP Professional to remotely control clients.
Both tools rely on RDP (Remote Desktop Protocol, based on ITU T.120 family of protocols) that was initially released as version 4.0 with Windows NT4.0 Terminal Server Edition and later introduced as:

• RDP 5.0 with Windows 2000 Server
• RDP 5.1 with Windows XP Professional
• RDP 5.2 with Windows Server 2003
• RDP 6.0 with Windows Vista
• RDP 6.1 with Windows Server 2008

NOTE: AFAIK Netmeeting in "Remote Desktop Sharing" mode was the only remote control option given by Microsoft in the NT4 era.

OK, sorry again for digression about RDP History…. I won’t digress any longer in this post about the Windows "terminal world", but be sure to know the difference between Remote Desktop and Remote Assistance on a computer running Windows later than version 2000:

• Remote Desktop allows a user to remotely control a computer desktop by authenticating and running his own session (the current logged user is forcibly logged out when the remote user logs-in on a Windows XP computer. Windows Server 2003 allows two concurrent connections that can also be “shadowed”)
• Remote Assistance allows an "helper" to remotely get control of the user desktop without terminating the user current session, so that the user can show the problem to the helper and get the issue fixed.

I was one of those who believed Remote Assistance could be asked ("solicited") by the user only and only through the Wizard in the Help and Support Center (Invite a friend to connect to your computer with Remote Assistance) that creates a Remote Assistance invitation file that the user could send by email or IM (see KB300546 and KB300692)…. not very practical for a number of reasons, such as the asynchronous establishment of the connection.

I was totally unaware that Remote Assistance could be "offered" by the helper as well! (thank you Antonio for telling me that!), this capability is called “Unsolicited Remote Assistance” and works as follow:

- Open the "Help And Support Center" in Windows XP and click on "Use Tools to view your computer information and diagnose problems"
NOTE: in Vista it’s under All Programs – Maintenance – Windows Remote Assistance

- click "Offer Remote Assistance" under the left Tools pane

- type the machine IP address or Host Name of the computer whose owner requires assistance (aka the “Novice” in RA jargon)

NOTE : administrative privileges won’t suffice, you need to setup the "Offer Remote Assistance" GPO setting under
Computer Configuration/Administrative Templates/System/Remote Assistance (see KB301527 for more info).
 
Replace DOMAIN\DesktopSupportTeam as seen in the picture below with your AD NETBIOS domain and AD security group created for people allowed to control users’ remote PC. Yes, you got it right, it works in Domain mode only!

NOTE: Remote Assistance uses DCOM, useless to say that DCOM needs to be enabled in the registry (enabled by default):[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]"
EnableDCOM"="Y"

NOTE: of course Windows Firewall (or any 3rd party firewall software) has to be configured to allow Remote Assistance traffic (see KB555179 and KB884910).

At this point on the “Novice” screen a message will pop up prompting the “Novice” to allow the “Expert” (the one who is giving support in RA jargon) to remotely control the computer by taking the current session.

 
NOTE: there are some tricks to override the Remote Assistance prompt and automatically take control of user session, but I strongly disencourage this behaviour, it does not respect the user privacy and most likely it is not allowed by the corporate policy.

When I saw the “Unsolicited Remote Assistance” working for the first time, I was pretty amazed, BUT I did not find it quick enough opening the "Help And Support Center" and clicking two links.. (you know I am lazy…!).

Fortunately I found JSI Tip 8047 explaining how to start "Offer Remote Assistance" from the command line (single line, wrapped for reading):
"%ProgramFiles%\Internet Explorer\iexplore"
hcp://CN=Microsoft%20Corporation,L=Redmond,S=Washington,C=US/Remote%20Assistance/Escalation/Unsolicited/Unsolicitedrcui.htm

That worked on a Windows XP box, but I suddenly thought about adding some kind of automatism…
…I wondered "Why not populating the computer name field by pulling the info from ADUC??".

Display Specifiers are our friends again here! So let’s add “Offer Remote Assistance” context menu as explained in my previous posts Extending ADUC for remote management (part 1 – introduction) and Extending ADUC for remote management (part 2 – Remote Desktop).

1. run ADSIEDIT.MSC and browse the configuration partition at cn=409,cn=DisplaySpecifiers, cn=Configuration,<ForestRootDN> (Enterprise Admins privileges are required)
2. right click on “CN=computer-Display” and select “Properties”, then open the AdminContextMenu multi valued string attribute
3. add the following string: “3,&Offer Remote Assistance,OfferRA.vbs” as shown in the picture NOTE: “3” is just a sequential number incremented by +1 over the last menu item. For instance, if you have only one string, use “2” as order number:
   “2,&Offer Remote Assistance,OfferRA.vbs”.
   
4. Wait for replication, now you will see the new menu time within ADUC (right click on a computer object).  

OK now we need a piece of code that sends the computer name from ADUC to the Offer Remote Assistance connection box.

Because, as I said in my previous posts, the computer name is passed as an argument by ADUC console in LDAP format (DN), I had to convert the machine Distinguished Name into DNS host name.

It was pretty easy to create a Visual Basic Script that queries AD for machine object DN and retrieves its dNSHostName attribute.

Now that we have the machine host name we can run the “Offer Remote Assistance” connection box and pass the machine host name as keystrokes.

' OfferRA.vbs (c) Gabriele Scolaro
' Feb 2009. This script is invoked by a context menu in ADUC (displaySpecifier)
' ADUC passes the full LDAP path as argument, the scripts retrieves the object DNS name,
' execute remote assistance GUI, write the DNS hostname and ALT-C + ALT-S
' Tested with Windows XP SP3 ENGLISH

set shell = createobject("wscript.shell")
dim strComputerName
' store the argument to strLDAPHost
strLDAPHost=WScript.Arguments.Item(0)

' retrieve dnshostname from full LDAP path
Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject(strLDAPHost)
strComputerName = objComputer.dnsHostName
' execute Offer Remote Assisance box
shell.run "hcp://CN=Microsoft%20Corporation,L=Redmond,S=Washington,C=US/Remote%20Assistance/Escalation/Unsolicited/Unsolicitedrcui.htm"

' Activate the Help and Support Center window and send the dnsHostName as Keystrokes + ALT-C (Connect) and ALT-S (Start)
shell.AppActivate("Help and Support Center")
wscript.sleep 3500
shell.sendkeys strComputerName
wscript.sleep 40
shell.sendkeys "%c"
wscript.sleep 20
shell.sendkeys "%s"

NOTE: copy the script to a folder that is included in the %path% system variable such as %windir% or %windir%System32

Now if you properly set Remote Assistance GPO and Firewall as explained above, you should be able to initiate (offer) a Remote Assistance by right clicking on a computer account and selecting “Offer Remote Assistance”…. nice eh? :-)

And if you believe this is not enough or it’s not very elegant… well, feel free to customize Remote Assistance as you like! http://msdn.microsoft.com/en-us/library/ms811079.aspx and don’t forget to publish your script!

Stay tuned, because I have other ideas to simplify your everyday IT life by adding new functionalities to your ADUC console!

I thought about creating this dedicated post for NTFS Alternate Data Streams – also knwn as “forks” – because very often I surprisingly notice that most system administrators are even not aware of ADS existence, even though ADS come into play in several occasions such as EFS (Encrypting File System) and AES (Attachment Execution Service), or just with many widely adopted applications such as Microsoft Office or Adobe Acrobat.
Alternate Data Streams are just pervasive and object of security concerns for some reasons I’m going to explain.

Let’s start to define what an Alternate Data Stream is by gathering some official information from Microsoft website and picking-up the fundamental concepts with some comments:

A multi-stream file is a collection of single-streams embedded in the same file system entry. They definitely look like a unique and atomic unit, yet comprise a number of independent sub-units you can create, delete, and modify separately.
Streams are particularly useful for adding extra information to files without altering or damaging the original format, a graphics program might store a thumbnail image of a bitmap in an Alternate Data Stream within the NTFS file containing the image itself.
More essential information:
- a file is made of sequence of bytes divided into data streams
- every file has always a main unnamed stream associated with it, regardless of the file system used
- additional named data streams can be added to a file and can be accessed by referring to their names
- the full name of a stream is filename:StreamName:StreamType (e.g. myfile.dat:stream1:$DATA)
- each stream has its own allocation size, actual size, and valid data length (a file can be 0-length but can have named streams that takes bytes)
- each stream maintains its own state for compression, encryption, and sparseness (think of an EFS encrypted file that is ciphered with DES/AES in the main stream and its FEK – File Encryption Key- that is RSA encrypted and stored in an stream named $EFS)
- extra data can be added to any file or directories (yes! a stream can be added to a folder as well!), including text and executables, but streams are invisible to Windows Explorer (here it comes the security concern as ADS can be misused to hide malware code.)
- streams of a file are not affected if the file is copied or moved from/to NTFS volumes, streams are lost if the file is moved/copied to FAT.
- multiple streams have been in existence since Windows NT 3.1
- all the low-level Win32 API functions support stream-based file names on NTFS partitions (remember that not all applications or command line tools are ADS-aware, for example “type” can’t access streams).
- Win32 backup API functions can be used to enumerate the streams within a file

 
This picture was taken from Microsoft Technet.

References:
- File Streams: http://msdn.microsoft.com/en-us/library/aa364404(VS.85).aspx
- How NTFS Works: http://technet.microsoft.com/en-us/library/cc781134.aspx
- The NTFS File System: http://technet.microsoft.com/en-us/library/cc976808.aspx
- A Programmer’s Perspective on NTFS 2000 Part 1: Stream and Hard Link: http://msdn.microsoft.com/en-us/library/ms810604.aspx

That definition said, let’s do some examples to understand how ADS work in the real-world.
1) create two files: MyDocument.txt and MyGoodApp.exe from the command line. For the EXE follow the instructions of my recent Creating simple EXE files from the CLI for testing purposes post, for the TXT you can run the following in a command prompt box:

echo This is My Document > MyDocument.txt

Pay attention to the size:
 

2) verify they have been properly created by typing the content of TXT file and running the EXE
 

3) now let’s add the Alternate Data Streams to those files, but first create a MaliciousApp.exe by following the instructions of my recent Creating simple EXE files from the CLI for testing purposes post.

add alternate stream to MyDocument.txt:

echo This is my SECRET document > MyDocument.txt:MySecret.txt

add alternate stream to MyGoodApp.exe:

type c:\gabro\MaliciousApp.exe>c:\gabro\MyGoodApp.exe:Infect.exe

Note: Remember that there’s no file type correspondence between different streams of a single file, you can “hide” an EXE behind a TXT file, you could even “hide” an EXE behind a folder.

Be aware that no messages will shows up in the command prompt box when creating ADS:

4) let’s see now if the data streams have been created properly.

To show streams behind the TXT file run the following:

type < MyDocument.txtmore < MyDocument.txt:MySecret.txt

Note: I used the command “more”, because it’s ADS-aware (see above), “type” is NOT able to display TXT data in alternate stream. Notepad is ADS-aware as well, you may try it out by yourself.

To execute streams behind the EXE file run the following:

MyGoodApp.exe
start c:\gabro\MyGoodApp.exe:infect.exe

Note: I used the command “start”, because just like “more”, it’s ADS-aware. “Start” requires the full path in front of the EXE and will execute the EXE in a separate cmd.exe session.

Fortunately Windows Task Manager is ADS-aware, this is how the hidden EXE shows up in the Processes tab while it is processed (before pressing a key):

I must admit I was impressed several years ago – or better… shocked! – the first time I saw how EXE can be easily hidden behind other files (or folders), I think you are scared as well now if you were not aware of ADS capability!
And look…. if you run the “dir” command or just use Windows Explorer, you will see that the file size hasn’t changed for both files! (only the “date modified” changed, but of course that could be changed by a malicious code that tries to hide itself behind a legitimate file).

In the next part 2 I will explain how you can discover and visualize streams that are hidden behind files by using some tools…
If you’re interested… stay tuned!!!

.NET Framework includes command-line compilers for different programming languages such as Visual Basic (vbc.exe) and C# Sharp (csc.exe), they come in very handy for a System Administrator who does not want to setup the entire Visual Studio IDE just to create simple EXE programs for testing.

The location of command-line compilers varies upon .NET Framework version beneath the C:\WINDOWS\Microsoft.NET\Framework folder.
Examples of vbc and csc runned from the .NET Framework v.3.5 folders.

Command-line options are very rich, but syntax is easy to create simple .NET Framework EXE files in Portable Executable (PE) format::

csc.exe /out:myapp.exe source.cs
vbc.exe /out:myapp.exe source.vb

Note: If /out switch is omitted, an exe file is created in the working directory with the same name as source file.
No OBJ files will be created when using command-line compilers as opposed to classic C++ compiler, exe or dll are created directly without the need of a linker.

OK, now Imagine you want to create two EXE files that represent a legitimate and a malicious program (nothing fancy, just a “Hello, World!” re-edition).
Create two source files called MyGoodApp.cs and MaliciousApp.vb by using a text editor such as Notepad.
Well programming the MyGoodApp in C# and MaliciousApp in Visual Basic does not mean that Visual Basic is bad! :-) just kiddin’ – I am using two different languages to show two different command line compilers (csc and vbc) – .

//MyGoodAPP.cs

public class MyGoodApp
{
    public static void Main()
    {
        System.Console.WriteLine("This is my Good App Running! Press Any key.");
        System.Console.ReadLine();
    }
}

'MaliciousApp.vb

Public Module MainMod

Sub Main()
    System.Console.WriteLine ("This is a MALICIOUS app running and harming your system! Press any key.")
    System.Console.ReadLine
End SubEnd Module

Now compile them:

csc /out:C:\gabro\MyGoodApp.exe C:\gabro\MyGoodApp.cs

vbc /out:C:\gabro\MaliciousApp.exe C:\gabro\MaliciousApp.vb

Note: gabro is just my working directory, you may change it as you want.

This is what you should see on your screen:

And finally run MyGoodApp.exe and MaliciousApp.exe:

That’s it! :-)

This is one of those statement that should be set in stones!

Her Majesty Don Hacherl replied to a “Newbie Question” in the amazing ActiveDir.org mailing list.

And PLEASE don’t ask who Don Hacherl is…. everybody knows he was the Lead Development Manager at Microsoft for Active Directory…

—- Original Post ————————————————

Subject: [ActiveDir] Newbie Question

We are upgrading our phone system (Unity (from Cisco) 4.2 –> 5).This requires an AD schema update.
We’re a relatively new company. 8000 seats. Not much AD experience.

We’re not trying to be too anal about this, but we do know that if AD gets screwed, we’re in a big mess.

Is there a preferred way to apply this upgrade to minimize any damage? We do not have a lab environment (I know, I know … We’ve tried). We won’t have time to set one up either.

How can we minimize any potential damage if something goes wrong?  How do you do it?
Thx in advance – smsadm

—- Don’s Reply ————————————————–

I have to make a comment here, as I’ve heard this too many times.
You do, in fact, have a lab environment. What you do not have is a production environment.
DonH

———————————————————————-

You can read the original thread here:
http://www.activedir.org/ListArchives/tabid/55/forumid/1/postid/33143/view/topic/ptarget/33153/Default.aspx

In the previous post Extending ADUC for remote management (part 1 – introduction) I explained how to customize ADUC with own menu items by playing with DisplaySpecifiers, not it’s the time to add some useful commands to ADUC.

Let’s start with something very easy, we are going to add a “Remote Control” menu item to the Computer context menu, so that we can initiate a Remote Desktop session by just right-clicking on the computer object in ADUC and select “Remote Control”.

Since 2004 Microsoft released an Add-on that just does the job, it’s called “Remote Control Add-on for Active Directory Users & Computers” and you can download it from the following link: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0a91d2e7-7594-4abb-8239-7a7eca6a6cb1

That Add-on completely relies on Remote Desktop Connection program (aka RDP Client or MSTSC), thus the RDP client must be installed and all conditions must be met for a working RDP session(Remote Desktop or Terminal Services enabled on the target computer, permission to connect, etc…).

Download/extract the rControlAD.exe and do the following:

a) run “rcontrol_setup.exe” in the context of user account member of Enterprise Admins group (don’t worry it won’t harm your AD, but of course give it a try in a test environment!)

b) copy rControl.exe to a folder that is included in the %path% system variable such as %windir% or %windir%System32

c) modify the registry (or create a reg file for importing) with the following parameters to control the behavior of Remote Control:

[HKEY_CURRENT_USERSoftwareMicrosoftrControlAD]

"FullScreen"="1"

"ConnectToConsole"="0"

"Width"="0"

"Height"="0"

"UseCustomPortNumber"="0"

"PortNumber"="3389"

Note: the settings are self-explanatory but you may learn more from the included Readme_first.txt file.

Give it a try, it will work like a charm!

So what did the setup do at point a)?
If you carefully read Part 1 you know the answer. It just added the context menu “Remote Control” item to ADUC by adding an entry in the adminContextMenu attribute of the Computer-Display object located in the Configuration Partition (that’s why Enterprise Admins rights are required).

Let’s have a look behind the curtains… run ADSIEDIT.MSC and browse the configuration partition (also said Configuration Naming Context) at
cn=409,cn=DisplaySpecifiers, cn=Configuration,<ForestRootDN> (remember 409 is the identifier for United States, but you will see rcontrol_setup.exe has changed all the language cn=! so that it can be used on any language OS).
Right click on “CN=computer-Display” and select “Properties”, then open the AdminContextMenu multi valued string attribute, you will find the default “1,{08eb4fa6-6ffd-11d1-b0e0-00c04fd8dca6}” (dsadmin.dll) PLUS a new entry in the format “<order number>,&<menu item name>,<command line/script>”:

“2,&Remote Control,rcontrol”

So what happens when you right click on the computer object in ADUC and select “Remote Control”?
ADUC passes the full LDAP path of the selected computer to rcontrol.exe which I presume will invoke MSTSC with the proper parameters such as the computer name retrieved from ADUC and those registry settings explain above at point c).

In the next part, we will see how the full LDAP path of a computer can be converted into its DNS name that is better usable when passed as an argument to an external command or script.

One of the most recurring issue I’ve been reported to by people who have delegated permissions to join computers to the domain is a Windows XP box showing up this error message:

Computer Name Changes – The following error occurred attempting to join the domain “domain.com”:
Your computer could not be joined to the domain. You have exceeded the maximum number of computer accounts you are allowed to create in this domain. Contact your system administrator to have this limit reset or increased.

First let me say that I dislike Microsoft suggesting to call the administrator and tell him/her what to do… even worse pretending to have that limit reset or increased!

Second, the answer is in the title of this post. Yes, any domain user by default can join up to 10 computers to the domain… or better… “Authenticated Users” are granted with the privilege to “Add workstation to domain” and create them in the default “Computers” container within a default quota (10) that is written in the ms-DS-MachineAccountQuota attribute at the root of the Domain Naming Context.
Although this value can be changed for example via ADSIEDIT, switching that value to 0 is the only change that can make sense to me! :-)
NOTE: Administrators and delegated users are exempt from this quota, of course.

How the number of computers a certain uses has joined to the domain is computed? Simply by looking at the mS-DS-CreatorSID attribute of each computer objects that is populated with the SID of the authenticated user who joined a computer to the domain (and created the computer object in AD), any matching mS-DS-CreatorSID to the user’s objectSID  SID adds +1 to the counter.
NOTE: ms-DS-CreatorSID is one of those indexed attribute, thus the query should not be slow even on huge AD.

Question: if one of those “marked” computer is deleted, does the number of computers created by a user decreases so that the user can again join another computer to the domain? Answer: Yes, because of the way joined/created computers are calculated!

So, going back to the initial issue, that user is attempting to join the eleventh machine (if default was not changed), it might be the user delegated to join computers to the domain is not pre-creating computer objects in the proper OU and his perception is that delegation does not work anymore…. that means he/she will blame on Domain Admins! LOL! :-)

It happens that when I say to someone “Open ADUC…”, I am said: “… ehm… what’s ADUC?”.

Well, ADUC is the short for “Active Directory Users and Computers“, the MMC snap-in (dsa.msc) that most administrators daily use to manage objects in Active Directory . Sometimes I get nervous with acronym insanity, but to be honest “ADUC” saves a lot of time here! :-) (precisely 32bytes!)

The nice thing of AD management GUIs (ops! yet another acronym!) is that they can be extended – for example with custom menu items – and those extensions are forest-wide available!

So, how can you customize ADUC? The magic words here are “Display Specifiers” and if you have been reading carefully so far you can imagine where Display Specifiers are located in AD…. they’re in the Configuration Partition of course (have you noticed I just said they’re forest-wide available?) and to be more precise you fill find them here:

cn=DisplaySpecifiers, cn=Configuration,<ForestRootDN>
(where “ForestRootDN” is the Distinguished Name of your forest, e.g. dc=contoso,dc=com)

NOTE: if you’re not familiar with LDAP syntax, be careful about the difference between cn= (common name) and dc= (domain component)

I hear you asking “Great! But… what are Display Specifiers?”.
To make it very short, any object that can be created in AD has its own objectClass (the object type) that is defined with a classSchema object stored in the forest schema, plus one or more display specifiers that define how that objectClass will be displayed in the management GUI. Of course the display specifier is an object itself and has its own class (displaySpecifier class) and the attributes of that object class are just the GUI elements such as context menus, property page, etc…
Remember that display specifiers are localized with language codes according to the following table: Language Identifier Constants and Strings (0×0409 is United States) so that you may have different display specifiers per each language.
You may also look at: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\ContentIndex\Language

Let’s do some practice (in your test environment of course!)
Log onto the system with a user account that has the proper privilege to write in the Configuration Partition (e.g. Enterprise Admins) and install an AD editor such as ADSIEDIT.MSC or Sysinternals AD EXPLORER.
Note: ADSIEDIT.MSC is part of Windows Server 2003 Support Tools, at the time I’m writing this post the latest version is SP2.

Run ADSIEDIT.MSC and browse the configuration partition at
cn=409,cn=DisplaySpecifiers, cn=Configuration,<ForestRootDN>
Note: 409 is the identifier for United States, you should select a different identifier if you use ADUC on a different Windows language.

On the right pane there is the list of all displaySpecifier classes whose names have a “-Display” suffix. The ones we will work on are “CN=computer-Display” and “CN=user-Display” because we will add context menus to manage Users and Computers.
Right click on “CN=computer-Display” or “CN=user-Display” and select “Properties” and open the AdminContextMenu multi valued string attribute, you will find “1,{08eb4fa6-6ffd-11d1-b0e0-00c04fd8dca6}” GUID, just know that it represents the whole context menu used by ADUC (and by Windows Server 208 ADSS as well) and it binds to C:\WINDOWS\system32\dsadmin.dll

Well, the Computer or User Context Menus can be customized in ADUC by just adding more items to the AdminContextMenu of the corresponding displaySpecifier class (remember the “-Display” suffix) with the following format:

<order number>,<clsid> or
<order number>,&<menu item name>,<command line/script>
NOTE: order number is the item position in the context menu

NOTE: the shellContextMenu attribute was used to identify end-user context menus to display in the Microsoft Windows shell. The context menu appeared when the user viewed the context menu for objects in the Windows Explorer. Beginning with Windows Server 2003, the Microsoft Windows shell no longer displays AD objects.

Because we’re going to add a context menu to run a program (a vbs script in our example), we expect that contextual value is passed to the program invoked by the menu item. Our expectation is met because the full LDAP path of the selected object is passed as an argument to our program:

LDAP://DC-FQDN/CN=Objectname,OU=OuName,<DomainDN>
example: LDAP://dc1.contoso.com/CN=pc01,OU=Computers,OU=Italy,DC=contoso,DC=com

Let’s do a quick test.
DON’T BE SCARED! Any change to display specifiers is reversible and has nothing to do with Active Directory Schema Extensions! (This does not mean you can do your tests in the production AD!).
Create a DisplayValue.vbs script with the following two lines:

set shell = createobject(“wscript.shell”)
wscript.echo WScript.Arguments.Item(0)

save the script under %windir%\system32 and execute ADSIEDIT.MSC as exaplained above.
Browse the configuration partition at:

cn=409,cn=DisplaySpecifiers, cn=Configuration,<ForestRootDN>
(remember 409 is the language identifier for US)

On the right pane right click on “CN=computer-Display”, select “Properties” and open the AdminContextMenu attribute to add the following string:
<order number>,&TestMenu,DisplayValue.vbs
(example: 2,&TestMenu,DisplayValue.vbs)

If you run multiple DCs with replication latency (weird in a test lab!), wait for the time that change will be replicated to the DC ADUC will target.
Finally start ADUC, right click on a computer object and select the “TestMenu” menu item.
You should get a windows box with the full LDAP path of that computer object!

OK, enough theory for an “introduction”, now we are ready to make things for real…. so if you’re interested… STAY TUNED AND DON’T MISS THE SOON COMING PARTS!

PS = Have I already told you that my friends call me “Mr. Verbose”? :-s

If you’re an AD lover, surely you came across the O’Reilly Active Directory book series, especially the 3rd Edition (by MVP Joe Richards), which is known to be one of the best book around AD in the Windows Server 2003 era.

Now it’s the time for MVP Brian Desmond with the 4th Edition that covers all the new features that Windows Server 2008 brought to AD such as RODC, FGPPs, GlobalName DNS Zones, etc… Joe Richards was a reviewer of this book.

Brian has a dedicated page on his blog: http://briandesmond.com/ad4/
Author, contributors and reviewers are top-porters in the amazing ActiveDir.org mailing list.