Blog - Title

June, 2010

  • Friday Mail Sack: 1970’s Conversion Van Edition

    Hello folks, Ned here again with another ridiculously overdue Friday Mail Sack. This week we talk about patching, admin rights, Kerberos, hiring, ADMT, and PKI. Next week we talk about… nothing. I will be out celebrating an Important Wife Birthday™ and unless Jonathan takes pity on you, there will be crickets. So bother him A LOT for me, would you?

    Now…let’s get groovy.


    What are the best practices for installing security updates on Domain Controllers? I always transfer the FSMO roles before rebooting any DC, is it correct, wrong? Is there anything else I should monitor or do before or after the restarts?


    There’s no requirement that you move the FSMO roles as none of them need to be online for general domain functionality in the short term; heck, I had one customer with a PDCE offline for more than a year before they noticed – nice! Even if something awful happens and the DC doesn’t immediately come online, most of the FSMO roles serve no immediate purpose (like Schema Master and Domain Naming Master) or are used in only a periodic/failsafe role (RID, PDCE, Infrastructure) where a few minutes won't matter.

    The important things are pretty common sense, but I’ll repeat them:

    1. Make sure not all DC’s are rebooted at once; stagger them out a bit.
    2. Make sure clients are not pointing to DC’s acting as DNS servers that are all being rebooted at once.
    3. Make sure you are using a patching system so you don’t miss DC’s; these include WSUS, SCCM, or a third party.
    4. Do it all off hours to minimize service interruption and maximize recover time if a DC doesn’t want to come back up!


    What group do I use to install security updates on DC’s and member servers if I do not want those users being Administrators.


    It’s called “Power Unicorn Operators”.


    No such group. Non-admins cannot install patches and security updates, and this is very much by design. If they could, they could also uninstall them – making a system unsecure. If they could, they could also install malware masquerading as patches and security updates, compromising a system. Use WSUS (free), SCCM ($), Automatic Updates with “download and install” (free), or a third party ($). Installing updates by hand is only going to work for admins, but even then it’s a poor management solution. Just ask all my Conficker-infected customers that were using that methodology…

    Man, what a kick-$%# group that would be!!!



    I want to create a startup script via GPO. When I use the DC's FQDN in the path the script runs just fine - i.e. \\\sysvol\netlogon\script1.cmd But when I specify DC1's IP address, the script silently fails: \\\sysvol\netlogon\script1.cmd

    I suppose it is an authentication issue (Kerberos?), but I cannot prove it – am I right?


    You are correct, it is Kerberos. :-)

    When a domain-joined client starts up and talks to an AD DC, it must use Kerberos as NTLM is not allowed for computer-to-computer communication. When given a network resource, it needs to be able to pass that host and service info off to the KDC to request a TGS ticket. For that to work, you have to be able to take that computer/service info and use it to find a Service Principal Name, and that starts with a computer or user principal.

    So when you give it an IP address, there is no way to get a SPN, and therefore no way to get Kerberos. So it fails, expectedly and by design. You need to use FQDN (or if you must, NetBIOS name). You will see all this in a network capture as well.

    Question (Continued)

    The key was “…NTLM is not allowed for computer-to-computer communication...”

    That really makes sense now :-). But staring at a network trace, captured during XP startup, I noticed the PC is looking for SPN CIFS/ (when I used DC’s IP address in the startup script path). I was tempted and I added this SPN in the ServicePrincipalName attribute of DC’s object in the lab. After restarting both machines – the startup script run even with DCs IP in the file path (i.e. \\\sysvol\netlogon\script1.cmd ).

    Sounds logical, but is it practical? I suppose this is one of the “do not ever do this!” things? What would be the impact (security/design) if I add SPN like this?


    Oh you sneaky engineers in the field, always clever and always hacking. :-)

    Possible, yes. Practical, no. For a few reasons:

    1. The computer will not self-maintain that SPN, unlike the other SPN’s.
    2. This means you will need to maintain this on all SPN’s for all file servers.
    3. It also means you need to remember to change this when IP addresses change, or serious confusion will ensue.
    4. It also means all IT staff will need to know this, since you will not be there forever and you may like taking vacation from time to time.
    5. It also means that if anyone forgets any of this, huge numbers of computers will not be getting policy/scripts and unless you are monitoring all client event logs, you won’t know it.
    6. Update Jan 21 2011: and starting in Vista, it won't work at all!

    So all that adds up to not recommended, leaning towards highly discouraged. Not to mention that pointing to a specific server isn’t needed when using DFSN (such as with SYSVOL). This will work perfectly well and guarantee the computer talks to the nearest DC first, then continue to work if that DC is down:




    I am trying to install ADMT 3.2 and there’s an error that it is not a valid Win32 application.



    Naughty naughty, you did not read the requirements. You are trying to install this on a Windows Server 2008 or Windows Server 2003 computer running x86 (32-bit). ADMT 3.2 only installs on Windows Server 2008 R2. Since that can only be x64, the installer was only compiled in 64-bit. When you run x64 on x86, you naturally get that error.

    If you tried to install this on Win2003/2008 X64, it would instead say that it requires Win2008 R2.


    I’ve not seen the Weekly DS KB articles from the AD Team blog for a while…. Is it because there aren't any? Or are you just no longer providing those?


    No, Craig just got a bit behind. He plans to resume that soon. Soon being sometime between now and the zombie apocalypse.


    Holy crap, do you believe we put pictures like that in Office Clipart?! We must give kids nightmares.


    Is constrained delegation between different domains (with trusted relationship) ever going to be supported? Maybe Windows Server 2014, Windows Server 2020, Windows server 2096, etc.  ;-)


    While I cannot speak about future releases, this is definitely something we get asked about all the time. When you ask us over and over for something, that helps make it more likely - not guaranteed, mind you - to happen. So if you have a Premier contract, whale on your TAM and let them know you need this functionality and why. The more compelling the argument and the more often it is made, the more likely to get examined for a future release. This goes for pretty much everything in Windows.


    We just created a new Win2008 R2 PKI (one Root CA and one Issuing Sub CA). We have two domains, so we placed the CA’s in our child domain, as we have an empty forest root domain. Should we have placed those CA’s in the empty root?


    [This answer courtesy of Rob Greene – Ned]

    I would recommend that you put the CA’s in the domain where the largest amount of certificate requests are going to be generated.  I say this this because if you configure your certificate templates to publish the certificate in AD, then the CA computer will contact a local domain controller to get it added to the domain. Less traffic, less hopping, generally more efficient.

    The other thing I would recommend is to add the CA’s computer account to the Cert Publishers group in both the child and root domains.  This allows the CA to publish certificates for users / computers in both domains.  


    I heard you are hiring, what are some good things to study up on if I want to interview and really rock your face off?


    Start below. These are the core technologies - mainly as represented in XP and 2003 – that every DS Support Engineer has to know inside and out to be worth a darn in MS Support. Once you have those down you can find the Vista/08/7/R2 differences on your own.

    Active Directory
    Active Directory Replication Model
    Active Directory Replication Topology
    Group Policy
    Interactive Logon
    Public Key Infrastructure (PKI)
    User Profiles

    Note: you can use these free trial editions below in order to do live repros of all this, and repros are highly suggested. Especially with the use of Netmon 3.4 to see how things look on the wire. Running these in Hyper-V, in Virtualbox, etc. will make the materials more understandable.

    Next time I’ll give some links to the post-graduate level studying. Most people think they know these above really well… then the hyperventilating starts in the interview.

    Until next time,

    - Ned “shag carpet” Pyle

  • Friday Mail Sack: Walking Tall Edition

    Hello folks, Ned here again. After a week in Las Colinas Texas, the blog migration, and Jonathan’s attempted coup, we are still standing. Since I’m sure your whole day has been designed around this post I won’t keep you waiting. 


    I am testing RODC’s in a WAN scenario, where the RODC is in a branch site. When the WAN is taken offline, some users cannot logon even when I have cached their passwords. Other users can logon but not access other resources using Kerberos authorization, like file shares and what not.


    Make sure that the computers in that branch site are allowed to cache their passwords also. This means that those computers need to be added into the Password Replication Policy allow list via DSA.MSC. For example:



    If a user tries to logon to a computer that cannot itself create a secure channel and logon to a DC, that user will receive the error “The trust relationship between this workstation and the primary domain failed”.

    If users can logon to their local computers, but then try to access other resources requiring a Kerberos ticket granting service ticket for those computers, and those computers are not able to logon to the domain, users will see something like:


    The error “The system detected a possible attempt to compromise security” is the key, the dialog may change – in this case I was trying to connect to a share.

    You will also see “KDC_ERR_SVC_UNAVAILABLE” errors in your network captures from the RODC. Here I am using a workstation called 7-04-x86-u to try and browse the shares on a file server called 2008r2-06-fn (which is IP address My RODC 2008r2-04-f has a KDC that keeps getting TGS requests that it cannot fulfill since that 06 server cannot logon. So now you see all the SMB (i.e. CIFS) related TGS issues below:



    Does DFSR talk to the PDCE Emulator like DFS Namespace root servers?


    Nope, it locates DC’s just like your computer does when you logon – through the DC Locator process. So if everything is working correctly, any DC’s in the same site are the primary candidates for LDAP communication.


    I understand that DFSR uses encrypted RPC to communicate, but the details are kind of lacking. Especially around what specific cipher suite is used. Can you explain a bit more?


    DFSR uses RPC_C_AUTHN_GSS_NEGOTIATE with Kerberos required, with Mutual Auth required, and with Impersonation blocked. The actual encryption algorithm depends on the OS’s supported algorithms used by Kerberos. On Windows 2003 that would be AES 128 (and RC4 or DES technically, but that would never be used normally). On Win2008 and Win2008R2 it would be AES-256. DFSR doesn’t really care what the encryption is, he just trusts Kerberos to take care of it all within RPC (and this means that you can replace “DFSR” here with “Pretty much any Windows RPC application, as long as it uses Negotiate with Kerberos”). Both AES 128 and AES 256 are very strong block cipher suites that meet FIPS compliance and no one is close to breaking them in the foreseeable future.



    Not really an AD thing, but is Windows 7 able to use the Novell IPX network protocol?


    Nope. Windows XP/2003 were the last Microsoft operating systems to include IPX support. Novell stopped including IPX when they released their client for Vista/2008:

    Novell Client for Windows XP/2003 Features Not Included in the Novell Client for Windows Vista/2008

    • IPX/SPXTM protocols and API libraries.


    What settings should I configure for Windows Security Auditing? What’s recommended?


    That’s a biiiiig question and it doesn’t have a simple answer. The most important thing to consider when configuring auditing – and the one that hardly anyone ever asks – is “what are you trying to accomplish?” Just turning on a bunch of auditing is wrong. Just turning on one set of auditing you find on the internet, a government website, or through some supposed “security auditing” company is also wrong – there is no one size fits all answer, and anyone that says there is can be discarded.

    • Decide what type of information you want to gain by collecting audit events – what are you going to do with this audit data.
    • Consider the resources that you have available for collecting and reviewing an audit log – not just cost of deployment, but reviewing, acting upon it, etc. Operational costs.
    • Collect and archive the logs using something like ACS. The forensic trail is very short in the event log alone.

    Don’t just turn on auditing without having a plan for those three points. Start by reviewing our auditing best practices guide. Then review Eric Fitzgerald’s excellent blog post “Keeping the noise down in your security log.” It has one of the best points ever written about auditing:

    “5. Don't enable "failure" auditing, unless you have a plan on what to do when you see one (that doesn't involve emailing me ;-) and you are actually spending time on a regular basis following up on these events.

    You might or might not realize, that auditing in general is a potential denial-of-service attack on the system.  Auditing consumes system resources (CPU & disk i/o and disk space) to record system and user activity.  Success auditing records activity of authenticated users performing actions which they've been authorized to perform.  This somewhat limits the attack, since you know who they are, and you've allowed them to do whatever it is that you're auditing.  If they try to abuse the system by opening the audited file a million times, you can go fire them.

    Failure auditing allows unauthenticated or unauthorized users to consume resources.  In the worst case, a logon failure event, a remote user with no credentials can cause consumption of system resources.”

    Make sure you are not impacting performance with your auditing – another good Eric read here. Understand exactly what it is your auditing will tell you by reviewing:

    Finally, for some general sample template security settings, take a look at the Security Compliance Manager tool.

    There must have been something in the water this week, as I got asked this by a dozen different customers, askds readers, and MS internal folks. Weird.


    When running AD PowerShell cmdlet get-adcomputer -properties * it always returns:

    Get-ADComputer : One or more properties are invalid.
    Parameter name: msDS-HostServiceAccount
    At line:1 char:15
    + Get-ADComputer <<<<  srv1 -Properties *
        + CategoryInfo          : InvalidArgument: (srv1:ADComputer) [Get-ADComputer], ArgumentException
        + FullyQualifiedErrorId :
    One or more properties are invalid.
    Parameter name: msDS-HostServiceAccount,Microsoft.ActiveDirectory.Management.Commands.GetADComputer

    Not using –properties * or using other cmdlet’s worked fine.


    Rats! Well, this is not by design or desirable. If you are seeing this issue then you are probably using the add-on "AD Management Gateway" PowerShell service on your Win2003 and Win2008 DC's, and have not yet deployed Windows Server 2008 R2 DC’s yet.  You don’t have to roll out Win2008 R2, but you do need to update the AD schema to version 47 – i.e. Windows Server 2008 R2. Steps here, and as always, test your forest schema upgrade in your lab environment first.

    Have a nice weekend.

    - Ned “not actually walking tall, per se” Pyle

  • One Stop Shop for Windows Time Information

    Hi folks, Ned here again. After much noodling and work here with our TechNet writer team, there is a new, consolidated set of info for Windows Time (w32time) in all of our operating systems, to include Windows 7 and Win2008 R2. All of it can be found here:

    Windows Time Service Technical Reference

    This includes updated info on:

    • Where to Find Windows Time Service Configuration Information
    • What is the Windows Time Service?
    • Importance of Time Protocols
    • How the Windows Time Service Works
    • Windows Time Service Tools and Settings

    I think you'll find this useful, make sure to give it a look. A huge thanks to Bob Drake, Kurt, and Jarrett for making this happen.

    PS: The phrase "one stop shop" is the pet peeve of David Fisher. If you ever find yourself talking to him, make sure you use it often.

    - Ned "tick tock you don't stop" Pyle

  • New Directory Services Content 5/23-5/29



    SMTP configuration options are reset in Windows Server 2008 R2, Windows Server 2008 Service Pack 1 and Service Pack 2, after you install the MS10-024 update (976323)


    In Windows Server 2008 or Windows Server 2008 R2 environment, if the network environment is set to enable Delay ACK and storage is connected with iSCSI, an iScsiPrt error is output to the System Event Log when a general operation is executed


    Designing and Implementing a PKI: Part III Certificate Templates

    FRS to DFSR Migration Tool Released

    Enabling CEP and CES for enrolling non-domain joined computers for certificates

    Hey, Scripting Guy! Weekend Scripter: Using the Get-ACL Cmdlet to Show Inherited Permissions on Registry Keys

    Offline Folders and Folder Redirection with Anjli

    Interview on Identity and the Cloud

    Group Policy Setting of the week 26 – Do not allow Windows Messenger to be Run

    Windows Server 2008 R2 Netsh Technical Ref – now available for download

    Inside the new PowerShell 2.0 commands for Active Directory

    Federation Trust Partner Certificates

    Kim Cameron on Identity, Federation and the Cloud

    How to apply a Group Policy Object to individual users or computer

    Transitioning your Active Directory to Windows Server 2008 R2

    What's New in Roaming User Profiles in Windows 7

    Information Card Issuance CTP

    Managing Windows Server 2008 R2 using PowerShell

    Work Remotely with Windows PowerShell without using Remoting or WinRM

    TechNet Wiki Pick of the Week: DirectAccess and Teredo Adaptor Behavior

    Issuing Information Cards with ADFS 2.0

    PowerShell Modules versus Snapins

    FAQ: Microsoft Hyper-V Server 2008 R2

    Deployment guides for Remote Desktop Services in Windows Server 2008 R2 and for Terminal Services in Windows Server 2008 are now available.

    Two Minute Drill: The Eventcreate command

    Should you install Microsoft Hyper-V on Server Core?

    Windows XP SP2 retirement looms, puts users in tough spot

    Delete certificate from smartcard with Base Smart Card provider

    ADFS V2.0 Lingo

    System Center Configuration Manager v.Next Beta 1 - now available

    VHD Getting Started Guide – now available