I have a bitlocker analysis that shows status of TPM and drive encryption, but I’d like to add the latest recovery key created date to that analysis. Not sure how to go about the relevance for that one. Thanks for any helps or hints!
Can you show what that looks like on the command line or in WMI?
Well, I think that is part of what I am looking for. I am not sure how to locate the create date of latest recovery key, for BigFix purposes. I’ve tried looking up how to find this information in WMI but I am not having any luck on that front. I’ve been spending a few days trying to get this information through Powershell to no avail, so I thought I would see what I can do with BigFix.
As far as I know it is just an Active Directory property. On the object properties, on the Bitlocker Recovery tab, there is a “date added” and “password ID”, I am trying to leverage the “Date Added”.
I do not see anything available in WMI for the created date, I believe it is only the AD property. Win32_EncryptableVolume class - Win32 apps | Microsoft Learn
Ah, ok, that makes a lot more sense then.
I’m afraid that makes it a lot trickier. In Relevance we don’t have a way to query Active Directory directly. For the AD properties we support (like the computer’s Distinguished Name, and Groups for the computer and user) thee BESClient caches those locally at startup and when users log on/off; our relevance inspectors use that cache, rather than querying AD directly.
We could also introduce some serious problems to the Domain Controllers if we have all of the clients querying AD properties frequently. We’ve seen instances where we crash the Domain Controllers if the AD property refresh is set too frequently, for example.
I’m looking, but it’s likely we would need to use an Action to run a script on the client to retrieve that info, I don’t think we’ll be able to do it in pure Relevance.
Thank you for the response! What I am looking to do is create an Analysis of this, but, I understand if that cannot be done. Makes total sense from a performance standpoint. It would be okay to use an action as well, that we could just run on demand, it really only needs to be checked on occasion. But it would need to be for all machines in a Computer Group. Thank you again for all of the info, I appreciate you looking into this!
Actually, even a report would be fine, if this is something that could be done in Web Reporting or the like…
The context - we periodically rotate our bitlocker recovery keys, and the idea is that we would like to check the status of this - so, on all computers in a Computer Group, I would like to know the creation/addition date of the latest/most current recovery key, and then evaluate that against a specific date. The last part, evaluation against a specific date, would be a bonus. So in other words…asking the question “do we have any machines that did not have their recovery key rotated since 10/1/2024?” for example.
So, I kept hacking at this for a few hours after my last post. I didn’t have success, but I came close enough that I decided to post this in case it’s helpful in putting together a better solution.
I found that it actually is possible query arbitrary Active Directory things - by using the WMI inspectors.
For reference my test client is in Active Directory with this distinguished name:
A: distinguished name of local computer of active directory
A: CN=WIN11,CN=Computers,DC=d,DC=domain,DC=home
I can use AD queries by going through the “root\directory\ldap” WMI namespace and retrieve all sorts of things. What sorts of things? Hundreds of them. A list of possible WMI object types can be retrieved by this query, where I’m selectively showing only a few of the answers:
q: (name of it, string values of it) of properties "__PATH" of select objects "* from meta_class" of wmis "root\directory\ldap"
A: __PATH, \\WIN11\root\directory\ldap:ads_container
A: __PATH, \\WIN11\root\directory\ldap:ds_computer
A: __PATH, \\WIN11\root\directory\ldap:ds_msfve_recoveryinformation
In particular what we want is the WMI object ‘ds_msfve_recoveryinformation’ which corresponds to the AD class ‘msfve_recoveryinformation’,
In AD, the bitlocker recovery info is stored in a msfve_recoveryinformation object which is a child object of the Computer. The name / CN of this object starts with the date/time the recovery info was stored. I can query that in the Fixlet Debugger!
q: (name of it, string values of it) of properties ("ds_CN"; "ds_distinguishedname") of select objects "* from ds_msfve_recoveryinformation" of wmis "root\directory\ldap"
A: ds_CN, 2024-10-22T16:33:08-08:00{906E8FC5-E54F-4BF7-B803-7DB22A9FCE7B}
A: ds_distinguishedname, ( CN=2024-10-22T16:33:08-08:00{906E8FC5-E54F-4BF7-B803-7DB22A9FCE7B},CN=WIN11,CN=Computers,DC=d,DC=domain,DC=home )
T: 4862.547 ms
(I was also able to filter that to the ones that match my computer’s distinguishedName).
But – I can only query that in the Debugger mode.
When it’s using my Administrator credentials.
It doesn’t work in Local Client Evaluation Mode.
Because apparently the Computer account cannot read its own BitLocker Recovery Info.
So, we can’t use this in an Analysis. It appears we need to use authenticated admin credentials to query that out of AD using WMI.
Next I tried using LDP to query, under the LocalSystem account. I can see that the object exists but cannot retrieve any properties from it. I think maybe I can enumerate it as a child of the Computer object in LDAP, but don’t have Read permission to it. And without Read permission I can only guess that the WMI provider isn’t returning anything at all.
Maybe someone can build off this and get closer, but I think I’m going to have to abandon it for now.
1 Like
Thank you Jason, I appreciate the effort! 
Yeah I believe that the AD object has specific permissions for read permissions for Bitlocker keys and they are locked down to specific accounts. I don’t think that the computer object can access the bitlocker key retrieval.
What I was thinking about doing a while back was create a task to periodically run a task to export the recovery key with Managebde and encode it with base64 encode and write it to a registry key or file so that it could be pulled from relevance with base64 decode but there is inherent risk of storing your recovery key on the drive even if it is encoded. Base64 encoding can be decoded pretty easily and is pretty recognizable that it’s base64. This also doesn’t account for bitlocker rotations but the only thing i can think of to account for that would be to look in the bitlocker event logs for when the rotation occurs and then trigger the managebde export task again. From a security perspective there would be some risk involved in doing it this way.
You could limit risk by obsuring the file/registry and setting permissions so that only the system account has privilege to it though.