IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hey y’all, Mark, Tom and the AskPFEPlat crew back for our last mailbag of 2014. It’s getting around the holidays, lots of people start to take vacation including myself. But don’t worry we’re really starting to get into a good rhythm with these posts and it’s looking like we’ll stick with this experiment for 2015. Our topics this week are as follows.
To verify my O365 domain I had to create a DNS TXT record, after it's been verified do I need this still?
Once the domain has been validated you can remove this record.
Last week, JJ asked us how to migrate the configuration, relying party trusts, certificates and everything from a prior version of ADFS to ADFS 2012 R2 while also changing the service account during the migration?
Turning this one over to David Gregory for the answer.
Yes, it is possible to migrate all the settings over while also changing the ADFS service account including a gMSA. We have tested this process and have also received a sign-off from the ADFS product group on this as well:
- On old ADFS Server, run ".\export-federationconfiguration.ps1 – Path c:\ADFS-Output" to export the configuration.
- Copy over the scripts and output to the new ADFS server.
- Install and configure ADFS 2012 R2 on new server and ensure you specify the new gMSA during the configuration.
- The configuration wizard may complain it can't set the SPN because it's already in use. Don't be concerned and you can safely ignore this.
- On the new ADFS server, run ".\import-federationconfiguration.ps1 -Path c:\ADFS-Output" to import the configuration.
- On the new ADFS server, run Set-ADFSCertSharingContainer –ServiceAccount domain.com\gMSA$ where you specify the correct domain name and gMSA. Don't forget to put the $ at the end.
- Remove the host/<sts.domain.com> from the ServicePrincipalName attribute on the old service account and add this SPN to the ServicePrincipalName attribute on the new gMSA.
- Change the DNS host (A) record to point to the new ADFS infrastructure.
The nice thing about this process is that it adds the new gMSA to the permission on the private keys of the certificates while not removing any pre-existing permissions therefore not preventing you from moving back to the old farm, if you need to. If you need to roll back for some reason, all you have to do is:
- Remove the host/<sts.domain.com> from the ServicePrincipalName attribute on the new gMSA and add this SPN back to the ServicePrincipalName attribute on the old service account.
- Change the DNS host (A) record to point to the old ADFS infrastructure.
Where are the Server Manager logs on WS 2012 and R2?
Hilde was all over this one. Like many (excellent) aspects of the Windows OSes these days, there is a dedicated Event Log for this under the "Applications and Services" section (Expand "Microsoft" > "Windows" > "ServerManager."
This tidbit and some more can be found in a prior post about Server Manager circa WS 2012:
While you're there, explore that area and the other logs under "Windows." There is one for Task Scheduler, Windows Update, Hyper-V, DHCP client, Backup, GPO, etc…
Combine that with the fact that you can trigger actions based on Events and you can do some wonderful things via 'in the box' tools.
I found a weird number on my dSHeuristics attribute such as 0000002 or 0000000001000006. How do I figure out what this is doing?
I get this one more often than you'd think when doing our Rap as a Service-Active Directory. So where do we start. First you can take a look at the MSDN documentation to explain to you what bit setting does what. In our first example, our 7th bit is set to a value of 2. According to the documentation it is configuring something with fLDAPBlockAnonOps. We actually have an entire KB dedicated to this setting so I wont spend time on it but basically you are turning on Anonymous LDAP BIND access.
The 2nd one is a bit more tricky, requires math and has to do with the AdminSDHolder role. So the 10th bit says if we are going to set more than 10 unicode characters long we have to set it to 1. And the 16th bit has something to do with dwAdminSDExMask references us to another section. We get this below
All this is saying is we need to take the value and then do a bitwise AND operation for each of these. If the value is not equal to 0, we are excluding these groups from the AdminSDHolder. So in our example we would get the following.
0x6 & 0x1 = 0
0x6 & 0x2 = 2
0x6 & 0x4 = 4
0x6 & 0x8 = 0
So we would be saying that the Server Operators group and the Print Operator groups should be excluded from the AdminSDHolder. There is an older article that has all the combinations listed out and is very good. Typically we find this and then have absolutely zero idea why it is set this way in the environment. Settings like these should be documented very clearly of what was changed and WHY it was changed. What was the reason behind this change?
-The last episode of The Newsroom is airing on Sunday. Nobody watched that show but me and three of my friends (they know who they are). Anyways if you watched The West Wing back in the day you'll enjoy this sketch on Seth Meyers show. If not, go watch West Wing and then come back.
-Ever see 7,358 teddy bears fly onto the ice? We(Mark and Tom) like hockey, so thus we will bring you weird hockey things. Good thing minor league hockey has that in spades. Don't worry all those bears went to a local charity.
-James Bond has to be darker because of Austin Powers. I'm for one ok with this.
-Someone made a vide with Carl Sagan talking and space things happening. Anytime Carl Sagan talks you should probably listen up.
-Finally as we get closer to the holidays 5 stations in my car turn into Christmas music. But they never play the best Christmas song ever!
See everyone Monday.
Mark 'I was told there'd be no math' Morowczynski, Tom 'my team never misses the playoffs' Moser, Michael 'no more coal please' Hildebrand and Dave 'stay out of my underground lair' Gregory