Red Hat Registration and Subscriptions

I recently decided to spend some time refreshing my Red Hat knowledge because it has been a while since I have supported production Red Hat based servers. A lot has changed. You can signup for a developer license for free and get limited access to Red Hat products.

Registration, among other things, controls the repos that the server can use.  For instance, you cannot run ‘dnf update’ until the system is registered and attached to the available desired software repositories. The ‘subscription-manager’ command exists to handle various subscription configuration situations.

For a basic free developer subscription, the following will get things started from the command line.

Show the various commands available to the subscription manager command:


Subscribe and configure the available repos. This can apparently be used with kickstart as well:

subscription-manager register --username --password --auto-attach

Update the system:

dnf update

There is a lot more to subscription manager based on workflows, hosted repositories, configurations, etc. Because of different workflows, registration can also be performed via the GUI, web console, automation, etc.

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"

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:


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.