Hi. Jim here again from Directory Services with a follow up to my Understanding Credential Roaming blog post. To review, credential roaming makes it possible to roam the user's credentials in a manageable, secure manner that is ultimately transparent to the user. What follows is a deeper dive into the inner workings of Credential Roaming. I will point out what must be setup initially and verified if you are planning to deploy Credential Roaming in your enterprise. Or you may have already deployed Credential Roaming and are interested in finding out what to check if your users report issues that would indicate their credentials are not roaming.
Potential credential roaming problems can be broken down into three major areas:
I will give you guidance on how to avoid some common problems with initial setup if you are currently planning to test and deploy credential roaming in your environment.
To help with all the different things that have to be checked Rob Greene has created a vbscript data gathering tool that can be used in a user logon script or run as a “one off” on a workstation to collect this information for you about the users in your environment. Of course, this script is provided “as is” without any warranties and it is not supported by Microsoft. This script requires CAPICOM.DLL to be deployed and registered on all workstations. I have included the link to the “CollectUserStore.vbs” script at the bottom of this post.
Let’s begin now with the initial setup.
Initial Setup
In this section I will illustrate the preliminary steps that must be taken to prepare your environment for credential roaming. These steps must be taken prior to the deployment of the credential roaming group policy.
If you are using Windows XP (pre-SP3) or Windows Server 2003 (Pre-SP2) you will need to deploy the latest credential roaming hotfixes to these operating systems before credential roaming will function properly. If you are using Windows Vista (pre-SP1) you must deploy SP1 or SP2 or you are unsupported. The following is the most recent Credential Roaming hotfix for XP at the time this blog was published:
907247 - Description of the Credential Roaming service update for Windows Server 2003 and for Windows XP - http://support.microsoft.com/default.aspx?scid=kb;EN-US;907247
and
973502 The size of the Ntds.dit file becomes larger on one or more domain controllers that are running Windows Server 2003 or Windows Server 2008 after you enable the credential roaming feature for the domain - http://support.microsoft.com/default.aspx?scid=kb;EN-US;973502
If your workstations and servers are running the latest versions of service packs then you only need install KB973502.
If you “turn on” credential roaming by configuring and applying the credential roaming group policy before deploying the 907247 hotfix or XP service pack 3 to your environment, your users might enroll for new certificates when they logon to computers where the 907247 hotfix has not been installed. This will result in differences within the certificate stores between workstations that the user logs into.
Before setting up credential roaming, one thing that we have found is that it’s best if you clean up unused user profiles from workstations and servers. If you are running Windows XP/2003 we recommend that you use DelProf.exe to clean up old or unused user profiles. This can be deployed via System Center or other management applications. If you do not have this ability you can use DelProf with a computer startup script. When a user starts to logon to multiple computers in the environment if they already have an existing profile on the computer they will start collecting old certificates and DPAPI master keys which will cause your Active Directory database size to grow. If you are using Windows Vista SP1 / 2008 or later there is a group policy setting that can be implemented in your environment that will delete older user profiles based on the number of days:
Image may be NSFW.
Clik here to view.
Computer Configuration\Policies\Administrative Templates\System\User Profiles\Delete user profiles older than a specified number of days on system restart
Client Side Problems
Profiles
It is also necessary to determine if you are using roaming profiles or folder redirection in your environment. In a large enterprise with many administrators this could prove to be a daunting task. It will be necessary to modify these policies to configure an exclusion list in Group Policy for the roaming folders required for credential roaming.
User Configuration\Administrative Templates\System\User Profiles\Exclude directories in roaming profile: Enabled
Windows XP/2003:
Application Data\Microsoft\Crypto
Application Data\Microsoft\Protect
Application Data\Microsoft\SystemCertificates
Windows Vista and higher:
AppData\Roaming\Microsoft\Credentials
AppData\Roaming\Microsoft\Crypto
AppData\Roaming\Microsoft\Protect
AppData\Roaming\Microsoft\SystemCertificates
The CollectUserStore.vbs script that is linked at the bottom of this post will detect if the folders have not been excluded as required and will report the following:
User Profile type is: Roaming
ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\Crypto
ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\Protect
ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\SystemCertificates
Credential roaming will not work properly when folder redirection has been enabled for “Application Data” when running Windows XP or Windows Server 2003. The user can face unexpected results if the previously mentioned folders are being redirected to file servers. This issue does not occur in Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008. Folder redirection in these operating systems automatically excludes the listed folders.
You can check the following locations in the registry on the client computer manually. This is where the aforementioned exclusion settings can be verified. You must check both locations below because the profile code merges the two locations.
Standard registry location:
HKEY_Current_User\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value name: ExcludeProfileDirs
Data type: REG_SZ
Group Policy registry location:
HKEY_Current_User\SOFTWARE\Policies\Microsoft\Windows\System
Value name: ExcludeProfileDirs
Data type: REG_SZ
Verify the installation of the credential roaming DLL:
Another thing to do prior to implementation is to validate the client side settings before applying the Credential Roaming group policy in test or production. If you have Windows XP or Windows Server 2003 clients you will want to make sure that DIMSNtfy.dll is listed under Winlogon in the registry as illustrated in Figure 1 below. In Windows Vista and later a new dll called dimsjob.dll replaces the dimsnotfy.dll. This new dimsjob.dll as well as dimsroam.dll and pautoenr.dll are loaded within the Task Engine Process as illustrated later.
HKEY_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\dimsntfy
Image may be NSFW.
Clik here to view.
The dimsntfy key exported –
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\dimsntfy
"Asynchronous"=dword:00000001
"DllName"=%SystemRoot%\system32\dimsntfy.dll”
"Startup"="WlDimsStartup"
"Shutdown"="WlDimsShutdown"
"Logon"="WlDimsLogon"
"Logoff"="WlDimsLogoff"
"StartShell"="WlDimsStartShell"
"Lock"="WlDimsLock"
"Unlock"="WlDimsUnlock"
We are looking for the existence and values for Winlogon Notification packages specifically the dimsntfy registry key and the values underneath it. If this key is missing, certificates are not being downloaded or uploaded from AD. It also means that the hotfix 907247 was not installed.
The CollectUserStore.vbs script will look for the existence of the DLLName value.
The error below will be displayed if the credential roaming hotfix has not been applied:
ERROR: The Credential Roaming Hotfix has not been applied or is not registered with Winlogon
On Vista and Windows 7 verify the scheduled task UserTask-Roam for credential roaming is in the ready status:
Image may be NSFW.
Clik here to view.![clip_image002[1]](http://blogs.technet.com/blogfiles/askds/WindowsLiveWriter/TroubleshootingCredentialRoaming_9B68/clip_image002%5B1%5D_thumb.jpg "clip_image002[1]")
Verify that the group policy settings are being applied to the user. Right click - export the following registry keys while logged on as the user:
HKEY_Current_User\Software\Policies\Microsoft\Cryptography\AutoEnrollment
The screenshot below is what you should expect to see on a client machine if the credential roaming group policy settings have applied successfully.
Image may be NSFW.
Clik here to view.
The AutoEnrollmentkey exported –
HKEY_CURRENT_USER\Software\Policies\Microsoft\Cryptography\AutoEnrollment
"AEPolicy"=dword:00000007
"DIMSRoaming"=dword:00000001
"DIMSRoamingTombstoneDays"=dword:0000003c
"DIMSRoamingMaxNumTokens"=dword:000007d0
"DIMSRoamingMaxTokenSize"=dword:0000ffff
After the client side settings have been validated you can begin issuing the Credential Roaming group policy to test computers and verify the policy is being applied successfully.
NOTE: DIMSRoaming registry value might be a value of 0x9 if you have Windows Vista or higher and enabled Stored User name and password roaming. Here we are looking for the group policy keys being applied to the user.
The “CollectUserStore.vbs” script will also collect this information:
Credentials Roaming Group Policy Settings appear OK
DIMSRoaming = 1
DIMSRoamingMaxNumTokens = 2000
DIMSRoamingMaxTokenSize = 65535
DIMSRoamingTombstoneDays = 60
When credential roaming is enabled there are two files created on the client machine. As a post configuration task after Credential Roaming is configured you should verify that there is a state.dat and state.da~ files in the following directory:
NOTE: You have to make sure that you can see Hidden and System files. The State.dat file acts like a traffic cop between the client machine and AD. It reconciles the certificates that are present in the user certificate store with the information that is stored in Active Directory. We can verify the last roaming time stamp on the State.dat file which will be modified whenever the credential roaming series of events occur as explained here.
If you are testing credential roaming before deploying it throughout the environment you DO NOT delete the certificates using certmgr.msc or from Internet Explorer’s internet options - content - security – certificates menu.
Image may be NSFW.
Clik here to view.
This effectively deletes the certificates from the local store. When this is done, now that credential roaming is enabled the certificate is now tombstoned. The settings for “Maximum tombstone credentials lifetime in days” is configured within the .adm template for credential roaming. It is 60 days by default. In Vista/2008 this group policy setting is integrated into the built in security settings under User Configuration. Essentially the certificate is gone because Credential Roaming not only brings the certificates down from Active Directory but also replicates deletions up to Active Directory.
The proper way to test if credential roaming is working optimally is to:
Before deploying Group Policy to enable credential roaming for client computers you should plan for the estimated growth of the Active Directory database.
Click here for more information on key sizes and a formula to determine the potential growth of the NTDS.DIT ahead of time. Keep in mind that the use of the word “Token” refers to a certificate private key, certificate public key, DPAPI Master key, and if enabled for Windows Vista each stored user name and password.
Again, make sure that you have deployed at least Vista SP1. Vista RTM is not supported, and had problems with credential roaming that could make your NTDS.DIT endlessly grow.
Taking the necessary preliminary steps to configure credential roaming and taking the time to perform initial testing in a controlled deployment will help to eliminate headaches later on.
Jim Tierney
Image may be NSFW.Hi! Jim here again to talk to you about Cryptographic Algorithms, SChannel and other bits of wonderment. So, your company purchases this new super awesome vulnerability and compliance management software suite, and they just ran a scan on your Windows Server 2008 domain controllers and lo! The software reports back that you have weak ciphers enabled, highlighted in RED, flashing, with that "you have failed" font, and including a link to the following Microsoft documentation –
KB245030 How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll:
The report may look similar to this:
SSL Server Has SSLv2 Enabled Vulnerability port 3269/tcp over SSL
THREAT:
The Secure Socket Layer (SSL) protocol allows for secure communication between a client and a server.
There are known flaws in the SSLv2 protocol. A man-in-the-middle attacker can force the communication to a less secure level and then attempt to break the weak encryption. The attacker can also truncate encrypted messages.
SOLUTION:
Disable SSLv2.
Upon hearing this information, you fire up your browser and read the aforementioned KB 245030 top to bottom and RDP into your DC’s and begin checking the locations specified by the article. Much to your dismay you notice the locations specified in the article are not correct concerning your Windows 2008 DC’s. On your 2008 DC’s you see the following at this registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Image may be NSFW.
Clik here to view.
"Darn you Microsoft documentation!!!!!!" you scream aloud as you shake your fist in the general direction of Redmond, WA….
This is how it looks on a Windows 2003 Server:
Image may be NSFW.
Clik here to view.
Easy now…
The registry key’s and their content in Windows Server 2008, Windows 7 and Windows Server 2008 R2 look different from Windows Server 2003 and prior. The referenced article isn't accurate for Windows Server 2008. I am working on getting this corrected.
Here is the registry location on Windows7 – 20008 R2 and its default contents:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel]
"EventLogging"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\CipherSuites]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Hashes]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\KeyExchangeAlgorithms]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
Allow me to explain the above content that is displayed in standard REGEDIT export format:
· The Ciphers key should contain no values or subkeys
· The CipherSuites key should contain no values or subkeys
· The Hashes key should contain no values or subkeys
· The KeyExchangeAlgorithms key should contain no values or subkeys
· The Protocols key should contain the following sub-keys and value:
Protocols
SSL 2.0
Client
DisabledByDefault REG_DWORD 0x00000001 (value)
Windows Server 2008, 2008 R2 and Windows 7 support the following Protocols:
· SSL 2.0
· SSL 3.0
· TLS 1.0
· TLS 1.1
· TLS 1.2
Similar to Windows Server 2003, these protocols can be disabled for the server or client architecture. Meaning that either the protocol can be omitted from the list of supported protocols included in the Client Hello when initiating an SSL connection, or it can be disabled on the server such that even if a client requests SSL 2.0, the server wouldn't respond with that protocol.
The client and server subkeys designate each protocol. You can disable a protocol for either the client or the server, but disabling Ciphers, Hashes, or CipherSuites affects BOTH client and server sides. You would have to create the necessary subkeys beneath the Protocols key to achieve this.
For example:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0][HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Server]
This is how it looks in the registry after they have been created:
Image may be NSFW.
Clik here to view.
Client SSL 2.0 is disabled by default on Windows Server 2008, 2008 R2 and Windows 7.
This means the computer will not use SSL 2.0 to initiate a Client Hello.
So it looks like this in the registry:
Image may be NSFW.
Clik here to view.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
Just like Ciphers and KeyExchangeAlgorithms, Protocols can be enabled or disabled.
To disable other protocols, select which side of the conversation you want to disable the protocol, and add the "Enabled"=dword:00000000 value. The example below disables the SSL 2.0 for the server in addition to the SSL 2.0 for the client.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001 <Default client disabled as I said earlier>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000 <Disables SSL 2.0 server-side>
Image may be NSFW.
Clik here to view.
After this, you will need to reboot the server. You probably do not want to disable TLS settings. I just added them here for a visual reference.
So why would you go through all this trouble to disable protocols and such, anyway? Well, there may be a regulatory requirement that your company's web servers should only support Federal Information Processing Standards (FIPS) 140-1/2 certified cryptographic algorithms and protocols. Currently, TLS is the only protocol that satisfies such a requirement. Luckily, enforcing this compliant behavior does not require you to manually modify registry settings as described above. You can enforce FIPS compliance via group policy as explained by the following:
The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows - http://support.microsoft.com/kb/811833
The 811833 article talks specifically about the group policy setting below which by default is NOT defined –
Computer Configuration\ Windows Settings \Security Settings \Local Policies\ Security Options
Image may be NSFW.
Clik here to view.
The policy above when applied will modify the following registry locations and their value content.
Be advised that this FipsAlgorithmPolicy information is stored in different ways as well –
Windows 7/2008 –
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy]
"Enabled"=dword:00000000 <Default is disabled>
Windows 2003/XP –
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
Fipsalgorithmpolicy =dword:00000000 <Default is disabled>
Enabling this group policy setting effectively disables everything except TLS.
Let’s continue with more examples. A vulnerability report may also indicate the presence of other Ciphers it deems to be “weak”. Below I have built a .reg file that when imported will disable the following Ciphers:
56-bit DES
40-bit RC4
Behold!
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 256]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000 ß We are also disabling the NULL cipher suite as well
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]
After importing these registry settings, you must reboot the server.
The vulnerability report might also mention that 40-bit DES is enabled, but that would be a false positive because Windows Server 2008 doesn't support 40-bit DES at all. For example, you might see this in a vulnerability report:
Here is the list of weak SSL ciphers supported by the remote server:
Low Strength Ciphers (< 56-bit key)
SSLv3
EXP-ADH-DES-CBC-SHA Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
TLSv1
EXP-ADH-DES-CBC-SHA Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
If this is reported and it is necessary to get rid of these entries you can also disable the Diffie-Hellman Key Exchange algorithm (another components of the two cipher suites described above -- designated with Kx=DH(512)).
To do this, make the following registry changes:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\KeyExchangeAlgorithms\Diffie-Hellman]
"Enabled"=dword:00000000
You have to create the sub-key Diffie-Hellman yourself. Make this change and reboot the server. This step is NOT advised or required….I am offering it as an option to you to make your server pass the vulnerability scanning test.
Keep in mind, also, that this will disable any cipher suite that relies upon Diffie-Hellman for key exchange.
You will probably not want to disable ANY cipher suites that rely on Diffie-Hellman. Secure communications such as IPSec and SSL both use Diffie-Hellman for key exchange. If you are running OpenVPN on a Linux/Unix server you are probably using Diffie-Hellman for key exchange. The point I am trying to make here is you should not have to disable the Diffie-Hellman Key Exchange algorithm to satisfy a vulnerability scan.
Being secure is a good thing and depending on your environment, it may be necessary to restrict certain cryptographic algorithms from use. Just make sure you do your diligence about testing these settings. It is also well worth your time to really understand how the security vulnerability software your company just purchased does it’s testing. A double-sided network trace will reveal both sides of the client server hello and what cryptographic algorithms are being offered from each side over the wire.
Jim “Insert cryptic witticism here” Tierney
Image may be NSFW.Hello. Jim here yet again to talk to you about deploying Windows Server 2008 R2 with the Network Device Enrollment Services (NDES) role in a secure perimeter network. Let's consider the scenario.
You have an internal PKI hierarchy consisting of an Offline Root Certificate Authority (CA), a policy CA, and an issuing CA. You want to deploy the server holding the NDES role to the secure perimeter network. You do not want to open any ports to facilitate communication between the internal network and the perimeter network. You want to enroll unmanaged non-Microsoft devices like iPads and iPhones using the NDES server in the perimeter network from the Internet.
Your preliminary idea looks like this:
Looks good on paper. The problem is that without any connectivity between the perimeter network and the internal AD forest, certificate enrollment via the NDES server will be impossible. There are a few options for you to consider. The first is to insist that the necessary ports opened between the perimeter network and the internal LAN, which is an uphill fight at best. Another option would be to configure the issuing CA to listen for RPC traffic on a single port, and then open that single port in the firewall. You can then use firewall rules allow traffic only between the NDES server and the CA. This requires opening a port to the internal network. Another option is to bring up a new AD forest within the perimeter network. This will require at least one domain controller, an issuing Certificate Authority, a Windows 2008 R2 server to handle the NDES role and finally a server to act as an Internet-facing HTTP CRL Distribution Point (CDP) location for all of your CAs when you first set up the PKI. Your perimeter hosts will use that to check revocation status of certificates issued by the internal and perimeter network PKI. HTTP CRL distribution point locations are ideal for providing accessible CRL locations for clients that are not running the Windows operating system.
"Why not setup a forest trust?" you may ask. Well, you would then need to punch even more holes in the firewall to establish and maintain the trust, which is sure to make your security team gnash their teeth even more than when you asked them to open up ports for the NDES server.
Good news! A forest trust is unnecessary. All we need to do is follow some specific steps concerning setting up the additional issuing CA in the perimeter network after we have created the new forest. This can be deployed quite effectively using Hyper-V or some other more costly virtualization solutions that will remain nameless.
Our new setup will look like this:
Sweet!
Configuration decisions for the perimeter network must be made including but not limited to IP settings, subnets, DNS, backup planning and management. For the sake of this blog post, I will leave those details to you and move on.
Here is a picture of how the PKI hierarchy will look on both sides of the firewall:
I am keeping it simple with one site, one subnet and the DC in the perimeter network will serve DNS only for the resources in the perimeter network. The first thing we do is bring up a new domain controller in the perimeter network and it will be the first DC for a brand new forest. This DC will also be a DNS server. Once this is accomplished, we build and join a Windows Server 2008 R2 server to the new perimeter forest. This server will be our issuing CA. We install the Certificate Services role on this member server and make it an Enterprise CA so we can leverage certificate templates.
During the configuration of the issuing CA, you have to save the certificate request to file and manually transport it to the parent CA because we do not have connectivity to the internal Root CA from the perimeter network.
Now we complete our install of the issuing CA in the perimeter network by getting the certificate back from the Root CA in the internal network and making our issuing CA operational.
You must also export the Offline Root CA certificate and publish it in the perimeter forest using the following certutil.exe command:
certutil.exe -dspublish -f filename.CER RootCA
Since this is a Windows Server 2008 Active Directory forest we must enable Certificate Services Client – Auto-Enrollment. This can be accomplished by creating a new Group Policy object or configured within the default domain policy as explained here – http://technet.microsoft.com/en-us/library/cc731522.aspx
This will propagate the Root certificate down to the trusted root store on all domain joined computers via Group Policy. This will establish your internal Root CA as a trust anchor in the perimeter forest.
Next, bring a server online in the DMZ to be the repository for all the CRLs for every CA that is involved. This server has the IIS role installed and will be configured as a CDP on all the certificates issued by the perimeter forests issuing CA.
To specify the Web Server as the CDP you will have to perform the following tasks on the internal ROOT CA and on the issuing CA server in the perimeter forest in that order. This will enable both to publish their CRLs to this location as well as including that CDP path on the certificate the ROOT CA issues to the issuing CA in the DMZ forest:
Load Certification Authority management console.
Right-click your CA, select Properties, and then click the Extensions tab.
With CRL Distribution Point (CDP) selected
Click Add.
In the Add Location dialog box, type the following and then click OK:
http://<FQDN_of_Web_Server/<CRL_directory_name>/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
For example, if your Web server is called crlserver.ExtForest.com and the virtual directory you created in IIS was called CRL, you would type:
http://crlserver.ExtForest.com/crl/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
The following options will be selected for this new entry and are highlighted in the above screen capture:
It will be necessary to copy the CRLs for the internal PKI hierarchy to the HTTP location in the perimeter forest. This can be accomplished via script or scheduled task leveraging robocopy and a service account in the perimeter forest.
You can then proceed with the installation of the NDES role on the Windows Server 2008 R2 member server in the perimeter forest. Steps for configuration are illustrated in detail here.
The CA in the DMZ should probably have a Hardware Security Module HSM as this network isn't safe.
After installing the NDES role, you may install the certificate authority web enrollment pages, as these are not installed by default when you install the NDES role nor are they needed. The ISAPI .DLL will intercept any requests for mscep_admin, or mscep so you don’t need an actual certsrv/mscep_admin virtual directory. However, if it makes you happy to open up IIS management and see the virtual directories there, have at it!
Something else to remember is if you install both Web Enrollment and NDES on the same server, depending on the order, anonymous access to the mscep virtual directory may be turned off. Anonymous access must be enabled on the mscep virtual directory so that NDES clients, without accounts, can submit requests.
Now you are cruising through the NDES install and get to the end. Much to your chagrin, you are confronted with the following error:
Element not found. 0x80070490 (WIN32: 1168)
Huh?
You verify the permissions on the following templates:
Authenticated Users – Read and Enroll
NDES service account – Read and Enroll
Domain Admins – Read, Write and Enroll
Enterprise Admins – Read, Write and Enroll
You test accessibility to the templates by logging in to the NDES server with an Enterprise Administrator account and then running the Computer Certificates MMC and attempting to enroll against the aforementioned templates. When the available templates window opens in the Computer Certificates MMC, nothing is listed.
You then take a network trace of the Computer Certificates MMC attempt at manual enrollment and observe the following:
618 192.168.124.121 10.0.2.69 LDAP searchRequest(60) "CN=CA Policy CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=Contoso,DC=COM" baseObject
619 10.0.2.69 192.168.124.121 LDAP searchResDone(60) operationsError (00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece) [0 results]
Frame 618 indicates that we are attempting to complete the chaining to a Policy CA certificate as part of the verification of the issuing CA's certificate. Remember the CA hierarchy from our internal forest in the diagram above.
We cannot access that LDAP path in the other forest from the perimeter network. The query fails as reported in frame 619 and so does the ability to enroll against any templates published by the subordinate CA in the perimeter forest.
Now we must export the Policy CA certificate from the internal forest and copy it to a domain joined computer in the perimeter forest and run the following command:
certutil.exe -f -dspublish policyca.cer SubCA
Autoenrollment, which is configured and in place will download the Policy CA certificate to the intermediate store on any domain joined computer.
Computer Autoenrollment runs when the computer is started and every 8 hours thereafter. You can force Computer Autoenrollment to run by running:
certutil.exe -pulse
Now the install of the NDES server will complete without error.
I deliberately skipped the Policy CA certificate -dspublish step to show you the kind of cryptic error you will receive during the install in this particular instance.
After you have accomplished all of the aforementioned please install the following hotfix as well:
2483564 Renewal request for an SCEP certificate fails in Windows Server 2008 R2 if the certificate is managed by using NDES - http://support.microsoft.com/kb/2483564
Now you have a relatively secure environment where you can leverage NDES for device certificate enrollment and renewal without opening up your internal LAN to the DMZ. There is understandably a lot of overhead in this design as we are working around the limitations placed on access to the internal network through the firewall. For information on non-Windows device enrollment, please refer back to this spectacular blog post written by my colleague Robert Greene.
Until next time.
Jim "Daily Double" Tierney
Image may be NSFW.It’s been four years and 591 posts since AskDS reached critical mass. You’d hope our party would look like this:
Image may be NSFW.
Clik here to view.
But it’s more likely to be:
Image may be NSFW.
Clik here to view.
Without you, we’d be another of those sites that glow red hot, go supernova, then collapse into a white dwarf. We really appreciate your comments, questions, and occasional attaboys. Hopefully we’re good for another year of insightful commentary.
Thanks readers.
The AskDS Contributors
Image may be NSFW.Hello. Jim here again to elucidate on the wonderment of change notification as it relates to Active Directory replication within and between sites. As you know Active Directory replication between domain controllers within the same site (intrasite) happens instantaneously. Active Directory replication between sites (intersite) occurs every 180 minutes (3 hours) by default. You can adjust this frequency to match your specific needs BUT it can be no faster than fifteen minutes when configured via the AD Sites and Services snap-in.
Back in the old days when remote sites were connected by a string and two soup cans, it was necessary in most cases to carefully consider configuring your replication intervals and times so as not to flood the pipe (or string in the reference above) with replication traffic and bring your WAN to a grinding halt. With dial up connections between sites it was even more important. It remains an important consideration today if your site is a ship at sea and your only connectivity is a satellite link that could be obscured by a cloud of space debris.
Now in the days of wicked fast fiber links and MPLS VPN Connectivity, change notification may be enabled between site links that can span geographic locations. This will make Active Directory replication instantaneous between the separate sites as if the replication partners were in the same site. Although this is well documented on TechNet and I hate regurgitating existing content, here is how you would configure change notification on a site link:
Image may be NSFW.
Clik here to view.
There is one caveat however. Change notification will fail with manual connection objects. If your connection objects are not created by the KCC the change notification setting is meaningless. If it's a manual connection object, it will NOT inherit the Options bit from the Site Link. Enjoy your 15 minute replication latency.
Why would you want to keep connection objects you created manually, anyway? Why don't you just let the KCC do its thing and be happy? Maybe you have a Site Link costing configuration that you would rather not change. Perhaps you are at the mercy of your networking team and the routing of your network and you must keep these manual connections. If, for whatever reason you must keep the manually created replication partners, be of good cheer. You can still enjoy the thrill of change notification.
Change Notification on a manually created replication partner is configured by doing the following:
Image may be NSFW.
Clik here to view.
If the value is anything other than zero, you must do some binary math. Relax; this is going to be fun.
On the Site Link object, it's the 1st bit that controls change notification. On the Connection object, however, it's the 4th bit. The 4th bit is highlighted in RED below represented in binary (You remember binary don't you???)
Binary Bit | 8th | 7th | 6th | 5th | 4th | 3rd | 2nd | 1st |
Decimal Value | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
NOTE: The values represented by each bit in the Options attribute are documented in the Active Directory Technical Specification. Fair warning! I'm only including that information for the curious. I STRONGLY recommend against setting any of the options NOT discussed specifically in existing documentation or blogs in your production environment.
Remember what I said earlier? If it's a manual connection object, it will NOT inherit the Options value from the Site Link object. You're going to have to enable change notifications directly on the manually created connection object.
Take the value of the Options attribute, let's say it is 16.
Open Calc.exe in Programmer mode, and paste the contents of your options attribute.
Image may be NSFW.
Clik here to view.
Click on Bin, and count over to the 4th bit starting from the right.
Image may be NSFW.
Clik here to view.
That's the bit that controls change notification on your manually created replication partner. As you can see, in this example it is zero (0), so change notifications are disabled.
Convert back to decimal and add 8 to it.
Image may be NSFW.
Clik here to view.
Click on Bin, again.
Image may be NSFW.
Clik here to view.
As you can see above, the bit that controls change notification on the manually created replication partner is now 1. You would then change the Options value in ADSIEDIT from 16 to 24.
Image may be NSFW.
Clik here to view.
Click on Ok to commit the change.
Congratulations! You have now configured change notification on your manually created connection object. This sequence of events must be repeated for each manually created connection object that you want to include in the excitement and instantaneous gratification of change notification. Keep in mind that in the event something (or many things) gets deleted from a domain controller, you no longer have that window of intersite latency to stop inbound replication on a downstream partner and do an authoritative restore. Plan the configuration of change notifications accordingly. Make sure you take regular backups, and test them occasionally!
And when you speak of me, speak well…
Jim "changes aren't permanent, but change is" Tierney
Image may be NSFW.
Hi. Jim here again from Directory Services with a follow up to my Understanding Credential Roaming blog post. To review, credential roaming makes it possible to roam the user's credentials in a manageable, secure manner that is ultimately transparent to the user. What follows is a deeper dive into the inner workings of Credential Roaming. I will point out what must be setup initially and verified if you are planning to deploy Credential Roaming in your enterprise. Or you may have already deployed Credential Roaming and are interested in finding out what to check if your users report issues that would indicate their credentials are not roaming.
Potential credential roaming problems can be broken down into three major areas:
I will give you guidance on how to avoid some common problems with initial setup if you are currently planning to test and deploy credential roaming in your environment.
To help with all the different things that have to be checked Rob Greene has created a vbscript data gathering tool that can be used in a user logon script or run as a “one off” on a workstation to collect this information for you about the users in your environment. Of course, this script is provided “as is” without any warranties and it is not supported by Microsoft. This script requires CAPICOM.DLL to be deployed and registered on all workstations. I have included the link to the “CollectUserStore.vbs” script at the bottom of this post.
Let’s begin now with the initial setup.
Initial Setup
In this section I will illustrate the preliminary steps that must be taken to prepare your environment for credential roaming. These steps must be taken prior to the deployment of the credential roaming group policy.
If you are using Windows XP (pre-SP3) or Windows Server 2003 (Pre-SP2) you will need to deploy the latest credential roaming hotfixes to these operating systems before credential roaming will function properly. If you are using Windows Vista (pre-SP1) you must deploy SP1 or SP2 or you are unsupported. The following is the most recent Credential Roaming hotfix for XP at the time this blog was published:
907247 - Description of the Credential Roaming service update for Windows Server 2003 and for Windows XP - http://support.microsoft.com/default.aspx?scid=kb;EN-US;907247
and
973502 The size of the Ntds.dit file becomes larger on one or more domain controllers that are running Windows Server 2003 or Windows Server 2008 after you enable the credential roaming feature for the domain - http://support.microsoft.com/default.aspx?scid=kb;EN-US;973502
If your workstations and servers are running the latest versions of service packs then you only need install KB973502.
If you “turn on” credential roaming by configuring and applying the credential roaming group policy before deploying the 907247 hotfix or XP service pack 3 to your environment, your users might enroll for new certificates when they logon to computers where the 907247 hotfix has not been installed. This will result in differences within the certificate stores between workstations that the user logs into.
Before setting up credential roaming, one thing that we have found is that it’s best if you clean up unused user profiles from workstations and servers. If you are running Windows XP/2003 we recommend that you use DelProf.exe to clean up old or unused user profiles. This can be deployed via System Center or other management applications. If you do not have this ability you can use DelProf with a computer startup script. When a user starts to logon to multiple computers in the environment if they already have an existing profile on the computer they will start collecting old certificates and DPAPI master keys which will cause your Active Directory database size to grow. If you are using Windows Vista SP1 / 2008 or later there is a group policy setting that can be implemented in your environment that will delete older user profiles based on the number of days:
Image may be NSFW.
Clik here to view.
Computer Configuration\Policies\Administrative Templates\System\User Profiles\Delete user profiles older than a specified number of days on system restart
Client Side Problems
Profiles
It is also necessary to determine if you are using roaming profiles or folder redirection in your environment. In a large enterprise with many administrators this could prove to be a daunting task. It will be necessary to modify these policies to configure an exclusion list in Group Policy for the roaming folders required for credential roaming.
User Configuration\Administrative Templates\System\User Profiles\Exclude directories in roaming profile: Enabled
Windows XP/2003:
Application Data\Microsoft\Crypto
Application Data\Microsoft\Protect
Application Data\Microsoft\SystemCertificates
Windows Vista and higher:
AppData\Roaming\Microsoft\Credentials
AppData\Roaming\Microsoft\Crypto
AppData\Roaming\Microsoft\Protect
AppData\Roaming\Microsoft\SystemCertificates
The CollectUserStore.vbs script that is linked at the bottom of this post will detect if the folders have not been excluded as required and will report the following:
User Profile type is: Roaming
ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\Crypto
ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\Protect
ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\SystemCertificates
Credential roaming will not work properly when folder redirection has been enabled for “Application Data” when running Windows XP or Windows Server 2003. The user can face unexpected results if the previously mentioned folders are being redirected to file servers. This issue does not occur in Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008. Folder redirection in these operating systems automatically excludes the listed folders.
You can check the following locations in the registry on the client computer manually. This is where the aforementioned exclusion settings can be verified. You must check both locations below because the profile code merges the two locations.
Standard registry location:
HKEY_Current_User\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value name: ExcludeProfileDirs
Data type: REG_SZ
Group Policy registry location:
HKEY_Current_User\SOFTWARE\Policies\Microsoft\Windows\System
Value name: ExcludeProfileDirs
Data type: REG_SZ
Verify the installation of the credential roaming DLL:
Another thing to do prior to implementation is to validate the client side settings before applying the Credential Roaming group policy in test or production. If you have Windows XP or Windows Server 2003 clients you will want to make sure that DIMSNtfy.dll is listed under Winlogon in the registry as illustrated in Figure 1 below. In Windows Vista and later a new dll called dimsjob.dll replaces the dimsnotfy.dll. This new dimsjob.dll as well as dimsroam.dll and pautoenr.dll are loaded within the Task Engine Process as illustrated later.
HKEY_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\dimsntfy
Image may be NSFW.
Clik here to view.
The dimsntfy key exported –
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\dimsntfy
"Asynchronous"=dword:00000001
"DllName"=%SystemRoot%\system32\dimsntfy.dll”
"Startup"="WlDimsStartup"
"Shutdown"="WlDimsShutdown"
"Logon"="WlDimsLogon"
"Logoff"="WlDimsLogoff"
"StartShell"="WlDimsStartShell"
"Lock"="WlDimsLock"
"Unlock"="WlDimsUnlock"
We are looking for the existence and values for Winlogon Notification packages specifically the dimsntfy registry key and the values underneath it. If this key is missing, certificates are not being downloaded or uploaded from AD. It also means that the hotfix 907247 was not installed.
The CollectUserStore.vbs script will look for the existence of the DLLName value.
The error below will be displayed if the credential roaming hotfix has not been applied:
ERROR: The Credential Roaming Hotfix has not been applied or is not registered with Winlogon
On Vista and Windows 7 verify the scheduled task UserTask-Roam for credential roaming is in the ready status:
Image may be NSFW.
Clik here to view.
Verify that the group policy settings are being applied to the user. Right click - export the following registry keys while logged on as the user:
HKEY_Current_User\Software\Policies\Microsoft\Cryptography\AutoEnrollment
The screenshot below is what you should expect to see on a client machine if the credential roaming group policy settings have applied successfully.
Image may be NSFW.
Clik here to view.
The AutoEnrollmentkey exported –
HKEY_CURRENT_USER\Software\Policies\Microsoft\Cryptography\AutoEnrollment
"AEPolicy"=dword:00000007
"DIMSRoaming"=dword:00000001
"DIMSRoamingTombstoneDays"=dword:0000003c
"DIMSRoamingMaxNumTokens"=dword:000007d0
"DIMSRoamingMaxTokenSize"=dword:0000ffff
After the client side settings have been validated you can begin issuing the Credential Roaming group policy to test computers and verify the policy is being applied successfully.
NOTE: DIMSRoaming registry value might be a value of 0x9 if you have Windows Vista or higher and enabled Stored User name and password roaming. Here we are looking for the group policy keys being applied to the user.
The “CollectUserStore.vbs” script will also collect this information:
Credentials Roaming Group Policy Settings appear OK
DIMSRoaming = 1
DIMSRoamingMaxNumTokens = 2000
DIMSRoamingMaxTokenSize = 65535
DIMSRoamingTombstoneDays = 60
When credential roaming is enabled there are two files created on the client machine. As a post configuration task after Credential Roaming is configured you should verify that there is a state.dat and state.da~ files in the following directory:
NOTE: You have to make sure that you can see Hidden and System files. The State.dat file acts like a traffic cop between the client machine and AD. It reconciles the certificates that are present in the user certificate store with the information that is stored in Active Directory. We can verify the last roaming time stamp on the State.dat file which will be modified whenever the credential roaming series of events occur as explained here.
If you are testing credential roaming before deploying it throughout the environment you DO NOT delete the certificates using certmgr.msc or from Internet Explorer’s internet options - content - security – certificates menu.
Image may be NSFW.
Clik here to view.
This effectively deletes the certificates from the local store. When this is done, now that credential roaming is enabled the certificate is now tombstoned. The settings for “Maximum tombstone credentials lifetime in days” is configured within the .adm template for credential roaming. It is 60 days by default. In Vista/2008 this group policy setting is integrated into the built in security settings under User Configuration. Essentially the certificate is gone because Credential Roaming not only brings the certificates down from Active Directory but also replicates deletions up to Active Directory.
The proper way to test if credential roaming is working optimally is to:
Before deploying Group Policy to enable credential roaming for client computers you should plan for the estimated growth of the Active Directory database.
Click here for more information on key sizes and a formula to determine the potential growth of the NTDS.DIT ahead of time. Keep in mind that the use of the word “Token” refers to a certificate private key, certificate public key, DPAPI Master key, and if enabled for Windows Vista each stored user name and password.
Again, make sure that you have deployed at least Vista SP1. Vista RTM is not supported, and had problems with credential roaming that could make your NTDS.DIT endlessly grow.
Taking the necessary preliminary steps to configure credential roaming and taking the time to perform initial testing in a controlled deployment will help to eliminate headaches later on.
Jim Tierney
Image may be NSFW.Hi! Jim here again to talk to you about Cryptographic Algorithms, SChannel and other bits of wonderment. So, your company purchases this new super awesome vulnerability and compliance management software suite, and they just ran a scan on your Windows Server 2008 domain controllers and lo! The software reports back that you have weak ciphers enabled, highlighted in RED, flashing, with that "you have failed" font, and including a link to the following Microsoft documentation –
KB245030 How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll:
The report may look similar to this:
SSL Server Has SSLv2 Enabled Vulnerability port 3269/tcp over SSL
THREAT:
The Secure Socket Layer (SSL) protocol allows for secure communication between a client and a server.
There are known flaws in the SSLv2 protocol. A man-in-the-middle attacker can force the communication to a less secure level and then attempt to break the weak encryption. The attacker can also truncate encrypted messages.
SOLUTION:
Disable SSLv2.
Upon hearing this information, you fire up your browser and read the aforementioned KB 245030 top to bottom and RDP into your DC’s and begin checking the locations specified by the article. Much to your dismay you notice the locations specified in the article are not correct concerning your Windows 2008 DC’s. On your 2008 DC’s you see the following at this registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Image may be NSFW.
Clik here to view.
"Darn you Microsoft documentation!!!!!!" you scream aloud as you shake your fist in the general direction of Redmond, WA….
This is how it looks on a Windows 2003 Server:
Image may be NSFW.
Clik here to view.
Easy now…
The registry key’s and their content in Windows Server 2008, Windows 7 and Windows Server 2008 R2 look different from Windows Server 2003 and prior. The referenced article isn't accurate for Windows Server 2008. I am working on getting this corrected.
Here is the registry location on Windows7 – 20008 R2 and its default contents:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel]
"EventLogging"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\CipherSuites]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Hashes]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\KeyExchangeAlgorithms]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
Allow me to explain the above content that is displayed in standard REGEDIT export format:
· The Ciphers key should contain no values or subkeys
· The CipherSuites key should contain no values or subkeys
· The Hashes key should contain no values or subkeys
· The KeyExchangeAlgorithms key should contain no values or subkeys
· The Protocols key should contain the following sub-keys and value:
Protocols
SSL 2.0
Client
DisabledByDefault REG_DWORD 0x00000001 (value)
Windows Server 2008, 2008 R2 and Windows 7 support the following Protocols:
· SSL 2.0
· SSL 3.0
· TLS 1.0
· TLS 1.1
· TLS 1.2
Similar to Windows Server 2003, these protocols can be disabled for the server or client architecture. Meaning that either the protocol can be omitted from the list of supported protocols included in the Client Hello when initiating an SSL connection, or it can be disabled on the server such that even if a client requests SSL 2.0, the server wouldn't respond with that protocol.
The client and server subkeys designate each protocol. You can disable a protocol for either the client or the server, but disabling Ciphers, Hashes, or CipherSuites affects BOTH client and server sides. You would have to create the necessary subkeys beneath the Protocols key to achieve this.
For example:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0][HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Server]
This is how it looks in the registry after they have been created:
Image may be NSFW.
Clik here to view.
Client SSL 2.0 is disabled by default on Windows Server 2008, 2008 R2 and Windows 7.
This means the computer will not use SSL 2.0 to initiate a Client Hello.
So it looks like this in the registry:
Image may be NSFW.
Clik here to view.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
Just like Ciphers and KeyExchangeAlgorithms, Protocols can be enabled or disabled.
To disable other protocols, select which side of the conversation you want to disable the protocol, and add the "Enabled"=dword:00000000 value. The example below disables the SSL 2.0 for the server in addition to the SSL 2.0 for the client.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001 <Default client disabled as I said earlier>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000 <Disables SSL 2.0 server-side>
Image may be NSFW.
Clik here to view.
After this, you will need to reboot the server. You probably do not want to disable TLS settings. I just added them here for a visual reference.
So why would you go through all this trouble to disable protocols and such, anyway? Well, there may be a regulatory requirement that your company's web servers should only support Federal Information Processing Standards (FIPS) 140-1/2 certified cryptographic algorithms and protocols. Currently, TLS is the only protocol that satisfies such a requirement. Luckily, enforcing this compliant behavior does not require you to manually modify registry settings as described above. You can enforce FIPS compliance via group policy as explained by the following:
The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows - http://support.microsoft.com/kb/811833
The 811833 article talks specifically about the group policy setting below which by default is NOT defined –
Computer Configuration\ Windows Settings \Security Settings \Local Policies\ Security Options
Image may be NSFW.
Clik here to view.
The policy above when applied will modify the following registry locations and their value content.
Be advised that this FipsAlgorithmPolicy information is stored in different ways as well –
Windows 7/2008 –
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy]
"Enabled"=dword:00000000 <Default is disabled>
Windows 2003/XP –
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
Fipsalgorithmpolicy =dword:00000000 <Default is disabled>
Enabling this group policy setting effectively disables everything except TLS.
Let’s continue with more examples. A vulnerability report may also indicate the presence of other Ciphers it deems to be “weak”. Below I have built a .reg file that when imported will disable the following Ciphers:
56-bit DES
40-bit RC4
Behold!
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 256]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000 ß We are also disabling the NULL cipher suite as well
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]
After importing these registry settings, you must reboot the server.
The vulnerability report might also mention that 40-bit DES is enabled, but that would be a false positive because Windows Server 2008 doesn't support 40-bit DES at all. For example, you might see this in a vulnerability report:
Here is the list of weak SSL ciphers supported by the remote server:
Low Strength Ciphers (< 56-bit key)
SSLv3
EXP-ADH-DES-CBC-SHA Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
TLSv1
EXP-ADH-DES-CBC-SHA Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
If this is reported and it is necessary to get rid of these entries you can also disable the Diffie-Hellman Key Exchange algorithm (another components of the two cipher suites described above -- designated with Kx=DH(512)).
To do this, make the following registry changes:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\KeyExchangeAlgorithms\Diffie-Hellman]
"Enabled"=dword:00000000
You have to create the sub-key Diffie-Hellman yourself. Make this change and reboot the server. This step is NOT advised or required….I am offering it as an option to you to make your server pass the vulnerability scanning test.
Keep in mind, also, that this will disable any cipher suite that relies upon Diffie-Hellman for key exchange.
You will probably not want to disable ANY cipher suites that rely on Diffie-Hellman. Secure communications such as IPSec and SSL both use Diffie-Hellman for key exchange. If you are running OpenVPN on a Linux/Unix server you are probably using Diffie-Hellman for key exchange. The point I am trying to make here is you should not have to disable the Diffie-Hellman Key Exchange algorithm to satisfy a vulnerability scan.
Being secure is a good thing and depending on your environment, it may be necessary to restrict certain cryptographic algorithms from use. Just make sure you do your diligence about testing these settings. It is also well worth your time to really understand how the security vulnerability software your company just purchased does it’s testing. A double-sided network trace will reveal both sides of the client server hello and what cryptographic algorithms are being offered from each side over the wire.
Jim “Insert cryptic witticism here” Tierney
Image may be NSFW.Hello. Jim here yet again to talk to you about deploying Windows Server 2008 R2 with the Network Device Enrollment Services (NDES) role in a secure perimeter network. Let's consider the scenario.
You have an internal PKI hierarchy consisting of an Offline Root Certificate Authority (CA), a policy CA, and an issuing CA. You want to deploy the server holding the NDES role to the secure perimeter network. You do not want to open any ports to facilitate communication between the internal network and the perimeter network. You want to enroll unmanaged non-Microsoft devices like iPads and iPhones using the NDES server in the perimeter network from the Internet.
Your preliminary idea looks like this:
Looks good on paper. The problem is that without any connectivity between the perimeter network and the internal AD forest, certificate enrollment via the NDES server will be impossible. There are a few options for you to consider. The first is to insist that the necessary ports opened between the perimeter network and the internal LAN, which is an uphill fight at best. Another option would be to configure the issuing CA to listen for RPC traffic on a single port, and then open that single port in the firewall. You can then use firewall rules allow traffic only between the NDES server and the CA. This requires opening a port to the internal network. Another option is to bring up a new AD forest within the perimeter network. This will require at least one domain controller, an issuing Certificate Authority, a Windows 2008 R2 server to handle the NDES role and finally a server to act as an Internet-facing HTTP CRL Distribution Point (CDP) location for all of your CAs when you first set up the PKI. Your perimeter hosts will use that to check revocation status of certificates issued by the internal and perimeter network PKI. HTTP CRL distribution point locations are ideal for providing accessible CRL locations for clients that are not running the Windows operating system.
"Why not setup a forest trust?" you may ask. Well, you would then need to punch even more holes in the firewall to establish and maintain the trust, which is sure to make your security team gnash their teeth even more than when you asked them to open up ports for the NDES server.
Good news! A forest trust is unnecessary. All we need to do is follow some specific steps concerning setting up the additional issuing CA in the perimeter network after we have created the new forest. This can be deployed quite effectively using Hyper-V or some other more costly virtualization solutions that will remain nameless.
Our new setup will look like this:
Sweet!
Configuration decisions for the perimeter network must be made including but not limited to IP settings, subnets, DNS, backup planning and management. For the sake of this blog post, I will leave those details to you and move on.
Here is a picture of how the PKI hierarchy will look on both sides of the firewall:
I am keeping it simple with one site, one subnet and the DC in the perimeter network will serve DNS only for the resources in the perimeter network. The first thing we do is bring up a new domain controller in the perimeter network and it will be the first DC for a brand new forest. This DC will also be a DNS server. Once this is accomplished, we build and join a Windows Server 2008 R2 server to the new perimeter forest. This server will be our issuing CA. We install the Certificate Services role on this member server and make it an Enterprise CA so we can leverage certificate templates.
During the configuration of the issuing CA, you have to save the certificate request to file and manually transport it to the parent CA because we do not have connectivity to the internal Root CA from the perimeter network.
Now we complete our install of the issuing CA in the perimeter network by getting the certificate back from the Root CA in the internal network and making our issuing CA operational.
You must also export the Offline Root CA certificate and publish it in the perimeter forest using the following certutil.exe command:
certutil.exe -dspublish -f filename.CER RootCA
Since this is a Windows Server 2008 Active Directory forest we must enable Certificate Services Client – Auto-Enrollment. This can be accomplished by creating a new Group Policy object or configured within the default domain policy as explained here – http://technet.microsoft.com/en-us/library/cc731522.aspx
This will propagate the Root certificate down to the trusted root store on all domain joined computers via Group Policy. This will establish your internal Root CA as a trust anchor in the perimeter forest.
Next, bring a server online in the DMZ to be the repository for all the CRLs for every CA that is involved. This server has the IIS role installed and will be configured as a CDP on all the certificates issued by the perimeter forests issuing CA.
To specify the Web Server as the CDP you will have to perform the following tasks on the internal ROOT CA and on the issuing CA server in the perimeter forest in that order. This will enable both to publish their CRLs to this location as well as including that CDP path on the certificate the ROOT CA issues to the issuing CA in the DMZ forest:
Load Certification Authority management console.
Right-click your CA, select Properties, and then click the Extensions tab.
With CRL Distribution Point (CDP) selected
Click Add.
In the Add Location dialog box, type the following and then click OK:
http://<FQDN_of_Web_Server/<CRL_directory_name>/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
For example, if your Web server is called crlserver.ExtForest.com and the virtual directory you created in IIS was called CRL, you would type:
http://crlserver.ExtForest.com/crl/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
The following options will be selected for this new entry and are highlighted in the above screen capture:
It will be necessary to copy the CRLs for the internal PKI hierarchy to the HTTP location in the perimeter forest. This can be accomplished via script or scheduled task leveraging robocopy and a service account in the perimeter forest.
You can then proceed with the installation of the NDES role on the Windows Server 2008 R2 member server in the perimeter forest. Steps for configuration are illustrated in detail here.
The CA in the DMZ should probably have a Hardware Security Module HSM as this network isn't safe.
After installing the NDES role, you may install the certificate authority web enrollment pages, as these are not installed by default when you install the NDES role nor are they needed. The ISAPI .DLL will intercept any requests for mscep_admin, or mscep so you don’t need an actual certsrv/mscep_admin virtual directory. However, if it makes you happy to open up IIS management and see the virtual directories there, have at it!
Something else to remember is if you install both Web Enrollment and NDES on the same server, depending on the order, anonymous access to the mscep virtual directory may be turned off. Anonymous access must be enabled on the mscep virtual directory so that NDES clients, without accounts, can submit requests.
Now you are cruising through the NDES install and get to the end. Much to your chagrin, you are confronted with the following error:
Element not found. 0x80070490 (WIN32: 1168)
Huh?
You verify the permissions on the following templates:
Authenticated Users – Read and Enroll
NDES service account – Read and Enroll
Domain Admins – Read, Write and Enroll
Enterprise Admins – Read, Write and Enroll
You test accessibility to the templates by logging in to the NDES server with an Enterprise Administrator account and then running the Computer Certificates MMC and attempting to enroll against the aforementioned templates. When the available templates window opens in the Computer Certificates MMC, nothing is listed.
You then take a network trace of the Computer Certificates MMC attempt at manual enrollment and observe the following:
618 192.168.124.121 10.0.2.69 LDAP searchRequest(60) "CN=CA Policy CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=Contoso,DC=COM" baseObject
619 10.0.2.69 192.168.124.121 LDAP searchResDone(60) operationsError (00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece) [0 results]
Frame 618 indicates that we are attempting to complete the chaining to a Policy CA certificate as part of the verification of the issuing CA's certificate. Remember the CA hierarchy from our internal forest in the diagram above.
We cannot access that LDAP path in the other forest from the perimeter network. The query fails as reported in frame 619 and so does the ability to enroll against any templates published by the subordinate CA in the perimeter forest.
Now we must export the Policy CA certificate from the internal forest and copy it to a domain joined computer in the perimeter forest and run the following command:
certutil.exe -f -dspublish policyca.cer SubCA
Autoenrollment, which is configured and in place will download the Policy CA certificate to the intermediate store on any domain joined computer.
Computer Autoenrollment runs when the computer is started and every 8 hours thereafter. You can force Computer Autoenrollment to run by running:
certutil.exe -pulse
Now the install of the NDES server will complete without error.
I deliberately skipped the Policy CA certificate -dspublish step to show you the kind of cryptic error you will receive during the install in this particular instance.
After you have accomplished all of the aforementioned please install the following hotfix as well:
2483564 Renewal request for an SCEP certificate fails in Windows Server 2008 R2 if the certificate is managed by using NDES - http://support.microsoft.com/kb/2483564
Now you have a relatively secure environment where you can leverage NDES for device certificate enrollment and renewal without opening up your internal LAN to the DMZ. There is understandably a lot of overhead in this design as we are working around the limitations placed on access to the internal network through the firewall. For information on non-Windows device enrollment, please refer back to this spectacular blog post written by my colleague Robert Greene.
Until next time.
Jim "Daily Double" Tierney
Image may be NSFW.It’s been four years and 591 posts since AskDS reached critical mass. You’d hope our party would look like this:
Image may be NSFW.
Clik here to view.
But it’s more likely to be:
Image may be NSFW.
Clik here to view.
Without you, we’d be another of those sites that glow red hot, go supernova, then collapse into a white dwarf. We really appreciate your comments, questions, and occasional attaboys. Hopefully we’re good for another year of insightful commentary.
Thanks readers.
The AskDS Contributors
Image may be NSFW.Hello. Jim here again to elucidate on the wonderment of change notification as it relates to Active Directory replication within and between sites. As you know Active Directory replication between domain controllers within the same site (intrasite) happens instantaneously. Active Directory replication between sites (intersite) occurs every 180 minutes (3 hours) by default. You can adjust this frequency to match your specific needs BUT it can be no faster than fifteen minutes when configured via the AD Sites and Services snap-in.
Back in the old days when remote sites were connected by a string and two soup cans, it was necessary in most cases to carefully consider configuring your replication intervals and times so as not to flood the pipe (or string in the reference above) with replication traffic and bring your WAN to a grinding halt. With dial up connections between sites it was even more important. It remains an important consideration today if your site is a ship at sea and your only connectivity is a satellite link that could be obscured by a cloud of space debris.
Now in the days of wicked fast fiber links and MPLS VPN Connectivity, change notification may be enabled between site links that can span geographic locations. This will make Active Directory replication instantaneous between the separate sites as if the replication partners were in the same site. Although this is well documented on TechNet and I hate regurgitating existing content, here is how you would configure change notification on a site link:
Image may be NSFW.
Clik here to view.
There is one caveat however. Change notification will fail with manual connection objects. If your connection objects are not created by the KCC the change notification setting is meaningless. If it's a manual connection object, it will NOT inherit the Options bit from the Site Link. Enjoy your 15 minute replication latency.
Why would you want to keep connection objects you created manually, anyway? Why don't you just let the KCC do its thing and be happy? Maybe you have a Site Link costing configuration that you would rather not change. Perhaps you are at the mercy of your networking team and the routing of your network and you must keep these manual connections. If, for whatever reason you must keep the manually created replication partners, be of good cheer. You can still enjoy the thrill of change notification.
Change Notification on a manually created replication partner is configured by doing the following:
Image may be NSFW.
Clik here to view.
If the value is anything other than zero, you must do some binary math. Relax; this is going to be fun.
On the Site Link object, it's the 1st bit that controls change notification. On the Connection object, however, it's the 4th bit. The 4th bit is highlighted in RED below represented in binary (You remember binary don't you???)
Binary Bit | 8th | 7th | 6th | 5th | 4th | 3rd | 2nd | 1st |
Decimal Value | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
NOTE: The values represented by each bit in the Options attribute are documented in the Active Directory Technical Specification. Fair warning! I'm only including that information for the curious. I STRONGLY recommend against setting any of the options NOT discussed specifically in existing documentation or blogs in your production environment.
Remember what I said earlier? If it's a manual connection object, it will NOT inherit the Options value from the Site Link object. You're going to have to enable change notifications directly on the manually created connection object.
Take the value of the Options attribute, let's say it is 16.
Open Calc.exe in Programmer mode, and paste the contents of your options attribute.
Image may be NSFW.
Clik here to view.
Click on Bin, and count over to the 4th bit starting from the right.
Image may be NSFW.
Clik here to view.
That's the bit that controls change notification on your manually created replication partner. As you can see, in this example it is zero (0), so change notifications are disabled.
Convert back to decimal and add 8 to it.
Image may be NSFW.
Clik here to view.
Click on Bin, again.
Image may be NSFW.
Clik here to view.
As you can see above, the bit that controls change notification on the manually created replication partner is now 1. You would then change the Options value in ADSIEDIT from 16 to 24.
Image may be NSFW.
Clik here to view.
Click on Ok to commit the change.
Congratulations! You have now configured change notification on your manually created connection object. This sequence of events must be repeated for each manually created connection object that you want to include in the excitement and instantaneous gratification of change notification. Keep in mind that in the event something (or many things) gets deleted from a domain controller, you no longer have that window of intersite latency to stop inbound replication on a downstream partner and do an authoritative restore. Plan the configuration of change notifications accordingly. Make sure you take regular backups, and test them occasionally!
And when you speak of me, speak well…
Jim "changes aren't permanent, but change is" Tierney
Image may be NSFW.
