Blog - Title

May, 2009

  • RSAT Release Candidate for Windows 7... ehh... Release Candidate

    Ned here again. The Remote Server Administration Tools (RSAT) have been released for Win7 RC. Grab them from:

    Here are the installation requirements:

    Supported Operating Systems: Windows 7
    Remote Server Administration Tools for Windows 7 RC can be installed on computers that are running the Professional, Enterprise, or Ultimate editions of Windows 7 RC.

    Remote Server Administration Tools for Windows 7 RC runs on both x86- and x64-based editions of Windows 7 RC, and can be used to manage roles and features that are running on either the Server Core or full installation options of the x64-based Windows Server 2008 R2 operating system. Remote management is also supported for some roles and features that run on Windows Server 2008 or Windows Server 2003.

    Remote Server Administration Tools for Windows 7 RC should not be installed on a computer that is running the Windows Server 2003 Administration Tools Pack or Windows 2000 Server® Administration Tools Pack. Remove all versions of Administration Tools Pack or Remote Server Administration Tools for Windows Vista SP1 from the computer before you install Remote Server Administration Tools for Windows 7 RC.

    Only one copy at a time of Remote Server Administration Tools for Windows 7 RC can be installed on a computer. Before you install a new package, remove any existing copies of Remote Server Administration Tools for Windows 7 RC. This includes any copies that are in different languages.

    And as if you didn't already know, Client and Server OS RC's are out and available to all...

    As always, feel free to post issues or questions in our Comments section below.

    - Ned Pyle

  • Five common questions about AdminSdHolder and SDProp

    Ned here again. After a few years of supporting Active Directory, nearly everyone runs into an issue with AdminSdHolder. This object and its AD worker code is used by Domain Controllers to protect high-privilege accounts from inadvertent modification – i.e. if an administrator account was moved into an OU that was being maintained by an delegated OU admin, it makes sure the high-privilege permissions are not stripped away. You can probably think of a few reasons why allowing a member of Enterprise Admins to be monkeyed with is a Bad Thing™.

    Anyhoo, the way this works is there’s a special object located at:


    Any security descriptors for those groups listed on that object are re-stamped on the user object members every 60 minutes. So you may have run into this where you had made some custom ACL changes on your Administrator user that was a member of some OU, then found an hour later that your changes had disappeared. All by design, all well-and-good. There is also the related SDProp code, which computes and fixes up group memberships for Administrative groups. Both tasks operate only on the PDC Emulator.

    So here are the questions Microsoft gets asked most commonly about this system, and where we haven’t always done the best job documenting answers – until now. :-)

    Question: How does the AdminSdHolder operation determine whether or not to ACL an account?

    Answer: It is based on transitively expanding the list of (possibly nested) protected groups. The attribute AdminCount was originally used only as an optimization to improve performance, since it was assumed that regardless of group membership, AdminCount being 1 should trigger protection. However from repro's on Windows Server 2003 and source code review, it appears this is no longer enough to actually trigger the AdminSdHolder operation all on its own.

    When a Security Principal is a member of a protected group its Security Descriptor is stamped with the SD of the AdminSDHolder Object for that domain. Also the Security Principal's adminCount attribute is set to value 1. If the SD of the security principal in question already matches the SD of the AdminSDHolder Object, the object is left untouched. Consequently its adminCount value could potentially remain 0. So using AdminCount is a pure mark of whether or not a user is protected is not always a good idea – the group membership is the key.

    Question: What is AdminCount, and why is it not being decremented to ‘0’ or ‘<not set>’ when I remove a user from a Protected Group?

    Answer: AdminCount is an attribute on the user account that is set to 1 on any users being protected by AdminSdHolder. When protected, the user gets this attribute set and the security inheritance bit is removed from their account.

    The reason AdminCount isn’t set back to 0 when the user is removed from a protected group is that you told us not to! A survey of customers early on in Windows 2000's design found that they favored deleting a user account after its high-privilege rights were revoked, as the account could have created explicit backdoors before having its rights stripped. Therefore the DC does not remove the AdminCount attribute entry, as it is assumed that the account is going to be disabled or deleted.

    If for some reason you didn’t want to get rid of that account after ‘de-admining’ it, you must manually set back to allowing inheritance and set AdminCount to 0, usually through ADSIEDIT.MSC..

    Question: Is it possible to make AdminSDHolder code run more or less frequently? What about SDProp?

    Answer: Yes, with a big caveat.

    To change the frequency of AdminSdHolder in SDPRop, set the following through regedit:

    "AdminSDProtectFrequency"= <something>

    The value is a DWORD and you can set a range from 60 to 7200 decimal (it's in seconds). By setting it to 60 you would override the default 60 minute wait time and it would fire every minute. By setting to 7200 it would run every 2 hours.

    Note that lowering the default is NOT recommended except for lab testing due to the potential LSASS performance ramifications in a large environment. I.e. doing this could cause your DC’s processor to spike to very high sustained levels and drastically hurt you.

    You can cause SDProp to run once ‘right now’ by using the steps in KB 251343 to execute FixUpInheritance.

    Question: Is there a way to warn administrators that a user being manipulated is covered under AdminSDHolder and SDProp? How do we stop Admins from doing ‘bad’ stuff like this?

    Answer: Nope, you just gotta know.

    As to how you stop Administrators from doing theoretically ‘bad’ stuff – with great power comes great responsibility; AdminSDHolder can only protect you so far from yourself. This is similar to customers who ask us ‘how do I keep administrators from reading all the files on the network?’ The answer is: you cannot. Trust your administrators, bond your administrators, or get different administrators.

    Question: Where are all the best articles on AdminSdHolder and related… stuff?


    • Description and Update of the Active Directory AdminSDHolder Object - KB 232199.
    • Delegated permissions are not available and inheritance is automatically disabled - KB 817433.
    • How To Delegate the Unlock Account Right (which is often why you run into this) – KB 294952.
    • AdminSdHolder Open Specification Document - AdminSDHolder.
    • Michael B. Smith has an excellent and very readable article on his blog here.

    And that’s that.

    - Ned ‘Turboprop’ Pyle

  • Understanding Password Policies

    Hey everybody, its Randy again to discuss Password Policies. I recently had a case that required excruciating detail of how Password Complexity is calculated and I will now take that opportunity to discuss some interesting facts. I need to begin this discussion by directing you to the Account Lockout Best Practices Whitepaper. This paper explains all the meanings of the various password policy settings that can be defined in the domain group policy.

    Most of these settings are pretty self explanatory. If you open your default domain policy and editAccount Lockout Policy, you will see that we have several settings listed.

    Enforce Password History: When changing your password, will you be required to use a different password than previous passwords and how many previous passwords are remembered. One additional note to Password History is that it is not case sensitive. See example below:

    - For uniqueness comparison, a new password must be at least one character different than the passwords in history, with the exception that upper and lower letters do NOT count.

    That is, if “Password1” is in password history then the following will be unique since there is at least 1 character different.

    Password2 (due to 2).

    Passw0rd1 (due to numeral “0” instead of o).

    Password[ (due to symbol “[” instead of 1).

    But following will NOT be unique since upper and lower letters are the same.




    Minimum Password Length, Maximum Password Age, and Minimum Password Age are all self-explanatory and are well explained in the Account Lockout Best Practices Whitepaper.

    Password Complexity: When changing a password, you will be required to use a password that meets the domain password complexity requirements. In Windows NT, this was controlled by an add-on password filter named passfilt.dll. A password filter is a procedure that is called during the password change request. LSA (Local Security Authority) will take the incoming password change request and load the password filter and then perform whatever task the filter has defined. You can make a password filter do just about anything, but typically it is used for password synchronization between separate platforms or a series of validations to confirm that a password change meets the company requirements. It is possible to create your own password filters as well, if you’re handy with C++. In Windows 2000 and later password complexity policies are now coded directly into the operating system as part of LSA, but the complexity requirements remain the same. You can find articles on MSDN with simplified explanations of these grammar checks, hopefully the information below will provide more detail:

    From this Microsoft TechNet article, I found the following discrepancies in our documentation:

    If this policy is enabled, passwords must meet the following minimum requirements when they are changed or created:

    From this Technet article:
    1. Not contain significant portions of the user's account name or full name.

    We look at the entire Account Name and the Full Name. We ensure that the Password does not contain the entire name of either. We also parse through the Account Name and Full Name for delimiters: commas, periods, dashes/hyphens, underscores, spaces, pound-signs and tabs. If any are found, the Account Name or Full Name are split and all sections are verified not to be included in the password. We do not check for any character or any three characters in succession.

    From this Technet article:
    2. Be at least six characters in length.

    Password complexity does NOT check password length.

    From this Technet article:
    3. Contain characters from three of the following four categories:

    English uppercase characters (A through Z)
    English lowercase characters (a through z)
    Base 10 digits (0 through 9)
    Non-alphabetic characters (for example, !, $, #, %)

    It is three of 5 categories. The four categories listed above and a catch-all category of any Unicode character that does not fall under the above four categories. This fifth category can be regionally specific.

    Complexity requirements are enforced when passwords are changed or created.

     The last setting, Store Passwords using reversible encryption, should never be used with a specific need. It is just available for compatibility with legacy apps using CHAP authentication. If you have an application or remote access policy requiring this setting then update it or replace it. You are essentially storing your passwords in plaintext.

    I just touched on a couple of points here, but the Account Lockout Best Practices Whitepaper is filled with a lot of really good information. I can’t leave without dropping some Windows 2008 science on you. So here is a tidbit of information on Fine-Grained Password Policies:

    One big concern from customers of Windows Server 2003 was that you could only set Password Policy at one location in the domain and the only way to separate these policies in your organization was to create separate domains. This has changed with Windows 2008 and Fine-Grained Password Policy. With Fine-Grained Password Policy, you can create different Password Settings Objects (PSO) and assign these PSOs to security groups in your organization. A PSO is simply a Password Policy stored in Active Directory to hold all the defined settings of that Password Policy. You can then associate the PSO to the security groups that you want to adhere to these settings. Here is a good step-by-step to setting this up in your 2008 domain.

    [Editors note: We are working to get that TechNet article with the incorrect info (and any others like it) hunted down and fixed.]

    - Randy Turner

  • ADMT 3.1 and Windows Server 2008 R2

    Hello All,

    UPDATE June 19 2010 - stop reading and go here:


    There’s a known issue with installing Active Directory Migration Tool (ADMT) v3.1 onto a Windows Server 2008 R2 computers that I want to bring to everyone’s attention. At this time it has been acknowledged that version 3.1 (which does require Windows Server 2008) returns the following error when attempting to install it onto R2:

    "ADMT must be installed on Windows Server 2008"

    This issue also occurs with Windows 2008 machines that previously had ADMT installed, and then upgraded to Windows 2008 R2. ADMT will no longer function correctly and returns the same error as detailed above. Microsoft is aware of the issue and diligently working on a resolution. Please stay tuned for further details and updates.

    I’d also like to take this opportunity to ask that you send me any future feature suggestions and requests for the tool, as I’ve been asked to present results of the “voice of the customer”. The ADMT development group would like to hear from our customers on how we could make the product better. Please feel free to post comments or email your recommendations and suggestions in what you’d like to see in a later release of ADMT.

    Happy migrating!

    -Jason Fournerat

  • MS Security Intelligence Report Volume 6 Released

    Ned here again. If you are at all interested in security, here is a must-read:

    Microsoft Security Intelligence Report volume 6 (July - December 2008)

    This covers trends and perspectives on:

    • Software vulnerabilities (both in Microsoft software and in third-party software)
    • Software exploits
    • Security and privacy breaches
    • Malicious and potentially unwanted software
    • E-mail, spam, and phishing

    It's not for the skimmer - it's 184 pages of very detailed analysis, and some of them are eye-opening. Such as the finding that industry-wide, roughly 90% of all vulnerabilities in this period were found to be in applications and browsers, not operating systems. What's your company's application patching strategy? What about your application vendors' strategy?

    For a quick sum up read, check out the smaller 'Key Findings' download, or stop by the MS Malware Protection portal.

    - Ned "Anti-Social Engineering" Pyle

  • SYSVOL migration from FRS to DFSR - Whitepaper Released

    Ned here. It's done, it's out, come get it, stop yelling at me! :-)

    SYSVOL Replication Migration Guide: FRS to DFS Replication (TechNet Version)
    SYSVOL Replication Migration Guide: FRS to DFS Replication (Word Doc Version)

    Be sure to also run through some of these (possibly) useful accompanying pieces:

    Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style
    DFSR SYSVOL Migration FAQ: Useful trivia that may save your follicles
    KB968733 (hotfix for migration under certain RODC scenarios)
    KB967326 (hotfix for migration under disjoint name space scenarios)

    - Ned 'Yes, my middle name is DFSR' Pyle

  • 8-bit Awesomeness

    Ned here. If you're having a lazy friday and don't feel like working too hard (don't lie!), take a trip over to:

    Come on, you know you want to...

    - Ned Pyle

  • Overview of New MPSReports Data Collection Tool

    Here is a nice overview of the new MPSReports and what it collects. Proactively running this before contacting support has been known to greatly reduce time to resolution. :-)