Scenario:
We are writing a PowerShell script to verify that BitLocker has escrowed a recovery password in Active Directory.
Challenges:
The local computer account doesn’t have rights to verify the key, and either does the user. An account with rights to access the data will need to be specified.
We are in transition between BigFix client versions 8.2 and 9.X. So we need a solution that will work in both environments. (or at least a command for each environment)
Can anyone provide some insight on how we can achieve this?
Be aware though that on anything below 9.x we have no way of securely sending a password so you would be exposing the password to your entire deployment (as there is no mailboxing there either)
As 8.2 is out of service I’d suggest you update anyway.
Why would you want BigFix to execute the PowerShell script? Sounds like something better done outside of BigFix, as you’re querying AD instead of the client.
I’d first try writing an LDAP query and making sure that the computer can’t retrieve it’s own key from AD. It looks like the BitLocker recovery key might be stored a container in AD now (and not an attribute) – you could also try to query if that container exists.
I’ve given this some thought and I think there aren’t any great ways to do this. The fundamental issue is you’re trying to do a privileged action. By having a single account that can query this info and distributing it to all of your computers you are really no more secure than letting the computers query their own recovery key.
The moment that you do anything without a secure parameter you must assume that information is visible to anyone in the world.
One account with access to all the bitlocker recovery keys in the domain is a pretty juicy target for an attacker.
You could setup a web service (asp.net) where you can query the NetBIOS computer name and the web service turns whether there is a backed up key. The fixlet when then query this web service. The Asp.net application would then have access to the keys in ad to do the check.
You could have another insecure attribute called, “bitlocker key populated” in ad and run a script that runs on the domain controller every hour and changes this value it the key is present. Grant the computer objects access to read this value and query it with powershell.
I was thinking about it more as well, and in some ways it depends in AD where this info is stored. If its in the computer entry (which seems the only logical place) then yes the computer should be able to query it.
The BitLocker key recovery data should be stored in a child object of the computer object, named for a timestamp and unique GUID, ie. 2005-09-30T17:08:23-08:00{063EA4E1-220C-4293-BA01-4754620A96E7}
I haven’t tried this myself (BitLocker is not our preferred encyption), but I’d expect the computer account should have permission to read the object; it’s unusual for the computer to have WRITE permission without also have READ. Otherwise it would have a hard time determining whether the key needs to be backed up, if it can’t check whether the value already exists. I haven’t done much with PowerShell LDAP queries, but I’ve been successful in the past querying LDAP using the computer account credentials in VBScript. I’d check whether the computer credentials are getting passed along; at minimum, you should be able to modify the PowerShell to query some other property of the computer account (computer accounts generally have a LOT of Read:Self permissions).
I’m sorry that I have been absent in this thread for awhile. The soltuion is to use Power Shell to perform the task. The reasl issue i’ve seen, on several occasions, is that BigFix lacks the ability to run actions under alternate credentials. SCCM has this as a function in their task sequence, I don’t see why BigFix cannot do the same. It’s one of the few drawback s to BigFix .