Functional levels were first introduced when Active Directory made its appearance in Windows 2000 Server. They allowed you to run different versions of domain controllers in your environment, and when all the domain controllers were brought up to a certain version of Windows, you could raise the functional levels to gain the added features of that operating system version. Now that Windows 2008 R2 is released, it is unlikely that you will mass deploy this new operating system to your entire forest or domain. Instead, you’ll deploy a single domain controller and kick the tires, so to speak. The time will eventually come when you’ve upgraded every domain controller to R2, and at that point you can raise the functional level to 2008 R2 to take advantage of the new features.

Functional levels can be raised in domains or, as of Windows 2003 Server, in the forest, providing different features in each. They are differentiated by labeling them Domain Functional Level and Forest Functional Level.

What’s new in 2008 R2

Domain Functional Level

There are two features added when raising the domain functional level to 2008 R2. They are Authentication Mechanism Assurance and Automatic SPN Management.

Authentication mechanism assurance is meant for domains that utilize federation services (ADFS) or certificate-based authentication methods, such as smart card or token-based authentication. This mechanism adds information to the user’s kerberos token on the type of authentication used. This allows administrators to modify group membership based on how the user authenticates. For example, a user can have access to different resources if they log in with a certificate versus when they log in with just their username and password.

Automatic SPN management provides a method for managing service accounts for applications such as Exchange, SQL and IIS. In the past, regular domain accounts were used for these purposes, adding management headaches in terms of password management and service principle names (SPNs). This new feature provides the following benefits:

• A class of domain accounts can be used to manage and maintain services on local computers.
• Passwords for these accounts will be reset automatically.
• Do not have to complete complex SPN management tasks to use managed service accounts.
• Administrative tasks for managed service accounts can be delegated to non-administrators.

Forest Functional Level

There is one new feature in raising the forest functional level to Server 2008 R2, and it is long overdue. It is the Active Directory recycle bin. In the days of old, when an IT administrator or help desk operator accidentally deleted an OU filled with user or computer objects (this has happened more times than you would think), there would be a scramble to perform a restore. The delete replicates to all domain controllers, so an authoritative restore in Active Directory restore mode from a good backup using NTDSutil would be in order. With 2008 R2 forest functional level, a powershell cmd-let will undo this instantly.

Note that this feature is not enabled automatically when raising forest functional level. Additionally, you must run the following command in the Active Directory Module for Powershell.

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration, DC=mydomain,DC=com’
–Scope ForestOrConfigurationSet –Target ‘mydomain.com’

Functional levels of previous version

The following are the previous functional levels and what features they added, as documented in Technet.

Domain Functional Levels:

Windows 2000 Native:

• Universal groups are enabled for both distribution groups and security groups.
• Group nesting.
• Group conversion is enabled, which makes conversion between security groups and distribution groups possible.
• Security identifier (SID) history.

Windows Server 2003

• The availability of the domain management tool, Netdom.exe, to prepare for domain controller rename.
• Update of the logon time stamp. The lastLogonTimestamp attribute will be updated with the last logon time of the user or computer. This attribute is replicated within the domain.
• The ability to set the userPassword attribute as the effective password on inetOrgPerson and user objects.
• The ability to redirect Users and Computers containers. By default, two well-known containers are provided for housing computer and user/group accounts: namely, cn=Computers, and cn=Users,. This feature makes possible the definition of a new well-known location for these accounts.
• Makes it possible for Authorization Manager to store its authorization policies in Active Directory Domain Services (AD DS).
• Includes constrained delegation so that applications can take advantage of the secure delegation of user credentials by means of the Kerberos authentication protocol. Delegation can be configured to be allowed only to specific destination services.
• Supports selective authentication, through which it is possible to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest.

Windows Server 2008

• Distributed File System (DFS) Replication support for SYSVOL, which provides more robust and detailed replication of SYSVOL contents.
• Advanced Encryption Services (AES 128 and 256) support for the Kerberos authentication protocol.
• Last Interactive Logon Information, which displays the time of the last successful interactive logon for a user, from what workstation, and the number of failed logon attempts since the last logon.
• Fine-grained password policies (FGPP), which make it possible for password and account lockout policies to be specified for users and global security groups in a domain.

Forest Functional Levels:

Windows 2000:

There were no forest functional levels, just domain.

Windows Server 2003:

• Forest trust.
• Domain rename.
• Linked-value replication (changes in group membership store and replicate values for individual members instead of replicating the entire membership as a single unit). This change results in lower network bandwidth and processor usage during replication and eliminates the possibility of lost updates when different members are added or removed concurrently at different domain controllers.
• The ability to deploy a read-only domain controller (RODC) that runs Windows Server 2008.
• Improved Knowledge Consistency Checker (KCC) algorithms and scalability. The Intersite Topology Generator (ISTG) uses improved algorithms that scale to support forests with a greater number of sites than can be supported at the Windows 2000 forest functional level. The improved ISTG election algorithm is a less intrusive mechanism for choosing the ISTG at the Windows 2000 forest functional level.
• An improved ISTG algorithm (better scaling of the algorithm that the ISTG uses to connect all sites in the forest).
• The ability to create instances of the dynamic auxiliary class called dynamicObject in a domain directory partition.
• The ability to convert an inetOrgPerson object instance into a User object instance, and the reverse.
• The ability to create instances of the new group types, called application basic groups and Lightweight Directory Access Protocol (LDAP) query groups, to support role-based authorization.
• Deactivation and redefinition of attributes and classes in the schema.

Windows Server 2008:

No forest functional level changes occurred from Windows 2003 to Windows 2008.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• Using Group Policy to Disable JavaScript in Adobe PDF Files

This article is not just for the CLI fans like me, who snicker when forced to grab at the mouse for tasks they much prefer taking on in that wonderful black box with the blinking cursor; but for anyone who will deploy a core installation of Windows. This is not an anti-GUI rant, but a look into the CLI, and one that is much needed after Microsoft released Windows 2008 Server Core Edition.

Microsoft started to return CLI tools back to administrators in Windows 2000 when they released netsh.exe. More and more CLI options surfaced with releases of Support Tools, Resource Kits, and the popular PS suite from SysInternals (now Microsoft). The most recent evidence of the resurgence of the CLI is Windows 2008 Server Core Edition. This version is entirely driven with the command line interface.

The following roles are supported in a core installation:

• Active Directory Certificate Services
• Active Directory Domain Services
• Active Directory Lightweight Directory Services (AD LDS)
• DHCP Server
• DNS Server
• File Services (including File Server Resource Manager)
• Hyper-V
• Print and Document Services
• Web Server (including a subset of ASP.NET)

Why choose core over a standard installation? A core setup will only install the binaries needed by the server roles. Microsoft claims that if Windows 2000 Server had a core edition, it would have had a 60% reduction in patches (40% in Windows 2003). This is a considerable amount of patches for critical servers such as domain controllers.

So let’s get started with some administration tasks in Windows 2008 Server Core Edition: getting things up and running, configuring roles, promoting to a domain controller, and essentially running a version of Microsoft’s OS that does not include explorer.exe. (What? No Desktop?)

The following commands were executed on an installation of Microsoft Windows 2008 Server Core Standard R2. For those who don’t have the time to muck with the CLI, R2 has included a new VBScript (sconfig.vbs) which provides a menu driven server configuration tool to quickly get through these steps. However, I recommend doing it the long way at least once to understand what’s happening in case you run into issues in the future. The install is straightforward, so details not needed. Most important is the option of which version of the OS to install, which I selected Windows 2008 R2 Standard (Server Core Installation). After a dialog to set the administrator password, I’m left with a DOS prompt.

GETTING STARTED

First things first, IP connectivity. I’ll be using 192.168.1.0/24 for the network:

Note: netsh.exe allows you to add all the options/parameters in one line, or you can run netsh.exe and go into each configuration category, (ie. interface), then eventually when deep enough into the options, execute the command, (ie. set). To keep it simple, I’ll write out the commands in single lines, but definitely run netsh.exe with no options and look into the many configuration areas available.

Let’s list available network interfaces to see which one we need to configure:

netsh interface ipv4 show interfaces

Result:

  Idx     Met        MTU           State                Name
  –--  ----------  ----------  ------------  ---------------------------
    3           5        1500  connected     Local Area Connection
    1          50  4294967295  connected     Loopback Pseudo-Interface 1

netsh int ipv4 set address name=3 source=static address=192.168.1.25 mask=255.255.255.0 gateway=192.168.1.1

Note the name=3 parameter; 3 was the IDX number retrieved in the previous step. You will not get a resulting output, but you can double check your settings by running ipconfig /all.

Next step is to add DNS servers for name resolution. If this will be the first Domain Controller in the Forest and will run DNS, you can skip this, otherwise, add your DNS servers now (the example assumes DNS servers 192.168.1.20 and 192.168.1.21):

netsh interface ipv4 add dnsserver name=3 address=192.168.1.20 index=1

add a secondary dns server:

netsh interface ipv4 add dnsserver name=3 address=192.168.1.21 index=2

Note that we used the name=3 parameter again to add these DNS entries to the network interface we are interested in. Once again, you can double check your settings with ipconfig /all.

Now we have connectivity. Let’s rename the computer and join a domain. Windows had assigned a random computer name, you can see what it is by typing hostname. Mine happened to be WIN-EPNB8G5FAUI. Let’s rename this to CORE-DEV:

netdom renamecomputer %COMPUTERNAME% /NewName:CORE:DEV

You will be warned about the potential hazards of renaming the computer, not our concern since this is a brand new installation. Proceed, and you will have the following results:

The computer needs to be restarted in order to complete the operation.

The command completed successfully.

Restart the computer by typing: shutdown /r /t 001

After restarting, log back in, and let’s join a domain. Our test domain is called testdom.local. We will use an account called admin to join the domain:

netdom join CORE-DEV /domain:testdom.local /userd:testdom\admin /passwordd:*

The * for the password option will prompt you for the password. A reboot is again required.

Now you can log in with a domain account by choosing other user, then typing domain\user for the user.

ACTIVATION

Now, let’s activate Windows. In R2, you enter the license key with slmgr.vbs (prior to R2, the installation setup prompted for the license key).

slmgr.vbs –ipk ABCDE-FGHIJ-KLMNO-PQRST-UVWXY

Next, activate:

slmgr.vbs -ato

If successful, you will not receive any messages back.

CONFIGURING AUTOMATIC UPDATES

I recommend controlling the behavior of automatic updates with Group Policy, but if you need to toggle the settings, here are the commands:

To verify the current setting:

cscript scregedit.wsf /AU /v

To enable automatic updates:

cscript scregedit.wsf /AU 4

To disable automatic updates:

cscript scregedit.wsf /AU 1

To check for updates:

wuauclt /detectnow

FIREWALL

Let’s take a look at the firewall now, since we will want to open up some rules to perform remote administrations tasks, such as using Remote Desktop or MMC tools to manage the server.

We can take a look at the firewall profiles by typing:

netsh advfirewall show allprofiles

If you have a domain profile applied via GPO, then those will apply. You can also look at all the rules by typing:

netsh advfirewall firewall show rule name=all

That command will display quite a bit of information. I like to output it to a text file and view it with notepad.

Now, let’s make some changes to allow remote connections to the server. Here, I don’t exactly follow the steps documented in Technet or most web sources since the commands documented will open up the ports and allow any source address. Here, we open Remote Desktop (TCP-3389) only to our subnet.

netsh advfirewall firewall set rule name="Remote Desktop (TCP-In)" new remoteip=192.168.1.0/24

This changes the firewall RDP rule to allow our subnet only. The default rule is Any. Now, let’s go ahead and enable this rule:

netsh advfirewall firewall set rule name="Remote Desktop (TCP-In)" new enable=yes

The firewall is now open for RDP connections from our internal subnet, but we still have to enable Remote Desktop:

cscript %windir%\system32\SCRegEdit.wsf /ar 0

Now you could Remote Desktop to the server. Of course you will only get a command prompt when you do.

Next, we’ll open up some rules to allow remote management using the MMC. This will allow using Computer Management, Shared Folders, Event Viewer, and other important snap-ins to manage your server. The process is the same as it was opening the Remote Desktop rule, but the rule names are different:

netsh advfirewall firewall set rule name="Remote Administration (NP-In)" new remoteip=192.168.1.0/24
netsh advfirewall firewall set rule name="Remote Administration (NP-In)" new enable=yes
netsh advfirewall firewall set rule name="Remote Administration (RPC)" new remoteip=192.168.1.0/24
netsh advfirewall firewall set rule name="Remote Administration (RPC)" new enable=yes
netsh advfirewall firewall set rule name="Remote Administration (RPC-EPMAP)" new remoteip=192.168.1.0/24
netsh advfirewall firewall set rule name="Remote Administration (RPC-EPMAP)" new enable=yes

These three rules are in a group called “Remote Administration” and if you are not concerned about modifying the rules so that only the specific subnet is allowed, you can modify enable the group as-is which will allow connections from any IP:

netsh advfirewall firewall set rule group="Remote Administration" new enable=yes

CONFIGURING ROLES

There are two commands to use when dealing with server roles: oclist and ocsetup. Later, we will look at the new dism.exe If you type oclist, you will get a list of all the roles and their optional components. The list is pretty lengthy, so I like to use the find command to narrow my results. For example, if we wanted to add the DHCP server role, I would check for the precise name of the role by typing:

oclist | find /i "dhcp"

Results:

Not Installed: DHCPServerCore

Now I know the role name is specifically DHCPServerCore and that it is in fact not installed. So, we install the role by typing:

ocsetup DHCPServerCore

Note that the above server role IS case sensitive. If I use oclist again to check for DHCP, I now see the following:

oclist | find /i "dhcp"

Results:

Installed: DHCPServerCore

If I wanted to remove the role, I’d use the uninstall switch with ocsetup:

ocsetup DHCPServerCore /uninstall

Pretty straight forward. Now, with R2, there is a new CLI tool called dism.exe. This tool can also configure server roles, but it does much more. For now, we will use it to configure roles like we did with ocsetup/oclist.

To get a list of roles (called features in dism):

dism /online /get-features

Let’s add that DHCPServerCore feature using dism:

dism /online /enable-feature /featurename:DHCPServerCore

And then to remove it:

dism /online /disable-feature /featurename:DHCPServerCore

So, what is the big deal? Same results as ocsetup, but, dism will replace it because it goes further than just toggling features. It will service WIM and VHD image files, allowing add/remove of drivers and features, especially useful if your server has the role of deploying images or runs Hyper-V.

PROMOTING TO A DC

dcpromo is still the way to handle promoting and demoting domain controllers, but in a Server Core installation, there is no GUI wizard that comes along with it. Instead, you use an answer file with the command to instruct how to promote your DC. The syntax to this is:

dcpromo /unattend:c:\temp\answerfile.ini

I like to use ini for my answer file extension, but that’s a personal preference. Here are two examples of answer files to us with dcpromo:

To create the very first DC in a Forest:

[DCInstall]
ReplicaOrNewDomain=Domain
Installdns=Yes
confirmgc=yes
domainlevel=4
domainnetbiosname=TESTDOM
forestlevel=4
newdomain=forest
newdomaindnsname=testdom.local
safemodeadminpassword=password123

To add a replica domain controller in an existing domain:

[DCInstall]
ReplicaOrNewDomain=Replica
ReplicaDomainDNSName=testdom.int
Installdns=Yes
confirmgc=yes
safemodeadminpassword=password123

MORE IN THE CLI

Now you have a fully functioning server, are able to manage it with your MMC, and can connect via Remote Desktop. Although there are hundreds of commands you can use in the CLI, one that can do an enormous amount of tasks is wmic.exe. WMIC is a tool with hundreds of options for WMI. You can do just about anything here. A few examples:

wmic useraccount list
wmic process list
wmic share list

The above examples are all very simple queries for information. You can also use wmic to add and modify (ie. not just list shares, but create or change them). To see a full list of options: wmic /?

POWERSHELL

Powershell is now included with R2 and you can enable it just like any other feature. Powershell provides a shell and scripting language which will open up a world of options for administrating your Windows environment. What gives this shell its power is that it accepts and returns .NET objects. Instead of getting stdout, you can get an object and then perform actions with that object or get its properties. With a couple of lines of script code, you can pull all users from an OU and set their description field, or check when the passwords were last set. That is just one simple example working with objects using the DirectoryServices interface, and there are many others.

CONCLUSION

It is nice to see that the command line has made a return in the Windows world. If you’re unlike me, who typically has five or six command prompts open during a regular day, don’t be intimidated by it. Server Core can be a lean, secure, and well-managed option in your environment. It may take a little time getting used to not reaching for the mouse and clicking on the start button, but at the end of the day you will have that extra bit of satisfaction knowing exactly what occurred without a GUI keeping the details behind the scenes.

References:

• Real Men Don’t Click–The Project: http://isg.ee.ethz.ch/tools/realmen/
• Server Core Installation: http://technet.microsoft.com/en-us/library/cc753802(WS.10).aspx
• Using DISM: http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part2.html
• DISM Command Line Options: http://technet.microsoft.com/en-us/library/dd772580(WS.10).aspx
• WMIC: http://technet.microsoft.com/en-us/library/bb742610.aspx
• Powershell: http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
• Windows 2008 Command Line List (A-Z): http://technet.microsoft.com/en-us/library/cc772390(WS.10).aspx

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action

This information can be handy for several reasons:

• An interface running in promiscuous mode may be due to the user running network sniffer such as Wireshark.
• An interface running in promiscuous mode may be due to the user running virtualization software, such as Virtual PC.
• An interface running in promiscuous mode may be due to malicious code.

I definitely want to know if users are running network sniffers, or virtualization software (likely the guests are not licensed or managed causing rogue workstations in the environment). Of course any potential activity that may be caused by malware or malicious code is a concern as well.

You could very easily download promqry and run a for loop against your machines. I wanted to use WMI for this task instead and rather than a text file, use the directoryservices object to query my AD for computers.

I couldn’t find any property in Win32_NetworkAdapterConfiguration to check for this, but I found this post on promqry which tracked down the WMI classes it uses. That led me in the right direction. The other key to this is what MSNdis_CurrentPacketFilter returns. Microsoft documents this here and we are checking if the NDIS_PACKET_TYPE_PROMISCUOUS bit is enabled.

Below is a quick Powershell script which will grab computer objects from AD, then use WMI and the MSNdis_CurrentPacketFilter class to check for promiscuous mode. You can incorporate this WMI query with Win32_NetworkAdapterConfiguration and get a better picture of the interface network settings:

$ErrorActionPreference = "SilentlyContinue"


$PingTest = New-Object System.Net.NetworkInformation.Ping
$Filter = "(&(ObjectCategory=computer))"
$Searcher = New-Object System.DirectoryServices.DirectorySearcher($Filter)
ForEach ($comp in $Searcher.Findall()) {
    $strComputer = $comp.properties.item("Name")
    write-host "Checking: $strComputer"
    if ($PingTest.Send($strComputer).Status -eq "Success") {
        $colComputer = get-wmiObject -class "MSNdis_CurrentPacketFilter" -namespace "root\WMI" -comp $strComputer
        if ($colComputer -eq $null) {
            write-host "Couldn't connect to WMI" }
        else {
            foreach ($comp in $colcomputer) {
                $val = $comp.NdisCurrentPacketFilter
                if ($val -band 0x00000020) {
                    $inst = $comp.InstanceName
                    write-host "Interface: $inst"
                    write-host "The NDIS_PACKET_TYPE_PROMISCUOUS value is set" -foregroundcolor red -backgroundcolor yellow
                }
            }
        }
    }
    else { write-host "Could not ping, machine not queried." }
}

The following screenshot shows the results. I don’t like waiting for RPC to time out when the machine is off or not reachable, so a quick ping check before querying WMI speeds things up. Also, when an interface has the bit set, the output is highlighted with red text and a yellow foreground. You could wrap an email function and schedule this so that you are alerted when it comes up.

You will need proper access to the workstations to query root\WMI so when you run this in a domain, your account should have local administrator privileges to the computers it will query. If it doesn’t, the command will return “Couldn’t connect to WMI”.

Finally, if you haven’t looked at the MSNdis class yet, I suggest taking a look, especially at MSNdis_80211 which will query various wireless information that may be of interest. There isn’t a whole lot of documentation on it, so I’ll work on getting some details together and maybe draft a Powershell script to find wireless adapters and networks they are connected to or available networks close enough to connect to. Until then, enjoy finding those promiscuous mode adapters in your domain.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• First Patch Tuesday of 2010