BitLocker – AD setup for BitLocker Recovery Key Management

Like most other posts in this blog, this is pieced together to make sense to me.

Especially in older domains, verify that the AD schema has the appropriate attributes using PowerShell window as administrator:

Get-ADObject -SearchBase ((GET-ADRootDSE).SchemaNamingContext) -Filter {name -like 'ms-FVE-*'}

On a domain controller, install the BitLocker Feature to display the BitLocker recovery information:

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart

To see the BitLocker tab containing the BitLocker recovery key from an admin workstation, the RSAT “BitLocker Drive Encryption Administration Utilities” needs to be installed on the workstation.

GPO Settings

On a domain controller: Server Manger>Tools>Group Policy Management

Edit the following:

Computer Configuration>Policies>Administrative Templates>Windows Components>BitLocker Drive Encryption

"Store BitLocker recovery information in Active Directory":
Select "Enabled"
Check "Require BitLocker backup to AD DS"
Select "Recovery passwords and key packages"


NOTE – At the bottom of the GPO “Help” it states that the TPM information also needs to be backed up. This, however, no longer appears to be the case after Windows 10 version 1607.

"Choose how users can recover BitLocker-protected drives":
        Select "Enabled"

Select “Operating System Drives”

"Choose how BitLocker-protected operating system drives can be recovered":
	Select "Enabled"

        Check "Save BitLocker recovery information to AD DS for operating system drives"
        Select "Store Recovery passwords and key packages"

        Check "Do not enable BitLocker until recovery information is stored to AD DS for operating system drives"
			

Select “Fixed Data Drives”

"Choose how BitLocker-protected fixed data drives can be recovered":
        Select "Enabled"

        Check "Save BitLocker recovery information to AD DS for fixed data drives"
	Select "Backup recovery passwords and key packages"

        Check "Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives"

IIS SSL/TLS Certificate Setup

Simplistic, works for me, in my given scenario.

Create Certificate Request:

From the IIS server needing the new certificate, open IIS Manager:

- In the left window pane, select the server.
- In the center window pane, select "Server Certificates".
- In the right window pane, select "Create Certificate Request".
- Enter the information in the pop up window.
- Cryptographic Service Provider:
	"Microsoft RSA SChannel Cryptographic Provider"
- Bit Length:
	2048
- Provide a path and a name for the request certificate:
	C:\Users\Me\Desktop\csr.txt

The copy/paste the csr.txt text in the request form in the certificate authority’s web interface, or submit the request file to the certificate authority.

Install the SSL Certificate:

Once the certificate authority has provided you with the new certificate, log back onto the IIS server that you created the request on and open IIS Manager:

- In the left window pane, select the server.
- In the center window pane, select "Server Certificates".
- In the right window pane, select "Complete Certificate Request…".
- In the pop up window:
	Select the new certificate.
	Add a friendly name to help ID it.
	Select "Web Hosting".

Bind to the new certificate to the web site:

- In the left window pane, select the web site 
	Possibly "Default Web Site", or maybe not.
- In the right window pane, select "Bindings…".
- In the "Site Bindings:" pop up, choose add or edit.  I'm doing edit here.
- Select "HTTPS" and click the "Edit" button.
- Select the new certificate.
- In the right window pane, restart the service.

Use a web browser to check the site and the new certificate expiration date.

Windows 10 – Network Drive has the Wrong Cached Credentials

The short scenario: The help desk got a call from our senior accountant that her various drives were not mapping and she had to keep entering her login credentials.

Two things to also note: The cached credentials were to another account, not her domain login account, and this happened during COVID-19 when people were switching between working at home and at the office. In this case, she was in the office that day.

The help desk employee could not figure out why this was happening and contacted me and I was also off site. Not sure what was happening, I went back to the beginning. I started by making sure her Active Directory account had not changed because her 5 network drives are mapped via a batch script at log in. I then had the help desk make sure she was logging in with her domain account. We then followed that up by changing her password since I needed to rule out any possible mismatch that may have happened while she was working from home.

The key to solving this issue was that when she was prompted to provide her credentials to connect to the drive, the wrong account was presented, indicating that it had be entered incorrectly at some point and was being cached. The help desk also reported that one of the network drives connected at log in then disconnected prior to the prompt being displayed. In short – her AD account was functioning as it should but the computer was overriding the drive mapping.

The walk through. Open a command prompt as the logged in user. Verify the proper account:

whoami

What drives are mapped:

net use

Show the credentials that the computer has cached:

rundll32.exe keymgr.dll, KRShowKeyMgr

This popped up a window and we could see the server name and the incorrect user account. We deleted the server name entry and rebooted. All 5 network drives connected properly at user login.

While we didn’t test this, I believe we could have also gotten access to the stored credentials through windows settings by searching for “credentials”, credential manager, windows credentials.