Blog roll

News

Navigation

Whitepapers

The challenge

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

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.

Mitigating factors

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

Cleanup

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.

Tip!
Protection from Accidental Deletion on individual computer objects might help preserving often targeted computer objects

Tip!
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.

Concluding

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.

Related blogposts

Tip: Zohno’s Z-Hire & Z-Term (freeware)
Top 5 Myths on Offline Domain Join

Related blogposts

Active Directory Domain Services Management Pack for System Center updated last week
System Center Monitoring Pack for Active Directory was updated today

Related downloads

System Center Management Pack for Windows Server Operating System
System Center Management Pack for Windows 8 Client Operating System

Posted: Monday, May 13, 2013 8:06 AM by Sander Berkouwer | 0 Comments

Filed under: Active Directory, Microsoft Windows Server 2008, Microsoft Windows Server 2008 R2, Microsoft Windows Server 2012, System Center, Microsoft Windows Server 2003

Active Directory Services and PowerShell manageability

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.

Related blogposts

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

Related blogposts

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

Related blogposts

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!)

Acknowledgements

Thanks to Meinolf Weber for the tip.

Posted: Friday, April 26, 2013 10:05 AM by Sander Berkouwer | 0 Comments

Filed under: Active Directory, System Administration, Setup & Deployment, Security

Applicability of Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs)

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):

Table showing the applicability of Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs), including Windows XP, Windows Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008 and Windows Server 2012

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.

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.

Photo of the previous VMUG UK London meeting (courtesy VMUG UK)

After the event there will be a bar from 4PM to 6PM.

Register today to attend this meeting.

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:
Referral
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).

The workaround

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.

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.

Guidance

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

Installing Essentials

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.

Example: corp.<domain>.com

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.

Note:
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.

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.

Related

Blog roll

News

Recent Posts

Tags

Navigation

Top posts in the past

Whitepapers

Archives

The challenge

Stale user objects

Stale computer objects

(Part of) The solution

Optimizing communication

Mitigating factors

Cleanup

Cleaning stale computer objects

Cleaning stale user objects

Concluding

Related blogposts

Related Microsoft Knowledgebase articles