Hey all, Ned here. Mike and I start teaching Windows Server 2012 and Windows 8 DS internals this month in the US and UK and won’t be back until July. Until then, Jonathan is – I can’t believe I’m saying this – in charge of AskDS. He’ll field your questions and publish… stuff. We’ll make sure he takes his medication before replying.
If you’re in Reading, England June 10-22, first round is on me.
![image]( "image")
I didn’t say what the first round was though.
Ned “crikey” Pyle
[This is another guest post from our pal Mark in Oz. Even if you don’t care about DFSR, I highly recommend this post; it teaches some very clever log analysis techniques, useful in a variety of troubleshooting scenarios – The Neditor]
Hi there! It’s Mark Renoden – Premier Field Engineer in Sydney, Australia – here again. Today I’m going to talk about an issue where a customer's DFSR environment lost file updates and they’d see regular alerts in SCOM about replication backlog. While I was on site working with them, I came up with a few creative ideas about how to use the DFSR debug logs that led us to the root cause.
The problem at hand was that a large DFS replication backlog would accumulate from time to time. Finding the root cause meant understanding the trend in changes to files in the replica. To do this, we needed to use the debug logs as our data source: to manipulate them so that they would tell the story.
With the aid of some custom scripts and tools, and a lab environment, I’m going to simulate their experience and talk through the investigation.
The test lab I’ve used for this post is pretty simple: I’ve got two file servers, DPS1 and DPS2 configured with a single replication group called RG1 that replicates C:\ReplicatedFolder between the servers. There are 100,000 files in C:\ReplicatedFolder.
In Ned’s previous post Understanding DFSR Debug Logging (Part 1: Logging Levels, Log Format, GUID’s), the various options for debug log verbosity are discussed. For this scenario, the only one I’ll change is the number of debug log files. 1000 is generally a good number to choose for troubleshooting purposes:
After reproducing the symptoms, we want to harvest the logs from the server that has pending replication. When on site at the customer, I just copied DFSR*.log.gz from the %windir%\debug folder, but the best possible practice would be to stop DFSR, copy the logs and then start the service again. This would prevent log rollover while you harvest the logs.
After you copy the logs for investigation, they need to be un-g-zipped. Use your favourite gzip-aware decompression utility for that.
Before we can mine the debug logs for interesting information, we need to look at what we’re dealing with. Opening up one of the logs files, I want to look for a change and to understand the log format –
20120522 12:39:57.764 2840 USNC 2450 UsnConsumer::UpdateIdRecord LDB Updating ID Record:
+ fid 0x2000000014429
+ usn 0x693e0ef8
+ uidVisible 1
+ filtered 0
+ journalWrapped 0
+ slowRecoverCheck 0
+ pendingTombstone 0
+ internalUpdate 0
+ dirtyShutdownMismatch 0
+ meetInstallUpdate 0
+ meetReanimated 0
+ recUpdateTime 20120521 01:04:21.513 GMT
+ present 1
+ nameConflict 0
+ attributes 0x20
+ ghostedHeader 0
+ data 0
+ gvsn {5442ADD7-04C7-486B-B665-2CB036997A67}-v937024
+ uid {5442ADD7-04C7-486B-B665-2CB036997A67}-v615973
+ parent {8A6CF487-2D5A-456C-A235-09F312D631C8}-v1
+ fence Default (3)
+ clockDecrementedInDirtyShutdown 0
+ clock 20120522 02:39:57.764 GMT (0x1cd37c42d5a9268)
+ createTime 20120516 00:41:05.011 GMT
+ csId {8A6CF487-2D5A-456C-A235-09F312D631C8}
+ hash 00000000-00000000-00000000-00000000
+ similarity 00000000-00000000-00000000-00000000
+ name file0000021380.txt
+
20120522 12:39:59.326 2840 USNC 2453 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD:
+ USN_RECORD:
+ RecordLength: 96
+ MajorVersion: 2
+ MinorVersion: 0
+ FileRefNumber: 0x2000000014429
+ ParentFileRefNumber: 0x4000000004678
+ USN: 0x693e0ef8
+ TimeStamp: 20120522 12:39:57.764 AUS Eastern Standard Time
+ Reason: Close Security Change
+ SourceInfo: 0x0
+ SecurityId: 0x0
+ FileAttributes: 0x20
+ FileNameLength: 36
+ FileNameOffset: 60
+ FileName: file0000021380.txt
What I can see here is a local database update followed by the USN record update that triggered it. If I can gather together all of the date stamps for USN record updates, perhaps I can profile the change behaviour on the file server…
The command above finds every line in every log file that contains USN_RECORD: and then excludes lines that contain a + (thereby eliminating occurrences of + USN_RECORD: as seen in the log excerpt above). Finally, it directs that output into USN.csv.
Let’s open our CSV file in Excel and see what we can do with it.
I'd ideally like to graph the data that I've got, to make it easy to spot trends. The data I have right now isn't super-easy to work with, so I'm going to sanitize it a bit, and then make a Pivot Table and chart from the sanitized data.
Here is a single column of USN_RECORD: timestamps:
I’d like to figure out the rate of change on the file system for files in the replicated folder so I’ll use text to columns. I’m using a fixed width conversion and I’m going to split out my timestamp to the minute (so I can see how many changes per minute I have) and I’ll split USN_RECORD: off the end of the line so that I have something to count:
Now I’ve got columns like this:
I delete the columns I don’t need (A and C). My result is a column of timestamps down to the minute and a column of identical values (column B) which I can count to understand the rate of change:
To do this, I insert a pivot table. I simply select columns A and B and then choose PivotTable from the Insert menu in Excel.
Now I configure my PivotTable Field List as follows:
After configuring the PivotTable, it looks like this
All that’s left for me to do is to click on one of the row labels and to select a chart from the Insert menu. The resulting chart tells us quite a lot:
Here I can see that there are constant changes at roughly 230 per minute, and that for a two-hour window, the changes increase to about 1500 per minute.
For the entire duration of the logs, a roughly consistent level of change was occurring. However, for a two-hour window, lots of change was occurring. There are two possibilities here: either the cause of change has become more aggressive during this time or this chart represents two different activities.
We need more investigation …
I start by skimming a log that contains the timestamps from the two-hour window where we see many changes, and look at the USN record updates. Skimming through, I can see two different types of change:
20120523 10:54:41.249 2840 USNC 2453 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD:
+ USN_RECORD:
+ RecordLength: 96
+ MajorVersion: 2
+ MinorVersion: 0
+ FileRefNumber: 0x20000000175FA
+ ParentFileRefNumber: 0x4000000004678
+ USN: 0xbf0ad430
+ TimeStamp: 20120523 10:54:39.827 AUS Eastern Standard Time
+ Reason: Close Security Change
+ SourceInfo: 0x0
+ SecurityId: 0x0
+ FileAttributes: 0x20
+ FileNameLength: 36
+ FileNameOffset: 60
+ FileName: file0000031231.txt
And:
20120523 10:54:41.249 2840 USNC 2085 UsnConsumer::UpdateUsnOnly USN-only update from USN_RECORD:
+ USN_RECORD:
+ RecordLength: 96
+ MajorVersion: 2
+ MinorVersion: 0
+ FileRefNumber: 0x2000000019AD4
+ ParentFileRefNumber: 0x4000000004678
+ USN: 0xbf0ad4f0
+ TimeStamp: 20120523 10:54:39.843 AUS Eastern Standard Time
+ Reason: Basic Info Change Close
+ SourceInfo: 0x0
+ SecurityId: 0x0
+ FileAttributes: 0x20
+ FileNameLength: 36
+ FileNameOffset: 60
+ FileName: file0000038828.txt
Skimming a log that covers a timeframe with a low rate of change, I can only seem to find:
20120522 23:28:54.953 2840 USNC 2453 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD:
+ USN_RECORD:
+ RecordLength: 96
+ MajorVersion: 2
+ MinorVersion: 0
+ FileRefNumber: 0x2000000022440
+ ParentFileRefNumber: 0x4000000004678
+ USN: 0x7e7f5188
+ TimeStamp: 20120522 23:28:52.984 AUS Eastern Standard Time
+ Reason: Close Security Change
+ SourceInfo: 0x0
+ SecurityId: 0x0
+ FileAttributes: 0x20
+ FileNameLength: 36
+ FileNameOffset: 60
+ FileName: file0000072204.txt
Now I have a theory – Basic Info Change Close events only occur during the two-hour window where there are many changes and there’s an underlying and ongoing security change the rest of the time. I can prove this if I extract the timestamps for Basic Info Change Close changes and similarly, extract timestamps for Close Security Change changes.
Looking back at the log entries, I can see I have a time stamp followed by a series of lines that start with a +. I need to parse the log with something (I chose PowerShell) that takes note of the timestamp line and when a Basic Info Change Close or Close Security Change follows soon after, return the timestamp.
Here’s my PS script:
$files = Get-ChildItem *.log
$processingBlock = $False
$usnBlock = $False
foreach ($file in $files)
{
$content = Get-Content $file
foreach ($line in $content)
{
if (!($line.ToString().Contains("+")))
{
$outLine = $line
$processingBlock = $True
}
if ($processingBlock)
{
if ($line.ToString().Contains("+ USN_RECORD:"))
{
$usnBlock = $True
}
}
if ($usnBlock)
{
if ($line.ToString().Contains("+ Reason: Basic Info Change Close"))
{
$outLine.ToString()
$processingBlock = $False
$usnBlock = $False
}
}
}
}
And:
$files = Get-ChildItem *.log
$processingBlock = $False
$usnBlock = $False
foreach ($file in $files)
{
$content = Get-Content $file
foreach ($line in $content)
{
if (!($line.ToString().Contains("+")))
{
$outLine = $line
$processingBlock = $True
}
if ($processingBlock)
{
if ($line.ToString().Contains("+ USN_RECORD:"))
{
$usnBlock = $True
}
}
if ($usnBlock)
{
if ($line.ToString().Contains("+ Reason: Close Security Change"))
{
$outLine.ToString()
$processingBlock = $False
$usnBlock = $False
}
}
}
}
I run each of these (they take a while) against the debug log files and then chart the results in exactly the same way as I’ve done above.
First, Basic Info Change Close (look at the time range covered and number plotted):
And Close Security Change, below:
This confirms the theory – Basic Info Change Close takes place in the two hours where there’s a high rate of change and Close Security Change is ongoing.
If this is an ongoing pattern where the high rate of change occurs during the same two hours each day, I can capture both activities using Process Monitor.
Once I have a trace, it’s time to filter it and see what’s happening:
Here I’ve reset the filter and added Operation is SetBasicInformationFile then Include. I chose SetBasicInformationFile because it looks like a good fit for the USN record updates labelled Basic Info Change Close. After clicking OK, my filtered trace has the answer…
As it turns out, the backup window matches nicely with the storm of Basic Info Change Close updates.
Clearly, this is my own little application replicating behaviour but in the case of my customer, it was actually their backup application causing this change. They were able to talk to their vendor and configure their backup solution so that it wouldn’t manipulate file attributes during backups.
Now all we need to do is identify the source of Close Security Change updates. Once again, I reset the filter and look for an operation that sounds like a good match. SetSecurityFile looks good.
What I found this time is that no entries show up in Process Monitor
What explains this? Either I chose the wrong operation or the filter is broken in some other way. I can’t see any other sensible operation values to filter with so I’ll consider other options. Looking at the filter, I realize that perhaps System is responsible for the change and right now, Procmon filters that activity out. I remove the exclusion of System activity from my filter and see what happens:
Aha! Now I’ve got something:
Now I need to understand what System is doing with these files. I right click the path for one of these entries and select “Include C:\ReplicatedFolder\file…”:
I also need to remove the filter for SetSecurityFile:
In summary, I’m interested in everything that happened to file0000033459.txt:
If I look at operations on the file that took place prior to SetSecurityFile, I can see a CreateFile operation. This is where System obtained a handle to the file. Looking at this entry, adding the Details column to Process Monitor and examining the fine print I find:
System is making this change in the context of the account CONTOSO\ACLingApp that just happens to be the service account of an application used to change permissions on resources in the environment.
The process I've described today is a good example of the need to Understand the System from my earlier post. The Event Logs - and even the debug logs - won’t always tell you the answer straight away. Know what you’re trying to achieve, know how to use the tools in your arsenal, and know how they can be made to produce the outcome you need.
Knowing what I know now, I might have found the root cause by starting with Process Monitor but there’s a chance I’d have missed Close Security Change updates (considering that System is excluded from Process Monitor by default). I may have also missed the Basic Info Change Close updates if the tracing interval wasn’t aligned with the backup window. By mining the debug logs, I was able to establish there were two separate behaviours and the appropriate times to gather Process Monitor logs.
- Mark “Spyglass” Renoden
Hi folks, Jonathan here. Dave and I wanted to share some important information with you.
By now you’ve all been made aware of the Microsoft Security Advisory that was published this past Sunday. If you are a Terminal Services or Remote Desktop Services administrator then we have some information of which you should be aware. These are just some extra administrative steps you’ll need to follow the next time you have to obtain license key packs, transfer license key packs, or any other task that requires your Windows Server license information to be processed by the Microsoft Product Activation Clearinghouse. Since there’s a high probability that you’ll have to do that at some point in the future we’re doing our part to help spread the word. Our colleagues over at the Remote Desktop Services (Terminal Services) Team blog have posted all the pertinent information. Take a look.
If you have any questions, feel free to post them over in the Remote Desktop Services forum.
Jonathan Stephens
Hi folks, Jonathan here again. Adam Conkle has posted some new goodies related to Office 365 and AD FS/DirSync that may interest you. Take a look, and be sure to rate the content if you find it useful.
----
Client Access Policy Builder - http://gallery.technet.microsoft.com/scriptcenter/Client-Access-Policy-30be8ae2
Short description:
Hotfix Rollup Update 2 for AD FS 2.0 had a new feature for Office 365 customers named Client Access Policy. Some organizations may want to create policies that limit access to Office 365 services, depending on where the client resides. For example, you might want to:
AD FS 2.0 provides a way for organizations to configure these types of policies. Office 365 customers using identity federation who require these policies can now use client access policy rules to restrict access based on the location of the computer or device that is making the request.
Today, customers must manually implement Client Access Policy rules within AD FS 2.0, and it can be confusing. The goal of Client Access Policy Builder is to automate the creation of these rules for the most common use case scenarios.
Microsoft Office 365 Federation Metadata Update Automation Installation Tool - http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
Short description:
This tool can be used to automate the update of the Microsoft Office 365 federation metadata regularly to ensure that changes in the case of the token signing certificate configured in Active Directory Federation Services 2.0 are replicated to the identity platform automatically.
Microsoft Office 365: DirSync - Count Total Synchronized Objects - http://gallery.technet.microsoft.com/office/Office-365-DirSync-Count-617d9268
Short description:
‘DirSync - Count Total Synchronized Objects' shows total counts of users, groups, contacts, and grand total objects by extracting the FIM SourceAD Connector Space data to an XML file named SourceAD.xml.
When an object makes its way past the Office 365 DirSync filters, they become 'synchronized holograms', and this tool parses the SourceAD.xml looking for synchronized holograms and counts the objects by object type.
The Office 365 Deployment Readiness Tool (DRT) assumes that you have not yet deployed Office 365 DirSync, and it is giving you total object counts, without having the ability to see if those objects will actually make it past the DirSync filters. 'DirSync - Count Total Synchronized Objects' allows you, now that you are in production with DirSync, to see more accurate numbers of objects that have made it past the filters.
---
Be sure to keep those questions coming. Yes, Ned is going to be busy for the next several weeks, but the entire Directory Services team is available to answer questions and point you to the best available resources.
Jonathan “What’s a lackey?” Stephens
[Editors Note: This is a guest post from Joe Isenhour, a Senior Program Manager in the Microsoft Engineering Excellence Center.]
Customers can come up with some fairly complex requirements for access control. It can be a challenge to accommodate these requirements in an Office 365 world. The ADFS claims rule system in ADFS 2.0 UR1 provides some powerful options to implement these controls—and some limitations.
The requirements:
It is important to note that the rule processing system always processes all rules. It is NOT a first match system. Because of this, the first rule is most always an “allow everything” rule followed by additional rules that block some access. Schematically, it could look like this:
When the CEO attempts to log in to OWA: Rule #1 allows him, Rule #2 blocks him, and then Rule #3 allows him. It is the state of the last matching rule that determine his final outcome. If the CIO were to attempt to log in, he would only match rules 1 and 2 and therefore would be blocked.
This is a fairly common requirement in a lot of enterprise Exchange environments. Security folks get a bit freaked out by the thought that a user could set up Outlook on a home machine. Meeting this challenge is pretty straightforward with ADFS 2.0 claims rules.
First, let’s review a bit how ADFS claims work in an Office 365 deployment. There are two flavors of ADFS claims requests: Active and Passive. When a claims request is created and submitted by the service (O365) it is an “active” request. This seems kind of counter-intuitive since you (the client) don’t have to do anything for these requests. The active/passive nature of the request refers to the participation of the _service_, not the client. Examples of O365 services that use active claims requests are Outlook 2007/2010 (RPC + HTTPS, EWS), Outlook 2011 for Mac (EWS), ActiveSync, Autodiscover and Lync Online.
A passive claims request is when the service sends you off to get the claim yourself. The main examples of this in O365 are OWA and Sharepoint Online. When you try to log in to OWA in O365 (and you are using federated identity) your browser is redirected to your ADFS endpoint. There you provide your credentials (either via a web form, basic authentication pop-up or integrated auth.), get your token and then return to OWA with your token in hand.
Back to the issue at hand: Blocking Outlook when client is not connected to the corporate network. To translate that into ADFS speak—We need to block active ADFS claims for the RPC+HTTPS and EWS services if the IP address doesn’t match a known set of corporate addresses.
Logically, the rule will look like this:
If {
{ClientApplication is RPC
Or
ClientApplication is EWS}
AND
ClaimType is Active
AND
ClientIPAddress is not in <corporate ip address list>}
THEN DENY THE CLAIM
Now let’s translate that to ADFS Claim Rule language:
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) &&
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/services/trust/2005/usernamemixed"]) &&
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == “Microsoft.Exchange.RPC|Microsoft.Exchange.WebServices"]) &&
NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ “<public NAT addresses>"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
Makes perfect sense, right? Oh…it doesn’t? Allow me to break it down:
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
The ‘Type’ x-ms-proxy exists. This simply means that the claim came through an ADFS Proxy server (or other compatible proxy). Note: we are not checking the ‘value’ for this type, just that the type exists.
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/services/trust/2005/usernamemixed"])
The type x-ms-endpoint-absolute-path exists and has a value of usernamemixed. This is the name of the endpoint for _Active_ ADFS Claims. Summary: This is an active ADFS claim.
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "”Microsoft.Exchange.RPC|Microsoft.Exchange.WebServices"])
ClientApplication is RPC or WebServices. We can use this ‘or’ (using the ‘|’ character) syntax to check the value field.
NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ “\b192\.168\.4\.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-5][0-9])\b|\b10\.3\.4\.5\b"])
The value for the type x-ms-forwarded-client-ip has a value that DOES NOT MATCH the regular expression “<public NAT addresses>”. That brings up two important questions:
According to TechNet:
“This AD FS claim represents a “best attempt” at ascertaining the IP address of the user (for example, the Outlook client) making the request. This claim can contain multiple IP addresses, including the address of every proxy that forwarded the request. This claim is populated from an HTTP header that is currently only set by Exchange Online, which populates the header when passing the authentication request to AD FS.”
(http://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx)
So, the value is going to be the border IP address that Exchange Online (EXO) sees for the client. That would be either the border firewall doing NAT/PAT or the border Proxy server. Exchange Online add this IP to the ADFS claim request. Perfect for our Outlook scenario here: Outlook attempt to connect to EXO, EXO builds up a claims request that includes the client IP and heads out to the ADFS endpoint to submit the request.
The second question is a bit easier (or perhaps a bit harder—regular expressions can get complicated) due to the fact that the regular expression format follows the general rules for regular expressions. The Internet is full of regular expression examples to filter IP addresses. For example, let’s say that your network has one block of addresses in use in a NAT pool: 192.168.4.0-192.168.4.255. You also have one satellite office with a single public IP address: 10.3.4.5. An expression you may use could be:
“\b192\.168\.4\.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-5][0-9])\b|\b10\.3\.4\.5\b”
To break that down:
\b192\.168\.4\.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-5][0-9])\b applies to the 192.168.4.0-255 network.
\b192\.168\.4\. matches 192.168.4.
[1-9] matches address ending in 1-9
[1-9][0-9] matches 10-99
1[0-9][0-9] matches 100-199
2[0-5][0-9] matches 200-259 (yeah…I know a few more than needed)
The ‘|’ represent “or”
\b10\.3\.4\.5\b applies to the 10.3.4.5 address.
These can get tricky. I recommend you use a regular expression verification tool and test.
Finally, if ALL of these conditions are true:
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
We deny the claim.
If any one of the elements of the rule evaluate to false, the entire rule is skipped. So, if the client IS coming from one of the addresses that match the regular expression, they do not match this rule.
The previous example illustrated how to allow or block users based upon where they are. This is a simple example of how to block users based upon who they are.
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) &&
exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD group"]) &&
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application, Value == “Microsoft.Exchange.ActiveSync”])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
The new element here from the previous example is the “groupsid” type. Yeah, you need to dive into AD and hunt down the SID of the group in question. As is hinted by the “=~” operator, you could create a regular expression that would match more than one group. You could also use the “==” operator and the “|” to do a multiple “or” match.
That one was easy—sets us up well for the next. Which gets a bit…complicated.
We built a rule above that did something very similar for Outlook, couldn’t we just add on or slightly alter that rule? Nope, we can’t. OWA login uses a passive ADFS claim, so the behavior is different. With Outlook, or other active claims, all requests come from O365 and land on the external ADFS proxy. To determine if a user is internal or external, we have to examine the “x-ms-forwarded-client-ip” value. With a passive claim request, like OWA, the client’s browser will be connecting directly to the ADFS endpoint (sts.contoso.com for example). So, we can control who gets in based upon where they are asking. If they ask the external proxies (and they are in the specified group) we say “no”. If they ask the internal ADFS servers we say “yes”.
The rule to accomplish this would look something like this:
exists([Type == http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy])
&& exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-299502267-1364589140-1177238915-114465"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
Line 1: Request went through a proxy
Line 2: User is a member of the specified group
Line 3: This is a passive claim to the /adfs/ls/ endpoint
Line 4: Deny
If they hit the internal ADFS servers directly, line 1 would be false and they would be allowed in.
Well…shoot. Easy enough to fix, right? Send everyone to the ADFS proxy and add in a line to the above rule that specifies which client IP addresses are allowed. Something like:
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-299502267-1364589140-1177238915-114465"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ “\b192\.168\.4\.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-5][0-9])\b|\b10\.3\.4\.5\b"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
I hope the blaring red font illustrates the point that this will not work. Why not? Scroll up a bit to the section on blocking Outlook based on IP address. Notice what fills in that x-ms-forwarded-client-ip? EXO. In this example we are dealing with _passive_ ADFS claims. EXO is not creating this claim—the user is hitting the ADFS login page directly. If you turn on this rule, everyone in the specified group will be blocked no matter where they are coming from. The x-ms-forwarded-client-ip type does not exist at all, so that line will evaluate to true. In order to make it false (and thereby stopping the deny rule from firing on someone) the element would need to exist AND the value need to match the regular expression.
If we can’t use the client’s source IP as a filter, how can we solve this problem?
The answer lies in an ADFS claim element that we have been checking all along, but not checking it fully. Let’s look at the debug log (for more on turning on debugging for ADFS see: http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(v=WS.10).aspx ).
Event ID 151 AD FS 2.0 Tracing:
<Claims>
ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname Value CONTOSO\USER1 ValueType http://www.w3.org/2001/XMLSchema#string Issuer AD AUTHORITY OriginalIssuer AD AUTHORITY
ClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name Value CONTOSO\USER1 ValueType http://www.w3.org/2001/XMLSchema#string Issuer AD AUTHORITY OriginalIssuer AD AUTHORITY
ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid Value S-1-5-21-3640651473-4051545122-2937135913-1136 ValueType http://www.w3.org/2001/XMLSchema#string Issuer AD AUTHORITY OriginalIssuer AD AUTHORITY
ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid Value S-1-5-15 ValueType http://www.w3.org/2001/XMLSchema#string Issuer AD AUTHORITY OriginalIssuer AD AUTHORITY Value S-1-5-11 Value S-1-5-2 Value S-1-5-32-545 Value S-1-1-0 Value S-1-5-21-3640651473-4051545122-2937135913-513
ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid Value S-1-5-21-3640651473-4051545122-2937135913-513 ValueType http://www.w3.org/2001/XMLSchema#string Issuer AD AUTHORITY OriginalIssuer AD AUTHORITY
ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod Value
http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password ValueType http://www.w3.org/2001/XMLSchema#string Issuer LOCAL AUTHORITY OriginalIssuer LOCAL AUTHORITY
ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant Value 2012-04-19T17:32:41.459Z ValueType http://www.w3.org/2001/XMLSchema#dateTime Issuer AD AUTHORITY OriginalIssuer AD AUTHORITY
ClaimType http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy Value adfs01p ValueType http://www.w3.org/2001/XMLSchema#string Issuer CLIENT CONTEXT OriginalIssuer CLIENT CONTEXT
</Claims>
We have been checking for the existence of the x-ms-proxy element, but we haven’t looked into its value. The value identifies the name of the proxy server that the request passed through. What if we could tell if a user was internal or external based upon which proxy server they came through?
With this change, internal OWA users will land on internal ADFS Proxy servers and external OWA users will land on external ADFS Proxy servers. That will allow us to add a rule like this:
exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy", Value =~ "\badfsp[0-9][0-9]\b"])
&& exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-299502267-1364589140-1177238915-114465"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
Line 1: User is coming through an ADFS Proxy and that proxy has a name that matches ADFSP##
Line 2: User is in the specified group
Line 3: User is hitting the passive endpoint
Line 4: Deny the claim
If a user in the specified group presents a claim to ADFS from outside the network, all elements of this rule will be true and the claim will be denied. If the same user is inside the network and is using one of the internal proxies, line 1 will be false (the proxy name will not match ADFSP##) and the claim will be allowed.
For illustration purposes, we can express the same thing in a slightly different way:
NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy", Value =~ "\badfspi[0-9][0-9]\b"])
&& exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-299502267-1364589140-1177238915-114465"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
Line 1: The user is NOT coming through an ADFS Proxy that matches ADFSPI##
…
While you may not need to meet access control requirements this complex, I hope that these notes provide some enlightenment into the ADFS claim rule language.
Joe “Piscopo” Isenhour
Hey all, Ned here again. After a few months of training room huffing, airline food loathing, and PowerPoint shilling, I’m back in Charlotte. I’ve got a backlog of legacy product posts to share from colleagues, and with Windows 8 and Windows Server 2012 nigh, more new goo coming your way from me and Mike. And if I can’t come up with a halfway-decent Mail Sack after nearly two months, I’ll eat my own pants – expect that Friday. The blog post, I mean; not trouser consumption.
See you soon,
Ned “In case you’re wondering, the Dutch are like the Yankees of Korfbal, and it still rains in England” Pyle
Hey all, Ned here again with one of my rare public service announcement posts:
In August 2012, Microsoft will issue a software update for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The update will block the use of RSA cryptographic keys that are less than 1024 bits.
To understand what all this means, why we are doing this, and how to determine your current certificate usage, check out:
Ned “Rob Greene made me post this, so I will make him answer your comments” Pyle
Hi, Gary here, and I have been seeing a few more questions regarding the recycle bin on redirected folders. With the advent of Windows Vista there was a change in redirected folders and the support for the Recycle bin. Now each redirected folder has a Recycle Bin associated with it. Windows XP only implemented it for the My Documents folder. Unfortunately, the Administrative Templates only give control of the bin as a whole and not for each redirected folder. The global settings can be controlled by the following policies that work with at least Windows XP:
User Configuration\Administrative Templates\Windows Components\Windows Explorer
Display confirmation dialog when deleting files
Do not move deleted files to the recycle bin
Maximum allowed Recycle bin size
Since there are no policies for the individual bins, we have to modify the registry settings for the user in other ways. That would be through the use of Group Policy Preferences Registry settings or script that would import or set the registry settings. No matter which way you would do it, the registry would have the following settings for each known folder recycle bin:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\{KnownfolderGUID}
MaxCapacity (REG_DWORD) in MB with a minimum value of 1
NukeOnDelete (REG_DWORD) 0 (move to recycle bin) or 1 (delete)
Note: Known Folder GUIDs can be found at here.
Example registry path for the redirected My Documents/Documents folder would be:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\{FDD39AD0-238F-46AF-ADB4-6C85480369C7}
The easy way to get the registry settings would be by redirecting the desired folders and configuring the Recycle bin for each folder as desired through the GUI with a user that is already redirected. That is by right-clicking on the Recycle Bin icon and bringing up Properties to configure the individual recycle bin settings of a user that has the folders already redirected. The following picture is an example where just the Documents folder was redirected and configured to delete the files immediately. As other folders are redirected there will be other entries that show up there for each of the additional locations.
Once you have the registry settings, you have the following options to push out the desired settings to the client machines:
Export the KnownFolder key and then import with a logon script or other method to import the values
regedit /s recyclebin.reg
Create a Group Policy Registry preference setting to push out the NukeOnDelete and MaxCapacity settings for each folder to control. The advantage of this is that if you desire you can modify the settings and get pushed out and use the built in filtering to control specific settings application or value.
The NukeOnDelete value just tells Explorer that no additional files will be put in the recycle bin and will be deleted from the file system. Files and folders that are already in that bin will remain until it is emptied and the MaxCapacity essentially gets ignored at that time. It might be best to configure the MaxCapacity to 1 MB and NukeOnDelete to 0 to start out with. That way the maximum size the recycle bin would be is 1 MB and the next time the user deletes a file it will be reduced to that size as well. Then the NukeOnDelete could be changed to 1 later on and the recycle bin won’t be taking up any additional space.
That would be one way to “empty” the specific recycle bin on the user’s behalf. However, no matter what the settings are, the next time a file is deleted it will get recreated so don’t expect it to remain deleted for very long. Also, from then on the recycle bin will honor the setting anyway.
No. The Recycle Bin folder view is a merged view of all the locations into one view. When a file or folder is deleted, it is just moved and renamed on the same drive. No copying is involved.
While we do not have a way to control the individual recycle bin folders through policy in box we can do it through the registry to get that out to multiple machines now for management.
Thanks,
Gary “Waste Management Consultant” Mudgett
[This is a guest post from Joe Isenhour, a Senior Program Manager in Windows Server. You may remember him from his previous ADFS claims rule post. If you are not yet up to speed on the DAC security suite in Windows Server 2012, I recommend our own Mike Stephens’ treatise Understand and Troubleshoot Dynamic Access Control in Windows Server "8" Beta - the Neditor]
Hello, my name is Joe Isenhour and I work in the Windows Server team. I’m continuing our blog series on Dynamic Access Control (DAC) with a post that addresses some of the scenarios related to deploying DAC to multiple Forests.
You can find a demo video that shows the examples from this post here:
To give you a little bit of background, DAC objects are stored in the Configuration container in Active Directory. This means that the scope for these objects is the Forest level. All of the Domains in a given Forest will use the same set of DAC objects.
CN=Claims Configuration,CN=Services,CN=Configuration,<forest-dn>
If your organization has multiple Active Directory Forests then you may encounter some of the scenarios covered in this post:
We have built a couple of tools that will help you with the scenarios above. The tools are included in the Data Classification Toolkit. You can obtain the beta version of the tools here.
The following conditions are required in order to use the tools that are described in this post:
Let’s say that your company has invested some time authoring Central Access Policies and Claims related data for your corporate Active Directory Forest. Now your CTO office is mandating that some or all of your existing DAC objects need to be included in all of your company’s other Active Directory Forests. This can be challenging for several reasons. One challenge is that the task of creating the objects in the new Forest is labor intensive and prone to error. Another challenge is keeping the unique object ID’s consistent between the Forests. Claim Types and Resource Properties have ID’s that will need to be identical across Forests in order to enable more advanced scenarios like Claim Transformations.
The Export-ClaimsConfiguration.ps1 tool will allow you to export specific DAC objects from a given Forest. The tool will allow you to export:
By default, the tool will export any dependent DAC objects. For example, if you choose to export only Central Access Policies, the tool will also export any Central Access Rules that are defined for the policies and any Claim Types and Resource Properties that are used in the policies.
The following example demonstrates how to export all Central Access Policies from a Forest (including dependent objects). In this example the export will be stored in file called DACExport.xml.
1. Open Windows PowerShell and navigate to the Data Classification Toolkit Tools directory
C:\Program Files (x86)\Microsoft\Data Classification Toolkit\Tools
2. Execute the following command:
.\Export-ClaimsConfiguration.ps1 -File "C:\Temp\DACExport.xml" -IncludeCentralAccessPolicies
When the export is finished, you should have a new file called DACExport.xml. Here is an example of the information contained in the file:
As you can see, there are many other data types defined in this file besides just Central Access Polices. There are Central Access Rules, Resource Properties, and a section called domainIdentities which we will discuss in a moment. This is because the Central Access Policy that was exported has dependencies on other objects. In order for the Central Access Policy to exist in a new Forest, it will need to have all of these dependent objects.
Take a look at the section titled domainIdentities. This section is used to store a mapping between the Security Identifiers that were found in the Central Access Rules and their friendly SamAccountName. Here is an example of how this section might look:
As you can see, the export tool created an entry for every Security Identity that it discovered during the export and stored the id along with the SamAccountName.
Security Identities are unique to a Domain and therefore cannot be exported/imported into other Domains or Forests. This section is used during the import process to map accounts or groups in the target Forest with the accounts found in the export file.
For a detailed list of the options available for exporting DAC objects, execute the following command:
.\Export-ClaimsConfiguration.ps1 –Help
Once you have created your export, you can begin importing the data into other Active Directory Forests. You have a few options when importing:
WhatIf: The import tool implements the standard Windows PowerShell WhatIf condition. If you import using this switch, none of the data will be written to the directory. Instead, you will see the output of what would have been written to the directory had you not chosen the WhatIf switch.
Overwrite: The import process will not write any data to the directory if it finds a conflict with one or more objects. A conflict occurs when a DAC object already exists in the target Forest and has one or more properties that differ from the object in the export file. You may choose the Overwrite option to overwrite the object properties in the target Forest with the properties found in the export file. Certain properties; like IsSingleValued, can’t be overwritten. In this case, the tool will alert you that the property will not be overwritten, but will continue overwriting the other properties.
The following example demonstrates how to import Central Access Policies from an export file. In this example the export will be stored in file called DACExport.xml.
1. Open Windows PowerShell and navigate to the Data Classification Toolkit Tools directory
C:\Program Files (x86)\Microsoft\Data Classification Toolkit\Tools
2. Execute the following command to import the data in WhatIf mode:
.\Import-ClaimsConfiguration.ps1 -File "C:\Temp\DACExport.xml" -Server [domaincontroller] –WhatIf
If the import file contains Central Access Rules then you will likely get prompted to match the identities in the source file with identities in the target Domain/Forest. The tool accomplishes this by matching the SamAccountName in the source file with accounts in the target Forest. You may choose to bypass this prompt using the DontPromptForSIDConfirmation switch. This switch will indicate that you want to accept any matches that are found by the tool.
In some cases, there may be multiple matching accounts in the target Forest. If that happens, you will be presented with a list of accounts that match the source account and you will need to select the proper account.
If there are no conflicts in the source file and the target Forest, then the script should complete with output similar to the image below.
If a conflict was found, then you will instead see a report indicating that there is a conflict. Remember, you can choose to overwrite conflicts using the –Overwrite switch.
If the output from the command looks correct then you can choose to run the command again without the WhatIf switch and write the DAC objects to the target Forest.
For a detailed list of the options available for exporting DAC objects, execute the following command:
.\Export-ClaimsConfiguration.ps1 –Help
I hope that you’ve found these examples helpful. Watch for more great posts and examples of Dynamic Access Control in Windows Server 2012.
Joe Isenhour
Hi all, Ned here again. After a few months of talking about Windows Server 2012 to other ‘softies from around the globe, I’m back with the sack. It was great fun – and not over yet, it turns out – but I am finally home for a bit. The only way you don’t know that the next version of Windows is nearly done is if you live in a hobbit hole, so I’ll leave all those breathless announcements to the rest of the internet.
This week we talk:
Let’s get to it.
I accidentally chose the wrong source replicated folder when setting up DFSR and now I have a few terabytes of data in the preexisting folder. I found your RestoreDfsr script to pull out the intentionally-mangled data, but it’s taking a long time to put everything back. Is there an alternative?
The script just wraps xcopy and makes copies rather than moving files, so it is not scalable when you get into the multi-TB realm (heck, you might even run out of disk space). If it’s reaaaallly slow (when compared to another server just copying some similar files) I’d worry that your disk drivers or firmware or SAN or NAS anti-virus or third party backup agents or whatever are contributing to the performance issues.
However!
All of the files and folders in pre-existing deeper than the root are not mangled and don’t require any special scripts to copy out. Only the files and folders at the root of the preexisting RF are mangled and require the preexistingmanifest.xml for the heavy lifting. Therefore, a quicker way to fix this would be to just figure out the original folder names at the root by examining the pre-existing manifest file with your eyeballs. Rename them to their original name and then use Windows Explorer MOVE (not copy) to just move them back into the original folder. That would leave only the mangled files in the root of the pre-existing folder, which you could then use the script to restore – presumably with less data to restore and where the slower xcopy performance no longer matters.
When I run dfsutil diag viewdfsdirs c: verbose on this Win2008 R2 server, I see errors like this:
Unable to open file by ID
Unable to open file by ID
This volume (C:\) contains 5 DFS Directories.
Done processing this command.
C:\DFSRoots\root1\link1
C:\DFSRoots\root2\link2
C:\DFSRoots\root3\link3
What is the ID in the error? How can I tell the other two folders that it’s missing?
Dfsutil.exe uses the reparse point index to find DFS links on a volume.
Due to some error, dfsutil.exe failed to open some of them. We definitely need a better error that tells you return code and failed path. Sorry.
First, look in c:\dfsroots. The two link folders not returned by your list below are probably in there. If they are not in c:\dfsroots at all, use:
DIR c:\ /S /AL
That returns all reparse points on the volume. Any besides the default ones (in user profiles, programdata, and sysvol) are probably your bad guys. You’d want to make sure they still show up correctly in fsutil, that you have no errors with chkdsk, that they have not been intercepted by some wacky third party, etc.
You can also use (if you have later OSes):
Dfsdiag /testreferral /dfspath:\\contoso.com\namespace /full > output.txt
I am using USMT 4.0 to migrate users that are members of the Administrators group and using a config.xml to make those users only be members of the Users group on the destination computer. I am running these USMT scripts as the users themselves, so they are already administrators on both the source and destination computer when scanstate and loadstate run.
I am finding that the users are still members of administrators after loadstate. Am I doing something wrong or does this XML not work?
<Configuration>
<ProfileControl>
<localGroups>
<mappings>
<changeGroup from="administrators" to="Users" appliesTo="MigratedUsers">
<include>
<pattern>*</pattern>
</include>
</changeGroup>
</mappings>
</localGroups>
</ProfileControl>
</Configuration>
Long answer, deep breath:
1. USMT 4.0 requires that the user running loadstate.exe is a member of the built-in Administrators group and holds privileges SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege, SeDebugPrivilege, SeSecurityPrivilege.
2. It is not a best practice that you log on as the end user being migrated or that end users run their own migrations:
It’s easy to misinterpret the results of using this XML, though. It is not retroactive - if the group memberships already exist on the destination before running loadstate, USMT does not alter them. USMT is designed to copy/skip/manipulate source groups but not destroy destination existing groups.
Since your design requires destination administrator group memberships before running loadstate, this XML cannot work as you desire. If you switch to using separate migration accounts, MDT, or SCCM, then it will work correctly.
I am using new Server Manager in Windows Server 2012 Release Candidate to manage the remote machines in my environment. If I right-click a remote server I see that list of management tools for the given roles I installed. When I run some of the GUI tools like LDP or Computer Management, they target the remote servers automatically. However, the command-line tools just show the help. Is this intentional or should it run in the context of the remote server?
All of the command-line tools are run in this fashion, even when they support remote servers (like repadmin or dcdiag) and even when targeting the local server. We can’t get into a design that deals out a million command-line arguments – imagine trying to provide the menus to support all the various remote scenarios with NETDOM, for example. :-D
![clip_image002]( "clip_image002")
Oy vey
Since providing a remote server alone isn’t enough to make most tools work – Dcdiag alone has several dozen other arguments – we just went with “let’s get the admin a prompt and some help, and let them have at it; they’re IT pros and smart”.
If you haven’t used Server Manager yet, get to it. It’s a great tool that I find myself missing in my Win200L environments.
The “L” is for legacy. YeeaaaahhinyourfaceolderproductsthatIstillsupport!!!
Does USMT 4.0 migrate the Offline Files cache from Windows XP to Windows 7? My testing indicates no, but I find articles implying it should work.
Unfortunately not. Through an oversight, the migration manifest and down-level plugin DLL were never included. The rules of USMT 4.0 are:
In order to migrate the CSC dirty cache, USMT needs plugin DLLs provided by Offline Files. The Offline Files changes from XP to Windows 7 were huge, but even Win7 to Win7 and Vista to Win7 need the plugins for the path conversions.
To workaround this issue, just ensure that users manually synchronize so that all offline files are up to date on the file server. Then migrate.
If you are migrating from Vista (why?! it’s great!!!) or Windows 7 and you want to get the entire cache of dirty and synchronized files, you can use the DWORD value to force the cscmig.dll plugin to grab everything:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CSC\Parameters
MigrationParameters = 1
This is rather silly in a LAN environment, as it will take a long time and increase the size of your compressed store for little reason; these files are going to sync back to the user anyway after the migration. Maybe useful for remote users though; your call.
I'm using Windows Server 2012 Release Candidate and I'm trying to create a new Managed Service Account. I'm running the following from an elevated PS Active Directory module:
New-ADServiceAccount -name Goo
The command fails with error:
NewADServiceAccount : Key does not exist
There are new steps required for managed service accounts in Win2012. We created an object class called a group Managed Service Account (gMSA). GMSA supersedes the previous standalone Managed Service Account (sMSA) functionality introduced in Windows Server 2008 R2. It adds support for multiple computers to share the same service account with the same password automatically generated by a domain controller. This makes server farms using MSAs possible for the first time. SQL 2012, Win2012 IIS app pools, scheduled tasks, custom services, etc. all understand it. It’s very slick.
The new Microsoft Key Distribution Service on Win2012 DCs provides the mechanism to obtain the latest specific key for an Active Directory account. The KDS also continuously creates epoch keys for use with any accounts created in that epoch period. For a gMSA, the domain controller computes the password on the keys provided by the KDS in addition to other attributes of the gMSA. Administrator-authorized Windows Server 2012 and Windows 8 member hosts obtain the password values by contacting a Win2012 DC through Netlogon and cache that password for use by applications. The administrator never knows the password and it’s secure as it can be – just like a computer account password, it’s the maximum 240-bytes of randomly generated goo, changed every 30 days by default. The new KDS is used for other features besides gMSA as well.
And this finally brings me to your issue – you have to first create the root key, using the Add-KdsRootKey cmdlet. This root key is then used as part of all the subsequent gMSA work.
If you want to see some preliminary step-by-step documentation, check out Getting Started with Group Managed Service Accounts. I’ll be coming back to this new feature in detail after we RTM Windows Server 2012.
What does the what /disabledirectoryverification option do in DFSRadmin.exe membership new?
If the folder you specified for the RF with /localpath does not exist with membership new, dfsradmin.exe will create it for you by default with the correct permissions. If it does exist already, it will modify the existing permissions to let the DFSR service use that folder. If the folder already exists with the correct permissions, it does nothing. Using this argument prevents all of these convenient actions.
You would use this argument mainly if you were a crazy person.
I didn’t get to go to Comic-Con this year, but thanks to the InterWaste, you can at least see some of the footage sans the special trailers. The best ones I’ve found are… well, pretty obvious:
There are often some heavy-duty spoilers in these panels – no whining if you find out that Superman is from Krypton and Batman’s parents were killed by the Joker. They also get a little sweary sometimes.
Naturally, if comic-con is your thing, you need your fill of cosplay. The two best galleries are Comicvine.com and – rather oddly – tested.com.
This is how David Fisher sees himself when he looks in the mirror.
It’s summer, which means good reading. IO9 has their annual list of the best Sci-Fi and Fantasy to check out. Redshirts was pretty good and I am starting Ready Player One shortly as no one can shut up about it (Ernest Cline will give you a Delorean if you are an ultrageek). Charles Stross is an automatic if you’re in IT or a British person; in that vein I recently enjoyed The Rook and am revisiting William Gibson this month.
And finally:
Hey, look it’s Ned in a restaurant, grab a picture!
And look, he’s with Satan!
Until next time,
- Ned “I always feel like someone’s watching me” Pyle
Hey all, Ned here with a quickie: Robert Paige just published an interesting read on Windows Server 2012 Dynamic Access Control over at the Windows Server blog:
It highlights the work done with Independent Software Vendor partners and the products they are creating to integrate with the DAC suite. Definitely worth a read.
As always, I recommend you check out Mike Stephens’ depth whitepaper Understand and Troubleshoot Dynamic Access Control in Windows Server "8" Beta if you are looking to get neck deep.
- Ned “the regurgitator” Pyle
Hello all, Dave here again. Over a year ago, Warren created an ASKDS blog post covering common DFS Replication (DFSR) mistakes and oversights. Someone asked me recently where the common DFS Namespaces (DFSN) mistakes article was located. Well, here it is now...
Below you will find details about the more common configuration mistakes or oversights with the DFSN service. I hope this post helps you avoid them. Where possible, I provided links for additional details.
If someone removes a namespace server from the network, turns it off permanently, or reinstalls the operating system, namespace access by clients and administrators alike may experience delays. If the server is the only namespace server hosting the namespace, namespace access will fail. In addition, this blocks you from creating a new namespace with that original namespace's name, as its configuration information still resides within the Active Directory. It is also possible to leave orphaned configuration information in the registry of a namespace server that may prevent it from hosting a future namespace.
None of these are irreversible situations, but it takes some manual work to remove references to an improperly decommissioned namespace server as detailed here (and check out all those errors you could cause!):
977511 About the DFS Namespaces service and its configuration data on a computer that is running Windows Server 2003 or Windows Server 2008
http://support.microsoft.com/kb/977511/EN-US
Before decommissioning a namespace server, remove the server from all namespaces using dfsmgmt or dfsutil. If a namespace server goes permanently offline, clean up the namespace configuration in Active Directory.
It may seem tempting, but domain controllers should never have the DFS Namespace service disabled. Clients require access to the DFS service of domain controllers to enumerate trusted domains, obtain lists of available domain controllers, and to process domain namespace referral requests. The DFSN service typically requires very little CPU and memory to service requests, even from numerous clients. Also, realize that Group Policy processing requires issuing DFSN referrals to clients that attempt to access the SysVol and Netlogon shares. Sysvol and Netlogon are specialized namespaces that Active Directory automatically manages.
Always keep the DFS Namespaces service running on domain controllers.
In Windows Server 2003, there exists an original version of the tool to manage DFS Namespaces called dfsgui.msc
("Distributed File System"). This version lacks many features provided by the 2003 R2 (and later) versions of the DFSN management tool dfsmgmt.msc ("DFS Management"). Although you may use dfsgui.msc to manage a namespace running on these later operating systems, the Windows product team never tested interoperability. The newer MMC also is much more efficient and has some usability improvements. Lastly, the older tool does not allow the configuration of delegation, referral ordering, client fail back, polling configuration, Access-based enumeration (2008 and later), DFSR, etc.
Always use the newer "DFS Management" console in lieu of the "Distributed File System" console.
The major benefit of DFSN is fault tolerance. However, there are times when namespace administrators would prefer a client's file access to fail if the local site's namespace or file server (DFS folder target) is unavailable. A common mistake is to enable this feature and not realize a number of conditions may prevent clients from reaching any targets.
For instance, to issue proper referrals, the DFSN service must determine the site of all namespace and folder targets. Then, it must identify the site of the client. With the exclusion setting configured, if the client's site cannot be determined, if the client is erroneously associated with a site without any targets, or if the site association of namespace servers and/or folder targets cannot be properly determined, access to the namespace's resources may fail. Below, I attempt to identify the site of the system named “workstation” using DFSUtil and the operation failed:
At the bottom of KB article 975440 are methods for troubleshooting this scenario. You may find the other details in the article useful as well.
Before configuring the "exclude targets outside of the client's site" setting, ensure each site containing clients that require access to a namespace path has a target within their site and verify your Active Directory site configuration is accurate.
Ned's details found here have become the standard for why Microsoft does not recommend or support using Distributed File System Replication (DFSR) and DFSN (multiple folder targets) for user profile data. For example: if a user were to be referred to a file server that hasn't yet replicated in recently changed data (or perhaps you don't have replication enabled on the shared folder), then the user will not have access to their expected data. The user will logon and receive an old version of their user profile. At best, this generates helpdesk calls--at worst, a user may unknowingly utilize outdated files and lose data.
Do not use DFSN paths with multiple folder targets to store user profiles or volatile user data. Whenever implementing DFSN, you must be vigilant to ensure users and clients are never affected by referrals to alternate file servers where expected data may not reside.
As mentioned previously, site associations evaluated by the DFS namespace service are crucial for clients’ direction to optimal folder targets. It is important to validate that each site required to have a target has one (or more) targets, that site configurations defined in the Active Directory are accurate, and that you monitor the environment for changes that can affect site associations.
DFSDiag.exe is one method to validate site associations of all servers involved in the referral process and you should run it from a client if you suspect it isn't working properly. I recommend using the "/testreferral" argument as it diagnoses just about everything related to the namespace's health along with the site associations of clients and targets.
Routinely use DFSDiag.exe to check for failures before they impact users or prior to going "live" with a new namespace.
As detailed in this blog post, IPv6 can cause the DFSN referral process to fail or be inaccurate (even on networks that do not support IPv6 functionality). If you are using IPv4 addresses that are not considered a member of the private address space (look here for details), then it is likely your servers are registering IPv6 address in DNS. If you haven't configured IPv6 subnet definitions in Active Directory, these DNS records may be used by DFSN when processing referrals. They cause site associations to fail and incorrect referral ordering.
Once easy method to see if this scenario affects you is to simply open up the DNS Manager MMC snap-in and scan all the host (A) records for your domain's forward lookup zone. If you see any that report an IPv6 address and they are namespace servers or folder targets, you must take corrective action. The aforementioned blog post details some options.
Validate your site configuration for IPv6 compatibility.
Avoid single-point-of-failure wherever possible. If hosting important data within a DFS Namespace that must be available at all times, there is no reason to have only a single namespace server hosting it. As mentioned previously, DFSN requires very little CPU and memory resources under typical conditions. If the single namespace server goes down, no one can access the data.
If server resources are scarce and prevent the configuration of additional namespace servers to host a namespace, consider adding domain controllers as namespace servers. On Windows Server 2008 and 2008 R2 domain controllers, install the "DFS Namespaces" role service to get the DFSN management console and command-line tools. Otherwise, the DFSN service is already installed on domain controllers via the DCPromo operation, but none of the tools are available on it.
Always utilize multiple namespace servers. If a standalone namespace is necessary, use a clustered namespace.
Windows Server 2008 introduced a new type for DFS Namespaces, aptly named "Windows Server 2008 mode". This offers increased scalability and functionality over a "Windows 2000 Server Mode" namespace. As long as your environment supports the minimum requirements for 2008 mode namespaces, there is no reason not to use them.
To use the Windows Server 2008 mode, the domain and namespace must meet the following minimum requirements:
Not choosing this mode is a common mistake by administrators. However, it is possible to migrate from a Windows 2000 Server Mode namespace to a Windows Server 2008 mode namespace using the information found here. However, you should perform the migration during a period where your DFS clients can tolerate an outage--migration requires recreating the namespace.
Standalone namespaces used to be the only option if your namespace required more than 5,000 DFS folders (links). If you fall into this scenario, consider replacing it with a Windows Server 2008 mode namespace.
Choose the correct namespace mode when creating a namespace.
Ned covers this very succinctly in a mail sack response found here. There is no reason to utilize mount points within a DFS Namespace's configuration for the namespace's shared folder. Note: we fully support utilizing mount points under a file share that is the target of a DFS folder.
Do not use mount points within the namespace.
Generally, we do not recommend enabling DFSR or File Replication Service (FRS) replication on a DFS namespace's share. Doing so causes a number of issues, as the replication service attempts to replicate modifications to the reparse folders maintained by the DFSN service within the share. As DFSN removes or adds these reparse folders, FRS/DFSR may replicate the changes before or after DFSN has an opportunity to update the reparse folders based on recent configuration changes.
Ken has an excellent blog here that goes into this further. He also covers additional problems if you try to mix DFSN with DFSR read-only replicas.
Replicate data within separate shared folders and refer clients to those shares using DFS folders within a namespace.
Avoid placing files or folders within the namespace share. Place any data requiring access via the namespace within a share targeted by a DFS folder. This prevents any potential conflicts with reparse folders. It also ensures that in the event a user connects to an alternate namespace server, they always have a consistent view of the data.
Do not place files or folders within the namespace share.
“DfsDnsConfig?” you may ask. This setting alters the types of names, NetBIOS or DNS FQDN, used for namespace referrals. As network environments grow larger and more complex, it makes sense to move away from the flat NetBIOS WINS namespace to a DNS namespace. Only utilize NetBIOS names if you have network clients that specifically require it and must access DFS namespaces. By using FQDN names, you reduce complexity as clients no longer are dependent on appending correct DNS suffixes to the targets’ names. .
Configure namespace servers to utilize the FQDN names for namespace referrals.
If you have enabled Access Based Enumeration (ABE) on a “Window server 2000 Mode” namespace using the instructions found here, you may find that the Windows Server 2008 or 2008 R2 namespace servers are not correctly maintaining permissions their reparse folders. Your custom permissions may be lost if you restart the server or its DFSN service. If any Windows Server 2003 namespace servers also host that namespace, they do not experience this symptom…
An update is available for both Windows Server 2008 and 2008 R2 to correct this behavior. It prevents the DFS Namespaces service from replacing your custom reparse folder permissions you implement via the instructions found in KB article 907458. Again, those instructions are only appropriate if you have a specific requirement to utilize “Windows 2000 Server Mode” namespaces with 2008 and/or 2008r2 namespace servers.
If supported by your environment (see section “Using the wrong namespace version” above), it is better to leverage the native support for ABE in a “Windows Server 2008 mode” namespace. You no longer require use of icacls.exe (or similar NTFS security editing tool) on each namespace server. The DFSN service automatically enforces the reparse folder permissions defined in the DFS Namespace configuration. Because of the mode requirement, Windows Server 2003 servers cannot be namespace servers in the namespace.
This is also a good opportunity to mention the "latest hotfixes" articles for DFS Namespace servers:
Ensure you update the DFSN services, especially if you wish to use ABE with 2008 and/or 2008 R2 namespace servers.
All DFS Namespace deployments require a healthy Active Directory environment to operate successfully. That is why the "How DFS Works" TechNet article begins by describing what constitutes an "optimal environment" for DFS. If DNS, Active Directory replication, site configuration, PDC FSMO owner domain controller, DFS service state, client health, network communications, and security settings are not operating properly, DFSN operations will suffer. Too often, administrators deploy DFSN in unhealthy environments and clients are unable to access resources properly.
Below are some strategies for verifying many components of your environment:
Use DFSDiag.exe to test all major dependencies of the DFSN service.
If you don't yet have any namespaces in the environment, you may still run the following command to test the domain controllers for DFSN service state and consistency of their site associations:
Dfsdiag /testdcs > dfsdiag_testdcs.txt
If a domain-based namespace already exists, the following commands may be utilized to exercise all of Dfsdiag's tests and output results to the specified file:
dfsdiag.exe /testreferral /dfspath:\\contoso.com\namespace1 /full > dfsdiag_testreferral.txt
dfsdiag.exe /testdfsintegrity /dfsroot:\\contoso.com\namespace1 /recurse /full > dfsdiag_testdfsintegrity.txt
Note: Many of DFSDiag's diagnostics are relative to the system running the utility (e.g. site associations, network connectivity, etc.). Thus, you may find running it from various systems throughout your environment gives you more accurate health assessment . In addition, you may acquire dfsdiag.exe from the Remote Server Administration Tools included with Server editions of 2008 or 2008 R2, or from the download for Vista or Windows 7. Install the "Distributed File System Tools" role administration tool.
Evaluate domain controller health, site configurations, FSMO ownerships, and connectivity:
Use Dcdiag.exe to check if domain controllers are functional. Review this for comprehensive details about dcdiag.
Suggested commands:
Dcdiag /v /f:Dcdiag_verbose_output.txt
Dcdiag /v /test:dns /f:DCDiag_DNS_output.txt
Dcdiag /v /test:topology /f:DCDiag_Topology_output.txt
Active Directory replication
If DCDiag finds any replication failures and you need additional details about them, Ned wrote an excellent article a while back that covers how to use the Repadmin.exe utility to validate the replication health of domain controllers.
Suggested commands:
Repadmin /replsummary * > repadmin_replsummary.txt
Repadmin /showrepl * > repadmin_showrepl.txt
Always validate the health of the environment prior to utilizing a namespace.
My hope is that you find this article helpful (I guess sometimes the glass half-empty folks need an article too!)
-Dave “Doppelwarren” Fisher
Hi guys, Joji Oshima here again. When troubleshooting Kerberos authentication issues, a network capture is one of the best pieces of data to collect. When you review the capture, you may see various Kerberos errors but you may not know what they mean or if they are real problems. In this post, I’m going to go over many of the common Kerberos errors seen in these traces, explain what they mean, and what to do about it when you see it.
I designed this post for IT professionals who have experience reviewing network captures. If you are unfamiliar with Kerberos Authentication, I recommend reading Kerberos for the Busy Admin by Rob Greene.
If you are looking for Kerberos related problems, it is important to see the ticketing process over the wire. Follow the steps below to see the requests and possible returned failures. I typically prefer Network Monitor to Wireshark for captures as it gathers the process name, but you can use either one.
1. To reduce the possibility of caching data, do one of the following:
2. Start the network capture
3. Clear DNS cache using:
ipconfig /flushdns
4. Clear NetBIOS cache using:
nbtstat –RR
5. Clear user Kerberos tickets using:
klist purge
6. Clear system / computer Kerberos tickets using (Vista or higher only):
Klist –li 0x3e7 purge
7. Reproduce the authentication failure with the application in question
8. Stop the network capture
Now that you have the capture, you can filter the traffic using the string ‘Kerberosv5’ if you are using Network Monitor. If you are using Wireshark, you can filter using the string ‘Kerberos’.
To be more thorough, load the Authentication Traffic filter that shows packets containing Kerberos tickets as well. You can do this by clicking the Load Filter button, choose Standard Filters, and then click Authentication Traffic.
You need to click the Apply button before the filter is actually loaded.
If there is a lot of traffic, remove the lines for NLMP to reduce some of the noise. Remember to click the Apply button again to make the changes effective.
Important: Depending on the application, the topology, and the domain structure, it may be beneficial to take simultaneous network captures from various points including the client, middle-tier server(s), and back-end server(s).
KDC_ERR_S_PRINCIPAL_UNKNOWN
When a domain controller returns KDC_ERR_S_PRINCIPAL_UNKNOWN, it means the client sent a ticket request for a specific Service Principal Name (SPN) and was unable to locate a single Active Directory object via an LDAP query with that service principal name defined on it.
There are two major causes of this error. The first is the SPN is not registered to any principal. In that case, you should identify which principal will be decrypting the ticket, and register the SPN to that account. The other major cause for this is the SPN was registered to more than one principal in the same Active Directory domain. In this scenario, the domain controller does not know which principal to use, so it returns the same error. Determine which principal is appropriate, and remove the SPN from the other(s). You can read more about this error here.
Extra details to keep in mind:
The HOST SPN (host/server.domain.com) works for multiple services like HTTP & RPCSS. If you would like to see the default Host to SPN mappings use LDP or ADSI Edit and navigate to: cn=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=[Your Domain Component]. Then look at the sPNMappings attribute.
KDC_ERR_C_PRINCIPAL_UNKNOWN
Similar to KDC_ERR_S_PRINCIPAL_UNKNOWN, KDC_ERR_C_PRINCIPAL_UNKNOWN means the domain controller does not know which client principal it should use to encrypt the ticket. The difference here is that instead of a missing or duplicate SPN, there is a missing or duplicate User Principal Name (UPN).
To resolve this, determine if the requestor has the correct UPN. If so, then determine if there is a principal with a matching UPN. If there is a match, look for a duplicate UPN.
You may be scratching your head on the duplicate UPN part because if you try to add/modify a principal that has a duplicate UPN in Active Directory Users & Computers (ADUC), it will block you from doing this. Active Directory does not actually enforce the uniqueness of User Principal Names, but it leaves that up to the application. ADUC checks for duplicates, but other utilities like adsiedit.msc and ktpass.exe do not.
KDC_ERR_ETYPE_NOTSUPP
Here, the client has requested a ticket from the domain controller with a specific algorithm of which the domain controller does not have a hash. In the request, the client will list all the algorithms it supports. The domain controller will pick the highest one that it supports and returns the ticket encrypted with that algorithm. If there are no matches, the domain controller returns KDC_ERR_ETYPE_NOTSUPP.
One common cause of this is older devices that are requesting DES encrypted tickets. By default, DES encryption is disabled in Windows 7 and Windows Server 2008 R2. Ideally, you should update those devices or Kerberos clients to support the newer encryption algorithms. If they cannot be upgraded or replaced, then you can enable DES through group policy. For a good way to find these devices, I recommend reading Hunting down DES in order to securely deploy Kerberos by Ned Pyle.
Another common cause of this is when a device requests an AES encrypted tickets before you raise the functional level of the domain to 2008 or higher. This does not typically occur on Windows clients as they request the legacy algorithms in addition to AES. This scenario is more likely to occur on Unix/Linux systems where an administrator specifies a single algorithm in the krb5.conf file. In this case, raise the functional level of the domain or configure the client to utilize another algorithm, like RC4-HMAC.
If the client is requesting an algorithm that the domain controller should support, but is still returning the error, try resetting the password on the account and wait for replication to converge. Resetting the password regenerates the hashes stored in the directory.
Note: Domain controllers do not store the password of the user. Instead, they store various hashes of the password using various algorithms.
KDC_ERR_PREAUTH_REQUIRED
If you see this error in the trace, it does not indicate there is a problem at all. The client requested a ticket but did not include the pre-authentication data with it. You will typically see the same request sent again with the data and the domain controller issuing the ticket. Windows uses this technique to determine the supported encryption types.
KDC_ERR_PREAUTH_FAILED
KDC_ERR_PREAUTH_FAILED indicates the pre-authentication data sent with the ticket is not valid. It usually means the user does not exist or the password supplied is invalid.
KRB_AP_ERR_SKEW
To avoid packet replay attacks, Kerberos tickets include an authenticator with the ticket. This authenticator is based on a timestamp so an attacker cannot reuse them. Getting KRB_AP_ERR_SKEW typically means there is a time synchronization issue in your domain, and the time difference is greater than the default 5 minutes. If this is a common problem, start looking for time drifts across the infrastructure.
KRB_AP_ERR_REPEAT
This is another mechanism created to reject replay attacks. The server caches information from recently received tickets. If the server name, client name, time, and microsecond fields from the Authenticator match recently seen entries in the cache, it will return KRB_AP_ERR_REPEAT. You can read more about this in RFC-1510. One potential cause for this is a misconfigured network device in between the client and server that could send the same packet(s) repeatedly.
KRB_AP_ERR_MODIFIED
If a service returns KRB_AP_ERR_MODIFIED, it indicates that the service was unable to decrypt the ticket that it was given. The name of the error suggests that an attacker may have modified the ticket in order to gain access to a system. While this is possible, the most common reason is when the Service Principal Name (SPN) is registered to the wrong account. If Service A gets a ticket encrypted with Service B’s password, Service A cannot decrypt it using its password. There is no way for the service to know why it cannot decrypt the ticket, so it returns this error. To resolve this issue, determine which account is actually running the service and move the SPN to that account. If the service is running as Local System, Local Service, or Network Service, set the SPN on the computer account.
Another possible cause is a duplicate SPN in two different domains in the forest. If it appears the SPN is registered to the correct account, search the entire forest for a duplicate SPN. For example: Say there is a service in Domain A that uses the SPN http/service.contoso.com and the same SPN exists in Domain B. If a user from Domain B tries to access the service in Domain A, it will fail with this error. The reason for this is the client in Domain B will first try to contact a domain controller in Domain B for that SPN. That domain controller will return a ticket for the account in Domain B.
An interesting issue we see revolves around IIS7 and Kernel Mode Authentication. Typically, you should register the SPN to the account that is running the application pool. Kernel Mode Authentication speeds up authentication requests and performs the decryption in the context of the computer account. In the case of load balanced web servers, you cannot have multiple nodes using the computer different contexts to decrypt the ticket. Either disable Kernel Mode Authentication or use the useAppPoolCredentials in the applicationhost.config file of the web server. For more information, review:
KDC_ERR_BADOPTION
If the domain controller returns KDC_ERR_BADOPTION, it means that one of the KrbFlags set in the KdcOptions is not allowed. You can see a sample of the options in the figure below.
The most common scenario is a request for a delegated ticket (unconstrained or constrained delegation). You will typically see this on the middle-tier server trying to access a back-end server. There are several reasons for rejection:
1. The service account is not trusted for delegation
2. The service account is not trusted for delegation to the SPN requested
3. The user’s account is marked as sensitive
4. The request was for a constrained delegation ticket to itself (constrained delegation is designed to allow a middle tier service to request a ticket to a back end service on behalf on another user, not on behalf of itself).
KDC_ERR_WRONG_REALM
This error may occur when a client requests a TGT from a domain controller for a domain to which the client does not belong. This error refers the client to the correct domain and does not indicate a problem. You can read more about it here.
KDC_ERR_TGT_REVOKED
Getting a KDC_ERR_TGT_REVOKED error means that the TGT presented to the domain controller in order to get a service ticket is not valid. These errors are common when the client is in a site with a Read Only Domain Controller (RODC) and is attempting to access a resource in another site. Seeing this error does not necessarily mean there is a problem. Read more about the ticketing process with RODCs here.
Troubleshooting authentication issues is not always cut and dry. I hope you now understand the meanings behind common Kerberos errors what you can do about them. If you want to dive a bit deeper into this, I recommend reading the RFCs associated with Kerberos.
Kerberos RFC
http://www.ietf.org/rfc/rfc1510.txt
http://www.ietf.org/rfc/rfc4120.txt
I’ve also linked to a more comprehensive list of Kerberos errors you may encounter.
Kerberos and LDAP Error Messages
http://technet.microsoft.com/en-us/library/bb463166.aspx
Until next time,
Joji “three-headed puppy” Oshima
Hey all Rob Greene here again. Yeah, I know, it’s been a while since I’ve written anything for you good people of the Internet.
I recently had an interesting issue with the Active Directory Web Services and the Active Directory Windows PowerShell 2.0 modules in Windows 7 and Windows Server 2008 R2. Let me explain the scenario to you.
We have a group of helpdesk users that need to be able to run certain Windows PowerShell commands to manage users and objects within Active Directory. We do not want to install any of the Active Directory RSAT tools on helpdesk groups Windows 7 workstations directly because these users should not have access to Active Directory console snap-ins [Note: as pointed out in the Comments, you don't have to install all RSAT AD tools if you just want AD Windows PowerShell; now back to the action - the Neditor]. We have written specific Windows PowerShell scripts that the help desk users employ to manage user accounts. We are storing the Windows PowerShell scripts on a central server that the users need to be able to access and run the scripts remotely.
Hmmm…. Well my mind starts thinking, man this is way too complicated, but hey that’s what our customers like to do sometimes… Make things complicated.
The basic requirement is that the help desk admins must run some Windows PowerShell scripts on a remote computer that leverages the ActiveDirectory Windows PowerShell cmdlets to manage user accounts in the domain.
So let’s think about the “ask” here:
By default you must connect to the remote server with an Administrator level account when PS remoting otherwise the remote session will not be allowed to connect. That means the helpdesk users cannot connect to the domain controllers directly.
If you are interested in changing this requirement the Scripting Guy blog has two ways of doing this via:
Wow, how do we make all this happen?
1. You need to enable Windows PowerShell Remoting on the Remote Admin Server. The simplest way to do this is by launching an elevated Windows PowerShell command prompt and type:
Enable-PSRemoting -Force
To specify HTTPS be used for the remote connectivity instead of HTTP, you can use the following cmdlet (this requires a certificate environment that's outside the scope of this conversation):
Set-WSManQuickConfig –Force -UseSSL
2. On the Remote Admin Server you will also want to make sure that the “Windows Remote Management (WS-Management)” service is started and set to automatic.
If you have done a decent amount of Windows PowerShell scripting you probably got this part.
Alright, the next part is kind of tricky. Since we are delegating the user’s credentials from the Remote Admin Server to the ADWS service, you are probably thinking that we are going to setup some kind of Kerberos delegation here. That would be incorrect. Windows PowerShell remoting does not support Kerberos delegation. You have to use CredSSP to delegate the user account to the Remote Admin Server (which does a logon to the Remote Admin Server) and then it is allowed to interact with the ADWS service on the domain controller.
More information about CredSSP:
951608 Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3
http://support.microsoft.com/kb/951608/EN-US
If you have done some research on CredSSP, it takes the user's name and password and passes it on to the target server. It is not sending a Kerberos ticket or NTLM token for validation. This can be somewhat risky. Just like with Windows PowerShell remoting CredSSP usage is disabled by default and must be enabled. The other key thing to understand about CredSSP is you have to enable the “Client” and the “Server” to be able to use it.
NOTE: Although Windows XP Service Pack 3 does have CredSSP in it. The version of Windows PowerShell for Windows XP does not support CredSSP with remote management.
3. On the Remote Admin Server, we need to enable Windows Remote Management to support CredSSP. We do this by typing the command below in an elevated Windows PowerShell command window:
Enable-WSManCredSSP –Role Server -Force
4. On the Windows 7 client, we need to configure the “Windows Remote Management (WS-Management)” service startup to Automatic. Failure to do this will result in the following error being displayed at the next step:
Enable-WSManCredSSP : The client cannot connect to the destination specified in the request. Very that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination to analyze and configure the winRM service: “winrm quickconfig”
5. On the Windows 7 client, we need to enable Windows Remote Management to support CredSSP. We do this by typing the command below in an elevated Windows PowerShell command window:
Enable-WSManCredSSP -Role Client -DelegateComputer *.contoso.com -Force
NOTE: “*.contoso.com” is a placeholder for your DNS domain name. Within the client configuration is where you can constrain the CredSSP credentials to certain “Targets” or destination computers. If you want them to only work to a specific computer replace *.contoso.com with the specific servers name.
6. Lastly, when the remote session is created to the target server we need to make sure that the “-Authentication CredSSP” switch is provided. Here are a couple of remote session examples:
Enter-PSSession -ComputerName con-rt-ts.contoso.com -Credential (Get-Credential) -Authentication CredSSP
Invoke-Command –ComputerName con-rt-ts.contoso.com –Credential (Get-Credential) –Authentication CredSSP –ScriptBlock {Import-Module ActiveDirectory; get-aduser administrator}
I hope that you have some new information around Windows PowerShell remoting today to make your Windows PowerShell adventures more successful. This story changes in Windows 8 and Windows Server 2012 for the better, so use this article only with your legacy operating systems.
Rob “Power Shrek” Greene
Hi all, Ned here again to talk further about managing your RID pool.
By default, a domain has capacity for roughly one billion security principals, such as users, security groups, managed service accounts, and computers. If you run out, you can’t create any more.
There aren’t any domains with that many active objects, of course, but we've seen:
All of these situations use up RIDs unnecessarily, often by mistake. Over many years, a few environments ran out of RIDs and this forced customers to migrate to a new domain or revert with domain and forest recoveries.
Windows Server 2012 addresses issues with RID allocation that have become more likely with the age and ubiquity of Active Directory. These include better event logging, more appropriate limits, and the ability to - in an emergency - increase the overall RID pool allocation by one bit.
Windows Server 2012 adds global RID space event tracking that provide early warning when major milestones are crossed. The model computes the ten (10) percent used mark in the global pool and logs an event when reached. Then it computes the next ten percent used of the remaining and the event cycle continues. As the global RID space is exhausted, events will accelerate as ten percent hits faster in a decreasing pool (but event log dampening will prevent more than one entry per hour). The System event log on every domain controller writes Directory-Services-SAM warning event 16658.
Assuming a default 30-bit global RID space, the first event logs when allocating the pool containing the 107,374,182ND RID. The event rate accelerates naturally until the last checkpoint of 100,000, with 110 events generated in total. The behavior is similar for an unlocked 31-bit global RID space: starting at 214,748,365 and completing in 117 events.
Important
Understand that these events are never "expected": investigate the user, computer, and group creation processes immediately in the domain if you see the event. Creating more than 100 million AD DS objects is quite out of the ordinary!
There are new event alerts that a local DC RID pool was discarded. These are Informational and could be expected, especially due to the new virtualized domain controller functionality. See the event list later for details on the event.
Ordinarily, a domain controller requests RID allocations in blocks of 500 RIDs at one time. You can override this default using the following registry REG_DWORD value on a domain controller:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values
RID Block Size
Prior to Windows Server 2012, there was no maximum value enforced in that registry key, except the implicit DWORD maximum (which has a value of 0xffffffff or 4294967295). This value is considerably larger than the total global RID space. Administrators sometimes inappropriately or accidentally configured RID Block Size with values that exhausted the global RID at a massive rate.
In Windows Server 2012, you cannot set this registry value higher than 15,000 decimal (0x3A98 hexadecimal). This prevents massive unintended RID allocation.
If you set the value higher than 15,000, the value is treated as 15,000 and the domain controller logs event 16653 in the Directory Services event log at every reboot until the value is corrected.
Prior to Windows Server 2012, the global RID space was limited to 230 (or 1,073,741,823) total RIDs. Once reached, only a domain migration or forest recovery to an older timeframe allowed new SIDs creation - disaster recovery, by any measure. Starting in Windows Server 2012, the 231 bit can be unlocked in order to increase the global pool to 2,147,483,647 RIDs.
AD DS stores this setting in a special hidden attribute named SidCompatibilityVersion on the RootDSE context of all domain controllers. This attribute is not readable using ADSIEdit, LDP, or other tools. To see an increase in the global RID space, examine the System event log for warning event 16655 from Directory-Services-SAM or use the following Dcdiag command:
Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"
If you increase the global RID pool, the available pool will change to 2,147,483,647 instead of the default 1,073,741,823. For example:
Warning!
This unlock is intended only to prevent running out of RIDS and is to be used only in conjunction with RID Ceiling Enforcement (see next section). Do not "preemptively" set this in environments that have millions of remaining RIDs and low growth, as application compatibility issues potentially exist with SIDs generated from the unlocked RID pool.
This unlock operation cannot be reverted or removed, except by a complete forest recovery to an earlier backup.
Windows Server 2003 and Windows Server 2008 Domain Controllers cannot issue RIDs when the global RID pool 31st bit is unlocked. Windows Server 2008 R2 domain controllers can use 31st bit RIDs but only if they install hotfix KB2642658. Unsupported and unpatched domain controllers treat the global RID pool as exhausted when unlocked.
To unlock the RID pool to the 31st bit after receiving the RID ceiling alert perform the following steps:
1. Ensure that the RID Master role is running on a Windows Server 2012 domain controller. If not, transfer it to a Windows Server 2012 domain controller
2. Run LDP.exe
3. Click the Connection menu and click Connect for the Windows Server 2012 RID Master on port 389, and then click Bind as a domain administrator
4. Click the Browse menu and click Modify
5. Ensure that DN is blank
6. In Edit Entry Attribute, type:
SidCompatibilityVersion
7. In Values, type:
1
8. Ensure that Add is selected in Operation and click Enter. This updates the Entry List
9. Select the Synchronous option, then click Run:
10. If successful, the LDP output window shows:
***Call Modify...
ldap_modify_ext_s(Id, '(null)',[1] attrs, SvrCtrls, ClntCtrls);
modified "".
11. Confirm the global RID pool increased by examining the System Event Log on that domain controller for Directory-Services-SAM Informational event 16655.
To afford a measure of protection and elevate administrative awareness, Windows Server 2012 introduces an artificial ceiling on the global RID range at ten (10) percent remaining RIDs in the global space. When within one (1) percent of the artificial ceiling, domain controllers requesting RID pools write Directory-Services-SAM warning event 16657 to their System event log. When reaching the ten percent ceiling on the RID Master FSMO, it writes Directory-Services-SAM event 16657 to its System event log and will not allocate any further RID pools until overriding the ceiling. This forces you to assess the state of the RID Master in the domain and address potential runaway RID allocation; this also protects domains from exhausting the entire RID space.
This ceiling is hard-coded at ten percent remaining of the available RID space. I.e. the ceiling activates when the RID master allocates a pool that includes the RID corresponding to ninety (90) percent of the global RID space.
You can hit this event twice in the lifetime of a domain - once with a default-sized RID pool and once when you unlock. Preferably never, of course.
When triggered, the RID Master sets AD attribute msDS-RIDPoolAllocationEnabled (common name ms-DS-RID-Pool-Allocation-Enabled) to FALSE on the object:
CN=RID Manager$,CN=System,DC=<domain>
This writes the 16657 event and prevents further RID block issuance to all domain controllers. Domain controllers continue to consume any outstanding RID pools already issued to them.
To remove the block and allow RID pool allocation to continue, set that value to TRUE. On the next RID allocation performed by the RID Master, the attribute will return to its default NOT SET value. After that, there are no further ceilings and eventually, the global RID space runs out, requiring forest recovery or domain migration.
Important
Do not just arbitrarily remove the ceiling once hit - after all, something weird and potentially bad has happened here and your RID Master is trying to tell you. Stop and take stock, find out what caused the increase, and don’t proceed until you are darned sure that you are not going to run out immediately due to some sort of run-away process or procedure in your environment.
To remove the block once reaching the artificial ceiling, perform the following steps:
1. Ensure that the RID Master role is running on a Windows Server 2012 domain controller. If not, transfer it to a Windows Server 2012 domain controller
2. Run LDP.exe
3. Click the Connection menu and click Connect for the Windows Server 2012 RID Master on port 389, and then click Bind as a domain administrator
4. Click the View menu and click Tree, then for the Base DN select the RID Master's own domain naming context. Click Ok
5. In the navigation pane, drill down into the CN=System container and click the CN=RID Manager$ object. Right click it and click Modify
6. In Edit Entry Attribute, type:
MsDS-RidPoolAllocationEnabled
7. In Values, type (in upper case):
TRUE
8. Select Replace in Operation and click Enter. This updates the Entry List.
9. Enable the Synchronous option, then click Run:
10. If successful, the LDP output window shows:
***Call Modify...
ldap_modify_ext_s(ld, 'CN=RID Manager$,CN=System,DC=<domain>',[1] attrs, SvrCtrls, ClntCtrls);
Modified "CN=RID Manager$,CN=System,DC=<domain>".
The following new messages log in the System event log on Windows Server 2012 domain controllers. Automated AD health tracking systems, such as System Center Operations Manager, should monitor for these events; all are notable, and some are indicators of critical domain issues.
| Event ID | 16653 |
| Source | Directory-Services-SAM |
| Severity | Warning |
| Message | A pool size for account-identifiers (RIDs) that was configured by an Administrator is greater than the supported maximum. The maximum value of 15,000 will be used when the domain controller is the RID master. See http://go.microsoft.com/fwlink/?LinkId=225963 for more information. |
Notes and resolution
The maximum value for the RID Block Size is now 15000 decimal (3A98 hexadecimal). A domain controller cannot request more than 15,000 RIDs. This event logs at every boot until the value is set to a value at or below this maximum.
| Event ID | 16654 |
| Source | Directory-Services-SAM |
| Severity | Informational |
| Message | A pool of account-identifiers (RIDs) has been invalidated. This may occur in the following expected cases: 1. A domain controller is restored from backup. 2. A domain controller running on a virtual machine is restored from snapshot. 3. An administrator has manually invalidated the pool. See http://go.microsoft.com/fwlink/?LinkId=226247 for more information. |
Notes and resolution
If this event is unexpected, contact all domain administrators and determine which of them performed the action. The Directory Services event log also contains further information on when one of these steps was performed.
| Event ID | 16655 |
| Source | Directory-Services-SAM |
| Severity | Informational |
| Message | The global maximum for account-identifiers (RIDs) has been increased to %1. See http://go.microsoft.com/fwlink/?LinkId=233329 for more information including important operating system interoperability requirements. |
Notes and resolution
If this event is unexpected, contact all domain administrators and determine which of them performed the action. This event notes the increase of the overall RID pool size beyond the default of 230 and will not happen automatically; only by administrative action.
| Event ID | 16656 |
| Source | Directory-Services-SAM |
| Severity | Warning |
| Message | Action required! An account-identifier (RID) pool was allocated to this domain controller. The pool value indicates this domain has consumed a considerable portion of the total available account-identifiers. A protection mechanism will be activated when the domain reaches the following threshold of total available account-identifiers remaining: %1. The protection mechanism prevents the allocation of account-identifier (RID) pools needed to allow existing DCs to create additional users, computers and groups, or promote new DCs into the domain. The mechanism will remain active until the Administrator manually re-enables account-identifier allocation on the RID master domain controller. See http://go.microsoft.com/fwlink/?LinkId=228610 for more information. |
Notes and resolution
Contact all domain administrators and inform them that the domain is close to preventing any further principal creation. Interrogate all administrators to find out who or what is creating principals lately and examine the Diagnosis section here for more inventory steps.
| Event ID | 16657 |
| Source | Directory-Services-SAM |
| Severity | Error |
| Message | Action required! This domain has consumed a considerable portion of the total available account-identifiers (RIDs). A protection mechanism has been activated because the total available account-identifiers remaining is approximately: %1. The protection mechanism prevents the allocation of account-identifier (RID) pools needed to allow existing DCs to create additional users, computers and groups, or promote new DCs into the domain. The mechanism will remain active until the Administrator manually re-enables account-identifier (RID) allocation on the RID master domain controller. It is extremely important that certain diagnostics be performed prior to re-enabling account creation to ensure this domain is not consuming account-identifiers at an abnormally high rate. Any issues identified should be resolved prior to re-enabling account creation. Failure to diagnose and fix any underlying issue causing an abnormally high rate of account-identifier consumption can lead to account-identifier (RID) pool exhaustion in the domain after which account creation will be permanently disabled in this domain. See http://go.microsoft.com/fwlink/?LinkId=228610 for more information |
Notes and resolution
Contact all domain administrators and inform them that no further security principals can be created in this domain until this protection is overridden. Interrogate all administrators to find out who or what is creating principals lately and examine the Diagnosis section here for more inventory steps. Use the steps above to unlock the 31st RID bit only after you have determined that any runaway issuance is not going to continue.
| Event ID | 16658 |
| Source | Directory-Services-SAM |
| Severity | Warning |
| Message | This event is a periodic update on the remaining total quantity of available account-identifiers (RIDs). The number of remaining account-identifiers is approximately: %1. Account-identifiers are used as accounts are created, when they are exhausted no new accounts may be created in the domain. See http://go.microsoft.com/fwlink/?LinkId=228745 for more information |
Notes and resolution
Contact all domain administrators and inform them that RID consumption has crossed a major milestone; determine if this is expected behavior or not by reviewing security trustee creation patterns. To ever see this event would be highly unusual, as it means that at least ~100 million RIDS have been allocated.
These are just some of the excellent supportability changes available in Windows Server 2012 AD DS. For more info, check out the TechNet library starting at:
http://technet.microsoft.com/en-us/library/hh831484
I hope to have more of these kinds of posts coming along soon, as the gloves were taken off this week for Windows Server 2012. You know me though – something shiny goes by and I vanish for weeks. We’ll see…
Ned “The Chronicles of RID” Pyle
Hello everyone. Jonathan here again with another Public Service Announcement post.
Today, Microsoft has published a new Security Advisory:
Microsoft Security Advisory (2661254): Update For Minimum Certificate Key Length
The Security Advisory and the accompanying KB article have complete information about the software update, but the key takeaway is that this update is now available on the Download Center and the Microsoft Update Catalog. In addition, Microsoft will release this software update through Microsoft Update (aka Windows Update) in October 2012. So all of you enterprise customers have two months to start testing this update to see what impact it has in your environments.
If you want information on finding weak keys in your environment then review the KB article. It describes several methods you can use. Microsoft Support has also created a PowerShell script that has been posted to the the TechNet Script Center.
Finally, I have one final warning for those of you that use makecert.exe to create test certificates. By default, makecert.exe creates certificates that chains up to the Root Agency root CA certificate located in the Intermediate Certification Authorities store. The Root Agency CA certificate has a public key of 512 bits, so once you deploy this update no certificate created with makecert.exe will be considered valid.
You should now consider makecert.exe deprecated. As a replacement, starting with Windows 7 / Windows Server 2008 R2, you can use certreq.exe to create a self-signed certificate. For example, to create a self-signed code signing certificate you can create the following .INF file:
[NewRequest]
Subject = "CN=Self Signed Cert"
KeyLength = 2048
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
KeySpec = "AT_SIGNATURE"
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE"
RequestType = Cert
SMIME = False
ValidityPeriod = Years
ValidityPeriodUnits = 2
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.3
The important line above is the RequestType value. That tells certreq.exe to create a self-signed certificate. Along with that value, the ValidityPeriod and ValidityPeriodUnits values allow you specify the lifetime of the self-signed certificate.
Once you create the .INF file, run the following command:
Certreq -new selfsigned.inf selfsigned.crt
This will take your .INF file and generate a new self-signed certificate that you can use for testing.
Ok, so this was supposed to be a short post pointing to where you need to go, but it turns out that I had some other related stuff. The important message here is go read the Security Advisory and the KB article.
Go read the Security Advisory and the KB article.
Ex pace.
Jonathan “I am the Key Master” Stephens
Hey all, Ned here again with a quick advert:
Robert Deluca from our Partner and Customer team just published a blog post on Dynamic Access Control. He walks through the configuration of “document quarantine” to protect sensitive data on file shares and automatically clean up files that violate storage policies. We’ve seen a lot of DAC blog posts over the past couple of months but this one talks about a real-world scenario Robert encountered with some of our early Beta customers.
Document Quarantine with Windows Server 2012 Dynamic Access Control
Definitely take a look at this one!
- Ned "CDC" Pyle
Hey all, Ned here with some new troubleshooting tool love, courtesy of the ADREPLSTATUS team at Microsoft. I’ll let them do the talking:
The Active Directory Replication Status Tool (ADREPLSTATUS) is now LIVE and available for download at the Microsoft Download Center.
ADREPLSTATUS helps administrators identify, prioritize and resolve Active Directory replication errors on a single DC or all DCs in an Active Directory Domain or Forest. Cool features include:
ADREPLSTATUs UI consists of a toolbar and Office-style ribbon to expose different features. The Replication Status Viewer tab displays the replication status for all DCs in the forest. The screenshot below shows ADREPLSTATUS highlighting a DC that has not replicated in Tombstone Lifetime number of days (identified here by the black color-coding)
Click me
Using the Errors Only button, you can filter out healthy DCs to focus on destination DCs reporting replication errors.
Click me
The Replication Error Guide has a Detected Errors Summary view that records each unique replication error occurring on the set of DCs targeted by the administrator.
Click me
Close up of the Detected Errors Summary view.
Click me
Selecting any of the replication error codes loads the recommended troubleshooting content for that replication error. The TechNet Article for AD Replication Error 1256 is shown below.
Click me
The goals for this tool are to help administrators identify and resolve Active Directory replication errors before they cause user and application failures, outages or lingering objects caused short and long-term replication failures, and to provide administrators greater insight into the operation of Active Directory replication within their environments.
The current version of ADREPLSTATUS as of this posting is 2.2.20717.1 (as reported by ADREPLSTATUS startup splash screen).
Known Issues
| Symptoms | Status |
| ADREPLSTATUS fails to launch on highly secure computers.
| ADREPLSTATUS will not work when the following security setting is enabled on the operating system: |
| Extra checkmark appears at bottom of column chooser when right clicking on a column header
| Known issue and by design. |
Support
http://social.technet.microsoft.com/forums/en-US/winserverDS/threads/
Until next time,
Ned “repple depple” Pyle
Heya folks, Ned here again. Rather than continue the lie that this series comes out every Friday like it once did, I am taking the corporate approach and rebranding the mail sack. Maybe we’ll have the occasional Collector’s Edition versions.
This week month, I answer your questions on:
Let’s incentivize our value props!
Everywhere I look, I find documentation saying that when Kerberos skew exceeds five minutes in a Windows forest, the sky falls and the four horsemen arrive.
I recall years ago at a Microsoft summit when I brought that time skew issue up and the developer I was speaking to said no, that isn't the case anymore, you can log on fine. I recently re-tested that and sure enough, no amount of skew on my member machine against a DC prevents me from authenticating.
Looking at the network trace I see the KRB_APP_ERR_SKEW response for the AS REQ which is followed by breaking down of the kerb connection which is immediately followed by reestablishing the kerb connection again and another AS REQ that works just fine and is responded to with a proper AS REP.
My first question is.... Am I missing something?
My second question is... While I realize that third party Kerb clients may or may not have this functionality, are there instances where it doesn't work within Windows Kerb clients? Or could it affect other scenarios like AD replication?
Nope, you’re not missing anything. If I try to logon from my highly-skewed Windows client and apply group policy, the network traffic will look approximately like:
| Frame | Source | Destination | Packet Data Summary |
| 1 | Client | DC | AS Request Cname: client$ Realm: CONTOSO.COM Sname: |
| 2 | DC | Client | KRB_ERROR - KRB_AP_ERR_SKEW (37) |
| 3 | Client | DC | AS Request Cname: client$ Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM |
| 4 | DC | Client | AS Response Ticket[Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM] |
| 5 | Client | DC | TGS Request Realm: CONTOSO.COM Sname: cifs/DC.CONTOSO.COM |
| 6 | DC | Client | KRB_ERROR - KRB_AP_ERR_SKEW (37) |
| 7 | Client | DC | TGS Request Realm: CONTOSO.COM Sname: cifs/DC.CONTOSO.COM |
| 8 | DC | Client | TGS Response Cname: client$ |
When your client sends a time stamp that is outside the range of Maximum tolerance for computer clock synchronization, the DC comes back with that KRB_APP_ERR_SKEW error – but it also contains an encrypted copy of his own time stamp. The client uses that to create a valid time stamp to send back. This doesn’t decrease security in the design because we are still using encryption and requiring knowledge of the secrets, plus there is still only – by default – 5 minutes for an attacker to break the encryption and start impersonating the principal or attempt replay attacks. Which is not feasible with even XP’s 11 year old cipher suites, much less Windows 8’s.
This isn’t some Microsoft wackiness either – RFC 4430 states:
If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW. The optional client's time in the KRB-ERROR SHOULD be filled out.
If the server protects the error by adding the Cksum field and returning the correct client's time, the client SHOULD compute the difference (in seconds) between the two clocks based upon the client and server time contained in the KRB-ERROR message.
The client SHOULD store this clock difference and use it to adjust its clock in subsequent messages. If the error is not protected, the client MUST NOT use the difference to adjust subsequent messages, because doing so would allow an attacker to construct authenticators that can be used to mount replay attacks.
Hmmm… SHOULD. Here’s where things get more muddy and I address your second question. No one actually has to honor this skew correction:
With that RFC’s indecisiveness and the other caveats, we beat the “just make sure it’s no more than 5 minutes” drum in all of our docs and here on AskDS. It’s too much trouble to get into what-ifs.
We have a KB tucked away on this here but it is nearly un-findable.
Awesome question.
I’ve found articles on using Windows PowerShell to locate all domain controllers in a domain, and even all GCs in a forest, but I can’t find one to return all DCs in a forest. Get-AdDomainController seems to be limited to a single domain. Is this possible?
It’s trickier than you might think. I can think of two ways to do this; perhaps commenters will have others. The first is to get the domains in the forest, then find one domain controller in each domain and ask it to list all the domain controllers in its own domain. This gets around the limitation of Get-AdDomainController for a single domain (single line wrapped).
(get-adforest).domains | foreach {Get-ADDomainController -discover -DomainName $_} | foreach {Get-addomaincontroller -filter * -server $_} | ft hostname
The second is to go directly to the the native .NET AD DS forest class to return the domains for the forest, then loop through each one returning the domain controllers (single lined wrapped).
[system.directoryservices.activedirectory.Forest]::GetCurrentForest().domains | foreach {$_.DomainControllers} | foreach {$_.hostname}
This also lead to updated TechNet content. Good work, Internet!
Hi, I've been reading up on RID issuance management and the new RID Master changes in Windows Server 2012. They still leave me with a question, however: why are RIDs even needed in a SID? Can't the SID be incremented on it's own? The domain identifier seems to be an adequately large number, larger than the 30-bit RID anyway. I know there's a good reason for it, but I just can't find any material that says why there are separate domain ID and relative ID in a SID.
The main reason was a SID needs the domain identifier portion to have a contextual meaning. By using the same domain identifier on all security principals from that domain, we can quickly and easily identify SIDs issued from one domain or another within a forest. This is useful for a variety of security reasons under the hood.
That also allows us a useful technique called “SID compression”, where we want to save space in a user’s security data in memory. For example, let’s say I am a member of five domain security groups:
DOMAINSID-RID1
DOMAINSID-RID2
DOMAINSID-RID3
DOMAINSID-RID4
DOMAINSID-RID5
With a constant domain identifier portion on all five, I now have the option to use one domain SID portion on all the other associated ones, without using all the memory up with duplicate data:
DOMAINSID-RID1
“-RID2
“-RID3
“-RID4
“-RID5
The consistent domain portion also fixes a big problem: if all of the SIDs held no special domain context, keeping track of where they were issued from would be a much bigger task. We’d need some sort of big master database (“The SID Master”?) in an environment that understood all forests and domains and local computers and everything. Otherwise we’d have a higher chance of duplication through differing parts of a company. Since the domain portion of the SID unique and the RID portion is an unsigned integer that only climbs, it’s pretty easy for RID masters to take care of that case in each domain.
You can read more about this in coma-inducing detail here: http://technet.microsoft.com/en-us/library/cc778824.aspx.
When I want to set folder and application redirection for our user in different forest (with a forest trust) in our Remote Desktop Services server farm, I cannot find users or groups from other domain. Is there a workaround?
The Object Picker in this case doesn’t allow you to select objects from the other forest – this is a limitation of the UI the that Folder Redirection folks put in place. They write their own FR GP management tools, not the GP team.
Windows, by default, does not process group policy from user logon across a forest—it automatically uses loopback Replace. Therefore, you can configure a Folder Redirection policy in the resource domain for users and link that policy to the OU in the domain where the Terminal Servers reside. Only users from a different forest should receive the folder redirection policy, which you can then base on a group in the local forest.
Does USMT support migrating multi-monitor settings from Windows XP computers, such as which one is primary, the resolutions, etc.?
USMT 4.0 does not supported migrating any monitor settings from any OS to any OS (screen resolution, monitor layout, multi-monitor, etc.). Migrating hardware settings and drivers from one computer to another is dangerous, so USMT does not attempt it. I strongly discourage you from trying to make this work through custom XML for the same reason – you may end up with unusable machines.
Starting in USMT 5.0, a new replacement manifest – Windows 7 to Windows 7, Windows 7 to Windows 8, or Windows 8 to Windows 8 only – named “DisplayConfigSettings_Win7Update.man” was added. For the first time in USMT, it migrates:
<pattern type="Registry">HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Connectivity\* [*]</pattern>
<pattern type="Registry">HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Configuration\* [*]</pattern>
This is OK on Win7 and Win8 because the OS itself knows what valid and invalid are in that context and discards/fixes things as necessary. I.e. this is safe is only because USMT doesn’t actually do anything but copy some values and relies on the OS to fix things after migration is over.
Our proprietary application is having memory pressure issues and it manifests when someone runs gpupdate or waits for GP to refresh; some times it’s bad enough to cause a crash. I was curious if there was a way to stop the policy refresh from occurring.
Only in Vista and later does preventing total refresh become possible vaguely possible; you could prevent the group policy service from running at all (no, I am not going to explain how). The internet is filled with thousands of people repeating a myth that preventing GP refresh is possible with an imaginary registry value on Win2003/XP – it isn’t.
What you could do here is prevent background refresh altogether. See the policies in the “administrative templates\system\group policy” section of GP:
1. You could enable policy “group policy refresh interval for computers” and apply it to that one server. You could set the background refresh interval to 45 days (the max). That way it be far more likely to reboot in the meantime for a patch Tuesday or whatever and never have a chance to refresh automatically.
2. You could also enable each of the group policy extension policies (ex: “disk quota policy processing”, “registry policy processing”) and set the “do not apply during periodic background processing” option on each one. This may not actually prevent GPUPDATE /FORCE though – each CSE may decide to ignore your background refresh setting; you will have to test, as this sounds boring.
Keep in mind for #1 that there are two of those background refresh policies – one per user (“group policy refresh interval for users”), one per computer (“group policy refresh interval for computers”). They both operate in terms of each boot up or each interactive logon, on a per computer/per user basis respectively. I.e. if you logon as a user, you apply your policy. Policy will not refresh for 45 days for that user if you were to stay logged on that whole time. If you log off at 22 days and log back on, you get apply policy, because that is not a refresh – it’s interactive logon foreground policy application.
Ditto for computers, only replace “logon” with “boot up”. So it will apply the policy at every boot up, but since your computers reboot daily, never again until the next bootup.
After those thoughts… get a better server or a better app. :)
I’m testing Virtualized Domain Controller cloning in Windows Server 2012 on Hyper-V and I have DCs with snapshots. Bad bad bad, I know, but we have our reasons and we at least know that we need to delete them when cloning.
Is there a way to keep the snapshots on the source computer, but not use VM exports? I.e. I just want the new copied VM to not have the old source machine’s snapshots.
Yes, through the new Hyper-V disk management Windows PowerShell cmdlets or through the management snap-in.
1. Examine the settings of your VM and determine which disk is the active one. When using snapshots, it will be an AVHD/X file.
2. Inspect that disk and you see the parent as well.
3. Now use the Edit Disk… option in the Hyper-V manager to select that AVHD/X file:
4. Merge the disk to a new copy:
Much simpler, although slightly counter-intuitive. Just use:
Convert-vhd
For example, to export the entire chain of a VM's disk snapshots and parent disk into a new single disk with no snapshots named DC4-CLONED.VHDX:
![image]( "image")
Violin!
You don’t actually have to convert the disk type in this scenario (note how I went from dynamic to dynamic). There is also Merge-VHD for more complex differencing disk and snapshot scenarios, but it requires some extra finagling and disk copying, and isn’t usually necessary. The graphical merge option works well there too.
As a side note, the original Understand And Troubleshoot VDC guide now redirects to TechNet. Coming soon(ish) is an RTM-updated version of the original guide, in web format, with new architecture, troubleshooting, and other info. I robbed part of my answer above from it – as you can tell by the higher quality screenshots than you usually see on AskDS – and I’ll be sure to announce it. Hard.
It has always been my opinion that if a DC with a FSMO role went down, the best approach is to seize the role on another DC, rebuild the failed DC from scratch, then transfer the role back. It’s also been my opinion that as long as you have more than one DC, and there has not been any data loss, or corruption, it is better to not restore.
What is the Microsoft take on this?
This is one of those “it depends” scenarios:
1. The downside to restoring from (usually proprietary) backup solutions is that the restore process just isn’t something most customers test and work out the kinks on until it actually happens; tons of time is spent digging out the right tapes, find the right software, looking up the restore process, contacting that vendor, etc. Often times a restore doesn’t work at all, so all the attempts are just wasted effort. I freely admit that my judgment is tainted through my MS Support experience here – customers do not call us to say how great their backups worked, only that they have a down DC and they can’t get their backups to restore.
The upside is if your recent backup contained local changes that had never replicated outbound due to latency, restoring them (even non-auth) still means that those changes will have a chance to replicate out. E.g. if someone changed their password or some group was created on that server and captured by the backup, you are not losing any changes. It also includes all the other things that you might not have been aware of – such as custom DFS configurations, operating as a DNS server that a bunch of machines were solely pointed to, 3rd party applications pointed directly to the DC by IP/Name for LDAP or PDC or whatever (looking at you, Open Source software!), etc. You don’t have to be as “aware”, per se.
2. The downside to seizing the FSMO roles and cutting your losses is the converse of my previous point around latent changes; those objects and attributes that could not replicate out but were caught by the backup are gone forever. You also might miss some of those one-offs where someone was specifically targeting that server – but you will hear from them, don’t worry; it won’t be too hard to put things back.
The upside is you get back in business much faster in most cases; I can usually rebuild a Win2008 R2 server and make it a DC before you even find the guy that has the combo to the backup tape vault. You also don’t get the interruptions in service for Windows from missing FSMO roles, such as DCs that were low on their RID pool and now cannot retrieve more (this only matters with default, obviously; some customers raise their pool sizes to combat this effect). It’s typically a more reliable approach too – after all, your backup may contain the same time bomb of settings or corruption or whatever that made your DC go offline in the first place. Moreover, the backup is unlikely to contain the most recent changes regardless – backups usually run overnight, so any un-replicated originating updates made during the day are going to be nuked in both cases.
For all these reasons, we in MS Support generally recommend a rebuild rather than a restore, all things being equal. Ideally, you fix the actual server and do neither!
As a side note, restoring the RID master used to cause issues that we first fixed in Win2000 SP3. This unfortunately has live on as a myth that you cannot safely restore the RID master. Nevertheless, if someone impatiently seizes that role, then someone else restores that backup, you get a new problem where you cannot issue RIDs anymore. Your DC will also refuse to claim role ownership with a restored RID Master (or any FSMO role) if your restored server has an AD replication problem that prevents at least one good replication with a partner. Keep those in mind for planning no matter how the argument turns out!
I am trying out Windows Server 2012 and its new Minimal Server Interface. Is there a way to use WMI to determine if a server is running with a Full Installation, Core Installation, or a Minimal Shell installation?
Indeed, although it’s not made it way to MSDN quite yet. The Win32_ServerFeature class returns a few new properties in our latest operating system. You can use WMIC or Windows PowerShell to browse the installed ones. For example:
The “99” ID is Server Graphical Shell, which means, in practical terms, “Full Installation”. If 99 alone is not present, that means it’s a minshell server. If the “478” ID is also missing, it’s a Core server.
E.g. if you wanted to apply some group policy that only applied to MinShell servers, you’d set your query to return true if 99 was not present but 478 was present.
Speaking of which, Windows Server 2012 General Availability is September 4th. If you manage to miss the run up, you might want to visit an optometrist and/or social media consultant.
Stop worrying so much about the end of the world and think it through.
So awesome:
And so fake :(
If you are married to a psychotic Solitaire player who poo-poo’ed switching totally to the Windows 8 Consumer Preview because they could not get their mainline fix of card games, we have you covered now in Windows 8 RTM. Just run the Store app and swipe for the Charms Bar, then search for Solitaire.
It’s free and exactly 17 times better than the old in-box version:
![image]( "image")
OMG Lisa, stop yelling at me!
Is this the greatest geek advert of all time?
Yes. Yes it is.
When people ask me why I stopped listening to Metallica after the Black Album, this is how I reply:
![Hetfield in Milan]( "Hetfield in Milan")
Ride the lightning Mercedes
We have quite a few fresh, youthful faces here in MS Support these days and someone asked me what “Mall Hair” was when I mentioned it. If you graduated high school between 1984 and 1994 in the Midwestern United States, you already know.
Finally – I am heading to Sydney in late September to yammer in-depth about Windows Server 2012 and Windows 8. Anyone have any good ideas for things to do? So far I’ve heard “bridge climb”, which is apparently the way Australians trick idiot tourists into paying for death. They probably follow it up with “funnel-web spider petting zoo” and “swim with the saltwater crocodiles”. Lunatics.
Until next time,
- Ned “I bet James Hetfield knows where I can get a tropical drink by the pool” Pyle
![clip_image002[6]](http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-58-02-metablogapi/3660.clip_5F00_image0026_5F00_thumb_5F00_014568D1.jpg "clip_image002[6]")
