First published on TechNet on Nov 27, 2014
Mark and Tom here again with Mailbag Issue #3. Keep a copy of these first issues in the walls somewhere , they’ll be worth a fortune one day. We hope all of our friends in the US had a great Thanksgiving and that all of our friends around the rest of the world had a great last Thursday in November. If you aren’t standing in line for a great deal on a mediocre TV, here’s what we’ve got for you this week:
Migrating to ADFS 3.0 and token signing certificates
Expanding Windows Storage Pools
Adventures in domain controller computer account password resets
Question
When migrating to ADFS 3.0 on Windows Server 2012 R2 will the migration scripts that migrate the relying party trusts also migrate the token signing certificate?
Answer
Yes. The internally generated self-signed token signing and token decrypting certificates will be migrated. If you have certificates issues by an enterprise or public CA, you will need to move these manually. There are a few other settings that are not migrated automatically, so check out this TechNet article for specifics.
Question
Reading the previous AskPFEPlat post on expanding Storage Spaces, how do I update my pools to add capacity when I’ve added large disks to the server, for example by replacing 2TB disks with 4TB disks?
Answer
Martin’s legacy lives on in these posts. Take a look at this FAQ about Storage Spaces on Windows Server 2012 and Windows Server 2012 R2. This section has all of the details on changing physical drives . The really important note in there is:
Removing the disk will not succeed if a simple space depends on the disk.
Otherwise, you’re golden.
Question
The info on AD commands in PowerShell from last week was great, but I need a bit more meat. Whatcha got for me?
Answer
We had a post previously about alternate learning options and Microsoft Virtual Academy. MVA has come through again. Ashley “CelebPFE” McGlone is the star of the show with six hours of great PowerShell with AD . Check it out.
Question
I noticed that one of my DCs was failing to replicate. I ran the netdom command to reset the machine account password, but after I reboot it’s still failing to replicate. What gives?
Answer
This one came up this week while I was working with a customer. We discovered a DC that had been failing to replicate for a few days. Given that we were seeing access denied and The target principal name is incorrect from repadmin and the logs (and the that replication delta was well within TSL), we took the obvious first step of resetting the machine password and rebooting the DC.
Running repadmin /replsum gave us this:
Easy enough. Let’s reset the machine account password and reboot.
From the broken DC, we ran:
Netdom resetpwd /s:DC01 /ud:corp\tommos- /pd:*
Note the highlighted server (/s) switch . We need to tell it to reset the password and update a good domain controller that will be able to replicate the password change to other DCs. Right now the broken DC, DC02, can’t replicate. If we update the password against DC02’s NTDS instance, we’ll still be in the chicken and egg scenario where DC02 has a new machine account password set that none of the other DCs are aware of and it’s still failing to replicate because of that.
We ran the above and rebooted. Not surprisingly, this didn’t fix our issue. We’d forgotten a key step: Setting the KDC to manual prior to reboot.
The reason for this is relatively simple to understand once we look at all of the parts involved.
We can verify this by running klist -li 0x3e7 from a Windows Server 2012 or 2012 R2 domain controller. It’ll work on older DCs as well, but we won’t see the Kdc Called field, which is what we’re interested in here. The -li 0x3e7 parameter tells klist to give us SYSTEM Kerberos tickets.
Note: Depending on how broken it is, you may not see the above. For the purposes of demonstration in my lab, I disconnected the VM NIC and forced a password reset on the DC, twice, to provide a loose reproduction. It may fail to authenticate entirely which would result in no tickets at all.
Whatever happened with the machine account password is hard to know for sure, but all of the other DCs replicated some change, and the problem child didn’t. After rebooting, and forgetting to set the KDC to manual, replication is still failing:
We needed to set the KDC service to manual, run the netdom command, and reboot. When the DC starts, it won’t be able to request any tickets from itself, so it’s forced to go to a good domain controller for a ticket. The new TGT and service tickets will be valid on the other replicas and replication will succeed. Below you can see that the DC obtained a TGT from DC03 startup.
Now we can set the KDC service back to automatic. And if we wait a few minutes and check back, we’ll see that replication is healthy.
TL;DR: We have to prevent the KDC from starting at boot so the domain controller obtains a TGT and service tickets from a known good domain controller. Replication will then succeed.
Stuff from the Interwebs
It’s the Friday after Thanksgiving (in the US…) so if you work in the places where I’ve worked that don’t have the day off, probably half of your team is there and you’re all bored. So here’s some stuff to work on.
Keep sending questions and feedback! We look forward to emails and comments.
-Mark “On the Gravy Train” Morowczynski and Tom “Whole Lotta Turkey” Moser
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.