In many organizations Active Directory Domain Services is the top tier in access management. Access to systems, information and connections, often, is governed by information in Active Directory. User objects and computer objects play a big role in this model, since they represent actual physical objects within the organization.
Now, not every organization acknowledges the importance of an up to date and lean Active Directory environment. In this series, I will show you four of the key challenges involved with managing Active Directory for any organization and how to solve them.
This series will focus most on the data inside the Active Directory database, instead of the actual technical implementation of Domain Controllers and such.
Today, I want to talk to you about stale user objects and stale computer objects. From a security point of view, these objects represent a real security risk to your organization.
Stale user objects
Depending on the process surrounding creating user objects, these objects are usually created with a predefined password. This makes the tasks of creating an account and communicating the account to the actual colleague two separate tasks, that can be carried out by two different persons at two different times.
Alas, the delegation of work does not outweigh the security risk involved with tens, hundreds or even thousands of user objects that can be brute forced for their password , most of the time configured with a default password for new accounts (Welcome123 and P@ssw0rd come to mind). Tools like Zohno’s free Z-Hire, I discussed last year, have the explicit option to provide a default password (but not generating one) per template.
One of the other factors that don’t help in the situation with stale user objects is that account lockout settings are non-existent in default Active Directory implementations.
Stale computer objects
Stale computer objects are even worse than stale user objects from a security point of view. By default computer accounts have broader access to information in Active Directory and by default, the password for the security channel used to be a default derivation of the hostname as explained in Microsoft KnowledgeBase article 255042 on How to make machine accounts programmatically by using ADSI with Visual C++:
The initial password for the machine account must be set to the name of the computer in lower case.
Using net use from a non-domain joined computer using the computer account (the NetBIOS hostname) and the default password for the computer account, a malicious person might gain access to data in Active Directory, on file servers and in Exchange public folders, as explained by Marcus Murray in his Live demonstration about some of the ways hackers attack [PDF] on page 11.
Luckily, by default a domain-joined computer will change its computer password at a regular interval. This means, the security concerns surrounding stale computer objects only apply to the first week or month of the lifecycle of the computer object, depending on the Operating System of the domain-joined machine:
|Windows 9x, Windows NT4, Windows 2000 || 7 days |
|Windows XP, Windows Vista, Windows 7, Windows 8 ||30 days |
A more permanent solution to the problem was introduced with Windows 7 with Offline Domain Join. Not only does this Active Directory Domain Services-related feature offer the ability to join a computer to an Active Directory domain without a networking connection between a Domain Controller and the computer to be joined. Its communication streamlining also applies to every domain join, as I covered earlier in my blog post on the Top 5 Myths on Offline Domain Join.
(Part of) The solution
A lot of times, the root cause of stale objects in Active Directory is the lack of (procedures for the) interaction between an HR department (who known who were hired and fired), a facilities department (who knows where computers are located) and the IT department (who need to make these changes to keep Active Directory up to date).
Optimizing communication between the HR, facilities and IT departments should be your main focus when trying to solve the situations surrounding stale user objects and computer objects. A process-based approach would best suit tackling this.
Processes will save you in the long run, but as an Active Directory admin, there’s also a couple of things you can do right now. You can take action to prevent most of the security breaches, by:
- configuring Account lockout policies in Active Directory
- configuring new user objects with randomly generated complex passwords
- migrating client computers to Windows 7 and/or Windows 8
With the long term covered with processes and the biggest security problems tackled, the only task left is the perform a cleanup in the Active Directory database.
You might want to get rid of:
- Computer objects that have not been used to log onto in the last 30 days
- User objects that have not been used to (interactively) log on ever
- User objects that have not been used to (interactively) log on in the last 30 days.
Cleaning stale computer objects
To detect stale computer objects, Microsoft has released a script as part of Knowledgebase Article 197478 that, under the hood, uses nltest.exe to check the PasswordLastSet output. Several PowerShell scripts exist that check the PwdLastSet (script) or lastLogonTimestamp (script) attributes directly in the Active Directory database. Joe Richards’ command-line tool oldcmp.exe is one of the leanest tools available to tackle the problem, while many other 3rd party solutions offer the functionality as part of a more elaborate reporting solution.
Many of these Active Directory reporting solutions will set you back a fair amount of budget, but STEALTHbits’ free StealthAUDIT Active Directory Assessment will both report on stale objects in bar graphs and will output its findings in XML-based files, ready for your PowerShell scripts. Since StealthAUDIT uses its own Microsoft SQL Server database, the load on your Domain Controllers when being examined remains minimal.
When you use these tools, you might find a surprising list of computers that have been identified as stale, but purring away peacefully as part of every day operations… This situation can be caused by settings that disable computer account password resets. Always browse through the list with inactive computer objects, before accidentally deleting active computer objects.
Protection from Accidental Deletion on individual computer objects might help preserving often targeted computer objects
Before performing any cleanup actions, would be an excellent moment to enable the Active Directory Recycle Bin.
Cleaning stale user objects
Stale user objects can be targeted with much of the same 3rd party tools. Again, a load of scripts can be used to find (and remove) unnecessarily created user objects.
When running Windows Server 2012 and Windows Server 2008 R2-based Domain Controllers you can also use the Global Search functionality in Active Directory Administrative Center (dsac.exe). The Global Search option has a couple of helpful default criteria, that help you identify dangerous user objects. Below is a view on the criteria in the Windows Server 2012 Active Directory Administrative Center:
Obviously, the stale user objects that have the most potential to be used to wreck your environment would be:
- enabled user objects
- user objects without a password expiration date
- user objects that have not been used to log on for more than 30 days.
Clicking on the Search button, would return a list with objects that need the attention of an Active Directory admin. Now, the list should not be considered as input to a script, since several reasons exist why user objects appear as stale, but still need to be retained:
- User objects belonging to colleagues on maternity leave, sabbatical, etc.
- User objects belonging to services that don’t log on interactively
From the list in the Active Directory Administrative Center you can easily pick the user objects you want to delete and disarming them by either right-clicking the selection and select Delete or Disable all from the context menu or pressing the Del button on your keyboard.
Stale objects in Active Directory pose a significant security risk. You can address these risks by introducing processes to control the lifecycle of objects in Active Directory. Additionally, you can take actions to clean up your Active Directory.
Tip: Zohno’s Z-Hire & Z-Term (freeware)
Top 5 Myths on Offline Domain Join
Related Microsoft Knowledgebase articles
154501 How to disable automatic machine account password changes
255042 How to make machine accounts programmatically by using ADSI with Visual C++
197478 How to detect and remove inactive machine accounts
SIA338: Authentication & Passwords, The Good, The Bad & The Really Ugly
Active Directory Recycle Bin Step-by-Step Guide
What's New in AD DS: Active Directory Administrative Center
Using Active Directory Administrative Center in Windows Server 2008 R2
Finding Stale Accounts in Active Directory
Active Directory: How to identify inactive computer accounts
Detecting and Removing Stale Computer Accounts in Active Directory
Active Directory True Last Logon
As you might be aware, every Microsoft technology has the requirement to be manageable through PowerShell and System Center. Manageability through System Center is done through Management Packs. (MPs).
While I discussed the PowerShell manageability stories for the five Active Directory services last Saturday, below is the overview of the availability and functionality of the Management Packs (MPs) for the five Active Directory services:
Active Directory Domain Services
For Windows Servers running the Active Directory Domain Services as Domain Controllers, a System Center Management Pack has been available for ages, even before the products responsible for management were labeled ‘System Center’ (System Center Operations Manager was called MOM Server and System Center Configuration Manager was called SMS Server).
The Active Directory Domain Services Management Pack for System Center provides both proactive and reactive monitoring of your Active Directory deployment. It monitors events that various Active Directory components and subsystems place in the Application, System, and Service event logs. It also monitors the overall health of the Active Directory system and provides alerts for critical performance issues.
When used with the Management Pack for the Windows Server Operating System, the DNS Server Role, File Services, Group Policy and DFS Replication, a complete management view starts to emerge, where you can monitor the health of your Domain Controllers.
The latest version (v6.0.8070.0) adds support for Windows Server 2012.
Download MP for AD Domain Services v6.0.8070.0
Also available is a System Center Integration Pack, that allows System Center 2012 - Orchestrator to connect to your Active Directory Server to automate Identity and Access management tasks.
Download System Center Integration Pack for Active Directory v7.0
Active Directory Lightweight Directory Services
The Active Directory Lightweight Directory Services (AD LDS) Management Pack provides both proactive and reactive monitoring of your AD LDS deployment running on Windows Server 2008 and Windows Server 2008 R2. It monitors events that are placed in the Application, System, and Service event logs by various Active Directory Lightweight Directory Services components and subsystems. It also monitors the overall health of the Active Directory Lightweight Directory Services system and alerts you to critical performance issues.
Download MP for AD Lightweight Directory Services v6.0.7220.0
Active Directory Certificate Services
The System Center Management Pack for Active Directory Certificate Services provides an early warning to administrators on issues that could affect services so they can investigate and take action, if necessary.
Two Management Packs for Active Directory Certificate Services are currently available. An ‘old’ Management Pack exists to manage Certification Authorities running on Windows Server 2008 and Windows Server 2008 R2. This Management Pack follows the 6.x version numbering. A completely new 7.x Management Pack is available alongside the 6.x version and enables management of Certification Authorities on Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012.
The Management Packs for Active Directory Certificate Services monitors the core Certification Authority, but does not monitor Certificate Services role services (such as the Online (OCSP) responder, Network Device Enrollment Services (NDES), Certificate enrollment web services, NDES, or CA web enrollment).
Download MP for AD Certificate Services v6.0.7231.0
Download MP for Windows Server 2012 AD Certificate Services v7.0.8560.0
Active Directory Federation Services
The System Center Management Pack for Active Directory Federation Services 1.x has been available since September 2007 and for Active Directory Federation Services 2.x since June 2010.
The Management Pack for Active Directory Federation Services offers the ability to detect service outages, operational errors and operational warnings. It also alerts on configuration issues and background tasks failures. Auditing can also be monitored, as well as the communication between the federation server and the federation server proxy. With the Management Pack you can be notified of malformed access requests and the health of the Secure Sockets Layer (SSL) certificate of the federation passive website in Internet Information Services (IIS).
Depending on the version of Active Directory Federation Services, you can choose between the 6.x version and the 7.x version of the Management Pack, where version 6.x can be used to monitor Active Directory Federation Services 1.0 and version 7.x can be used to monitor Active Directory Federation Services 2.0 (available as a separate download for Windows Server 2008 R2) and 2.1 (bundled with Windows Server 2012).
Download MP for Windows Server 2003 R2 AD Federation Services v6.0.5000.0
Download MP for AD Federation Services 2.0 and 2.1 v7.0.8560.0
Active Directory Rights Management Services
The System Center Management Pack for Active Directory Rights Management Services (AD RMS) has been available since July 2011 and monitors the performance and availability of the Windows Server 2008 SP2 or Windows Server 2008 R2 versions of AD RMS. By detecting, alerting on, and automatically responding to critical events and performance indicators, this Management Pack helps indicate, correct, and prevent possible AD RMS related service outages. The System Center Monitoring Pack for Active Directory Rights Management Services for Windows Server 2008 SP2 or Windows Server 2008 R2 helps ensure that your AD RMS components are available and working correctly.
In September 2012, Microsoft released a version 7.x of the Management Pack for Active Directory Rights Management Services. This Management Pack can be used to manage Rights Management Services, running on Windows Server 2012. For Rights Management Services running on Windows Server 2008 and Windows Server 2008 R2, the 6.0.7xxx.x version of the Management Pack is the one to use. For sturdy Rights Management Servers on Windows Server 2003, the 6.0.5000.0 version of the Management Pack offers the desired monitoring capabilities.
Download MP for Windows Server 2003 Rights Management Services v6.0.5000.0
Download MP for AD Rights Management Services v6.0.7597.0
Download MP for Windows Server 2012 AD Rights Management Services v7.0.8560.0
Related blogposts Active Directory Domain Services Management Pack for System Center updated last week System Center Monitoring Pack for Active Directory was updated today
Understanding Active Directory Domain Services Management Pack Operations
OpsMgr: Recent Management Pack Releases and Updates (January 2013)
New and Recent System Center Downloads
New Version: Active Directory Domain Services Management Pack for System Center
Windows Server Active Directory Certificate Services 2012 MP *Language Packs* Released
System Center Management Pack for Windows Server Operating System
System Center Management Pack for Windows 8 Client Operating System
As you might be aware, every Microsoft server product has the requirement to be manageable through PowerShell and System Center. The PowerShell requirement is formulated as part of the Common Engineering Criteria (CEC).
With PowerShell available as a version 3 product (and part of Windows Server 2012) it’s time to see how the teams, responsible for the Active Directory products have built their management stories around PowerShell.
Active Directory Domain Services
The Active Directory Domain Services, that we love and loath as the core of our networking infrastructure on our Domain Controllers is manageable through PowerShell scripting. To enjoy PowerShell support in Active Directory Domain Services, it is recommended to manage your Domain Controllers from Windows Server 2012 or from a Windows 8 installation with the Remote Server Administration Tools (RSAT) for Active Directory installed. This way you can enjoy the 135 Active Directory Domain Services management-related PowerShell Cmdlets and 9 Active Directory Domain Services deployment-related PowerShell Cmdlets.
The Active Directory Domain Services team even went a few steps further and incorporated the PowerShell History viewer into the Active Directory Administrative Center (dsac.exe), that helps you discover the PowerShell magic that happens under the hood.
A couple of exceptions still exist, that make it impossible to manage Active Directory Domain Services from the PowerShell prompt completely. Tools like ntdsutil.exe, dsamain.exe, redirusr.exe and redircmp.exe come to mind, almost immediately. On the other end of the spectrum, several other functions in Active Directory Domain Services are only easily manageable with PowerShell. MSAs come to mind, quite to my own surprise...
Active Directory Lightweight Domain Services
The Active Directory Lightweight Domain Services offer specialized Domain Services, targeted at applications and perimeter networks. Their charm is you can manage the Lightweight Directory Services (mostly) with the same tools as you can manage the Directory Services in PowerShell (as long as you install the AD LDS Display Specifiers schema and Display Specifiers by importing MS-ADLDS-DisplaySpecifiers.ldf.).
Alas, the PowerShell learning ability, offered by the Active Directory Administrative Center (dsac.exe), is not available for Active Directory Lightweight Directory Services, since this management tool can not be directed to a Lightweight Directory Services installation.
Since most tools are exchangeable between Lightweight Directory Services and Directory Services, roughly the same exceptions for full PowerShell manageability exist.
Active Directory Certificate Services
Active Directory Certificate Services enable you to run Certification Authorities on Windows Servers. For Windows Server 2012, the team behind Active Directory Certificate Services has developed twelve PowerShell Cmdlets to deploy Certificate Services. Also an additional nine PowerShell Cmdlets were specifically created to manage certificates, but you can also manage these by mounting the Certificate Store as a PowerShell drive, if need be.
In versions of Windows Server earlier than Windows Server 2012, no built-in PowerShell Cmdlets were available to manage Active Directory Certificate Services, but you could rely on certutil.exe to script through them.
Active Directory Federation Services
As was the case with Active Directory Federation Services 2.0, which was a separately downloadable installation, Active Directory Federation Services 2.1, that comes bundled with Windows Server 2012, can be managed through PowerShell. A total of 48 Active Directory Federation Services-related PowerShell Cmdlets are available on Windows Server 2012, covering both deployment and management.
Active Directory Rights Management Services
As you might expect, the Active Directory Rights Management Services in Windows Server 2008 R2 and Windows Server 2012 are also PowerShell-enabled. Three straightforward Rights Management Services deployment-focused PowerShell Cmdlets (appropriately named Install-ADRMS, Uninstall-ADRMS and Update-ADRMS) and 21 Rights Management Services administration-focused PowerShell Cmdlets are at your disposal.
New features in AD DS in Windows Server 2012, Part 4: New PowerShell Cmdlets
New features in AD DS in Windows Server 2012, Part 5: PowerShell History Viewer
Managing Active Directory with Windows PowerShell
Active Directory Cmdlets for Windows Server 2008 R2
AD FS 2.0 Cmdlets for Windows Server 2008 R2
AD RMS Cmdlets for Windows Server 2008 R2
AD CS Administration Cmdlets in Windows Server 2012
AD CS Deployment Cmdlets in Windows Server 2012
AD DS Administration Cmdlets in Windows Server 2012
AD DS Deployment Cmdlet in Windows Server 2012
AD FS Cmdlets in Windows Server 2012
AD RMS Administration Cmdlets in Windows Server 2012
AD RMS Deployment Cmdlets in Windows Server 2012
Windows Server 2012 is a major leap forward for Server Core installations of Windows Server. Not only are Full installations of Windows Server convertible back and forth to Server Core installations without reinstallation, a whole slew of new Server Roles have become available for installation on the mean, clean Server Core installations.
Active Directory Domain Services have been available since day 1 on Server Core installations, but what about the other four services? Can you install these on Server Core?
The table below shows the Active Directory services, available for installation on Server Core installation of Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012:
You can install the Active Directory Services on Server Core installations in four ways:
- From the command-line of the Server Core installation using:
- dism.exe, pkgmgr.exe or the Install-WindowsFeature / Add-WindowsFeature PowerShell Cmdlet on Windows Server 2012
- dism.exe or pkgmgr.exe or the Add-WindowsFeature PowerShell Cmdlet (after you’ve manually installed PowerShell and have imported the ServerManager PowerShell module) on Windows Server 2008 R2
- ocsetup.exe or pkgmgr.exe on Windows Server 2008
- From the command-line of the Server Core installation over a Remote Desktop Connection.
- From a remote command-line of a Full installation of Windows, a full installation of Windows Server or another Server Core installation of Windows Server through remote PowerShell or Windows Remote Management (winrs.exe).
- From Server Manager in Windows Server 2012, targeted at a Server Core installation of Windows Server 2012. This method does not work with Windows Server 2008 or Windows Server 2008 R2.
Installing Server Core Domain Controllers
How to install a Server Core R2 Domain Controller
The importance of Server Core
Server Core Roles and Features in 2008 R2
Some Server Core Domain Controllers heading for a dead end street
How to get going with PowerShell in Server Core R2
How to configure Windows Server 2012 Server Core as Domain Controller
How to Configure a Server Core Domain Controller: Vanilla to First DC in a Forest
Windows Server 2008 - Server Core
Install an Additional Domain Controller on Server Core R2
Last week, Microsoft released a poster, detailing identity and authentication for Office 2013 and Office 365. It details the scenario where you would provision accounts in Microsoft's Online Services environment (Scenario 1) and also details the scenario where you would federate your on-premises Active Directory infrastructure with Microsoft's Online Services environment (Scenario 2):
You can download the poster in both PDF and Microsoft Visio Drawing (*.vsd) format. The PDF can be used across Operating Systems (as would identity and authentication in the cloud), where the Visio drawing can be used to reuse some of the drawing in your own drawings and/or presentations.
This PDF would also do nicely over your bed, but could also be used to escape from Alcatraz, if that more resembles your situation…
Today, Microsoft has released an update to the Server Posterpedia app. I’ve mentioned this app before and it has seen several updates since. Today, the Identity and Authentication in the cloud: Office 2013 and Office 365 Poster was added to the app. You’ll be able to spot it when you scroll to the right in the app under Office.
Today, Microsoft has released a document, detailing the Best Practices for Securing Active Directory Domain Services.
The document contains 22 best practice recommendations to assist organizations in enhancing the security of their Active Directory installations. By implementing these recommendations, organizations will be able to identify and prioritize security activities, protect key segments of their organization’s computing infrastructure, and create controls that significantly decrease the likelihood of successful attacks against critical components of their networking environments:
- Patch applications.
- Patch operating systems.
- Deploy and promptly update antivirus and antimalware software across all systems and monitor for attempts to remove or disable it.
- Monitor sensitive Active Directory objects for modification attempts and Windows for events that may indicate attempted compromise.
- Protect and monitor accounts for users who have access to sensitive data.
- Prevent powerful accounts from being used on unauthorized systems.
- Eliminate permanent membership in highly privileged groups.
- Implement controls to grant temporary membership in privileged groups when needed.
- Implement secure administrative hosts.
- Use application whitelisting on domain controllers, administrative hosts, and other sensitive systems.
- Identify critical assets, and prioritize their security and monitoring.
- Implement least-privilege, role-based access controls to administer the directory, its supporting infrastructure, and domain-joined systems.
- Isolate legacy systems and applications.
- Decommission legacy systems and applications.
- Implement secure development lifecycle programs for custom applications.
- Implement configuration management, review compliance regularly, and evaluate settings with each new hardware or software version.
- Migrate critical assets to pristine forests with stringent security and monitoring requirements.
- Simplify security for end users.
- Use host-based firewalls to control and secure communications.
- Patch devices.
- Implement business-centric lifecycle management for IT assets.
- Create or update incident recovery plans.
The document also discusses the most common attacks against Active Directory and countermeasures to reduce the attack surface, and recommendations for recovery in the event of complete compromise.
The 321-page document (135 pages of main content and 185 pages with appendices A through M) is provided for free in *.docx format. Download it here.
Auditing directory changes aka "Who deleted this object"
How to create and use confidential attributes
MS013-032 Vulnerability in Active Directory Could Allow Remote Code Execution (Important)Preventing Domain Controller promotions, cloning and demotions in Windows Server 2012
Updated Active Directory Capacity Planning Guidance Available (adsizer.exe Be Gone!)
Thanks to Meinolf Weber for the tip.
Recently, one of my readers approached me with some questions on Managed Service Accounts (MSAs). From our discussion, I realized a lot of people may be unclear about the applicability of Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs).
So, this blogpost features a comprehensive table, showing the applicability of Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs) in a glance.
In this table you can quickly see which Operating Systems you can run services, configured with Managed Service accounts (MSAs) and group Managed Service accounts (gMSAs):
Managed Service Accounts (MSAs)
Managed Service Accounts (MSAs) were introduced with Active Directory Domain Services in Windows Server 2008 R2. Managed Service Accounts (MSAs) can be used to run services on domain-joined clients and servers, to address typical service account challenges:
- Service account password changes are a nightmare and they tend to break stuff. Thus, many organizations configure service accounts with non-expiring passwords. Nonetheless, it is a best practice to change these passwords regularly, for these accounts have a high risk of getting their passwords brute-forced.
- Passwords for service accounts are stored in plain text in registry. Sure, the passwords are protected, but still accessible if you know how.
- The Scope of service accounts is not easily set. Service accounts can often be used outside the intended scope, for instance to set up VPN connections are send mail through the (authenticated) SMTP gateway.
Under the hood, Managed Service Accounts (MSAs) are a new type of object (msDS-ManagedServiceAccount), derived from the computer account object and living in the Managed Service Accounts container under the domain root.
Managed Service Accounts (MSAs) can be configured in Active Directory environments running Windows Server 2003 and Windows Server 2008 Functional levels. Domains at the Windows Server 2008 R2 functional level provide native support for both automatic password management and SPN management.
Group Managed Service Accounts (gMSAs)
Alongside the Managed Service Account (MSA), in Windows Server 2012, a new type of object is being introduced: the group Managed Service Account. (msDS-GroupManagedServiceAccount)
gMSAs provide the same functionality as MSAs within the domain but also extends that functionality over multiple servers. This way, gMSAs provide a single identity solution for services running on a server farm, or on systems behind Network Load Balance. By using gMSAs, services can be configured for the new gMSA object and the password management is handled by Windows.
group Managed Service Accounts (gMSAs) can be configured in Active Directory environments running Windows Server 2003 and Windows Server 2008 Functional levels. Domains at the Windows Server 2008 R2 functional level provide native support for automatic SPN management.
Active Directory Feature Requirements
New features in AD DS in Windows Server 2012, Part 8: Group MSAs (gMSAs)
Yesterday, the Dutch Networking User Group organized the Tablet Day at the Reehorst in Ede, the Netherlands. Dave and I presented a 45-minute session on device management through ActiveSync. The whole day was packed with sessions from many speakers and it was a great success with good drinks and a dinner afterwards.
Some people took pictures during our session, so I thought of sharing some of them with you in this blogpost.
We had a big room with nice natural lighting, that felt like a breath of fresh air in contrast to the main auditorium of the Reehorst. The room was filled with 150 seats and, as you can see in the picture below, the majority of them were used by people attending our session:
Since this was the third time Dave and I presented on the topic, we felt pretty confident and had a lot of fun discussing the IOS 6.1 ActiveSync bug, the effects of ActiveSync settings on various tablet and phone models and the missing Swipe Password API on Android-based devices:
Dave and I will be presenting at the NGN Tablet Day
NGN Tablet Dag Dutch
OGD’ers en Microsoft-experts Dave en Sander spreken tijdens NGN TabletDag Dutch
I just received confirmation on speaking at the UK Virtual Machine User Group (VMUG) Meeting in the Hilton Doubletree hotel in London on Tuesday May 21, 2013.
I will be delivering my session on virtualization-safe(r) Active Directory and Domain Controller Cloning. The same session I have been delivering for the past year at numerous events, including the Dutch 2013 Microsoft TechDays.
About the UK Virtual Machine User Group
The UK Virtual Machine User Group (VMUG) is an association of persons with a vested interest in the successful deployment of virtual infrastructure and their associated technologies.
The committee are all volunteers and are directly employed to manage and design virtual infrastructure in their organizations.
VMUG UK is the largest independent cloud and virtualization user group in the UK. As a user group, run by administrators and architects of virtualized systems, the VMUG is all about the contents in the presentations at their events, meeting like minded engineers and learning about new products and trends.
In contrast to other VMUGs, the UK VMUG has a broader view on virtualization than most VMUGs, who mostly focus on VMware-only virtualization.
About the London Meeting
The London meeting will take place from 9AM to 4PM on May 21, 2013 at the Hilton Doubletree hotel.
The meeting is packed with presentations from Microsoft, VMware, York University, EG Innovations and Verizon. Also, attendees will be able to discover VMware automation in the available lab environment. As an attendee looking at advancing your career in virtualization, arrange for a one to one meeting with UK's largest virtualization and cloud employment agency during the Career Clinic.
After the event there will be a bar from 4PM to 6PM.
Register today to attend this meeting.
VMUG UK London Meeting Page
VMUG UK London Venue
VMUG UK on Twitter
VMUG UK on Facebook
In the past years, I’ve found many systems and many errors. Today, I’m sharing behavior in Microsoft Windows Server that had me frown and chuckle. A bug in Active Directory code I’ve been grateful for, since it illustrates the nature of software.
This behavior has not been publicized in the Microsoft KnowledgeBase (yet).
In the past two versions of Windows Server, the Active Directory team has made an effort to migrate all of the command-line stuff to PowerShell. Two of the command-line tools I still use frequently, however, have not been converted to PowerShell: redirusr.exe and redircmp.exe.
redirusr.exe and redircmp.exe were my partners in crime for the last couple of years, in which I setup loads of Active Directory structures for small sized organizations, following the Best Practice Active Directory Design for Managing Windows Networks. I used them in newly setup environments to automatically place newly created computer and user accounts in specific Organizational Units (OUs) in Active Directory.
A short history on redirusr.exe and redircmp.exe
Microsoft introduced the ability to change the default container (or Organizational Unit) where new users and computers are stored in the Windows Server 2003 Domain Functional Level (DFL). Both tools won’t work in Windows 2000 Domain Functional Level. When using the commands on a Windows Server 2008-based Domain Controller for a domain with the Windows 2000 Domain Functional Level both tools error out with the following message:
Error, unable to modify the wellKnownObjects attribute. Verify that
the domain functional level of the domain is at least Windows Server 2003:
Unwilling To Perform
Redirection was NOT successful.
This is by design. As the error indicates you need to raise the Domain Functional Level (DFL) to Windows Server 2003. It is not the subject of this blogpost.
Using redirusr.exe and redircmp.exe
On a Windows Server 2003-based Domain Controller and Windows Server 2008-based Domain Controller in an Active Directory domain with the Windows Server 2003 Domain Functional Level (DFL) you can use the following commands:
dsadd ou "OU=Redirected Users OU,DC=DomainName,DC=Tld"
dsadd ou "OU=Redirected Computers OU,DC=DomainName,DC=Tld"
redirusr "OU=Redirected Users OU,DC=DomainName,DC=Tld"
redircmp "OU=Redirected Computers OU,DC=DomainName,DC=Tld"
These commands will add two Organizational Units with names Redirected Users OU and Redirected Computers OU. After creation it will run the two commands to automagically place new useraccounts and computeraccounts in the new OUs.
The below two commands will output the following message, when successful:
Redirection was successful.
Now for the bug…
I expected the above commands to work on a Windows Server 2008-based Domain Controller for an Active Directory domain with the Windows Server 2008 Domain Functional Level (DFL)…
Unfortunately this is not the case. The error message is:
Error, unable to modify the wellKnownObjects attribute. Verify that
the domain functional level of the domain is at least Windows Server 2003:
Redirection was NOT successful.
Obviously the Verify that the domain functional level of the domain is at least Windows Server 2003 part of the message is a standard message, but the part behind it is different, compared to the Windows 2000 Domain Functional Level output. It is apparently willing to perform, but was referred.
This is actual behavior on a Domain Controller running Windows Server 2008 RTM. (or Windows Server 2008 with Service Pack 1, if you want to be 100% correct)
Unfortunately there is no way to redirect users and computers using the redirusr.exe and redircmp.exe commands on a Windows Server 2008 RTM-based Domain Controller in an Active Directory domain with the Windows Server 2008 Domain Functional Level (DFL).
To use the redirusr.exe and redircmp.exe commands in an Active Directory domain with the Windows Server 2008 Domain Functional Level (DFL), either:
- Install Service Pack 2 on a Windows Server 2008-based Domain Controller and run the commands on this Domain Controller, or
- Upgrade a Domain Controller to Windows Server 2008 R2 or Windows Server 2012 and run the commands on this Domain Controller.
Redirecting the users and computers containers in Windows Server 2003 domains
The Lazy Admin : Redirect New Users and Computers to an OU
Overview of the New Active Directory Tools in Windows Server 2003
Redirecting the computers container in Windows Server 2003 domains
Organizational Units, and Virtual Machines
It’s not often, that Active Directory Domain Controllers get security updates. The Active Directory Domain Services Server Role is one of the most robustly written code, as I pointed out in an earlier blogpost on Statistics on Active Directory-related Security Bulletins. Since 2001, Microsoft has issued 18 Security Bulletins with patches to address issues in Active Directory Directory Services, Active Directory Lightweight Directory Services and ADAM.
Yesterday, during the April 2013 Patch Tuesday, Microsoft has released a new Active Directory-related security bulletin: MS013-032.
This security update resolves a privately reported vulnerability in Active Directory. The vulnerability could allow denial of service if an attacker sends a specially crafted query to the Lightweight Directory Access Protocol (LDAP) service, that leads to excessive memory consumption and could cause the LDAP service to become non-responsive. This issue was privately reported to Microsoft and documented as CVE-2013-1282
This Security update is not classified as Critical, since an attacker must have valid logon credentials to exploit this vulnerability. The vulnerability could not be exploited remotely by anonymous users. However, the affected component is available remotely to users who have standard user accounts. In certain configurations, anonymous users could authenticate as the Guest account.
Affected Operating Systems
This security update is rated Important for Active Directory, Active Directory Application Mode (ADAM), Active Directory Lightweight Directory Service (AD LDS), and Active Directory Services on the following, currently supported, Windows Server Operating Systems:
- Active Directory on Windows Server 2003 SP2 x86
- Active Directory on Windows Server 2003 SP2 x64
- Active Directory Application Mode (ADAM) on Windows Server 2003 SP2 x86
- Active Directory Application Mode (ADAM) on Windows Server 2003 SP2 x64
- Active Directory Services on Windows Server 2008 SP2 x86
- Active Directory Services on Windows Server 2008 SP2 x64
- Active Directory Application Mode (ADAM) on Windows Server 2008 SP2 x86
- Active Directory Application Mode (ADAM) on Windows Server 2008 SP2 x64
- Active Directory Services on Windows Server 2008 R2
- Active Directory Application Mode (ADAM) on Windows Server 2008 R2
- Active Directory Services on Windows Server 2008 R2 SP1
- Active Directory Application Mode (ADAM) on Windows Server 2008 R2 SP1
- Active Directory Services on Windows Server 2012
This security update is rated Low for Active Directory Application Mode (ADAM) and Active Directory Lightweight Directory Services (AD LDS) on the following, currently supported, Windows client Operating Systems:
- Active Directory Application Mode (ADAM) on Windows XP SP3
- Active Directory Application Mode (ADAM) on Windows XP Professional x64 SP2
- Active Directory Lightweight Directory Service (AD LDS) on Windows Vista SP2 x86
- Active Directory Lightweight Directory Service (AD LDS) on Windows Vista SP2 x64
- Active Directory Lightweight Directory Service (AD LDS) on Windows 7 x86
- Active Directory Lightweight Directory Service (AD LDS) on Windows 7 x64
- Active Directory Lightweight Directory Service (AD LDS) on Windows 7 SP1 x86
- Active Directory Lightweight Directory Service (AD LDS) on Windows 7 SP1 x64
- Active Directory Lightweight Directory Service (AD LDS) on Windows 8 x86
- Active Directory Lightweight Directory Service (AD LDS) on Windows 8 x64
The security update addresses the vulnerability by correcting how the LDAP service handles specially crafted LDAP queries.
On all affected Operating Systems, except for Windows 8 and Windows Server 2012, this security update replaces Security update MS011-095.
You are urged to test and implement the update corresponding to the Security Bulletin on the affected Operating Systems running the aforementioned Active Directory services.
MS08-003 Security Update for Active Directory
A New Vulnerability in Active Directory (MS09-018)
MS11-095 Vulnerability in Active Directory could allow Remote Code Execution (Important)
Statistics on Active Directory-related Security Bulletins
Microsoft Security Bulletin MS13-032 – Important
MS13-032: Vulnerability in Active Directory could lead to denial of service: April 9, 2013
Microsoft Windows Active Directory CVE-2013-1282 Denial of Service Vulnerability
Vulnerability Summary for CVE-2013-1282
Today, Microsoft made Azure Active Directory generally available (GA). This means it is ready for production use.
Azure Active Directory enables organizations to provision their users with a single identity that can be used to access applications that are run on Windows Azure, run by 3rd party cloud-based vendors and/or within their own datacenters.
Azure Active Directory offers four main capabilities:
- It’s an Azure-based Active Directory environment, that you, as an admin, can use to authorize access to apps and services within your organization’s Azure, Intune and Office 365 subscriptions.
These Microsoft cloud services already rely on the identity management capabilities provided by Azure Active Directory. These capabilities include a cloud based store for directory data and a core set of identity services including user logon processes, authentication and federation services.
- The Azure Active Directory that you create is able to federate with an on-premise Active Directory environment, based on open standards including SAML, OData and WS-FED. With federation and single sign-on enabled, your colleagues can access resources within your company, plus access cloud applications seamlessly with the set of credentials and means of authentication they are already familiar with.
With Identity controlled on-premises, colleagues can granularly be enabled for federation, granted access and revoked access. All without any delays.
- Azure Active Directory can be used to leverage identity and access management to 3rd party cloud-based apps.
As an organization, you can leverage this functionality to use Azure Active Directory as your identity federation hub or identity provider (IP) to provide a seamless, single sign-on experience across your on-premises environment, Microsoft Online Services, 3rd party cloud services and applications built on Windows Azure with popular web identity providers like Microsoft Account, Google, Yahoo!, and Facebook.
- Azure Active Directory offers the Azure Active Directory Graph. This is an innovative social enterprise graph providing an easy RESTful interface for accessing objects such as Users, Groups, and Roles with an explorer view for easily discovering information and relationships.
You may leverage any of these capabilities, independent of each other.
The best thing? Azure Active Directory is free.
Windows Azure Active Directory: Ready for Production with over 265 Billion Authentications & 2.9 Million Organizations Served!
As of today, Windows Azure Active Directory has reached general availability and is now ready for use in production environments.
Windows Azure: Active Directory Release, New Backup Service + Web Site Monitoring and Log Improvements
Identity in Windows Azure
Windows Azure Active Directory
Windows Azure Active Directory Cartoon
Windows Azure Opens Active Directory For General Availability As Identity Battle Heats Up
Windows Azure Active Directory Service Now Available
Microsoft hosts bar mitzvah for mature Azure
Windows Azure Active Directory has reached general availability
MMS 2013 - Windows Azure Active Directory, Backup, Web Site Monitoring and Log Improvements Release Information
Microsoft readies free cloud Active Directory service
Microsoft starts making more of its Azure cloud services generally available
Windows Azure Active Directory Reaches General Availability
Microsoft has released KnowledgeBase Article 2830511, detailing a bug in the Installation Wizard of Windows Server 2012 Essentials, that prevents you from installing the server as a Domain Controller for an Active Directory domain with a public top-level domain (TLD), like .com, .corp, .org, .edu, .int and the country-specific top-level domains.
About Windows Server 2012 Essentials
Windows Server 2012 Essentials is the latest version of Windows Small Business Server Essentials. It is a flexible, affordable, and easy- to-use server solution designed and priced for small businesses with up to 25 users and 50 devices that helps them reduce costs and be more productive. Windows Server 2012 Essentials is an ideal first server, and it can also be used as the primary server in a multi-server environment for small businesses.
By removing the ‘Small Business Server’ moniker, Microsoft clearly communicates how Windows Server Essentials is positioned in the market relative to the other Windows Server editions. It does not come with Exchange Server, but it does come with client backup and remote web access.
As Microsoft aims Windows Server 2012 Essentials as the successor to Windows Small Business Server 2011, After installing Windows Server 2012, which is more or less identical to installing the Standard or Datacenter edition of Windows Server 2012, Microsoft assists system administrators, apparently installing their first server, with a wizard to configure the server; the Set Up Windows Server 2012 Essentials wizard.
The first screen of this wizard makes you verify the date and time settings. This is specifically useful when your time zone is not Pacific Time (-08h00 GMT). From an Active Directory point of view, though, it doesn’t matter since Active Directory, internally, runs at Greenwich Main Time (GMT). The second screen lets you choose between a Clean install and a Server migration.
The third screen is where the Active Directory magic happens:
The link What should I know before I personalize my server? explains that the Company name is used to associate your server with your company and the customize your company reports. You can type up to 254 characters for your company name.
The Internal domain name groups your server and client computers together to share a common database of user names, passwords, and other common information. Your users see this name when they log on to their computers, but is used internally only and is not the same as an Internet domain name. Your internal domain name must meet the following criteria:
- Can be up to 15 characters long
- Can contain letters, numbers and dashes (-)
- Must not start with a dash
- Must not contain any spaces
- Most not contain only numbers
This screen only offers to set up your Windows Server 2012 Essentials as a Domain Controller for a .local domain name, where the NetBIOS name of the domain is equal to the second level domain name. The wizard does not offer to configure Windows Server 2012 Essentials as a Domain Controller for an Active Directory domain with a public top-level domain (TLD), like .com, .corp, .org, .edu, .int and the country-specific top-level domains. (ccTLDs)
Microsoft KnowledgeBase article 2830511 explains the absence of a sensible choice for the domain name as by design to simplify the user experience.
Now, I can agree to some extent, that preventing a situation where an inexperienced admin may create a single-label domain name, is a good goal. However, other means exist to prevent these associated problems. Since Windows Server 2008, for instance, when you try to create a single-label domain name, you are presented with the following error:
The DNS name "<single label DNS domain name> proposed for this Active Directory domain consists of a single label, which is not recommended. DNS domain name should be unique and fully qualified, consisting of one or more labels separated by a period ("."), followed by a top level domain.
If you click No, you can assign a fully qualified DNS name like the example. If you implement a single-label DNS domain name, you must configure all member computers and domain controllers as described in article 300684 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=92467) so they can register records and resolve queries until the domain is retired.
Do you really want to assign a single-label DNS domain name to this Active Directory domain?
Also, targeting Windows Server 2012 Essentials as the cost-efficient server solution, brings back the point of not forcing business into register a public domain name (at up to $10 per year).
The part I can’t agree with is the absence of the ability to create a domain name with a public top-level domain (TLD), since Microsoft has repeatedly made this a best practice approach.
Many Microsoft products and services assume your internal domain name ends with a public top-level domain (TLD). Lync Server and Exchange Server, for instance, are easier installed, configured and integrated when using the public DNS domain name. Also, Single Sign-On with Office 365 is problematic when you use a DNS domain name ending with a non-public top-level domain (TLD).
Configuring Essentials with a public TLD
Now, while the Set Up Windows Server 2012 Essentials wizard does not give you the option to configure the Active Directory domain name with a public top-level domain (TLD), it is possible to configure Windows Server 2012 Essentials with a public top-level domain (TLD) through the answer file method.
To this purpose you’ll need to place a plain text file named cfg.ini in the root of removable media (floppies not allowed, sorry) and make sure the media is available to Windows Server 2012 Essentials at the moment you set it up.
The fields NetBiosName and DNSName can be used to configure your Windows Server 2012 Essentials with the Active Directory domain names you’d like to use. More information on creating the contents of cfg.ini can be found here.
Windows Server 2012 Essentials configures Active Directory with the Windows Server 2012 Domain Functional Level (DFL) and Windows Server 2012 Forest Functional Level (FFL). There is no way in cfg.ini to configure it otherwise. You will need to configure a Domain Controller on Windows Server 2012 Standard first and use the Server migration option in the Set Up Windows Server 2012 Essentials wizard. Afterwards, you can remove the Windows Server 2012 Standard Domain Controller from the network.
Why you shouldn't use .local in your Active Directory domain name.
Create the Cfg.ini File
Namespace planning for DNS
Support for DNS Namespace planning in Microsoft server products
Related KnowledgeBase articles
2830511 Unable to install with domain suffixes .net, .corp, .com, .org etc
300684 Information about configuring Active Directory domains by using single-label names
254680 DNS Namespace Planning
909264 Naming conventions in Active Directory for computers, domains, sites, and OUs
2002634 Warnings installing Active Directory Domain Services on Windows Server 2008 and Windows Server 2008 R2 in domains with single-label DNS names
One year of Windows XP support remains. After twelve years, now is the time to migrate off this 2001 Operating System or to take your security measures to assure your colleagues experience the least impact of the End of Support (EoS) situation. Of course, migrating to a later version of Windows or to another (supported) Operating System is the best approach. If, however, you want to continue running Windows XP in your organization, you should begin taking measures, beginning today:
Disable unneeded administrator accounts
A decade ago, when admins started deploying Windows XP machines, often, colleagues were given accounts with local administrative privileges. Many organizations came from Windows 9x and colleagues were used to having these privileges on their systems and demanded it (back). However, when logged on as an administrator in Windows XP, every action performed, is performed with total control over the system. When a colleague, logged on as an administrator, encounters malware, this piece of malware is capable of taking full control over the system, including installing a hypervisor to make itself undetectable from malware scanners.
Windows XP installations should be checked for accounts that are members of the local Administrators group. Colleagues that are part of this group should have a good reason to be in it. Applications that require administrative privileges can be run through runas.exe.
Don’t replace memberships of the Administrators group with memberships of the Power Users group. A power user is an administrator, but doesn’t know it yet…
When done, you should create a group policy to fill the local Administrators groups on your Windows XP machines based on Restricted Groups. This group should be as empty as possible and configured in replace-mode.
Also, the built-in local administrator account on all your Windows XP machines should be disabled, where possible. You can perform this action in various ways, but the most effective method is through Group Policy. The Accounts: Administrator account status was introduced to this purpose, specifically.
Update Windows XP with the latest updates
April 8, 2014 will be the last Patch Tuesday for Windows XP. After this date, no updates or Service Packs will be released for Windows XP. Shortly after this date, you will want to create a system image for Windows XP, including all the updates. Sysprep it, so you can deploy it easily when a Windows XP installation fails.
While this image can be used to reimage Windows XP computers, it will have no effect on the current install base.
Not all software handles sysprep gracefully. Test.
Now, some updates require earlier updates. It is, therefore, an illusion to think that updating a Windows XP computer once, will update it to the fullest. Also, running Windows Update might confront your colleagues with a hundred updates and the accompanying hours of their unproductivity to install them.
Centralized update solutions, like the free Windows Server Update Services (WSUS) and C’t’s WSUS Offline Update, allow a phased roll out of Windows Updates and Service Packs, but you should start to do this today if you want to make sure your Windows XP computers are up to date on April 8, 2014.
Don’t use the built-in programs to access the Internet
Windows XP comes with several built-in tools, like Internet Explorer, Windows Media Player, Wordpad and Notepad. With the End of Support in sight, you should at least change processes and behavior within your organization to move away from these programs, since these programs are updated through Windows Update and, thus, don’t receive updates after April 8, 2014.
As an alternative to Internet Explorer, Google’s Chrome or Mozilla’s Firefox should be used. At the moment, both manufacturers support Windows XP (with at least Service Pack 2) for their newest releases. As an alternative to Windows Media Player, VLC Media Player may be used.
However, you should be aware that these programs get updates. Using Group Policy to deploy these programs, allows you to deploy and replace them. Group Policy Setings and Group Policy Preferences can be used to manage settings for these programs.
Software Restriction Policies can be used to limit access to the built-in programs. After April 8, 2014, you can use hash rules without problems, since the hashes will no longer change due to the lack of updates.
Deploy and update a multi-tier anti-malware solution
Malware scanners come in many forms and shapes. Everyone has their own favorite, but for your organization you should be looking for a centrally manageable malware solution, like McAfee’s ePolicy Orchestrator, Symantec AntiVirus Corporate Edition and Microsoft System Center Endpoint Protection. These solutions let you manage your anti-malware measures centrally and empower you to stay on top of outbreaks.
Scanning mere workstations for malware is not enough. You should scan for malware on user-accessible network locations (like file- and mailservers) and, ideally, on the perimeter of your network. If you possess a perimeter device that supports malware scanning, enable it.See if you can enable Intrusion Detection (IDS) and Host Intrusion Prevention (HIPS) too.
Luckily, centralized management also means centralized updates. When giving a choice, make sure to check for updates at least daily for workstations and hourly for mailservers and perimeter devices.
Configure the (Windows) Firewall
Most anti-malware solutions for endpoint protection include firewalls. If yours doesn’t, or if you don’t want to use it, Windows XP with Service Pack 2 comes with an elaborate firewall.
The built-in firewall can be configured with Group Policy to allow only the traffic you want to allow, based on port, program, protocol and host whitelisting. This will raise the bar significantly for malware to communicate and propagate.
You only have to configure and test Windows Firewall rules once. You can then drag them to the Windows Firewall pane in the Group Policy editor.
Testing of firewall rules is easy with the logging feature. Instead of dropping connections, you can just log them. The logs will show you the additional rules to create. Also, free network traffic capture tools like Netmon and WireShark can be useful to analyze (the purpose of) network chatter.
Uninstall or disable add-ons, plug-ins and extensions
Running the most recent version of a 3rd party browser, will not ensure you have the recent version of the add-ons, plug-ins and extensions used within the browser. Software from Adobe, like Flash, Reader and its Shockwave Player and Oracle (Java) will need to be updated regularly or disabled. These notorious programs have been known to provide attack vectors on fully patched Windows installations, so if you can’t keep them up to date, disable them.
Update Microsoft Office
While the End of Support for Windows XP is gathering quite some mainstream media attention, you should be aware of the lifecycle of the other business-critical Microsoft software in your environment. On Windows XP clients, the most obvious business-critical Microsoft program would be Microsoft Office. You should be aware that support for Office XP (version 2002) ended on July 12, 2011. Support for Office 2003 ends on April 8, 2014 too.
If you want to keep using Office XP or Office 2003, make sure to update it and disable macros. Also, think about using Outlook Web Access / Outlook Web App and not Outlook. These measures will defuse most Office-based attacks, but will not protect you from leaks within Office programs. If you want to safely exchange documents with partners and customers over the Internet and through mail, make sure to upgrade to Office 2007.
You cannot install Office 2010 or Office 2013 on Windows XP. If you want to migrate to these Office versions, you will need to migrate the Operating System first.
Build a software and documents repository
With many software vendors ending their support for Windows XP at the same time as Microsoft does, you could become stuck in the situation where you can no longer download the version of a program that you need. Or the documentation on how to install it, configure it and/or manage it.
How Windows XP end of life will affect your desktop applications
Windows XP SP3 and Office 2003 Support Ends April 8, 2014
End of support for Microsoft Windows XP SP3 and Office 2003
Support for Office 2003
End of support for Office XP
XP in 2020? Not even close. Read the fine print...
Microsoft counts down to end of support for Windows XP
Microsoft: MED-V Not a Cure for Windows XP End-of-Life
Set Your Watches For the End of Windows XP
Prepare now for end of support for Windows XP, Microsoft Office 2003
Extended support for Windows XP ends in 365 days
Microsoft Set to Retire Windows XP
Preparing for the End of Windows XP and Office 2003 Support
Windows XP dies a year from … now!
UK businesses stalling on XP migration as end of Microsoft support looms
Related KnowledgeBase articles
294676 How to enable and use the "Run As" command when running programs
281140 How to disable the Local Administrator account in Windows
279301 Description of Group Policy Restricted Groups
825069 A member of the Power Users group may be able to gain administrator rights
302577 How to use the Sysprep tool to automate successful deployment of Windows XP
In the earlier 20 blogposts on new features in Active Directory Domain Services in Windows Server 2012, I’ve covered most of the main stream new features. Today, I’m covering a lesser known feature: SID Compression. While this feature has been around in earlier versions of Active Directory Domain Services in Windows Server, it has been enhanced in Windows Server 2012 to provide more value.
Along with related token features like the default larger size (48,000 bytes) and the capabilities to store claims as part of Dynamic Access Control it offers the path to solve token bloat.
SID Compression in earlier versions
In earlier versions of Active Directory Domain Services in Windows Server, SID Compression has been available for years.
When a Ticket Granting Ticket (TGT) is created, the SIDs for global groups and universal groups of the Active Directory domain the user account is a member of, are compressed in the authorization data field (PAC) of the TGT. Compression is achieved by storing the SID Namespace once with a shorter identifier. SIDs for group in this SID Namespace were then linked with their Relative ID (RID) to the SID Namespace through the identifier.
The following group SIDs are compressed:
- Global groups in the user's account domain
- Universal groups in either the user’s account domain
All other group SIDs are uncompressed. This includes Domain Local Groups, SIDs from any other groups outside the Active Directory domain the user account is a member of (like SIDhistory) and SIDs for well-known groups.
SID Compression in Windows Server 2012
Along with other Kerberos Token logic, in Windows Server 2012 a new SID Compression scheme is used. This feature is called Resource SID Compression. It is enabled by default.
SID Compression can now also be used to compress Kerberos Service Tickets (STs), not just Kerberos Ticket Granting Tickets (TGTs), enabling the compression of SIDs for Domain Local Groups for the Active Directory domain the user account is a member of and any resource domains.
The following group SIDs will be compressed by default in Windows Server 2012:
- Global groups in the user's account domain
- Domain local groups in the resource domain
- Universal groups in either the user’s account or resource domain
- SID history groups in either the user’s account or resource domain
The following group SIDs will not be compressed:
- Groups a user is a member of which are in other domains
- Well known SIDs
Disabling Resource SID Compression
Microsoft has identified some problems with the new SID Compression scheme in Microsoft KnowledgeBase article 2774190. Since Service Tickets (STs) now also feature SID compression and are the tickets that are presented to services (like file servers, web servers) these services need to understand the new scheme. If they don’t, obviously, access denied errors will be displayed.
When you’re running into this situation, you can disable resource SID compression on a Windows Server 2012 KDC using the DisableResourceGroupsFields registry value under the HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters registry key.
This registry value has a DWORD registry value type. You completely disable resource SID compression when you set the registry value to 1. The Key Distribution Center (KDC) reads this configuration when building a service ticket. With the bit enabled, the KDC does not use resource SID compression when building the service ticket.
You do not need to reboot Domain Controllers after making these changes.
Related KnowledgeBase Articles
327825 Problems with Kerberos authentication when a user belongs to many groups
2774190 Resource SID Compression in Windows Server 2012 may cause authentication problems on NAS devices
MaxTokenSize and Windows 8 and Windows Server 2012
220.127.116.11.3 Domain Local Group Membership
Key Distribution Center
Many thanks to Guido Grillenmeier, Lee Flight and Dean Wells.