First published on TechNet on Jun 25, 2010
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:
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”.
:-D
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. \\dc1.contoso.com\sysvol\netlogon\script1.cmd But when I specify DC1's IP address, the script silently fails: \\10.20.30.40\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.
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/10.20.30.40 (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. \\10.20.30.40\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:
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:
Voila!
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.
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
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.
- Security update best practices for DCs
- Installing security updates on DCs when not an admin
- IP addresses and Kerberos part 1
- IP addresses and Kerberos part 2
- ADMT 3.2 not a valid Win32 application error
- Inter-forest constrained delegation
- CA location in multi-domain forests
- AD Self-study
Question
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?
Answer
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!
Question
What group do I use to install security updates on DC’s and member servers if I do not want those users being Administrators.
Answer
It’s called “Power Unicorn Operators”.
:-D
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!!!
Question
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. \\dc1.contoso.com\sysvol\netlogon\script1.cmd But when I specify DC1's IP address, the script silently fails: \\10.20.30.40\sysvol\netlogon\script1.cmd .
I suppose it is an authentication issue (Kerberos?), but I cannot prove it – am I right?
Answer
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/10.20.30.40 (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. \\10.20.30.40\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?
Answer
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:
\\contoso.com\netlogon\script1.cmd
Voila!
Question
I am trying to install ADMT 3.2 and there’s an error that it is not a valid Win32 application.
Answer
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.
Question
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?
Answer
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.
Question
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. ;-)
Answer
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.
Question
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?
Answer
[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.
Question
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?
Answer
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.
TCP/IP
DNS
Active Directory
Kerberos
Active Directory Replication Model
Active Directory Replication Topology
Group Policy
Interactive Logon
Authentication
Authorization
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.
http://www.microsoft.com/windowsserver2008/en/us/trial-software.aspx
http://technet.microsoft.com/en-us/evalcenter/cc442495.aspx
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
Updated Apr 04, 2019
Version 2.0
NedPyle
Microsoft
Microsoft
