In this second part of our discussion on Credential Roaming, we are going to discuss about its relation to key archival as well as offer some practical alternatives to credential portability.
As we saw in the previous blog post, the capability of “transporting” private keys in Active Directory is one of the basic pillars of the process’s ability to roam credentials. However, this should in no way be seen as a good way of backing them up for future restores. The procedure that should be used for key backup is the Windows PKI process of Key Archival and there is no way of replacing this with credential roaming’s private key “upload” process. In fact, even though private keys do reside inside the AD database, there is no known or supported way of extracting them in any form, in case of disaster recovery procedures. Moreover, if the user deletes his certificate along with his private key from one of his profiles, this deletion will propagate into all other profiles where the certificate has roamed to.
Even though it has already been mentioned in the previous blog post, it is worth noting that an easy and quick workaround for credential roaming is the use of roaming user profiles, which (of course) involves a lot more administrative costs and changes in relation to the activation of credential roaming in ΡΚΙ. In accordance to this, the concurrent use of user profile roaming and credential roaming is not supported.
Another workaround (although not as automated as Credential Roaming) is the storage of certificates and private keys in a smart card. This solution does make the user’s credentials available in every PC that he logs on to, however it assumes smart card hardware availability (this can also be a USB-based token) and also assumes a planned or existing smart card infrastructure, which does come with high deployment and administrative costs. However, a carefully planned and executed smart card deployment can furthermore be used for other applications, like VPN remote access, local computer and RDP user login etc. In general, and independently of the fact that a smart card deployment is a good alternative to credential roaming, the use of smart cards is recommended in all medium- & high-security PKI deployments, as many security officers are not happy with the storage of private leys inside an operating system (inside non-dedicated devices, in general).
Credential roaming is the ability of a Windows Server PKI infrastructure to support roaming certificates from a Windows computer to another Windows computer, according to where a user is logged on. The way it works is as follows: when a user requests a certificate, its local operating system generates a private and public key and, using a secure channel between the computer and the CA, it uploads the private key and the signed request to the CA. The private key is securely stored in Active Directory and can later be downloaded to any PC that a domain user logs on to.
All this is fine and dandy and, based on specs, it is the perfect solution for users that tend to use a multitude of computers for their business use. However, setting up the infrastructure to support it is not as easy as one would have thought. In this post, we will take a look at some of the disadvantages and difficulties of credential roaming. In the post to follow, we will make some more general observations as well as offer some alternatives to credential roaming. So, to cut a long story short, credential roaming:
- Demands a complicate (but not very time-consuming) procedure of installation and use, as well as many scenarios to be tested to make sure it works as expected.
- Extends the physical size of the Active Directory database, according to the issued certificates to be roamed. If the service is extended to a few hundred or thousands of certificates, we may have an AD database which will grow to a few hundred MBs larger. Accordingly, the AD backup/restore time will be bigger, the AD database will become more fragmented etc. Microsoft Support has been involved in many support cases where a sudden increase of the Active Directory database has been attributed to the activation of credential roaming.
- Demands Windows XP SP3 or Windows XP SP2 with a specific update, Windows Vista , 7 or 8. It does not support other operating systems (for example, mobile OSs).
- Needs difficult and time-consuming troubleshooting techniques for Windows XP (Vista/7 use CAPI2 logging, so it’s easier there).
- Increases the organization’s attack vector. In case we don’t use enhanced security measures at the PCs that will use private key actions (i.e., lock workstation, Bitlocker protection, users’ security training etc.), using multiple points where certificates are accessible and used, we multiply the possibility of someone extracting the private key(s).
- Poses problems in network EFS encryption. Under normal circumstances, credential roaming does not work as expected, due to the nature of the logon that it supports (credential roaming: local logon, network shares: network logon). The specific limitation is described in KB907247 (in Credential roaming will not be used when using EFS to encrypt files on a file server). EFS (and EFS using credential roaming) has not been designed to work with network shares, but only for local encryption. Some workarounds exist, such as using Roaming profiles instead of credential roaming (KB837359), use Offline Files and local encryption of the cache, use of web folders (in Remote EFS Operations on File Shares and Web Folders).
A successful request for a certificate from a mobile device always depends on its operating system. Currently, all mobile devices (notebooks, tablets etc.) that rely on the Windows operating system can request certificates using the well-known MMC or web enrollment ways. Moreover, non-domain-joined clients can also request certificates using the CEP/CES services of Windows 2008R2 and above CAs.
Windows RT tablets, based on version 8.1, can also request certificates as we have already mentioned the inclusion of a SCEP client in Windows 81. at a previous blog post. However, certificate issuance for devices that depend on other, mobile-only operating systems such as iOS and Android, depend on the vendor. In this blog post, we will limit our scope to iOS 5.x devices. These devices support the SCEP protocol, which allows for certificate requests directly from the mobile OS. Microsoft supports SCEP via the NDES service of the Certificate Services role.
For this reason, we need to install the NDES feature of Windows CAs. We will also create a specific service account which will run NDES. The service itself will be installed on the existing Enterprise Issuing CA. Moreover, we will need to:
- run the following command for IIS:
%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/requestFiltering /requestLimits.maxQueryString:”3072″ /commit:apphost
- install post-Windows 2008R2 hotfix KB2483564 that is needed for correct parsing of iOS HTTP SCEP requests.
- install, in a test machine, the software needed to create profiles for iOS to request certificates (iPhone configuration utility)
- test certificate issuance using an iPhone
This is how we request certificates for SCEP-compliant devices (in this example, iOS devices):
First, we visit the URL http://issuingca/CertSrv/MSCEP_Admin/ where we receive the password (challenge) needed to complete the certificate issuance
Retrieving the challenge string from the NDES server
After we receive the challenge string, we start the iOS configuration software, move to the configuration profiles section and create the profile needed for the certificate request. We finally select SCEP and fill in all the required values of the form. A sample request form has been captured in the following screenshot as a reference.
SCEP selection from the iPhone configuration utility
The completed form of the iPhone configuration utility
Please note: the following post describes a procedure which require Active Directory Certificate Services in an Active Directory environment, as well as Windows 2008R2 domain controller in order to work.
In order to configure the certificate template needed for SSL in RDP connections, we could create a new template based on the existing “Computer” one, via duplication (of course we could duplicate another one, but for the sake of this example we chose the Computer template). When the duplicated template settings appear we should change the following:
a) [optional] change the name and display name of the template to something descriptive of our deployment, for example “RemoteDesktopComputer” (the existence -or not- of spaces is irrelevant in ADCS)
b) [optional] change the validity of the certificate to something different than the default value
c) [required] In the “Extensions” tab, delete the “Server Authentication” and “Client authentication” Application Policies and add the “Remote Desktop Authentication” application policy.
d) [required] Configure Group Policy – we must choose whether to create a new group policy object or configure an existing one (example, default domain policy) with the following settings:
- On a domain controller, start the “Group Policy Management” administrative tool.
- Right-click the “Default Domain Policy” and click on “Edit…” in the menu that appears. The “Group Policy Management Editor” appears.
- Navigate to “Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security.”
- Double-click the “Server Authentication Certificate Template” policy.
- Enable the policy, type “RemoteDesktopComputer” (or whatever other name we gave to the template) in the “Certificate Template Name” box, and then click “OK.”
- As soon as this policy propagates to the computers that are affected by it, every server that has Remote Desktop connections enabled will automatically request a certificate based on the “RemoteDesktopComputer” template from the Certification Authority server and use it to authenticate to Remote Desktop clients. You can speed up the propagation to a specific machine by running the “gpupdate.exe” command line tool locally .
Manual Remote Desktop Connection check and configuration for Windows 2008/R2 Terminal Services servers
After the issuance of the certificates for Windows Server 2008/R2 servers, we may manually check each Windows Server 2008/R2 server as follows:
- Open Remote Desktop Session Host Configuration, in Administrative Tools, in the middle pane, we should right-click RDP-Tcp and select Properties.
- In the Select button, make sure that the certificate selected comes from the name of Issuing CA, for example ABC Bank Issuing CA. A previously issued certificate for an existing service on a server could conflict with the ones we have issued via the RDP method.
I was once contacted by one of our enterprise customers to troubleshoot a strange client-side PKI problem – an email encryption certificate could not be issued for some specific PCs.
One of the problematic clients was a Windows 7 PC. Upon starting my troubleshooting session, I saw the “One of the CA certificates is not trusted by the policy provider” event.
This usually indicates that the Issuing CA’s certificate is not published in the NTAuth container of the Active Directory. In that case, the solution would be easy and we would just need to run certutil -dspublish -f IssuingCAcert.cer NTAuthCA so as to populate the container with the missing certificate. However, this was not the case, since most clients would successfully autoenroll for an encryption certificate – the problem was present only in specific PCs.
After digging some more into the registry, it was evident that something to that effect was happening – but this time, in the client-side PKI structure. Windows PCs cache whatever certificates are found in the AD NTAuth container at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates]. This key would contain (cache) all NTAuth certificates which are propagated via group policy, which should also contain autoenrollment settings. What was found in the particular PC is that the client-side NTAuth cache was totally empty, which meant that either the NTAuth AD container
was empty (we rejected this based upon our previous observations) or the client could not successfully process its GPO(s). After running RSOP locally and opening the Group Policy Management console, we saw that the client was in an OU where the autoenrollment & encryption GPOs did not apply.
After we moved the PC to the expected OU and GPOs started “flowing”, the NTAuth client-side setting was populated and the autoenrolled encryption certificate was installed successfully.
During a recent smart card logon certificate deployment for a customer, we decided to enable the policy which disconnects a user who has logged in using a smart-card via an RDP connection if the smart card is physically removed (“Interactive logon: Smart card removal behavior” set to “Disconnect if a remote Remote Desktop Services session”). We tested it by starting the Smart Card Logon removal service (it was in manual startup state) in the Windows 2008R2 server and when we removed the smart card, the session was indeed disconnected. However, we noticed that at subsequent logons, when the smart card was re-inserted the user would login but would be immediately disconnected. After some troubleshooting, we tried disabling the Fast Logon Optimization feature (http://support.microsoft.com/kb/305293/en-us) via GPO, and after that the problem was solved. Thus, if you find yourself tackling with the same issue, it might be useful to add a custom smart-card GPO that will also force the Smart-card removal service to Automatic and disable the Fast-Logon feature and check if these actions solve your problem.
A new PKI-related hotfix has been released recently, that mitigates a problem which results in poor performance of Windows 2008R2 domain controllers and services that depend upon them (practically anything from slow user logons to Outlook timeouts).
Although there are several non-PKI parameters that might create such a problem, one more has been recently identified and a hotfix has been issued fir it – and that is slow CRL fetching. This is more likely to happen in environments were hundreds or thousands of domain controllers operate and/or CRLs have become excessively large (the article states refers to CRLs larger than than 20MB). You can find the related hotfix here.