Blog - Title

June, 2011

  • Friday Mail Sack: LeBron is not Jordan Edition

    Hi folks, Ned here again. Today we discuss trusts rules around domain names, attribute uniqueness, the fattest domains we’ve ever seen, USMT data-only migrations, kicking FRS while it’s down, and a few amusing side topics.

    Scottie, don’t be that way. Go Mavs.

    Question

    I have two forests with different DNS names, but with duplicate NetBIOS names on the root domain. Can I create a forest (Kerberos) trust between them? What about NTLM trusts between their child domains?

    Answer

    You cannot create external trusts between domains with the same name or SID, nor can you create Kerberos trusts between two forests with the same name or SID. This includes both the NetBIOS and FQDN version of the name – even if using a forest trust where you might think that the NB name wouldn’t matter – it does. Here I am trying to create a trust between fabrikam.com and fabrikam.net forests – I get the super useful error:

    “This operation cannot be performed on the current domain”

    image

    But if you are creating external (NTLM, legacy) trusts between two non-root domains in two forests, as long as the FQDN and NB name of those two non-root domains are unique, it will work fine. They have no transitive relationship.

    So in this example:

    • You cannot create a domain trust nor a forest trust between fabrikam.com and fabrikam.net
    • You can create a domain (only) trust between left.fabrikam.com and right.fabrikam.net
    • You cannot create a domain trust between fabrikam.com and right.fabrikam.net
    • You cannot create a domain trust between fabrikam.net and left.fabrikam.com

    fabrikam1

    Why don’t the last two work? Because the trust process thinks that the trust already exists due to the NetBIOS name match with the child’s parent. Arrrgh!

    image

    BUT!

    You could still have serious networking problems in this scenario regardless of the trust. If there are two same-named domains physically accessible through the network from the same computer, there may be a lot of misrouted communication when people just use NetBIOS domain names. They need to make sure that no one ever has to broadcast NetBIOS to find anything – their WINS environments must be perfect in both forests and they should convert all their DFS to using DfsDnsConfig. Alternatively they could block all communication between the two root domains’ DCs, perhaps at a firewall level.

    Note: I am presuming your NetBIOS domain name matches the left-most part of the FQDN name. Usually it does, but that’s not a requirement (and not possible if you are using more than 15 characters in that name).

    Question

    Is possible to enforce uniqueness for the sAMAccountName attribute within the forest?

    Answer

    [Courtesy of Jonathan Stephens]

    The Active Directory schema does not have a mechanism for enforcing uniqueness of an attribute. Those cases where Active Directory does require an attribute to be unique in either the domain (sAMAccountName) or forest (objectGUID) are enforced by other code – for example, AD Users and Computers won’t let you do it:

    image

    The only way you could actually achieve this is to have a custom user provisioning application that would perform a GC lookup for an account with a particular sAMAccountName, and would only permit creation of the new object should no existing object be found.

    [Editor’s note: If you want to see what happens when duplicate user samaccountname entries are created, try this on for size in your test lab:

    1. Enable AD Recycle Bin.
    2. Create an OU called Sales.
    3. Create a user called 'Sara Davis' with a logon name and pre-windows 2000 logon name of 'saradavis'.
    4. Delete the user.
    5. In the Users container, create a user called 'Sara Davis' with a logon name and pre-windows 2000 logon name of 'saradavis' (simulating someone trying to get that user back up and running by creating it new, like a help desk would do for a VIP in a hurry).
    6. Restore the deleted 'Sara Davis' user back to her previous OU (this will work because the DN's do not match and the recreated user is not really the restored one), using:

    get-adobject -filter 'samaccountname -eq "saradavis"' -includedeletedobjects | restore-adobject -targetpath "ou=sales,dc=consolidatedmessenger,=dc=com"

    (note the 'illegal modify operation' error).

    7. Despite the above error, the user account will in fact be restored successfully and will now exist in both the Sales OU and the Users container, with the same sAMAccountName and userPrincipalName.
    8. Logon as SaraDavis using the NetBIOS-style name.
    9. Logoff.
    10. Note in DSA.MSC how 'Sara Davis' in the Sales OU now has a 'pre-windows 2000' logon name of $DUPLICATE-<something>.
    11. Note how both copies of the user have the same UPN.
    12. Logon with the UPN name of saradavis@consolidatedmessenger.com and note that this attribute does not get mangled.

    Fun, eh? – Ned]

    Question

    Which customer in the world has the most number of objects in a production AD domain?

    Answer

    Without naming specific companies - I have to protect their privacy - the single largest “real” domain I have ever heard of had ~8 million user objects and nearly nothing else. It was used as auth for a web system. That was back in Windows 2000 so I imagine it’s gotten much bigger since then.

    I have seen two other customers (inappropriately) use AD as a quasi-SQL database, storing several hundred million objects in it as ‘transactions’ or ‘records’ of non-identity data, while using a custom schema. This scaled fine for size but not for performance, as they were constantly writing to the database (sometimes at a rate of hundreds of thousands of new objects a day) and the NTDS.DIT is - naturally - optimized for reading, not writing.  The performance overall was generally terrible as you might expect. You can also imagine that promoting a new DC took some time (one of them called about how initial replication of a GC had been running for 3 weeks; we recommended IFM, a better WAN link, and to stop doing that $%^%^&@).

    For details on both recommended and finite limits, see:

    Active Directory Maximum Limits - Scalability

    http://technet.microsoft.com/en-us/library/active-directory-maximum-limits-scalability(WS.10).aspx

    The real limit on objects created per DC is 2,147,483,393 (or 231 minus 255). The real limit on users/groups/computers (security principals) in a domain is 1,073,741,823 (or 230). If you find yourself getting close on the latter you need to open a support case immediately!

    Question

    Is a “Data Only” migration possible with USMT? I.e. no application settings or configuration is migrated, only files and folders.

    Answer

    Sure thing.

    1. Generate a config file with:

    scanstate.exe /genconfig:config.xml

    2. Open that config.xml in Notepad, then search and replace “yes” with “no” (including the quotation marks) for all entries. Save that file. Do not delete the lines, or think that not including the config.xml has the same effect – that will lead to those rules processing normally.

    3. Run your scanstate, including config.xml and NOT including migapp.xml. For example:

    scanstate.exe c:\store /config:config.xml /i:migdocs.xml /v:5

    Normally, your scanstate log should be jammed with entries around the registry data migration:

    Processing Registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\AllowedDragImageExts [.ico]
    Processing Registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\AllowedDragImageExts [.jfif]
    Processing Registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\AllowedDragImageExts [.jpe]
    Processing Registry HKCU\Control Panel\Accessibility\HighContrast
    Processing Registry HKCU\Control Panel\Accessibility\HighContrast [Flags]
    Processing Registry HKCU\Control Panel\Accessibility\HighContrast [High Contrast Scheme]

    If you look through your log after using the steps above, none of those will appear.

    You might also think that you could just rename the DLManifests and ReplacementManifests folders to get the same effect and you’d almost be right. The problem is that Vista or Windows 7also use the built in %systemroot%\winsxs\manifests folders, and you certainly cannot remove those. Just go with the config.xml technique.

    Question

    After we migrate SYSVOL from FRS to DFSR on Windows Server 2008 R2, we still see that the FRS service is set to automatic. Is it ok to disable?

    Answer

    Absolutely. Once an R2 server stops replicating SYSVOL with FRS, it cannot use that service for any other data. If you try to start the FRS service or replicate with it will log events like these:

    Log Name: File Replication Service
    Source: NtFrs
    Date: 1/6/2009 11:12:45 AM
    Event ID: 13574
    Task Category: None
    Level: Error
    Keywords: Classic
    User: N/A
    Computer: 7015-SRV-03.treyresearch.net
    Description:
    The File Replication Service has detected that this server is not a domain controller. Use of the File Replication Service for replication of non-SYSVOL content sets has been deprecated and therefore, the service has been stopped. The DFS Replication service is recommended for replication of folders, the SYSVOL share on domain controllers and DFS link targets.

    Log Name: File Replication Service
    Source: NtFrs
    Date: 1/6/2009 2:16:14 PM
    Event ID: 13576
    Task Category: None
    Level: Error
    Keywords: Classic
    User: N/A
    Computer: 7015-srv-01.treyresearch.net
    Description:
    Replication of the content set "PUBLIC|FRS-REPLICATED-1" has been blocked because use of the File Replication Service for replication of non-SYSVOL content sets has been deprecated. The DFS Replication service is recommended for replication of folders, the SYSVOL share on domain controllers and DFS link targets.

    We document this in the SYSVOL Replication Migration Guide but it’s easy to miss and a little confusing – this article applies to both R2 and Win2008, and Win2008 can still use FRS:

    7. Stop and disable the FRS service on each domain controller in the domain unless you were using FRS for purposes other than SYSVOL replication. To do so, open a command prompt window and type the following commands, where <servername> is the Universal Naming Convention (UNC) path to the remote server:

    Sc <servername>stop ntfrs

    Sc <servername>config ntfrs start=disabled

    Other stuff

    Another week, another barrage of cloud.


    (courtesy of the http://xkcd.com/ blog)

    Finally… friggin’ Word. Play this at 720p, full screen.

     

    ----

    Have a great weekend folks.

    - Ned “waiting on yet more email from humor-impaired MS colleagues about his lack of professionalism” Pyle

  • RSA SecurID Do Over

    Ned here. If you are using RSA SecurID, you’re probably aware they were compromised several months ago. You may also have heard that since then, hackers have been using that stolen info to attack or compromise various organizations. What you may not know is RSA is now issuing replacement tokens for their customers. The catch is you need to contact them; they are not necessarily going to contact you. More info from their executive chairman here:

    http://www.rsa.com/node.aspx?id=3891

    U.S.:
    1-800-782-4362, Option #5 for RSA, Option #1 for the RSA SecurID Remediation Program
     
    Canada:
    1-800-543-4782, Option #5 for RSA, Option #1 for the RSA SecurID Remediation Program
     
    International:
    +1-508-497-7901, Option #5 for RSA, Option #1 for RSA SecurID Remediation Program

    None of this is directly AD or Microsoft-related, but I’d be remiss if I didn’t spread the word – RSA has a large customer base. That said, if you’re interested in alternatives, here’s some reading on understanding and deploying two-factor smartcard authentication:

    Ned “fobbing any questions off on Jonathan” Pyle

  • Blocking Wallpaper Migration with USMT (or: you are a jerk)

    Hi folks, Ned here again. Do you hate your users? Do you revel in removing the slightest joy they have in their day? Do you wish to crush their hope and dreams, to the point of removing the small shreds of humanity they see while walled into their bleak veal pens?

    If so, this post is for you.

    Today I talk about how to block wallpaper and theme migration from Vista or Windows 7 source computers when running USMT. The actual blocking part here is trivial, so if that's all you care about skip to the end. If you want to learn something, start at the beginning: this is part of an informal series that explains USMT reverse engineering. Once you get good at this, you can figure out any weird little corner-case on your own. Even blocking default behaviors. Like not letting people have pictures of their grandkids.

    How do you live with yourself?

    Understanding how wallpaper works

    If you're migrating from Windows XP, you are already good to go - as you know from previous reading, wallpapers are not migrated automatically from that OS unless you write custom XML. However, if you are migrating from Windows Vista or Windows 7, user backgrounds do transfer over and work fine. It's tricky to turn off though, due to the shell's various personalization options. Let's walk through this.

    Here for example, looking at a Windows Vista computer, you see that the desktop key (which contains a wallpaper registry value) is migrated using an OS built-in manifest:

    C:\Windows\winsxs\Manifests>findstr /i "[wallpaper]" *.manifest

     

    x86_microsoft-windows-win32k-settings_31bf3856ad364e35_6.0.6002.18005_none_b326fbadff7217f6.manifest:

    <pattern type="Registry">HKCU\Control Panel\Desktop [Wallpaper]</pattern>

    A quick Internet search seems to confirm that this is the right key data, as does looking at the registry:

    image

    If you set that Win32k manifest to NO in your config.xml (which is a bad idea, as that manifest migrates quite a few other settings and the users are going to be noticeably affected), then test a migration:

    <component displayname="Microsoft-Windows-Win32k-Settings" migrate="no"

    ... the wallpaper customizations are still migrated.

    This shows the danger of searching for references in the manifests without actually looking at the rules in the XML. Let's zoom out a bit:

    <exclude>
     <objectSet
    >
      <
    pattern type=
    "Registry">HKCU\Control Panel\Desktop [Wallpaper]</pattern>

    Examining that manifest closely shows that it actually already blocks migration of the wallpaper setting. But if you look at an actual user migration you will see that this wallpaper registry key does migrate even with this exclusion. You can search XML all you want for this one but you will only figure it out by the process of elimination: it's coming from:

    x86_microsoft-windows-shmig_31bf3856ad364e35_6.0.6002.18005_none_6189f2a77440c81c.manifest

    … which has no rules and only runs a "SHMIG.DLL" plugin that is completely opaque to you.

    That manifest gets called by this guy in the config.xml:

    <component displayname="Microsoft-Windows-shmig" migrate="yes"

    Which is overruling the Win32K manifest. Gotta love the shell… turning that manifest off is definitely a bad idea, as it does a bazillion other things that you definitely want to migrate.

    So what to do? It turns out there are two places in the user registry settings that control the wallpaper: the wallpaper registry value in the Desktop key, and the user's custom theme:

    image
    Ahhh Vista. We hardly knew ya.

    image

    The theme encapsulates the wallpaper settings as well. That does migrate over, thanks to this component manifest:

    <component displayname="Personalized Settings" migrate="yes" ID="appearance_and_display\personalized_settings">

    <component displayname="Microsoft-Windows-uxtheme" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-uxtheme/microsoft-windows-uxtheme/settings"/>

    <component displayname="Microsoft-Windows-themeui" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-themeui/microsoft-windows-themeui/settings"/>

    Which is the OS-supplied manifest:

    x86_microsoft-windows-themeui_31bf3856ad364e35_6.0.6000.16386_none_82c7d4771e961867.manifest

    Which only does this:

    <rules context="User">

     <include>

      <objectSet>

       <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\* [*]</pattern>

      </objectSet>

     </include>

    </rules>

    If you block the Themeui settings explicitly by using the config.xml, you block the wallpaper migration implicitly. This works because when the user first logs on and has blank theme settings, the default theme is set by the OS and voila: no customization happened, even if the Control Panel\Desktop\Wallpaper value is set. It sets the user to the default Windows theme. Sweet!

    Nevermind all that, let's block some wallpaper!

    Either of these works ion its own, pick one. The second one is the recommended one, the first one is the easier one:

    1. Use the themeui config.xml (this can have unwanted side effects for various manifests, but in this case it's atomic to wallpaper and themes) to set only this change:

    <component displayname="Microsoft-Windows-themeui" migrate="no"

    2. Use custom XML (this is a best practice and generally recommended when blocking default migration behaviors):

    scanstate c:\store /o /i:migapp.xml /i:miguser.xml /i:blockwallpaper.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <
    migration urlid="
    http://www.microsoft.com/migration/1.0/migxmlext/blockwallpaperandthemes
    ">
    <
    component type="Documents" context="User"
    >
     <
    displayName>Block Wallpaper and Themes</displayName
    >
     <
    role role="Data"
    >
     <
    rules
    >
      <
    unconditionalExclude
    >
       <
    objectSet
    >
       <!--
    Blocks wallpaper and themes (which include wallpaper) from migrating from Vista/7
    -->
        <
    pattern type="Registry">HKCU\Control Panel\Desktop [WallPaper]</pattern
    >
        <
    pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\* [*]</pattern
    >
       </
    objectSet
    >
      </
    unconditionalExclude
    >
     </
    rules
    >
     </
    role
    >
    </
    component
    >
    </
    migration
    >

    And that's it. I hope you're happy with yourself, you made that nice user cry…

    Ned "they probably had LOLCat pictures, no big loss" Pyle