Ask Premier Field Engineering (PFE) Platforms

Fire & Forget – How to Stop a Network Trace Programmatically using Network Monitor

Doug Symalla — Mon, 20 May 2013 06:00:00 GMT

From time to time, we come across issues where capturing a network trace is critical to determining root cause for a problem and even more important… a solution. Simple right? Just start Network Monitor or WireShark and reproduce the problem. Things can’t get much easier than that!

The reality is that sometimes it’s just not that simple. It’s not uncommon to hit an issue where unexpected failures occur at random, unpredictable times. This poses a real challenge when it comes to collecting the right data at the right time.

There’s good news! If the problem happens to log something to the Event Log, things just got a whole lot easier for us. Beginning in Windows Vista/Server 2008, the Event Viewer now includes functionality that allows us to “attach a task” to any event. This comes in super-handy when capturing an open-ended network trace because we can now programmatically stop the network trace when a specific Event is logged in any of the Event Logs.

The setup to programmatically stop a network trace consists of a two-part process that utilizes the following components:

- Network Monitor

- Event Viewer

- Task Scheduler

The two-part process looks like this:

Part A: Performed by Network Monitor

- Capture network data and watch for a specific “pattern” on the network

- Stop the network trace when the “pattern” is detected

Part B: Performed by Event Viewer & Task Scheduler

- Watch the Event Logs for a specific Event ID

- When the Event ID is logged, “do something” that will generate the “pattern” that Network Monitor is waiting for to stop tracing.

In this example, the “do something” will be to query for non-existent host name “stopthetrace”.

Now that we have an idea of what we need to do… let’s get started.

We’ll need to setup the following 3 items in order to get this going:

1. Start the network capture with appropriate triggers to stop the trace automatically

2. Create a batch file that will query DNS for “stopthetrace”

3. Configure a “task” in Event Viewer that will execute the batch file when a specific Event ID is logged.

STEP 1: DOWNLOAD & INSTALL NETWORK MONITOR

This is simple. Just make sure to right-click the installer and “run as administrator”

This ensures that the Network Monitor driver successfully binds to all network interfaces.

Network Monitor 3.4

http://www.microsoft.com/en-us/download/details.aspx?id=4865

STEP 2: CREATE A BATCH FILE THAT WILL GENERATE A DNS QUERY FOR “STOPTHETRACE”

In order to verify that we configured the appropriate filter in the NMCAP command (we’ll do this in step 4, below), we can simply run “Nslookup StopTheTrace” from a command prompt while running a network trace. Once we’ve captured the DNS name resolution for “stopthetrace”, we can simply expand all of the DNS header in the Frame Details and right-click on the “QuestionName” field and select “Add Selected Value to Display Filter”. This results in the following filter:

DNS.QRecord.QuestionName == “stopthetrace.CORP.CONTOSO.MSFT” (Note that the primary DNS suffix is automatically appended to the name)

Now that we have the filter syntax, we have 2 options here:

A. We can use the filter “as is” if we specify the Fully Qualified Domain Name (FQDN) in the DNS query

DNS.QRecord.QuestionName == “stopthetrace.CORP.CONTOSO.MSFT”

B. We can use the Contains() function built in to Network Monitor to look for any DNS query “containing” string matching “StopTheTrace”

DNS.QRecord.QuestionName.Contains(‘stopthetrace’)

For the purposes of this example, we’ll create a batch file in C:\Scripts and name it STOPTHETRACE.BAT

The batch file will simply contain the following command:

NSLookup stopthetrace

STEP 3: ATTACH A TASK TO A SPECIFIC EVENT ID

Next, we’ll attach a task to a specific event that can be logged in any one of the Event Logs (e.g. System, Application, Security, etc.)

In this example, we want to capture network data until Event ID 5719 is logged in the System Event log.

With Event ID 5719 highlighted, select “Attach a Task to this Log”

In the task wizard, we’ll specify a name and description for the task that we’re creating… click “Next”

The next dialog will default to the appropriate required settings. We’ll keep the defaults here… click “Next”

On the Action dialog, we’ll select “Start a program”… click “Next”

We’ll specify the location of the batch file that we created on the “Start a Program” window… click “Next”

On the Summary window, select the option “Open the Properties dialog for this task when I click Finish”… click “Finish”

Notice that the wizard simply creates a Scheduled Task.

The properties dialog for the task looks just like any other Scheduled Task property window.

In this example, we’ve specified that the batch file should run as SYSTEM… click “OK” to close.

By default, the Event Viewer task will automatically stop after 3 days and will not execute additional instances.

These options are configurable. We can simply uncheck the “auto stop” option to run the task indefinitely if needed.

Note: We should now see a new task under “Event Viewer Tasks” within Task Scheduler

Check out Michael Hildebrand’s “PFE Troubleshooting Series” blog which outlines more Event Log goodies.

PFE Troubleshooting Series

http://blogs.technet.com/b/askpfeplat/archive/2012/01/02/pfe-troubleshooting-series-second-post-and-happy-new-year.aspx

STEP 4: START THE NETWORK CAPTURE USING NMCAP.EXE

NMCAP.exe is simply the command-line version of NetMon. In this example, we’re going to start a network trace using a circular buffer of 50 Mb. The data collected will be saved to a file named NetworkCapture1.cap on the root of the C:\ drive. The capture will continue to run until the specified pattern match is detected.

nmcap /Network * /Capture /File c:\NetworkCapture1.cap:50M /StopWhen /Frame dns.qrecord.questionname.Contains(‘stopthetrace’)

Note: Make sure to use single quotes when specifying a string in the Contains() function.

Run “nmcap /?” to get more detail related to each switch used here.

In order to be able to configure NMCAP.EXE to continue running after we log off, we’ll need to run it as a Scheduled Task.

We’ll create a batch file named NETTRACE.BAT that contains the NMCAP syntax that we’ve come up with.

Note: Unless we create the batch file in the same location as NMCAP.EXE, we’ll need to specify the full path to NMCAP.EXE.

Next, create a basic Scheduled Task that runs NETTRACE.BAT

Configure the task to run as SYSTEM

Right-click the task and select “Run”

Since the trace is running under the SYSTEM context, we won’t see it interactively on our desktop.

We can use Task Manager to verify that NMCAP.EXE is running.

To verify that the trace will actually stop when the batch file is executed, we can manually run the batch file named STOPTHETRACE.BAT.

We’ll need to confirm that we no longer see NMCAP.EXE running in Task Manager and that a network trace file was successfully created.

At this point, simply start NMCAP.EXE again using the Task Scheduler, log off… and go have dinner!

Victor Zapata

Update Rollups For Windows Server 2012 and Windows 8 Explained

Mark Morowczynski [MSFT] — Mon, 13 May 2013 09:00:00 GMT

Hello all,

If you pay attention to the updates we rollout each month or take note of what Windows Updates are on your Windows 8 PC or Windows Server 2012 Server, you may have seen some monthly rollup updates. Below are the rollups from the first one when we released Windows 8 up to April 2013:

(Note that we recently renamed the updates from Cumulative Update to Update Rollup which we feel better describes them).

· Windows 8 and Windows Server 2012 Update Rollup: April 2013 – KB2822241

· Windows 8 and Windows Server 2012 Update Rollup: March 2013 – KB2811660

· Windows 8 and Windows Server 2012 Update Rollup: February 2013 – KB2795944

· Windows 8 and Windows Server 2012 Update Rollup: January 2013 – KB2785094

· Windows 8 and Windows Server 2012 Update Rollup: December 2012 – KB2779768

· Windows 8 and Windows Server 2012 Update Rollup: November 2012 – KB2770917

· Windows 8 Client and Windows Server 2012 General Availability Update Rollup – KB2756872

This post will discuss the intended purpose of these rollups, where they come from, and the intended audience. Note that the way we package updates may change as our products evolve so this information is relevant only to Windows 8 and Windows Server 2012.

So to start, these update rollups are not cumulative updates. You do need to apply each of the monthly update rollups to get the fixes and enhancements from each month. Installing the February 2013 Update Rollup does not get you the January 2013 to October 2012 rollup updates. This is to say, these rollups are independent of each other. Searching on the KB number (or just use the above links for existing updates) will discuss what each rollup is addressing that month. Note that these updates do not focus on a particular component as we have seen with previous cumulative or rollup type updates but are broader to Windows.

There are several mechanisms used to decide which fixes are put into these updates including feedback from Premier Customers, Original Equipment Manufacturers (OEM), Independent Hardware Vendors (IHV), Independent Software Vendors (ISV), telemetry from Windows Error Reporting (WER), forums, blogs and internal Microsoft organizations. Based on this data, we then make the decision on whether to include these fixes in the upcoming update on some of the below criteria:

· Impact to the end user. The impact needs to be rather significant. For example, does the problem being fixed result in a BugCheck, data loss, or other significant event.

· Applicability or number of systems impacted. This is where the telemetry data is important (turn on WER to make the products better). We also rely on estimate volumes from our OEMs, ISVs and IHVs.

· Confidence that the fix will not cause regressions. This confidence is based on our code analysis and extensive testing.

Note that the update rollups are not security-related and are intended to improve the overall performance and reliability of Windows. Security issues are still evaluated and deployed as discussed on the Microsoft Security Response Center site.

Most consumers will take these updates on a monthly basis without even realizing it and improve their overall experience. It is recommended that enterprises follow this same path and distribute these update rollups monthly, just as they do the Security updates from the second Tuesday of the month. It is expected that these updates can be distributed and tested using the same procedures that are used for the monthly Security updates so as to not significantly increase the burden on IT staff.

If you install updates by manually downloading updates from the Windows Update catalog or links from the related KB article, you also need to be aware that there may be prerequisite fixes that need to be installed first. This is handled automatically when using Windows Update, WSUS, Configuration Manager, etc. For example, if you go to the Microsoft Download Center and search on the March update rollup (paste in KB2811660 in the search field), you will see a several typical links for the different architecture types. Selecting any of these (note that Windows 8 x64 and Windows Server 2012 are the same) will display the chained updates. We use the word chained here because if were to install parent KB2811660 from Windows Update, it will install all of the other child updates automatically. So again, the typical home user will not only get KB2811660 installed but also KB2800088, KB2812829, KB2815769, and KB2823233 automatically. Users who do not use Windows Update will need to manually install all of the updates from the download center when searching on the parent update rollup– so for the March update, a total of five updates. Home users who use Microsoft Update and As mentioned, customers who utilize WSUS and System Center Configuration Manager with its approval process do not need worry about the parent / child relationships as they take care of that for you.

Here is an example of the March update rollup and how it appears on the Microsoft Download Center:

The end goal of these update rollups is for home and enterprise users to maintain a solid and well tested baseline of the overall Operating System (OS). Update Rollups are a way for us to accommodate the way our customers are using the product today. These update rollups allow customers to maintain an up-to-date system simpler and in a more speedy fashion than ever before.

Steve “SteveMat” Mathias

Premier Technology Day Hosted by AskPFEPlat- Live Events in St. Louis and Minneapolis on June 21, 2013

Doug Symalla — Fri, 10 May 2013 13:00:44 GMT

Hey everyone, I’d like to make you aware of an opportunity to connect with some AskPFEPlat celebrities (relatively speaking, of course). We’re hosting two, one-day workshops, live and in-person. This is a unique opportunity for you to participate in detailed, interactive discussions around some very specific Windows Server 2012 topics. These topics include some of our most popular from AskPFEPlat including domain controller cloning, storage and file services, PowerShell and Performance.

You can expect a full day of technical sessions with presentations, demonstrations and most importantly - questions and answers. Each event will be hosted by 3 Premier Field Engineers from AskPFEPlat, so you will get a broad variety of perspectives, backed by real-world experiences.

Both sessions will take place on Friday June 21, 2013. One of the events will be in Minneapolis and the other in St. Louis. The events will be hosted at the local Microsoft office.

This opportunity is only available to Microsoft Premier Support customers. If you’re in the area, and you are a Premier Support customer, be sure to contact your Technical Account Manager (TAM) who can give you more details, including pricing, and register you for the event. We expect to fill all the seats, well in advance, so don’t delay. If you have questions about Premier Support, and you don’t know where to turn, feel free to ask us. We’ll be happy to put you into contact with the right people.

We are excited about this opportunity to connect with you in person and talk shop. We hope to host similar events in other cities in the near future, so stay tuned. If you think we ought to visit your city, let us know and we’ll definitely consider it – especially if you’ve got a nice climate.

Doug Symalla

How Domain Controllers are Located Across Trusts

Tom Moser [MSFT] — Mon, 06 May 2013 06:00:00 GMT

Hi AskPFEPlat readers. Tom Moser here. A question I get on a pretty frequent basis from my larger, multi-forest enterprise customers is:

“Do I need to add subnets from Forest A to Forest B so that clients find the correct DC across the trust?”

And here’s how I try to answer that question, usually with a lot of words, a little white boarding, and a lot of pointing. I thought, “this needs pictures…” so here you go.

If you’re in a hurry to get back to /r/sysadmin, the short answer is no. If you want to know why, keep reading. Then maybe cross post this for me there.

*** Point of Clarification ***

This post is about the a scenario where the subnets in the two forests do not overlap (i.e., client’s IP address from forest A is not covered by any subnet in forest B). This would typically occur in resource forest scenarios with separate networks. For example: federating via trust with Microsoft online services or a trust between a corporate forest and a perimeter forest. Everything you’re about to read below assumes that the client IP from Forest A is not covered by any subnet in Forest B.

In cases where the two forests have conflicting subnets (for example, 10.1.1.0/24 means site “Detroit” in Forest A, but means site “Siberia” in Forest B), there are additional considerations. We will cover these in a later post.

Where’s my DC?

First, let’s talk about how your workstation, or any domain member, finds a domain controller at startup. To demo this, I configured port mirroring on my VMs in Hyper-V and intercepted the entire network conversation on another VM. For the purposes of demonstration, I’ve filtered the traffic to just DNS, LDAP, and Netlogon responses.

At startup, the first thing a domain member needs to do is authenticate. Almost. Before that, it needs to find a (hopefully local) domain controller. It does this by sending a DNS query to its primary DNS server. The query is simply looking for an LDAP server in the DNS domain of the workstation. My client queried DC01 (primary DNS) for _ldap._tcp.dc._msdcs.corp.milt0r.com (Figure 1).

Figure 1 - First DNS queries at start

The first frame shows the DNS query, and the second shows the response. In the response data, we get a list of all of the SRV records (Figure 2). Examining the frame details for the response, we can see all of the DCs with an LDAP SRV record registered in the global SRV list. This is the list of all DCs in my forest that are configured to globally register SRV records.

Figure 2 - DNS Response Frame Details

Next, the client picks one of those “ARecord” entries and queries the hostname. Here (Figure 3) it queries its DNS server for the IP address of dc04.corp.milt0r.com and receives a response of 10.2.1.11.

Figure 3 - DNS Query: Round 2

You can see that based only on that initial query for _ldap._tcp.dc._msdcs.corp.milt0r.com we’ve resolved an IP address for a DC that is (well, should be) hosting the LDAP service.

Anybody home?

Netlogon now has what it needs to contact the DC. Using the IP address it resolved, the client sends a UDP ping in the form of a UDP LDAP query to the DC (Figure 4).

Figure 4 - UDP LDAP “Ping” Conversation

DC04 responds to the LDAP “ping” in the form of a Netlogon SAM Response. If no response is received, it tries another DC. The payload contains (Figure 5):

Figure 5 - More Frame Details

Check that out. ClientSiteName. The response from the UDP LDAP query tells my client which site it (the client) belongs to. Now you know. That value ends up getting written under Netlogon’s parameters key in the registry on the client machine(HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName).

But, we still aren’t connected to a local DC. That DcSiteName property indicates that DC04 is in CORPDR. We want a local DC. If you wanted to go way off in to the weeds here, you could enable Netlogon debug logging and look for MAILSLOT entries in the log. There you’d see (Figure 6):

Figure 6 - Netlogon.log with debug level logging

It shows us right in the logs that DC04 isn’t a local DC and that it’s going to try to find a DC in a closer site. Immediately after that, we see another DNS query (Figure 7). This query is for another LDAP SRV record, but this time it looks a little different:

Figure 7 - Site specific DNS query

Instead of querying for any DC as the service did at start, the service now performs a site specific query using _ldap._tcp.CORPHQ._sites.dc._msdcs.corp.milt0r.com. DNS returns a response that contains the SRV records for all of the domain controllers in the CORPHQ site. The frame details for the DNS reply contains (Figure 8):

Figure 8 - Site specific DNS reply - Frame Details

Each ARecord entry contains info about an SRV record. Now we know that DC02 is hosting LDAP on 389. Next we would expect a DNS query for DC02 (Figure 9):

Figure 9 - DNS Query for DC A Record

Based on the response, Netlogon tries the UDP LDAP query again, this time to 10.1.1.11 (in the log above). And there you have it. From this point on, any process using DCLocator or DsGetDcName should use the site specific queries.

But “how does that help you cross-forest” you ask? Great question.

Finding DCs Cross-Forest

I have a forest trust configured between corp.milt0r.com and dmz.milt0r.com. I’ve also got a stub zone configured on my primary DNS server pointing to dmz.milt0r.com. From my client, Win8, I’ll open cmd.exe and run nltest to find a DC in the other forest (Figure 10).

Figure 10 – nltesting…

Examining the network trace shows some interesting information. When my machine started, it performed that generic query to the global SRV list. When I crossed my forest trust and needed to find a DC, it did this (Figure 11):

Figure 11 - Cross-trust DNS Query – Site specific

The first query to the trusting forest performed a DNS query looking for _ldap._tcp.CORPHQ._sites.dc._msdcs.dmz.milt0r.com. Weird. We don’t even know if that’s a valid site in dmz.milt0r.com… and according to that “Name Error” message in the response, it isn’t! Based on the information provided in the capture, we now know that the first DNS query for a DC in another forest will look for a DC in a site that matches the client’s site in its own forest. Since it didn’t find one, it falls back to the global list (Figure 12).

Figure 12 - Cross-trust DNS Query – Non-site specific

This one returns a response. From there, we witness a similar behavior to what we saw in the local forest. A DNS query to the hostname we want to use, then one of the UDP LDAP “pings” (Figure 13).

Figure 13 - A Record Query and LDAP Ping

And then the corresponding MAILSLOT entry in the Netlogon debug log (Figure 14).

Figure 14 - More netlogon logs.

So how do I ensure that I find a DC across the trust in a “local” site or desired site?

By now, you’ve probably guessed it. You simply need to create a site in the trusting forest that has the same name as the site in the trusted forest. If I jump on to OLDDC01 in the DMZ forest and fire up Sites and Services, I can add a new site (Figure 15):

Figure 15 - It's a 2003 DC, hence OLDDC01.

The site doesn’t need to actually contain any domain controllers. You’ll just want to ensure that it’s connected to a site that you want to service the authentications and LDAP queries. The rest will happen via automatic site coverage. DCs linked to empty sites recognize that the other site has no DCs and register SRV records there to ensure that clients find a “close enough” domain controller. When that happens, you’ll see a message from Netlogon like the one below (Figure 16).

Figure 16 - Automatic Site Coverage event log message

And now when running that nltest command again, we observe:

Figure 17 - Cross-trust DNS Query - Site Specific and successful!

The first query we see (Figure 17) is, once again, site specific…except this time it returns a successful response. Next, it queries the A record and finally performs the LDAP ping. From there authentication occurs against the site-specific foreign DC. By matching the site name, we’re able to help predict and control which DCs I will go to across the forest trust.

Conclusion

My hope is that by this point you have an understanding of how DCLocator works for finding DCs in the domain of the workstation and that you understand how to get it to find specific DCs across a forest trust. Long story short, you don’t need to go out and register all of your subnets in the trusting forest, but you do need to have site names that match, as well as a topology that matches how you’d like the traffic to flow between the two forests. You won’t want to place a matching site name off of some site that contains DCs but is poorly connected and unreliable.

Please keep in mind that caveat I mentioned at the beginning. This methodology works great when the subnet in Forest A doesn’t exist in Forest B. There could, however, be some unintended results and issues if conflicting subnet definitions exist. Watch for another post on that very soon.

Big thanks to fellow PFE Matt Reynolds for his assistance with this post and doing some labbing and confirmation around these topics. His contribution provided the info for the follow up post. Look for that in the next few weeks.

Thanks for reading and post any questions in the comments below!

- Tom "I'm gonna need a 10-20 on that DC" Moser

@Milt0r

Upgrading or Migrating Active Directory to Windows Server 2012 – Build Your Roadmap Now

Doug Symalla — Mon, 29 Apr 2013 06:00:00 GMT

If you’ve been managing an Active Directory infrastructure for the last 5-10 years, you might have noticed that the pace of change has rapidly increased. After surviving the migrations from Windows NT to Windows 2000 and then Windows 2003, we settled into a nice lull for about 5 years. Suddenly Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012 released in about a four year time frame. Now the rumors around the web are hinting at another new version of Windows.

As a lover of technology, all this new stuff is exciting. As a support professional who has to help customers implement all this change, I can understand that you may feel overwhelmed. Can you imagine trying to manage and upgrade an AD infrastructure that has domain controllers running a mix of one/more/all of the following: Server 2003, Server 2008, Server 2008 R2 and Server 2012?

Now is the time to start planning and build your roadmap for moving forward. Don’t worry, because we’re here to help. AskPFEPlat has already given you a great look at Windows Server 2012. Greg’s even given you some practical information on deploying the first Windows Server 2012 Domain Controller.

What we’re going to deliver to you now (and in some soon-to-follow blogs), is everything you need to know about the upgrade process in general as well as some great specifics. I know that there is already good information on TechNet and elsewhere on the internet. What we have to offer is comprehensive and practical information based on our experiences helping hundreds of customers through this process.

Let’s start by talking about a framework to manage the process. At the end of the day, it is simple:

Assess Your Environment

Start by assessing where you are today with your Active Directory infrastructure. Specifically:

Document your current Architecture, Design and Sizing. Where, how many and how big are your current domain controllers?
Research and document your dependents. Which applications in your environment depend on AD? What applications run the business, and what dependency, if any, do they have on Active Directory?
Discover and document your current Domain Controllers configuration. Any non-default configurations that you need to carry forward?
Research the changes to the default OS behavior in the “new” versions of Windows. Do you know what these are, and how they might affect you?
Inventory other applications/services that are running on your DCs. Don’t forget that these might need to be migrated as your old DCs disappear.

Plan Your Upgrade

Now think about where you’re going, and what you have to do to get there. Use your assessment data to drive the plans. Specifically:

Decide which version of Windows Server you are heading for – Windows Server 2012?
Determine whether you are ready for this new version of Windows. Do you have a tried and tested build?
Document your desired architecture. Are you going to carry your current architecture forward? Do you have the right number of DCs in the right place of the right capacity?
Decide if the type of DC you deploy will change. What about Read-Only DCs, or Virtual DCs? Should they play a role in your new infrastructure?
Research which of your dependents are compatible with these new types of Domain Controllers.
Determine which application/client dependents need to be tested against new DCs.
Plan to manage the behavior changes in the default configuration of the new the OS. Will you roll these changes back (can you roll them back?), roll these changes forward before you deploy new DCs, or let them trickle in as new DCs are deployed?
Sequence the introduction of new DCs. Where will you start, and how quickly will you introduce them?
Sequence the retirement of old DCs. How will you migrate “other” services off of these DCs? Do you need to move IP addresses (or hostnames) from old DCs to new DCs?

Test

Ideally, you test every proposed change. Practically, you need to determine what you must test and what you can test, and how you will test. In some cases you will test in a lab, in other cases you may test in production (with a pilot or limited deployment, for example).

If you haven’t already introduced the new OS into production elsewhere, test your server build for the new OS.
You really should test Schema extensions and other changes made to the Active Directory database (aka ADPREP), especially since these are irreversible.
Decide which applications or clients that depend on Active Directory need to be tested.
Test your migration plan for other services like DHCP, WINS, or IAS that may be running on your current DCs.

Deploy

Now that you’ve done your homework, phase your deployment into stages. Some of the milestones you will set, include:

Preparing the Active Directory database for the new DCs (aka ADPREP).
Deploying the first Domain Controller running the new OS.
Deploying additional Domain Controllers and retiring old DCs.
Deploying the final new DC, and retiring the last old DC.
Upgrading Domain Functional Levels, Forest Functional Levels and implementing new features.

I know this is a lot to take in, and we’re not sharing technical details here. However, once you have the framework for the upgrade process, you just have to fill in the blanks. Stay tuned for future blogs that will cover these phases in much more detail.

Doug “I’ll drag you along the AD upgrade, Kicking and Screaming” Symalla

Choosing a Hash and Encryption Algorithm for a new PKI?

Mark Morowczynski [MSFT] — Mon, 22 Apr 2013 11:00:00 GMT

I frequently get asked to consult on building out new Public Key Infrastructures here in Premier Field Engineering. One of the things that I get asked commonly is “How do I choose a key length and Hash Algorithm?”. That’s a complex question, that generally is difficult to answer, but I thought I might collect “Some Thoughts” on that and put them in a single place.

First, some current background

There is a subtle kind of arms race going on – encryption and hash algorithms are always going to be subject to increasingly sophisticated attacks. CPU’s get faster and faster, making brute force attacks against encryption easier and easier, requiring longer keys. We recently released a security update that by default disallows RSA keys of less than 1024 bits in length. Kurt Hudson documented that here:

http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx

Mathematicians and hackers work to manipulate hash algorithms in order to create collision attacks, like the one used by the Flame Malware:

http://blogs.technet.com/b/srd/archive/2012/06/06/more-information-about-the-digital-certificates-used-to-sign-the-flame-malware.aspx

So when choosing hash algorithms and key lengths, one needs to take into account the current landscape. You need to do a little bit of research on how hash algorithms are currently standing up to collision attacks and what key lengths are acceptable.

One of the key indicators here that I frequently refer to is the Certificate Policy for the U.S. Federal PKI:

Section 1.4.1 states that

The use of SHA-1 to create digital signatures is deprecated beginning January 1, 2011. As such, use of SHA-1 certificates issued under this policy should be limited to applications for which the risks associated with the use of a deprecated cryptographic algorithm have been deemed acceptable.

And section 6.1.5 states

Trusted Certificates that expire before January 1, 2031 shall contain subject public keys of 2048 or 3072 bits for RSA or 256 or 384 bits for elliptic curve, and be signed with the corresponding private key. Trusted Certificates that expire on or after January 1, 2031 shall contain subject public keys of 3072 bits for RSA or 256 or 384 bits for elliptic curve, and be signed with the corresponding private key.

This provides an excellent starting point for choosing a hash algorithm, and key lengths for RSA or ECC algorithms for public/private key pairs. Additionally, the Microsoft Root Certificate Update Program contains some excellent verbiage that closely corresponds:

“we require a minimum crypto key size of RSA 2048-bit modulus for any root and all issuing CAs. Microsoft will no longer accept root certificates with RSA 1024-bit modulus of any expiration. We prefer that new roots are valid for at least 8 years from date of submission but expire before the year 2030, especially if they have a 2048-bit RSA modulus.”

Now, some history

There are a large number of clients that cannot understand anything greater than a 2048 bit key length, or hash algorithms more current than SHA-1. For example, Windows Server 2003 offers limited support for the SHA2 hash algorithms:

948963 An update is available to adds support for the TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA and the TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA AES cipher suites in Windows Server 2003

http://support.microsoft.com/kb/948963/EN-US

and

968730 Windows Server 2003 and Windows XP clients cannot obtain certificates from a Windows Server 2008-based certification authority (CA) if the CA is configured to use SHA2 256 or higher encryption

http://support.microsoft.com/kb/968730/EN-US

document that level of support. So in addition to thinking about the future, you’ve got to consider the past when building out a hierarchy. One of the hierarchies I helped build had a 2048 bit key for a Root Certificate primarily because of the requirement to support legacy operating systems and devices.

And finally a Recommendation

If you absolutely must support legacy applications that don’t understand CNG algorithms, and are building out a new public key infrastructure, my advice today is to build two hierarchies. The first hierarchy – a legacy hierarchy if you will – would have a lower key lifetime aimed at a documented point at which legacy applications and devices MUST support CNG algorithms. You could issue certificates based on this “lower assurance” hierarchy for a limited time only to legacy clients, perhaps with limited EKUs and a specific Certificate Policy attached to it. The second PKI would be erected with more current algorithms and key lengths to support more current clients and with much longer expiry periods. When building that PKI, you could follow the stronger guidance put forth in the Federal CP and choose SHA-256, or SHA-384 along with RSA Keys of 4096 bits or ECC keys of 256 or 384 bits. I agree that this adds complexity, but I find in the IT industry that we’re constantly dragging older applications and devices into a new security world – often, kicking and screaming the entire way.

-Rick Sasser

References:

A.Sotirov, M.Stevens, J.Applebaum, A.Lenstra, D.Molnar, D.A. Osvik, B. de Weger, “MD5 considered harmful today”, http://www.win.tue.nl/hashclash/rogue-ca/, Dec.30, 2008.

Microsoft Root Certificate Update Program, http://technet.microsoft.com/en-us/library/cc751157.aspx

Some Other PFE Blogs You’ll Want To Be Reading

Mark Morowczynski [MSFT] — Fri, 19 Apr 2013 09:00:00 GMT

Hey y’all, Mark here with some quick links for you. We have two other PFE team blogs that have been getting some steam as of late we thought we’d pass along so our fine readership can check them out and spread the word.

A bunch of SQL folks have started to bring an old blog back from the dead. You can find their blog here. Their latest post, SQL 2012 System Health Reporting Dashboard is the type of great content they are putting out. They are always looking for community feedback so send in your questions or if SQL is not your thing, don’t worry its not mine either, pass it on to your favorite DBA. They can owe you one.

Also if you are running Dynamics CRM you should be reading our PFE CRM in the Field blog. If you weren’t before…you’re welcome. Several of them just got back from the Dynamics Convergence conference where they get to mingle with their community which they are highly active in. Reach out to them and tell them we sent you.

As always send us in your questions via email or if you dare to Doug ‘Grandpa Simpson’ Symalla has just discovered in his own words “this new thing called twitter” and is manning our @PFEPlatforms account. He’s in the process of changing the profile picture. You’ve been warned. I too can also be found on twitter @markmorow don't be shy. Have a good weekend and as always we’ll have a new post up for Monday. It’s a good one.

Mark “SQL DROP TABLE Joke Here” Morowczynski

Building a VM in Windows Azure using PowerShell in a few quick steps

Rick Sheikh [MSFT] — Mon, 15 Apr 2013 04:57:44 GMT

Hello folks, its Rick here. In a previous post Michael gave you nice overview of Windows Azure Services and helped you setup your own VMs in cloud using the free trial thru the Azure portal. Today I would like to walk you through building a VM in Windows Azure using your favorite management tool ‘PowerShell’, and in doing so you will also unlock 133 cmdlets that will help you manage other services you may have running in Windows Azure. If you have not signed up for a 90 day trial yet, I suggest you give it a try. Also did you know if you have an existing MSDN subscription, you may be entitled to up to 1500 compute hours that’s $6500 in annual Windows Azure benefits at no charge.

Let’s get started;

1. Download the Windows Azure PowerShell and install it on a Windows 8, Windows 7, Windows Server 2012, or Windows Server 2008 R2 machine.

2. If you would like to use Windows Azure PowerShell snap-in you can directly launch it from your Start Menu/Screen, but if you are like me and rather import the module into your existing Windows PowerShell, you know the drill.

Set-ExecutionPolicy RemoteSigned

Import-Module "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1"

3. Configuring connectivity between your workstation and Windows Azure; before a connection can be made from your Windows Azure Powershell module you first need to download your publish settings from Azure portal using the cmdlet below.

Get-AzurePublishSettingsFile

4. Your browser will take you to https://windows.azure.com/download/publishprofile.aspx, where you can sign in to Windows Azure account download the publish settings file. Note the location where you save this file. This file has Azure API information, your subscription ID and more importantly the management certificate that needs to be imported locally on your machine using another cmdlet.

5. Now we will go ahead the import the publish settings file we have just downloaded using the command below. Where <mysettings>.publishsettings is the file that you downloaded in the previous step. You should delete the publishing profile that you downloaded after you import those settings. The downloaded profile contains a management certificate that should not be accessed by unauthorized users.

Import-AzurePublishSettingsFile <mysettings>.publishsettings

You can optionally view the publish settings file you downloaded in Step 4, in Notepad.

6. Let’s take a look at our current subscription, notice the certificate being good for one year since the time you set this up.

7. Now let’s take a look what are some of the cmdlets that Azure PowerShell module unlocks for us, focusing on VM management. You can see the rest here.

8. Let’s see what I already have running out there..

9. We are almost ready to build the VM, but before we do that we have to use Set-AzureSubcription cmdlet to save our subscription information and set the storage account that was previously setup using the Azure portal. You can use the Get-AzureStorageAccount cmdlet to retrieve the StorageAccountName property.

Set-AzureSubscription -SubscriptionName "Windows Azure MSDN - Visual Studio Ultimate" –CurrentStorageAccount portalvhdshmdl42f1wmfd7

You can verify the above command using the Get-AzureSubscription cmdlet again.

Above “portalvhds*” being the name of my storage.

10. Let’s build a new VM using the New-AzureQuickVM cmdlet, (note that as mentioned in the previous post, Azure provides pre built images in VHD, in following example we have run the Get-AzureVMImage and passing the name of a 2012 image. You can also use Test-AzureName cmdlet to verify if the VM or service name you are wanting to acquire is available.

New-AzureQuickVM -Windows -ServiceName TESTADDC03 -Name TESTADDC03 -ImageName MSFT__Windows-Server-2012-Datacenter-201210.01-en.us-30GB.vhd -InstanceSize 'Small' -Password Password!@# -AffinityGroup Chicago

You will see everytime you deploy a VM, it first gets created as a Cloud Service and then the VM itself gets deployed, you will see the progress bar for the VM creation as well.

It took less than a minute to spin up this test VM for this demo, your time may vary.

11. Let’s verify that our VM is up and running.

This wraps up this quick tutorial, hopefully you can see that after you have your initial subscription ready and registered and at least one storage account setup, you can provision VMs using PowerShell in a matter of minutes. I invite you try this out yourself and see what other useful cmdlets you find in the Azure PowerShell module.

Until next time, Rick “is there a cmdlet for that” Sheikh !

RaaS-Active Directory The Engineers Point Of View

Mark Morowczynski [MSFT] — Wed, 10 Apr 2013 12:00:00 GMT

My name is Bryan Zink and I am a Microsoft Premier Field Engineer focused on supporting Windows Server and Active Directory. You’ve probably read the fantastic post by Yong Rhee introducing RAP as a Service. Maybe you even read What is RaaS? Is That a Real Acronym? posted by Doug Symalla. Today I wanted to assure you that yes, it is a real acronym and one you’ll want to fully understand. In this post, we’ll dig into HOW it works and WHY you should jump in.

First a brief history

A long time ago in a galaxy far far away (actually, it was Dallas, TX), a team of 15 PFEs pulled together some tools, wrapped them in a process and called it the Active Directory Health Check (ADHC for short). The intention was to partner with a customers’ IT team to help spot the issues we knew caused pain to avoid lost productivity and outages.

As the process matured, we found there were two huge benefits. First, outages were dropping as customers better understood how to operate their AD environments. Second, we drove some great changes through the Windows product team resulting in improvements to diagnostic tools and prescriptive guidance.

When we transitioned from the ADHC to the era of the Active Directory Risk and Health Assessment Program (ADRAP for short) we formalized the tools and services development process in many ways. While our goals around assessing the issues and providing remediation guidance were still the same, we wanted to bring a more exciting experience to the customer and leave behind a much nicer toolset.

Now we’re bringing you the next big thing in Active Directory assessments, RAP as a Service for Active Directory (RaaS-AD for short). Essentially we’re combining the best of the best in tools and processes, moving it to the Azure Cloud platform and giving customers a persistent on-demand assessment experience.

HOW RaaS-AD works

First and foremost, RaaS is a service with a few basic components. These components are made up of the following:

· RaaS Client

· Windows Azure Cloud service

· Online Services portal

The front-end (RaaS Client) is downloaded and installed onto a machine in your AD Forest. This tool essentially discovers the Active Directory components in your environment and facilitates the data collection process. Once data collection is completed, the RaaS Client allows you to securely submit an encrypted blob into the Azure Cloud service.

Once you complete data collection and submission, you will fill out an Operational Survey. This survey covers topics we can’t answer with diagnostic tests. Backup and Disaster Recovery, operational processes etc are examples of topics covered in the Survey.

The Azure Cloud service is where the heavy lifting happens. The collected data along with the Survey results are analyzed for the good, the bad and the ugly against our collection of rules.

The Online Services portal is your view of not only the collected data but also the issues that were identified through the analysis process. This portal is your customized and secured dashboard view. You have the ability to control who from within your organization has access to view this information.

In addition to the components described above, you will receive not only a detailed report of the findings and recommendations but also deep-dive knowledge transfer on the top issues in the environment. You also have a couple of options for how this all comes together. We offer a remote delivery option as well as something that includes on-site time. Specifics can be explained in more detail with your Microsoft Technical Account Manager (TAM).

RaaS does have a re-use license whereby you’re able to leverage the persistent on-demand assessment experience. This enables you to track progress against recommended remediation tasks and generally, check-up on your AD environment at whatever frequency makes sense.

WHY RaaS-AD matters

There are numerous benefits for you to leverage with the RaaS platform. Instead of listing the bullet points from the marketing glossy, let’s cut right to the chase.

Customers who have leveraged the power of RAPs in the past have had almost zero exposure to issues such as the time rollback problem so elegantly detailed in Mark’s post Fixing When Your Domain Traveled Back In Time, the Great System Time Rollback to the Year 2000.

Another example of an issue that strikes many environments who have not had the pleasure of an AD assessment DFS Shares either not replicating or seemingly missing data. Here’s a post by the infamous Ned Pyle covering the Top 10 Common Causes of Slow Replication with DFSR.

Finally, have you ever wondered about just how weird the symptoms of Lingering Objects can be? Have a look at this post from David Everett setting us straight on Strict Replication Consistency - Myth versus Reality.

At present, there are roughly 600 Health and Risk issues we specifically look for in a RaaS-AD assessment and more are being added weekly. All of this can and should be yours, operators are standing by. If you’re still reading and would you’d like a RaaS-AD, feel free to contact us at Askpfeplat and we’ll get the right people going.

In the event you want to see a more formalized list of value points, keep reading.

Delivered when you’re ready: Faster turnaround time for generating actionable results: data is collected and submitted as soon as you are ready and reports generated by a PFE within a few days of completing the submission tasks.

New/Updated IP always available: Absolute latest rules (IP) and all new IP updates available to customers during their contract without paying for an additional assessment.

Current State Assessment on-demand: Updated view of your environment through the Online Services portal, as often as you would like, helps tracking remediation progress.

A PFE can still go on-site: If you still want on-site assistance in the form of knowledge transfer or remediation assistance, we can still absolutely provide that experience.

Support: ADRAP (actually all RAPs in general) had no support for either the toolset or the process other than what the PFE was able to deliver as part of the engagement. However, RaaS has full support for both the toolset and the end to end process. The only thing not supported is the actual remediation of an identified issue.

Updates to the toolset: Not only do we update the IP (rules and issues) much more frequently but we now also perform updates to the RaaS Client as well as the back end platform.

Reliability, Security and Privacy: Providing a feature rich and usable experience is only part of the solution. Reworking the backend systems that integrate to complete this experience have allowed us to provide a more reliable, stable and secure experience for everyone.

-Bryan

Audit Membership in Privileged Active Directory Groups. A Second Look.

Doug Symalla — Mon, 08 Apr 2013 07:00:00 GMT

Some months ago, I shared a PowerShell script to enumerate the membership of privileged groups (including membership in nested groups) and report membership as well as password ages. Like most scripts, it works well in most environments, but has some limitations. One glaring limitation that I’ve found, for example, is that it searches for privileged groups by name. However, in some environments the groups may have been renamed. Or even more problematic are instances where built-in group names are different in non-English versions of the OS.

Since the built-in privileged groups all have well known SIDs, the logical solution was to re-write the script to search for groups based-on SIDs rather than names. So I started by identifying the well-known SIDs for the built-in privileged groups. There’s a KB for that. As it turns out, some of the well-known SIDs are constructed from the domain SID or the forest root domain SID. For example, the SID for Enterprise Admins is the root domain SID with “-591” appended to it.

Consequently, I had to re-work my script to identify the SID for every domain in the forest. Then, I had to construct all the SIDs for the privileged groups and enumerate their memberships.

To add another degree of difficulty, I wrote the entire script without using the AD PowerShell Cmdlets. As I’ve mentioned before, I still run into customers who can’t use the AD Powershell Cmdlets because they still have all 2003 domain controllers (without the AD web services installed). So instead of using one line of PowerShell to generate a list of domain SIDs:

(Get-ADForest).domains | forEach {Get-ADDomain $_} | Select-Object Name,DomainSid

I had to use about twenty lines of code to generate my list of SIDs. Most interesting was the use of .Net methods to convert SIDs to string values:

$RootDomainSid = New-Object System.Security.Principal.SecurityIdentifier($AdObject.objectSid[0], 0)

So I began talking to my peers about the beauty of the AD PowerShell Cmdlets and how they’ve saved us from writing lines and lines of code. I thought, “Let me re-write my script and show people how much more succinct the code could be.”

What started out as a noble effort, has turned into my White Whale. While sections of my script can be obliterated with single line Cmdlets, there are holes in the AD PowerShell Cmdlets that are frustratingly difficult to address. So here’s a challenge for you PowerShell junkies out there (and who have environments where the Cmdlets work), tear down my script and replace sections with AD Cmdlets.

I’m already working on my next blog, tentatively titled “Who’s the tool – PowerShell or Me?” where I’ll detail some of the different ways of using PowerShell with AD – including the AD Cmdlets. I’ll point out the differences and some of the relative strengths and weaknesses of each way.

Meanwhile, I’m counting the days until July 14^th 2015 when Windows Server 2003 is no longer supported, so I can leverage the AD Cmdlets in every environment I visit.

Since I’ve taken you off on a tangent, let’s get back to the original purpose of this post. You’ll find an updated version of the script on the TechNet Script Center. As before, it will enumerate membership in privileged groups and report password ages. While it’s not perfect, it better than the original in the following ways:

1. It targets groups based on well-known SIDs, so it will work in more environments.

2. It also reports on members that may not be users (computers or managed service accounts)

The syntax is straight-forward. Launch PowerShell. No special privileges are necessary, but you’ll have to run as a domain account, so we can read the directory. You’ll also need connectivity to DCs in the forest so we can enumerate group memberships. Simply run the script.

privilegedUsersV2.ps1

It’ll dump output to the screen and in a CSV file (that will dump in the same directory from which you launch the script).

Don’t forget to review the original blog for information on how (and why) to use the script.

Doug Symalla

A note on all of our AskPFEPlat scripts. We’ve removed all script attachments to our blogs and posted them on the TechNet Script Center. The blog will contain a hyperlink to the relevant location. You can find all of our scripts on the Script Center by searching for the keyword AskPFEPlat.