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 https://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...

 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
https://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,

https://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.

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
https://support.microsoft.com/kb/929851

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

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

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

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

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

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.

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 https://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
https://technet.microsoft.com/en-us/library/ee619754(v=WS.10).aspx

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

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

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

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.

There’s a really good Wiki article on backing up ADFS on https://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 https://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 https://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 https://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
https://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
https://technet.microsoft.com/en-us/library/cc787348(v=WS.10).aspx

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.

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.