Blog - Title

Ask the Directory Services Team

  • MD5 Signature Hash Deprecation and Your Infrastructure

    Hi everyone, David here with a quick announcement.

    Yesterday, MSRC announced a timeframe for deprecation of built-in support for certificates that use the MD5 signature hash. You can find more information here:

    Along with this announcement, we've released a framework which allows enterprises to test their environment for certificates that might be blocked as part of the upcoming changes (Microsoft Security Advisory 2862966). This framework also allows future deprecation of other weak cryptographic algorithm to be streamlined and managed via registry updates (pushed via Windows Update).


    Some Technical Specifics:

    This change affects certificates that are used for the following:

    • server authentication
    • code signing  
    • time stamping
    • Other certificate usages that used MD5 signature hash algorithm will NOT be blocked.

    For code signing certificates, we will allow signed binaries that were signed before March 2009 to continue to work, even if the signing cert used MD5 signature hash algorithm.

    Note:  Only certificates issued under a root CA in the Microsoft Root Certificate program are affected by this change.  Enterprise issued certificates are not affected (but should still be updated).


    What this means for you:

    1) If you're using certificates that have an MD5 signature hash (for example, if you have older web server certificates that used this hashing algorithm), you will need to update those certificates as soon as possible.  The update is planned to release in February 2014; make sure anything you have that is internet facing has been updated by then.

    You can find out what signature hash was used on a certificate by simply pulling up the details of that certificate's public key on any Windows 8 or Windows Server 2012 machine.  Look for the signature hash algorithm that was used. (The certificate in my screenshot uses sha1, but you will see md5 listed on certificates that use it).

    If you are on Server Core or have an older OS, you can see the signature hash algorithm by using certutil -v against the certificate.

    2) Start double-checking your internal applications and certificates to insure that you don't have something older that's using an MD5 hash.  If you find one, update it (or contact the vendor to have it updated).

    3) Deploy KB 2862966 in your test and QA environments and use it to test for weaker hashes (You are using test and QA environments for your major applications, right?).  The update allows you to implement logging to see what would be affected by restricting a hash.  It's designed to allow you to get ahead of the curve and find the potential weak spots in your environment.

    Sometimes security announcements like this can seem a little like overkill, but remember that your certificates are only as strong as the hashing algorithm used to generate the private key.  As computing power increases, older hashing algorithms become easier for attackers to crack, allowing them to more easily fool computers and applications into allowing them access or executing code.  We don't release updates like this lightly, so make sure you take the time to inspect your environments and fix the weak links, before some attacker out there tries to use them against you.

    --David "Security is everyone's business" Beach

  • DFS Replication in Windows Server 2012 R2 and other goodies, now available on the Filecab blog!

    Over at the Filecab blog, AskDS alum and all-around nice guy Ned Pyle has posted the first of several blogs about new features coming your way in Windows Server 2012 R2.  If you're a DFS administrator or just curious, go take a look!

    Ned promises more posts in the near future, and Filecab is near and dear to our hearts here in DS (they make a bunch of things we support), so if you don't already have it on your RSS feed list, it might be a good time to add it.

  • Roaming Profile Compatibility - The Windows 7 to Windows 8 Challenge

    [Editor's note:  Everything Mark mentions for Windows 8 clients here is also true for Windows 8.1 clients.  Windows 8 and Windows 8.1 clients use the same (v3) profile version, so the 8.1 upgrade will not prevent this from happening if you have roaming profiles in your environment.  Something to be aware of if you're planning to migrate users over to the new OS version. -David]


    Hi. It’s Mark Renoden, Senior Premier Field Engineer in Sydney, Australia here again. Today I’ll offer a workaround for an issue that’s causing a number of customers around the world a degree of trouble. It turns out to be reasonably easy to fix, perhaps just not so obvious.

    The Problem

    The knowledge base article "Unpredictable behavior if you migrate a roaming user profile from Windows 8 to Windows 7" - states:

    Windows 7 and Windows 8 use similar user profile formats, which do not support interoperability when they roam between computers that are running different versions of Windows. When a user who has a  windows 7 profile signs in to a Windows 8-based computer for the first time, the user profile is updated to the new Windows 8 format. After this occurs, the user profile is no longer compatible with Windows 7-based computers. See the "More information" section for detailed information about how this issue affects roaming and mandatory profiles.

    This sort of problem existed between Windows XP and Windows Vista/7 but was mitigated by Windows Vista/7 using a profile that used a .v2 extension.  The OS would handle storing the separate profiles automatically for you when roaming between those OS versions.  With Windows 7 and Windows 8, both operating systems use roaming profiles with a .v2 extension, even though Windows 8 is actually writing the profile in a newer format.

    Mark’s Workaround

    The solution is to use separate roaming profiles for each operating system by utilizing an environment variable in the profile path.


    File server for profiles:

    1. Create profile share “\\Server\ProfilesShare” with permissions configured so that users have write access
    2. In ProfilesShare, create folders “Win7” and “Win8”


    Active Directory:

    1. Create OU for Windows 7 Clients (say “Win7OU”) and create/link a GPO here (say “Win7GPO”)
    2. Create OU for Windows 8 Clients (say “Win8OU”) and create/link a GPO here (say “Win8GPO”)

    Note:As an alternative to separate OUs, a WMI filter may be used to filter according to Operating System:

    Windows 7 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.1%” and ProductType = “1″

    Windows 8 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.2%” and ProductType = “1″

    3. Edit Win7GPO

      1. Expand Computer Configuration -> Preferences -> Windows Settings
      2. Under Environment create an environment variable with
        1. Action: Create
        2. System Variable
        3. Name: OSVer
        4. Value: Win7

    4. Edit Win8GPO

      1. Expand Computer Configuration -> Preferences -> Windows Settings
      2. Under Environment create an environment variable with
        1. Action: Create
        2. System Variable
        3. Name: OSVer
        4. Value: Win8

    5. Set user profile paths to \\Server\ProfilesShare\%OSVer%\%username%\



    1. Log on with administrative accounts first to confirm creation of the OSVer environment variable

    2. Log in as users and you’ll observe that different user profiles are created in the appropriate folder in the profiles share depending on client OS


    I haven't run into any issues in testing but this might be one of those cases where it's important to use "wait for network". My testing suggests that using "create" as the action on the environment variable mitigates any timing issues.  This is because after the environment variable is created for the machine, this variable persists across boots and doesn't depend on GPP re-application.

    You may also wish to consider the use (and testing) of a folder redirection policy to provide users with their data as they cross between Windows 7 and Windows 8 clients. While I have tested this to work with
    “My Documents”, there may be varying degrees of success here depending on how Windows 8’s modern apps fiddle with things.

     - Mark “Square Peg in a Round Hole” Renoden



  • Because TechNet didn't have enough Active Directory awesomeness already

    Time for a quick lesson in blog history.  There'll be a quiz at the end!  Ok not really, but some history all the same.

    Back a few years ago when we here at Microsoft were just starting to get savvy to this whole blog thing, one of our support escalation engineers, Tim Springston, decided to start up a blog about Active Directory.  You might have seen it in the past.  Over the years he's posted some really great insights and posts there that are definitely worth reading if you have the time.

    Of course, the rest of us decided to do something completely different and started up AskDS a little later.  Rumor has it that it had something to do with a high-stakes poker game (Tim *is* from Texas, after all), but no one is really sure why we wound up with two support blogs to be honest - it's one of those things that just sort of happened.

    Anyway, all this time while we've been partying it up over here on TechNet, our AD product team has been marooned over on MSDN with an audience of mostly developers.  Not that developers are bad folks - after all, they make the apps that power pretty much everything - but the truth is that a lot of what we do in Active Directory in terms of feature development is also targeted at Administrators and Architects and IT Pros.  You know, the people who read blogs on TechNet and may not think to also check MSDN.

    After a lot of debate and discussion internally, the AD product team came to the conclusion that they really should have a presence on TechNet so that they could talk to everyone here about the cool features they're working on.

    The problem?  Well, we sort of had a monopoly over here in support on AD-related blog names. :)

    Meetings were convened.  Conferences were held.  Email flew back and forth.  Their might even have been some shady dealings involving gifts of sugary pastries.  In the end though, Tim graciously agreed to move his blogging efforts over to AskDS and cede control of to the Active Directory Product team.

    The result?  Everyone wins.  Tim's now helping us write cool stuff for AskDS (you'll see plenty of that in the near future, I'm sure), and the product team has already started posting a bunch of things that you might have missed when they were on MSDN.

    If you haven't seen what they're up to over there, go and take a look .  And as we get out of summer and get our people back from vacation, and, you know, roll a whole new server OS out the door, keep an eye on both blogs for updates, tips, explanations, and all manner of yummy AD-related goodness.


    --David "Wait, we get another writer for AskDS??" Beach

  • Interesting findings on SETSPN -x -f

    Hello folks, this is Herbert from the Directory Services support team in Europe!

    Kerberos is becoming increasingly mandatory for really cool features such as Protocol Transition.  Moreover, as you might be painfully aware, managing Service Principal Names (SPN’s) for the use of Kerberos by applications can be daunting at times.

    In this blog, we will not be going into the gory details of SPNs and how applications are using them. In fact, I’m assuming you already have some basic knowledge about SPN’s and how they are used.

    Instead, we’re going to talk about an interesting behavior that can occur when an administrator is doing their due diligence managing SPN’s.  This behavior can arise when you are checking the status of the account the SPN is planned for, or when you are checking to see if the SPN that must be registered is already registered in the domain or forest.

    As we all know, the KDC’s cannot issue tickets for a particular service if there are duplicate SPN’s, and authentication does not work if the SPN is on the wrong account.

    Experienced administrators learn to use the SETSPN utility to validate SPNs when authentication problems occur.  In the Windows Server 2008 version of SETSPN, we provide several options useful to identifying duplicate SPNs:

    -      If you want to look for a duplicate of a particular SPN: SETSPN /q <SPN>

    -      If you want to search for any duplicate in the domain: SETSPN /x

    You can also use the “/f” option to extend the duplicate search to the whole Forest. Many Active Directory Admins use this as a proactive check of the forest for duplicate SPNs.

    So far, so good…

    The Problem

    Sometimes, you’ll get an error running SETSPN -x -f:

    c:\>SETSPN -X -F -P
    Checking forest DC=contoso,DC=com
    Operation will be performed forestwide, it might take a while.
    Ldap Error(0x55 -- Timeout): ldap_get_next_page_s

    “-P” just tells the tool not to clutter the output with progress indications, but you can see from that error message that we are not talking only about Kerberos anymore. There is a new problem.


    What are we seeing in the diagnostic data?

    In a network trace of the above you will see a query against the GC (port 3268) with no base DN and the filter (servicePrincipalName=*)”. SETSPN uses paged queries with a page size of 100 objects. In a large Active Directory environment this yields quite a number of pages.

    If you look closely at network capture data, you’ll often find that Domain Controller response times slowly increase towards the end of the query. If the command completes, you’ll sometimes see that the delay is longest on the last page returned. For example, when we reviewed data for a recent customer case, we noted:

    ”Customer also noticed that it usually hangs on record 84.”


    Troubleshooting LDAP performance and building custom queries calls for the use of the STATS Control. Here is how you use it in LDP.exe:

    Once connected to port 3268 and logged on as an admin, you can build the query in the same manner as SETSPN does.

    1. Launch LDP as an administrator.

    2. Open the Search Window using Browse\Search or Ctrl-S.

    3. Enter the empty base DN and the filter, specify “Subtree” as the scope. The list of attributes does not matter here. 

    4. Go to Options:


    5. Specify an “Extended” query as we want to use controls. Note I have specified a page size of 100 elements, but that is not important, as we will see later. Let’s move on to “Controls”:


    5. From the List of Controls select “Search Stats“. When you select it, it automatically checks it in.

    6. Now “OK” your way out of the “Controls” and “Options” dialogs.

    7. Hit “Run” on the “Search” dialog.


    You should get a large list of results, but also the STATS a bit like this one:


    Call Time: 62198 (ms)

    Entries Returned: 8508

    Entries Visited: 43076

    Used Filter: (servicePrincipalName=*)

    Used Indices: idx_servicePrincipalName:13561:N

    Pages Referenced          : 801521

    Pages Read From Disk      : 259

    Pages Pre-read From Disk  : 1578

    Pages Dirtied             : 0

    Pages Re-Dirtied          : 0

    Log Records Generated     : 0

    Log Record Bytes Generated: 0


    What are these stats telling us?

    We have a total of 8508 objects in the “Entries Returned” result set, but we have visited 43076 objects. That sounds odd, because we used an Index idx_servicePrincipalName”. This does not really look as if the query is using the index.


    So what is happening here?

    At this point, we experience the special behavior of multi-valued non-linked attributes and how they are represented in the index. To illustrate this, let me explain a few data points:


    1. A typical workstation or member server has these SPNs:










    2. When you look at the result set from running setspn, you notice that you’re not getting all of the SPNs you’d expect:

    dn:CN=HQSCCM2K3TEST,OU=SCCM,OU=Test Infrastructure,OU=Domain Management,DC=contoso,DC=com
    servicePrincipalName: WSMAN/sccm2k3test
    servicePrincipalName: WSMAN/

    If you look at it closely, you notice all the SPN’s start with characters very much at the end of the alphabet, which also happens to be the end of the index. These entries do not have a prefix like “HOST”.


    So how does this happen?

    In the resultant set of LDAP queries, an object may only appear once, but it is possible for an object to be in the index multiple times, because of the way the index is built. Each time the object is found in the index, the LDAP Server has to check the other values of the indexed attribute of the object to see whether it also matches the filter and thus was already added to the result set.  The LDAP server is doing its diligence to avoid returning duplicates.

    For example, the first hit in the index for the above workstation example is HOST/HERBERTM5“.

    The second hitHOST/ kicks off the algorithm.

    The object is read already and the IO and CPU hit has happened.

    Now the query keeps walking the index, and once it arrives at the prefix WSMAN”, the rate of objects it needs to skip approaches 100%. Therefore, it looks at many objects and little additional objects in the result set.

    On the last page of the query, things get even worse. There is an almost 100% rate of duplicates, so the clock of 60 seconds SETSPN allows for the query is ticking, and there are only 8 objects to be found. If the Domain Controller has a slow CPU or the objects need to be read from the disk because of memory pressure, the SETSPN query will probably not finish within a minute for a large forest.  This results in the error Ldap Error(0x55 -- Timeout): ldap_get_next_page_sThe larger the index (meaning, the more computers and users you have in your forest), the greater the likelihood that this can occur.

    If you run the query with LDIFDE, LDP or ADFIND you will have a better chance the query will be successful. This is because by default these tools do not specify a time-out and thus use the values of the Domain Controller LDAP Policy. The Domain Controller LDAP policy is 120 seconds (by default) instead of 60 seconds.

    The problem with the results generated by these tools is that you have to correlate the results from the different outputs yourself – the tools won’t do it for you.


    So what can you do about it?

    Typically you’ll have to do further troubleshooting, but here are some common causes/resolutions that I’ve seen:

    1. If a domain controller is short on memory and encounters many cache misses and thus substantial IO. You can diagnose this using the NTDS performance counters in Performance Monitor.  You can add memory to reduce the IO rate and speed things up.
    2. If you are not experiencing memory pressure, the limiting factor could be the “Single-Thread-Performance” of the server. This is important as every LDAP query gets a worker thread and runs no faster than one logical CPU core can manage.  If you have a low number of logical cores in a system with a high amount of CPU activity, this can cause the threads to delay long enough for us to see an  nconsistent query return.  In this situation your best bet is to look for ways to reduce overall processor load on the domain controller – for example, moving other services off of the machine.
    3. There is an update for Windows Server 2012 which helps to avoid the problem:

    2799960          Time-out error when you run SETSPN.exe in Windows 8 or Windows Server 2012

    The last customer I helped had a combination of issues 1 and 2 and once he chose a beefier DC with more current hardware, the command always succeeded.  Another customer had a much bigger environment and ended up using the update I listed above to overcome the issue.

    I hope you have enjoyed this journey explaining what is happening on such a SETSPN query.


    Herbert "The Thread Master" Mauerer

  • Windows Server 2012 R2 - Preview available for download

    Just in case you missed the announcement, the preview build of Windows Server 2012 R2 is now available for download.  If you want to see the latest and greatest, head on over there and take a gander at the new features.  All of us here in support have skin in this game, but Directory Services (us) has several new features that we'll be talking about over the coming months.  Including a lot of this stuff named in the announcement:

    "Empowering employee productivity – Windows Server Work Folders, Web App Proxy, improvements to Active Directory Federation Services and other technologies will help companies give their employees consistent access to company resources on the device of their choice."

    Obviously this is still a beta release.  Things can change before RTM.  Don't go doing anything silly like deploying this in production - it's officially unsupported at this stage, and for testing purposes only.  But with all that in mind, give it a whirl, and hit the TechNet forums to provide feedback and ask questions.  You will also want to keep an eye on some of our server and tools blogs in the near future.  For your convenience, a bunch of those are linked in the bar up top for you.

    Happy previewing!

    --David "Town Crier" Beach

  • Two lines that can save your AD from a crisis

    Editor's note:  This is the first of very likely many "DS Quickies".  "Quickies" are shorter technical blog posts that relate hopefully-useful information and concepts for you to use in administering your networks.  We thought about doing these on Twitter or something, but sadly we're still too technical to be bound by a 140-character limit :-)

    For those of you who really look forward to the larger articles to help explain different facets of Windows, Active Directory, or troubleshooting, don't worry - there will still be plenty of those too. 


    Hi! This is Gonzalo writing to you from the support team for Latin America.

    Recently we got a call from a customer, where one of the administrators accidentally executed a script that was intended to delete local users… on a domain controller. The result was that all domain users were deleted from the environment in just a couple of seconds. The good thing was that this customer had previously enabled Recycle Bin, but it still took a couple of hours to recover all users as this was a very large environment. This type of issue is something that comes up all the time, and it’s always painful for the customers who run into it. I have worked many cases where the lack of proper protection to objects caused a lot of issues for customer environments and even in some cases ended up costing administrators their jobs, all because of an accidental click. But, how can we avoid this?

    If you take a look at the properties of any object in Active Directory, you will notice a checkbox named “Protect object from accidental deletion” under Object tab. When this enabled, permissions are set to deny
    deletion of this object to Everyone.


    With the exception of Organizational Units, this setting is not enabled by default on all objects in Active Directory.  When creating an object, it needs to be set manually. The challenge is how to easily enable this on thousands of objects.

    ANSWER!  Powershell!

    Two simple PowerShell commands will enable you to set accidental deletion protection on all objects in your Active Directory. The first command will set this on any users or computers (or any object with value user on the ObjectClass attribute). The second command will set this on any Organizational Unit where the setting is not already enabled.


    Get-ADObject -filter {(ObjectClass -eq "user")} | Set-ADObject -ProtectedFromAccidentalDeletion:$true

    Get-ADOrganizationalUnit -filter * | Set-ADObject -ProtectedFromAccidentalDeletion:$true


    Once you run these commands, your environment will be protected against accidental (or intentional) deletion of objects.

    Note: As a proof of concept, I tested the script that my customer used with the accidental deletion protection enabled and none of the objects in my Active Directory environment were deleted.


    Gonzalo “keep your job” Reyna

  • Back to the Loopback: Troubleshooting Group Policy loopback processing, Part 2

    Welcome back!  Kim Nichols here once again with the much anticipated Part 2 to Circle Back to Loopback.  Thanks for all the comments and feedback on Part 1.  For those of you joining us a little late in the game, you'll want to check out Part 1: Circle Back to Loopback before reading further.

    In my first post, the goal was to keep it simple.  Now, we're going to go into a little more detail to help you identify and troubleshoot Group Policy issues related to loopback processing.  If you follow these steps, you should be able to apply what you've learned to any loopback scenario that you may run into (assuming that the environment is healthy and there are no other policy infrastructure issues).

    To troubleshoot loopback processing you need to know and understand:

    1. The status of the loopback configuration.  Is it enabled, and if so, in which mode?
    2. The desired state configuration vs. the actual state configuration of applied policy
    3. Which settings from which GPOs are "supposed" to be applied?
    4. To whom should the settings apply or not apply?
      1. The security filtering requirements when using loopback
      2. Is the loopback setting configured in the same GPO or a separate GPO from the user settings?
      3. Are the user settings configured in a GPO with computer settings?

    What you need to know:

    Know if loopback is enabled and in which mode

    The first step in troubleshooting loopback is to know that it is enabled.  It seems pretty obvious, I know, but often loopback is enabled by one administrator in one GPO without understanding that the setting will impact all computers that apply the GPO.  This gets back to Part 1 of this blog . . . loopback processing is a computer configuration setting. 

    Take a deep cleansing breath and say it again . . . Loopback processing is a computer configuration setting.  :-)

    Everyone feels better now, right?  The loopback setting configures a registry value on the computer to which it applies.  The Group Policy engine reads this value and changes how it builds the list of applicable user policies based on the selected loopback mode.

    The easiest way to know if loopback might be causing troubles with your policy processing is to collect a GPResult /h from the computer.  Since loopback is a computer configuration setting, you will need to run GPResult from an administrative command prompt.



    The good news is that the GPResult output will show you the winning GPO with loopback enabled.  Unfortunately, it does not list all GPOs with loopback configured, just the one with the highest precedence. 

    If your OU structure separates users from computers, the GPResult output can also help you find GPOs containing user settings that are linked to computer OUs.  Look for GPOs linked to computer OUs under the Applied GPOs section of the User Details of the GPResult output. 

    Below is an example of the output of the GPResult /h command from a Windows Server 2012 member server.  The layout of the report has changed slightly going from Windows Server 2008 to Windows Server 2012, so your results may look different, but the same information is provided by previous versions of the tool.  Notice that the link location includes the Computers OU, but we are in the User Details section of the report.  This is a good indication that we have loopback enabled in a GPO linked in the path of the computer account. 


    Understand the desired state vs. the actual state

    This one also sounds obvious, but in order to troubleshoot you have to know and understand exactly which settings you are expecting to apply to the user.  This is harder than it sounds.  In a lab environment where you control everything, it's pretty easy to keep track of desired configuration.  However, in a production environment with potentially multiple delegated GPO admins, this is much more difficult. 

    GPResult gives us the actual state, but if you don't know the desired state at the setting level, then you can't reasonably determine if loopback is configured correctly (meaning you have WMI filters and/or security filtering set properly to achieve your desired configuration). 

    Review security filtering on GPOs

    Once you determine which GPOs or which settings are not applying as expected, then you have a place to start your investigation. 

    In our experience here in support, loopback processing issues usually come down to incorrect security filtering, so rule that out first.

    This is where things get tricky . . . If you are configuring custom security filtering on your GPOs, loopback can get confusing quickly.  As a general rule, you should try to keep your WMI and security filtering as simple as possible - but ESPECIALLY when loopback is involved.  You may want to consider temporarily unlinking any WMI filters for troubleshooting purposes.  The goal is to ensure the policies you are expecting to apply are actually applying.  Once you determine this, then you can add your WMI filters back into the equation.  A test environment is the best place to do this type of investigation.

    Setting up security filtering correctly depends on how you architect your policies:

    1. Did you enable loopback in its own GPO or in a GPO with other computer or user settings?
    2. Are you combining user settings and computer settings into the same GPO(s) linked to the computer’sOU?

    The thing to keep in mind is that if you have what I would call "mixed use" GPOs, then your security filtering has to accommodate all of those uses.  This is only a problem if you remove Authenticated Users from the security filter on the GPO containing the user settings.  If you remove Authenticated Users from the security filter, then you have to think through which settings you are configuring, in which GPOs, to be applied to which computers and users, in which loopback mode....

    Ouch.  That's LOTS of thinking!

    So, unless that sounds like loads of fun to you, it’s best to keep WMI and security filtering as simple as possible.  I know that you can’t always leave Authenticated Users in place, but try to think of alternative solutions before removing it when loopback is involved. 

    Now to the part that everyone always asks about once they realize their current filter is wrong – How the heck should I configure the security filter?!


    Security filtering requirements:

    1. The computer account must have READ and APPLY permissions to the GPO that contains the loopback configuration setting.
    2. If you are configuring user settings in the same GPO as computer settings, then the user and computer accounts will both need READ and APPLY permissions to the GPO since there are portions of the GPO that are applicable to both.
    3. If the user settings are in a separate GPO from the loopback configuration setting (#1 above) and any other computer settings (#2 above), then the GPO containing the user settings requires the following permissions:  


    Merge mode requirements (Vista+):

    User account:

    READ and APPLY (these are the default
      permissions that are applied when you add users to the Security Filtering
      section of the GPO  on the Scope tab in

    Computer account:

    Minimum of READ permission


    Replace mode requirements:

    User account:

    READ and APPLY (these are the default
      permissions that are applied when you add users to the Security Filtering
      section of the GPO  on the Scope tab in

    Computer account:

    No permissions are required



    Tools for Troubleshooting

    The number one tool for troubleshooting loopback processing is your GPRESULT output and a solid understanding of the security filtering requirements for loopback processing in your GPO architecture (see above).

    The GPRESULT will tell you which GPOs applied to the user.  If a specific GPO failed to apply, then you need to review the security filtering on that GPO and verify:

    • The user has READ and APPLY permissions
    • Depending on your GPO architecture, the computer may need READ or it may need READ and APPLY if you combined computer and user settings in the same GPO.

    The same strategy applies if you have mysterious policy settings applying after configuring loopback and you are not sure know why.  Use your GPRESULT output to identify which GPO(s) the policy settings are coming from and then review the security filtering of those GPOs. 

    The Group Policy Operational logs from the computer will also tell you which GPOs were discovered and applied, but this is the same information that you will get
    from the GPRESULT.

    Recommendations for using loopback

    After working my fair share of loopback-related cases, I've collected a list of recommendations for using loopback.  This isn’t an official list of "best practices", but rather just some personal recommendations that may make your life easier.  ENJOY!

    I'll start with what is fast becoming my mantra: Keep it Simple.  Pretty much all of my recommendations can come back to this point.


    1. Don't use loopback  :-) 

    OK, I know, not realistic.  How about this . . . Don't use loopback unless you absolutely have to. 

    • I say this not because there is something evil about loopback, but rather because loopback complicates how you think about Group Policy processing.  Loopback tends to be configured and then forgotten about until you start seeing unexpected results. 

    2. Use a separate GPO for the loopback setting; ONLY include the loopback setting in this GPO, and do not include the user settings.  Name it Loopback-Merge or Loopback-Replace depending on the mode.

    • This makes loopback very easy to identify in both the GPMC and in your GPRESULT output.  In the GPMC, you will be able to see where the GPO is linked and the mode without needing to view the settings or details of any GPOS.  Your GPRESULT output will clearly list the loopback policy in the list of applied policies and you will also know the loopback mode, without digging into the report. Using a separate policy also allows you to manage the security of the loopback GPO separately from the security on the GPOs containing the user settings.

    3. Avoid custom security filtering if you can help it. 

    • Loopback works without a hitch if you leave Authenticated Users in the security filtering of the GPO.  Removing Authenticated Users results in a lot more work for you in the long run and makes troubleshooting undesired behaviors much more complicated.

    4. Don't enable loopback in a GPO linked at the domain level!

    • This will impact your Domain Controllers.  I wouldn't be including this warning, if I hadn't worked several cases where loopback had been inadvertently applied to Domain Controllers.  Again, there isn’t anything inherently wrong with applying loopback on Domain Controllers.  It is bad, however, when loopback unexpectedly applies to Domain Controllers.
    • If you absolutely MUST enable loopback in a GPO linked at the domain level, then block inheritance on your Domain Controllers OU.  If you do this, you will need to link the Default Domain Policy back to the Domain Controllers OU making sure to have the precedence of the Default Domain Controllers policy higher (lower number) than the Domain Policy.
    • In general, be careful with all policies linked at the at the domain level.  Yes, it may be "simpler" to manage most policy at the domain level, but it can lead
      to lazy administration practices and make it very easy to forget about the impact of seemingly minor policy changes on your DCs.
    • Even if you are editing the security filtering to specific computers, it is still dangerous to have the loopback setting in a GPO linked at the domain level.  What if someone mistakenly modifies the security filtering to "fix" some other issue.
      • TEST, TEST, TEST!!!  It’s even more important to test when you are modifying GPOs that impact domain controllers.  Making a change at the domain level that negatively impacts a domain controller can be career altering.  Even if you have to set up a test domain in virtual machines on your own workstation, find a way to test.

    5. Always test in a representative environment prior to deploying loopback in production.

    • Try to duplicate your production GPOs as closely as possible.  Export/Import is a great way to do this.
    • Enabling loopback almost always surfaces some settings that you weren't aware of.  Unless you are diligent about disabling unused portions of GPOs and you perform periodic audits of actual configuration versus documented desired state configuration, there will typically be a few settings that are outside of your desired configuration. 
    • Duplicating your production policies in a test environment means you will find these anomalies before you make the changes in production.


    That’s all folks!  You are now ready to go forth and conquer all of those loopback policies!


    Kim “1.21 Gigawatts!!” Nichols