A hotfix has recently been issued that resolves an issue where the Windows 7/Windows 2008 R2 client "forgets" its dynamic site name during the startup sequence.

The net effect of this being that the client always makes additional generic DNS queries which return non-site specific DC names back to the client. 
The DC returned from the DNS query will in turn tell the client to talk to a DC in its own site.

However, this peculiar type of amnesia will affect your systems particularly negatively if you've either configured the PreferLogonDC registry setting or else if DNS registration for branch office sites has been turned off and the link to the main site is down.

With PreferLogonDC set, the DFS server the client talks to will place itself at the top of the list (even as it sends you the site you're in) - if the client talks to the same DC again the next time it asks for DFS referrals for Sysvol the process will be repeated.

Fix details are otherwise available in KB266938.

Client computer uses site-less SRV records after you restart the computer in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2666938

DFS-Related Processes on Client
http://technet.microsoft.com/en-us/library/cc782417(v=WS.10).aspx#w2k3tr_dfs_how_wxun

Available Updates for Remote Desktop Services (Terminal Services) in Windows Server 2008 R2
http://support.microsoft.com/kb/2601888

Latest BaseCSP.DLL (as of April 2012):

You may wait for up to 30 seconds when you use a smart card to unlock a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/kb/2577550

Latest Winscard.dll (as of April 2012)

A program that requires you to use a smart card stops responding in a remote desktop connection in Windows Server 2008, in Windows Vista, in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2521923

...and make sure you're at SP1 on the W2k8 R2 terminal server.
...also make sure you create and set FilterCSPCardCacheByTSSessionConnectTime to 1 – it is by default 0 or not present (this is read by the BaseCSP.DLL component).

See also http://blogs.technet.com/b/instan/archive/2011/03/24/smartcard-redirection-diaries.aspx for other aspects.

From http://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-policy-web-services-in-active-directory-certificate-services-ad-cs.aspx: 

Starting in Windows Server 2008 R2, there is an enrollment protocol that is based on WS-Trust and contains two new role services.
These services use HTTP-based messaging over a TLS-encrypted transport and they do not depend solely on the Kerberos protocol for authentication.
[Note: Using this for enrollment requires Windows 7 or Windows 2008 R2 clients.]

The role services are called:

• Certificate Enrollment Policy Web Service (the policy service)
• Certificate Enrollment Web Service (the enrollment service)

 ....

Windows Client Enrollment – Policy Server Load Balancing

For Group Policy configured policy settings, you can configure two servers (URLs) as part of the same policy.  As a result, both policy server URLs will be functionally equivalent. The client then selects one URL to use, based upon the following rules:

Note: To configure the load balancing behavior described below, Group Policy configured settings must be used. User configured policies do not enable multiple URLs to be configured as part of the same policy.

1. The URI whose policy has been cached from a previous request and whose next update time is the latest is most preferred.
2. If two URI’s have the same next update time then:
   1. The URI with the lower value in the “Cost” registry entry is preferred. The default value is that all costs are equal.
   2. If two costs are equal then:

                                                                          
i.     The URI is selected based on authentication type, in the following order: Kerberos, Anonymous, Username/Password cached in the vault or Client Auth Certificate cached in the vault, Username/Password or Client Auth Certificate.

ii.     If all properties are equal then a URI is randomly selected.

Windows Client Enrollment – Enrollment Server Load Balancing

Once a policy server is selected there may be multiple enrollment servers to choose from. The client will pick an enrollment server as follows:

1. The URI for the enrollment server which has the lowest priority number as defined in the enrollment policy. If two enrollment servers have the same priority then
   1. The URI with the following authentication type is preferred in order: Kerberos, Anonymous, Username/Password cached in the vault or Client Auth Certificate cached in the vault, Username/Password or Client Auth Certificate.
   2. If all properties are equal then a URI is randomly selected.

....

Change the Cost settings

• To change the order in which the client will try different policy servers (Enrollment Policy URIs) within the same policy, update the “cost” registry DWORD. 
  The default value is 0x7ffffffd, a lower value (such as 1) will cause the client to use that policy URI first. 
• The “Cost” registry key is found in the following locations:
• For group policy configured policy server settings (listed under “Configured by your administrator” in the Certificate enrollment wizard)
• For user certificate policy
• HKCU\Software\Policies\Microsoft\Cryptography\PolicyServers\
• For machine certificate policy
• HKLM\SOFTWARE\Policies\Microsoft\Cryptography\PolicyServers\

• For user configured policy server settings (listed under “Configured by you” in the Certificate Enrollment wizard
• For user certificate policy
• HKCU\Software\Microsoft\Cryptography\PolicyServers\
• For machine certificate policy
• HKLM\SOFTWARE\Microsoft\Cryptography\PolicyServers\

While working at a customer site the other day I was reminded of an article by Eric Lawrence on why you sometimes start seeing endless pop-up windows asking for credentials when using Fiddler to decrypt HTTPS traffic during troubleshooting.

In short; If the web server has Extended Protection for Authentication enabled then it detects that the Channel Binding Token Fiddler is presenting to it doesn't match the one created by the original user during the session so it invalidates the credentials and requests authentication again (which loops endlessly).

The solution; Fiddle around with Fiddler internally and add the site you're having problems with specifically as a site that Fiddler is allowed to authenticate to on your behalf and add credentials to authenticate with against that site to the Fiddler config file (See Eric's MSDN article for details).

Details:

Fiddler and Channel Binding Tokens Revisited
http://blogs.msdn.com/b/fiddler/archive/2011/09/04/fiddler-http-401-authentication-workaround-to-support-channel-binding-tokens-removing-endless-prompts.aspx

Extended Protection for Authentication - Microsoft Security Advisory (973811)
http://technet.microsoft.com/en-us/security/advisory/973811

During the installation of ADFS 2.1 on Windows Server 2012 the Add-Role wizard grants the local virtual account NT SERVICEMSSQL$MICROSOFT##WID that runs the WID service ‘Log on as a service‘ user rights via the Local Group policy.

If the Local Group Policy that grants the user rights is overwritten by a GPO with a higher priority that also defines User Rights the WID service account will not have Log on as a Service user rights and this will in turn cause the addition of the WID role to fail during the Add-Role wizard run.

Other symptoms are that the WID service will appear to be installed but cannot start and further Add-Role wizard runs will complain that a restart is pending – which is technically correct as the WID service will not be fully removed until the next reboot.

The resolution is to ensure the local Group Policy defining the User Rights permissions for the server is not overwritten at a higher level (the priority being Local-Site-Domain-OU in order) or to add NT SERVICEMSSQL$MICROSOFT##WID *or* NT SERVICEALL SERVICES to the winning GPO that is applying Log on as a Service User Rights settings to the W2k12 server.

If you ever find yourself yearning to break into Powershell for extending your technological tendrils into areas normally reserved for C++ or C# developers then you’ll want to leverage the Power of the Get-Help Powershell cmdlet.

Example: Let’s say you want to list all and any cmdlets that contain ‘ADFS’ or that mention ‘ADFS’ anywhere in the associated help:

Update-Help

Get-Help *ADFS*

- or -

Get-Help *LDAP*

Once you have figured out which cmdlet you want to run you can then typically append the -example option to get some sample code for each cmdlet.

What do I need to do a Disaster Recovery of ADFS?
What exclusions should I configure for my ADFS Server?

There’s a really good Wiki article on backing up ADFS on http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-how-to-back-up-the-federation-service.aspx that is a must-read for any serious deployment of ADFS.

In short; a System State backup that includes all volumes of the ADFS server will be sufficient for ADFS disaster recovery (assuming AD is still present).
A more extended Technet article is also available on http://technet.microsoft.com/en-us/library/cc787348(v=WS.10).aspx.
If SQL is being used rather than WID then a backup of the ADFS configuration database on the target SQL server being used is also required for ADFS recovery.

For Antivirus exclusions for ADFS with WID involved you should combine the exclusion recommendations for SQL and IIS on http://social.technet.microsoft.com/wiki/contents/articles/953.microsoft-anti-virus-exclusion-list.aspx.

For monitoring purposes you can use the ADFS 2.x management pack for SCOM, see http://blogs.msdn.com/b/card/archive/2010/08/06/announcing-active-directory-federation-services-2-0-management-pack-for-microsoft-system-center-operations-manager-2007.aspx for details.

Related links:

How to back up the federation service
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-how-to-back-up-the-federation-service.aspx 

Back up ADFS components on a federation server, federation server proxy, or Web server
http://technet.microsoft.com/en-us/library/cc787348(v=WS.10).aspx

There’s a neat policy module plug-in called “Support for non-FIM CM certificate requests” that’s available in the latest version of FIM CM 2010 R2 SP1: 

After adding this plugin as a custom policy module on the CA you need to do the following:

• put in the SQL connection string (should already be present in the FIM CM Exit module if your FIM CM is already set up and working)
• tick the certificate templates that you want the template to be applied to
• define a Profile Template that you want to use for this and specify it in the Profile Template section above

 …after this you should see all autoenrollment or manal enrollments that go through that CA show up in the FIM CM database – even if they aren’t passing through the FIM Portal.

The limitation is of course that this is for reporting and informational purposes only – as FIM isn’t making the requests on behalf of the users in this case then no private keys are being handled by FIM when enrollment is done outside the FIM CM portal so you won’t be able to do certificate recovery via FIM either.

The following is useful for scenarios where you want to either batch process a command online against all of the DC’s in the domain or if you have data files from all the DC’s that you want to process offline.

The PS script will check for the presence of a file called dclist.csv with the output of all DC’s in the domain (or export the same to that file if not present) and do a loop of DSQuery to do a simple check for the LDAP response time for each.  You’ll need PowerShell 3.0 on the box you’re running this from and you also need to add the AD PowerShell module option in the Remote Server Administration Tools section (Add Features Wizard on the server variant or in Programs on the client versions).

clear-host
 $objsum = New-Object -TypeName PSObject
 $chkfile = test-path DCList.csv
 $ScriptStart = Get-Date
 [string[]]$DCInfo=""
 $Msg= @()
 
 function getExTime ([object]$variable)
 {
 " ...completed in $($variable.Days) days, $($variable.Hours) hours, $($variable.Minutes) minutes, $($variable.Seconds) seconds, $($variable.Milliseconds) milliseconds"
 }
 
 "Processing DC's:"
 
 if ($chkfile -eq "True") {
 "Found DCList.csv - loading it"
 $DCList=import-csv DCList.csv|select-object
 "...imported list of DC's from DCList.csv"
 }
 else {
 Write-host "No DCList.csv found - creating it"
 import-module ActiveDirectory
 "...imported AD PowerShell module"
 $DCList=get-addomaincontroller -filter *
 $DCList|Export-CSV DCList.csv
 }
 
 "`nBreakdown of DC's in domain:"
 $DCList | ForEach {
 $DCInfo+="$($_.OperatingSystem) $($_.OperatingSystemServicePack)"|sort-object -unique
 }
 $DCsInDomain=($DCinfo.Count)-1
 $tableFormat = @{Expression={$_.Count};Label="Count";width=6}, @{Expression={$_.Name};Label="Operating System and Service Pack of DC's";width=120}
 $msg=$DCInfo|select-string -pattern "Server"|%{$data =[regex]::Replace($_,'(Windows Server).+ 2008', 'Windows Server 2008'); Write-Output "$($data)"}|Group-Object |Sort-Object -Descending -Property Count| Select-Object Count,Name |ft $tableFormat -autosize
 $msg
 "`nTotal number of DC's in domain: $($DCsInDomain)"
 
 
 $DCList | ForEach {
 #Do some tests
 "`nQuerying $($_.name) for partitions using LDAP:"
 $xScripts=Measure-command {
 dsquery partition -server $_.name
 }
 getExTime($xScripts)
 Add-Member -inputobject $objsum -membertype NoteProperty -name "$($_.name)" -value "$($xScripts)"
 
 }
 
 $objsum|sort-object|fl

 We’re seeing what appears to be random revocation checking failures on clients for certificates issued by our CA. The infrastructure is a 2-tier PKI with an OCSP defined on the issuing CA certificate and the CRL from the Root CA signed by a dedicated CRL-signing certificate (i.e. not the issuing cert). 

We´ve observed that in cases where the OCSP is reachable the revocation checking succeeds but even this seems to sometimes fail for the same CRL.

CAPI2 does not support using a dedicated CRL signing certificate, it only supports CRL’s signed by the issuer of the certificate being validated.  CAPI2 *does* however support OCSP responses signed by a dedicated OCSP-signing certificate.

In your case the CRL check will always fail because the CRL isn’t signed by the issuer, when using OCSP it will succeed as the OCSP response is signed by the dedicated OCSP-signing certificate.  As long as the OCSP check succeeds then the certificate validates and everything is fine and dandy.

However, if a revocation check request is made more than the magic number of 50 times (the default) for a specific issuer then the default behaviour is to switch to CRL instead and this will fail as the CRL isn’t signed by the issuer of the CRL (which explains the seeming randomness of the failure).

So, in your case once the client has made more than 50 revocation checks for certificates issued by your CA (which will succeed) then it switches to CRL’s (which will fail).  This will be locally on each client so you may see two clients side-by-side where one works and the other one fails because it has done more than 50 checks.  Rebooting the failing client will reset the magic number count and things will magically work again (until 50 checks have been made).

Simple, eh?

From http://technet.microsoft.com/en-us/library/ee619754(v=WS.10).aspx:

In some cases, CryptoAPI may retrieve CRLs before OCSP URLs. This only occurs when one of the following two circumstances exist:

• The number of cached OCSP responses for a specific certificate issuer exceeds the magic number defined in Group Policy. This number is 50 by default.
• Group Policy is configured to prefer CRLs over OCSP for revocation checking.

….

When CryptoAPI must validate a certificate for revocation status, the following algorithm is used:

1. If a stapled OCSP response that was returned by the TLS server or the DC is time valid, the stapled response is used to validate the certificate.
2. If the certificate being validated only includes either OCSP or CRL information, then the URLs are processed in the order in which they are presented in the certificate.
3. If both OCSP URLs and CDP URLs are present, the following routine is followed:
   1. The initial assumption is that OCSP is preferred over CRLs.
   2. When an OCSP response is cached, the URL is hashed and used as the prefix for the file name in the URL cache entry.
4. The total number of cached OCSP responses from a single OCSP responder URL is calculated, and then compared to a predefined value known as the magic count. The default magic count value is 50.
   • If the number is less than or equal to the magic count, then the OCSP URLs are processed in the order dictated by the authority information access extension.
   • If the number of is greater than the magic count, then the CRL URLs are processed in the order dictated by the CRL distribution point extension.
   • If none of the OCSP URLs in the authority information access extension succeeds, then fall back to using CRLs.

The magic count value can be specified in the “CryptnetCachedOcspSwitchToCrlCount” DWORD value in the HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificatesChainEngineConfig registry key. 

Note: setting this to 0 uses the default of 50, if you want to turn off OCSP fetching then you need to use the Options DWORD and the CERT_CHAIN_OPTION_DISABLE_AIA_URL_RETRIEVAL flag (0x2).  See WinCrypt.h in the Platforms SDK for details.

Further details:

How Certificate Revocation Works
http://technet.microsoft.com/en-us/library/ee619754(v=WS.10).aspx

Optimizing the Revocation Experience
http://technet.microsoft.com/en-us/library/ee619783(v=WS.10).aspx

Installing the Platform SDK and Configuring Visual C++
http://msdn.microsoft.com/en-us/library/windows/desktop/ms759194(v=vs.85).aspx

It’ s summer, you’re bored enough to start reading random newsletters and then you pick up something useful.

1. Create a folder on your Surface desktop with the name GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
2. Open The folder for a surprise…

…this incidentally also works on Windows 7.

Just wanted to put this here as it’s not been easy to find this information anywhere:

ADLDS registers a custom RPC port which is by default taken from the dynamic port range 49152-65535, this is NOT the same as the LDAP port specified for the instance. On ADAM the same thing applies but the dynamic port range there is 1025-5000.

This means that if you’re upgrading from ADAM to ADLDS and are using firewalls with aggressive blocking between your ADAM instances then you’ll need to update the firewall rules to allow the new dynamic port range.

Alternatively, you can also lock down each ADAM or ADLDS instance to a specific RPC port using the following registry entry:

Registry value:  TCP/IP Port
Value type:  REG_DWORD
Value data: (available port)

This is effectively the same as the setting for NTDS in KB224196 but needs to reference each ADLDS instance and use a separate port for each.
The DCTcpipPort entry only applies to Netlogon on DC’s and shouldn’t need to be set.

Details:

The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
http://support.microsoft.com/kb/929851

Understanding ADAM bind redirection
http://technet.microsoft.com/en-us/library/cc758386(v=WS.10).aspx

Restricting Active Directory replication traffic and client RPC traffic to a specific port
http://support.microsoft.com/kb/224196

Active Directory Application Mode Tools and Settings
http://technet.microsoft.com/en-us/library/cc739021(v=WS.10).aspx

Active Directory Lightweight Directory Services (ADLDS) Monitoring Management Pack
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=1451

 ADLDS ASKDS entries:
http://blogs.technet.com/b/askds/archive/2009/04/02/one-stop-audit-shop-for-adam-and-adlds.aspx 
http://blogs.technet.com/b/askds/archive/2011/05/27/viewing-adlds-traffic-with-netmon-where-is-my-ldap.aspx

I‘ve been talking to a colleague who insists a 1-tier PKI infrastructure is better than a 2-tier PKI infrastructure but without providing details on exactly why. 
Is it better?

 The word „Better“ is fairly meaningless as a quantitative descriptor.  If you‘re talking to someone that uses that word when describing an IT-related subject it probably means that it‘s a question of belief and preference rather than a matter of logic and factual evidence.

Easier to deploy and simpler to manage, yes – Better, no.

The answer to the 1-tier vs. 2-tier question for PKI deployments is entirely dependant on what you intend to do with the PKI environment and, more importantly, the requirements of other organizations that you want to establish a certificate relationship with.

For example; most military or financial institutions that you want to establish a certificate trust with will typically dictate security requirements that you must fulfil in order for them to start considering whether they can trust you (and this will typically include a requirement for the Root CA to be offline while the issuing CA‘s can be online.

The general rule of thumb is that you should not spend more money on protecting assets than what they are worth.  However, this cost can include goodwill, privacy concerns, prestige and loss of reputation from a breach so even if you‘re not protecting an asset that has a high value in itself the secondary value needs to be considered in the equation.

The primary reason for deploying an offline root CA is typically to minimize the attack surface of it and simplify revocation in case of a breach as distributing a CRL for a revoked issuing CA to all affected workstations requires less work and takes less time than removing a trusted Root CA certificate from the clients (especially for unmanaged clients that you don’t have direct control of). 

A secondary reason for a 2-tier deployment is to be able to revoke the issuing CA certificate without needing to redeploy the trusted root certificate which would be necessary for a 1-tier online issuing root CA.

Additionally, if you have no management control over the clients you cannot remove a breached Root CA certificate from them whereas revoking a SubCA certificate will be subject to normal revocation checking and will be picked up by the clients the next time they download your CRL (or OCSP response) without you being involved.

Policy requirements and company politics can also come into play for the design decisions, for example if you have several different departments that must be able to manage their own issuing CA servers then the overhead of distributing and managing multiple trusted Root CA certificates is higher than having one Root CA that all issuing CA‘s chain up to.

In short; there are pros and cons for both 1-tier and 2-tier PKI infrastructures, you need to start any PKI project by evaluating what your needs are and what your budget is before you decide on a 1-tier or a 2-tier deployment (or a 3-tier for that matter).  Just make sure you don’t let anyone tell you one is always better than the other, that is simply not the case.

For a second opinion from non-Microsoft sources, please consult the following non-Microsoft sites:

Hierarchies in PKI
http://networklore.com/hierarchies-in-pki/

3.4.1 PKI Certificate
Hierarchy Recommendations for ICCP Networks Each certification hierarchy has
its advantages and disadvantages, and each network is different. See section 1,

http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/19-Secure_ICCP_Integration.pdf

From page 88:

[1-Tier]

This centralized approach has several strengths and weaknesses:

Strengths

• • Certificates are managed by one central site, relieves burden from
  individual companies
• • A node needs to send only its own certificate in the handshake
• • CRLs are simpler and valid across the system
• • CRLs are managed at one central site
• • Simplicity; getting PKI services is very straightforward

Weaknesses

• • Does not scale to large networks (500+ nodes)
• • Centralized solution provides a single point of failure
• • “One size fits all” model of security for all nodes across
  different companies. Changes to the security policy must be more formal and
  restrictive since they affect all nodes.
• • Companies must trust the single CA to manage everyone fairly
• • Single node responsible for CRLs can experience heavy load
• • The process of adding a node to the CRL can be complicated

As networks grow larger, the flat PKI structure becomes difficult
for a single entity to manage and service. Furthermore, either out of
convenience or distrust, organizations may prefer to manage their own PKI nodes
themselves. To satisfy these issues, a tiered PKI hierarchy can be implemented.

[2-tier]

Strengths

• • Scales very well for larger networks. There can be multiple tiers
  of CAs between the root CA and the end node.
• • Each company can independently manage its own nodes
• • There is much less stress on the single root CA
• • The burden of circulating the CRL is no longer on a single node
• • A failure or compromise at a company’s CA will only affect that
  company’s nodes

Weaknesses

• • Complexity. This scenario is slightly more complex. The company
  CAs must occasionally have their certificates updated, which in turn must be
  distributed to all the nodes.
• • There are multiple CAs that must be secured from failure and
  attack
• • Each company must maintain its own CRL and distribute
  certificates.
• • Multiple certificates must be passed to provide proper
  authentication
• • Lower-tiered CAs must have
  reachback to the primary “root” CA.

This blog has been my scratchpad for the last 6 years or so for noting down interesting things encountered while assisting customers get the most out of their Microsoft Environments. However, as I’m leaving Microsoft and relocating then this will be the closing entry on it.

My primary goal at Microsoft was to make Windows just a Little Bit Better and as part of the hivemind of engineers contributing to it I’d like to believe that was a success*.

Once the initial dust settles after our relocation you can go to http://blog.cryptocrap.com if you’re interested in following future Writings/scratchpad entries on similar subjects from the author of this blog.

Thanks for your time

Footnotes

* No, I did *not* remove the Start button…