Open a Socket!

A number of companies that I work with use the Acctinfo.dll to provide  additional user information when working with Active Directory Users and Computers (DSA.MSC).  You can download Acctinfo.dll from the Microsoft web site as part of the Account Lockout and Management Tools package.

What isn’t quite so well known is that an updated version of the tool, Acctinfo2.dll, has been available for some time.  There is sadly no download available for it and the only way I know to get hold of it is via Microsoft Product Support Services (PSS).  The newer version contains a number of enhancements, such as:

• Ability to view replication metadata.  This provides the same information as the repadmin /showmeta <objectDN> command.
• Support for lastLogonTimestamp attribute.  The original acctinfo.dll only shows the last logon for a specific Domain Controller.
• The tab now appears as an option when users are returned as a result of a search.  This was not the case with acctinfo.dll.

The screenshot below shows the acctinfo2.dll in action.

I was pleased to see from Kurt Roggen’s Blog that Acctinfo.dll still works with Vista SP1 and RSAT.  Based on this, I thought I would try to get Acctinfo2.dll working on Vista SP1 and RSAT.  Unfortunately, I currently only have a 64-bit version of Vista in my VMWare lab environment and it doesn’t work on this platform.  The dll fails to register with the following error:

“The module “c:\windows\acctinfo2.dll” was loaded but the call to DllRegisterServer failed with error code 0×80070002.”

I’ve since had it confirmed from an authoritative source within Microsoft that the tool won’t load on a x64 platform.  It seems no further development of the tool is planned, which is a shame given that so may people appear to be using it. ++++ Update: news about a 64-bit version available here ++++

There are a number of different versions of Acctinfo2.dll floating around.  If you are planning to request a copy from PSS make sure it is the following (or more recent):

Version 2.0.0.2000 (Modified: Thursday, 26 October 2006)

Here’s a cautionary tale.  In a rash moment I volunteered to present a session at TechEd in Auckland in early September.  Be careful what you wish for….I’ve been confirmed as a speaker for a break-out session on Windows Server 2008 Active Directory.  The title is Windows Server 2008 Active Directory Deep Dive and you can catch it on Wednesday 3rd September at 12.10pm.  Or you could simply take an early lunch

I remember the last time I spoke at TechEd.  I woke up at 5am on the morning of my session and thought about gnawing my leg off in an attempt to avoid having to stand up and talk in front of a few hundred people.  In the end it was all ok and I managed to make it through the presentation without looking like a complete idiot (or so my friends tell me…).

I won’t be presenting a session at TechEd Australia in Sydney.  Instead I will be speaking at what they call a MVP Theatre Session.  I’m kind of hoping the Theatre part refers to the venue, rather than a call upon my limited thespian skills.  Anyway, my theatre session is on Administrator Role Separation in Windows Server 2008 at 1pm on Friday 5th September.  Be there or be…at lunch.

If you’re reading this and will be attending either of the TechEd events, come along an say hi (even if you decide to prioritise lunch ahead of listening to my session).

Call me rash and impulsive, but the other day I blew away XP and installed Windows Server 2008 x64 Standard Edition on my Dell Latitude D830 laptop.  Other than idle curiosity, the main driver behind my foolishness was the need to create some demo machines using Hyper-V.  I don’t have any other hardware that meets the system specifications for Hyper-V, so it was the laptop or nothing.

The installation itself was a breeze and completed without mishap.  Windows Server 2008 didn’t have the correct video drivers, but I found these fairly quickly on the Dell support site.  They were Vista 64bit drivers, but work just as well for Windows Server 2008.

The first problem I encountered was that the built-in Intel PRO\Wireless 3945ABG wireless connection no longer works.  I found some 64bit Vista drivers from the Intel web site, which seemed to load ok, but I can’t see any wireless networks despite Device Manager showing the device as working properly. The Intel PROSet/Wireless diagnostic tool passes on the driver test, but fails on the hardware test.  The Dell web site also has 64bit Vista drivers but these are older than those from Intel.  I tried these older drivers too, but again without success.

I even tried installing my old Cisco Aironet 350 series wireless card, but couldn’t find any drivers that would work for that either.  The Cisco support site’s latest drivers for the card are for XP.

The second annoyance is that VMWare Workstation guests were working fine until I installed Hyper-V.  Then all hell broke loose.  The VMWare guests started causing the host to bluescreen.  There were also warning messages on the guests about changes to processor speed.  Oh, and I lost 64bit guest support.   Apparently, all this is due to incompatibilities between the hypervisors used by VMWare and Hyper-V.  Happily, I found a workaround on Geert Baeke’s web site that shows how to create a new entry in the boot loader that allows you to select a hypervisorless (is that a word?) boot option.  Good stuff.  Here’s a link to the information.

http://blog.baeke.info/blog/_archives/2007/12/18/3416738.html

Now I’m busy creating virtual machines in Hyper-V.  I haven’t used it before, but it all seems fairly intuitive, especially for anyone already familiar with VMWare.

One of the improvements to Active Directory Users and Computers (DSA.MSC) in Windows Server 2008 is the "protection from accidental deletion" feature.  This blog article explains what the feature is and how it works under the hood.

Probably the most common cause of restore operations in AD is accidental deletion of objects.  Administrators with fat fingers can fairly easily delete a single object, an OU or an entire OU tree.  Windows Server 2008 provides a handy checkbox that protects an object from accidental deletion.  The screenshot below shows the checkbox selected by default during the creation of a new OU.

The checkbox is subsequently available on the Object tab of the object’s properties, as shown below.  Note that the protection is not just for OUs, it can be set on the Object tab for all object types, including users.

When you attempt to delete an object in Active Directory Users and Computers, you will see the following standard warning.

If you then select Yes, and the object is protected from accidental deletion you will see the error message, "You do not have sufficient privileges to delete <object_name>, or this object is protected from accidental deletion", as shown below.

To go ahead and delete the object you have to go back to the object’s properties, deselect the checkbox on the Object tab and then try the deletion again.

So how is this feature implemented behind the scenes?  Well, it’s simply really.  When the checkbox is selected, two new "Deny" access control entries (ACEs) are added to the discretionary access control list (DACL) in the object’s security descriptor.  These explicitly deny everyone permission to delete the object and/or delete the subtree.   The screenshot below shows the entries in the Security -> Advanced view of the object’s properties.   An explicit Deny entry beats an Allow entry, which effectively means the object cannot be deleted by anyone without first removing the ACEs, either by editing the security directly or toggling the accidental deletion checkbox on the Object tab.

It may not represent a radical change to AD like the RODC or Fine-Grained Password Policies, but Microsoft has done a good job in providing a simple-yet-effective method of protecting objects from accidental deletion in Windows Server 2008. 

Those of you already familiar with Windows Server 2008 will know that one of the key Active Directory-related improvements is the introduction of the Read-Only Domain Controller (RODC).  With the RODC comes the ability to separate administrative roles.  This removes the restriction of having to use a Domain Administrators account when carrying out administrative tasks on a DC.   For example, changing the Network Card on a Domain Controller on a Windows Server 2003 DC requires a Domain Admin account, which is clearly overkill.  On a Windows Server 2008 RODC you can now delegate machine-specific administrative tasks to a local administrator.  The delegated account requires no elevated privileges within AD. 

You can specify an account or group to be the the local administrator for a RODC when pre-staging the creation of the RODC on a writeable DC (or at a later time if you prefer).  This pre-staging activity (also new in Windows Sever 2008) delivers the ability to complete the promotion of the RODC using the account (or members of the group) you specified to be the local administrator.  In the example below, I have specified a group named RODC1 Local Admins to be the local administrator for the RODC1 Domain Controller.  Note that the group name I use specifies the the machine name (i.e. RODC1).  This is because the group will typically be used for only one RODC, rather than for all RODCs.

The group or account that you specify will be assigned to the managedBy attribute value of the RODC’s computer object in AD.

You can then use the account (or member of the group you created if you used a group) to complete the promotion of the RODC by running DCPROMO on the server that is to become the RODC (see below).   Again, bear in mind that the account used does not need to be a member of Domain Admins.  You will however receive a warning during the DCPROMO process (see below), which you can safely ignore when completing the promotion of a pre-staged RODC.

The local administrator account can then subsequently be used to log on locally to the RODC and to perform administrative tasks.  Remember that the account will only have local administrator rights to the local RODC. 

We know that the managedBy attribute for the RODC is used to store the account or group that is allowed local administrator rights on the RODC.  But the authentication mechanism needs to provide for scenarios where AD is not available, so how is this information actually used by the RODC?   The information is actually stored in the registry on the RODC in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RODCROLES

As you can see from the screenshot below, the Security Identifier (SID) shown in the “Repair Admins” REG_SZ value corresponds to the account or group specified in the managedBy attribute value on the RODC’s AD object.

Hint: You can use the SID Lookup feature of LDP.EXE to match a  SID to a friendly name.

If you need to include additional local roles, you can use the “Local Roles” feature within NTDSUTIL.   You can define the following local roles

Administrators
Users
Guests
Remote Desktop Users
Network Configuration Operators
Performance Monitor Users
Performance Log Users
Distributed COM Users
IIS_IUSRS
Cryptographic Operators
Event Log Readers
Certificate Service DCOM Access
Incoming Forest Trust Builders
Terminal Server License Servers
Pre-Windows 2000 Compatible Access
Windows Authorization Access Group
Print Operators
Server Operators
Account Operators
Backup Operators
Replicator

When a new local role has been defined, it will appear within the same RODCROLES registry key with a relative identifier that corresponds to the role.  In the example below, an account named “morgaaa” has been assigned the Print Operators local role. 

C:\Windows\system32\ntdsutil.exe: lo ro
local roles: add morgaaa “print operators”
Successfully updated local role.
local roles: show role “print operators”
        TMAD\morgaaa
local roles:

Given that the registry values show the relative identifer (e.g. 550), rather than the the friendly name (e.g. Print Operators) you can use the Microsoft KB article Well-known security identifiers in Windows operating systems to match the registry value to the role.

Remember to ensure that the passwords for the domain accounts used for local roles are cached on the RODC.   Unless you do this, you will not be able to log on to the RODC in situations where other DCs are not available (e.g. when the network link from the Branch office to the hub site is down).

The way in which the local roles are assigned and used is currently not well documented.  Hopefully this blog entry provides you with some useful additional information on how this new Windows Server 2008 feature.

Okay, okay, so I’m a little behind the times.  “Welcome to the nineties, dude!”, as a friend of mine would say.  I can’t help it - I’m the one who thinks this whole Interweb thing is just a fad.

Anyway, I’m working with a new laptop (Dell Latitude D830) that, apart from being the size of a dining room table, has some reasonably good specs.  The key thing about the D830 is that it has a 64-bit chipset.  This means that, although the operating system is the 32-bit version of Windows XP, I have the ability to run 64-bit VMWare Virtual Machine guests.  Getting the system to the point where I could fire up a 64-bit guest took a while, so I thought I would share my experiences here.

The first step is to determine whether your host machine hardware is capable of running 64-bit guests.  There are two methods I came across for doing this.

Method 1.  VMWare Processor Check for 64-Bit Compatibility

Download the tool from http://www.vmware.com/download/server/drivers_tools.html

The tool itself is tiny and gives a minimalist output when successful, as shown in the screenshot below.

Method 2.  CPU-Z

CPU-Z is a handy little freeware utility from http://www.cpuid.com/cpuz.php and provides information on some of the main devices of your system.  More importantly, it provides detailed information relating to your processor.

In my case it tells me that my processor is an Intel Mobile Core Duo T7500 (codename “Merom”).  The EM64T (Extended Memory 64 Technology) tag is important in that it indicates that the CPU is based on Intel’s 64-bit technology.  EM64T was the original name and has now been superseded by the term “Intel 64″.

Armed with the processor information from Method 2, I then used Google to try to confirm whether the model supports Virtualization Technology (VT).  Some CPU models that are based on EM64T architecture (like the one in my home PC!) are not VT-capable, which means that they do not support virtual machines as guests.  The best information I found was, curiously enough, on Wikipedia.   The page covering the “List of Intel Core 2 Microprocessors”  quickly gave me the information I was looking for.  Regarding my “merom” CPU it had this to say:

“Virtualization Technology: supported by all models except T5200, T5450 and some T5500″

Given that my model is T7500 it all looked very promising!

The next step was to check that the VT was enabled in my laptop’s BIOS.  For some bizarre reason known only to hardware manufacturers VT is typically disabled by default.  The BIOS settings obviously vary according to the manufacturer and model. For my Dell Latitude D830 the VT setting is located in the “POST Behavior” section under “Virtualization”.  POST stands for Power-on Self-Test - essentially the computer’s pre-boot sequence. As suspected, virtualization support was disabled in line with the factory default settings.

With VT was enabled in the BIOS it was all plain sailing and I am watching my Windows Server 2008 x64 guest machine run through the setup routine as I type.  The next step will be to install the 64-bit version of Exchange Server 2007 - something I have been unable to do in the lab until now. 

Windows Server 2008 introduces a new security principal called OWNER RIGHTS.  It was introduced to fill a security and delegation loophole in previous versions of Windows whereby creators of objects potentially inherit more permissions than are intended.  For detailed information on how the new feature works in the context of AD, see Jorge’s blog entry here.

Having learned about OWNER RIGHTS, I had a thought that there was perhaps some potential for organisations to snooker themselves through over-enthusiastic (or downright stupid) delegation.  Taking an extreme example, was it possible to completely block administrator access to domain objects through willful abuse of OWNER RIGHTS?  Here’s how I approached the task.

First, I checked the current owner of the top of the domain tree (domainDNS object).  In my lab the domain is named DC=ad,DC=fisheagle,DC=net and the owner is set to the default Administrators group.  The only account in the Administrators group is the default Administrator account.

I then set explicit Deny entries for everything for the OWNER RIGHTS security principle and applied it to “This object and all descendant objects”.  An explicit Deny beats an Allow entry, so my thinking was that the effect would be to block the Administrator account from having any permissions on any objects in the domain.

After setting the security in this way, I tried to launch Active Directory Users and Computers (DSA.MSC) while logged in with the Administrator account and was encouraged to see the following error.

When the snap-in opened, it looked very much like my Administrator account was indeed denied access to anything in the domain.  If this were a live environment with no other admin accounts, I thought, there would be some sweaty palms right about now!

That’s when I tried a few things and found a workaround.  I ran the following DSACLS command while logged in with the Administrator account:

          dsacls “DC=ad,DC=fisheagle,DC=net” /takeOwnership

It applied successfully and the effect of this was that I could then immediately get back in to manage objects in the domain.  I hadn’t expected this to work, because one of the Deny entries I had set was for “Modify permissions”.  When I had a look at the security descriptor afterwards, I saw that the OWNER RIGHTS permissions had been changed.  The explicit Deny entries were still there, but it now applied to “Nothing” instead of “This object and all descendant objects”.

I don’t usually try to break things, but sometimes it helps when learning new product features.  In this case, it was reassuring to discover that there are ways to recover from badly implemented delegation using OWNER RIGHTS.

If you’ve managed to get some hands-on experience with the RTM Windows Server 2008, you might be surprised to see the version shown as Service Pack 1.  Relax, you haven’t been in a coma - this really is what the RTM release calls itself (see below).

The reason for Service Pack 1 moniker is so that service packs and patches for Vista and Windows Server 2008 can be streamed together.  From a customer perspective this is potentially less confusing than was the case with, say, Windows XP and Windows Server 2003 where the service packs were not aligned. 

The cynical among us might also consider than many organisations hold off from deploying a new Microsoft release until at least SP1.  In other words, this is perhaps a clever ploy from Microsoft to push customers towards early adoption.

One interesting facet of the close alignment between the Vista and Windows Server 2008 is that it appears to have caused some confusion with BgInfo, as shown in the screenshot below from a Windows Server 2008 machine.