In my other threads, I am repeatedly dealing with an issue where on an AMT system, first-stage provisioning completes, but second-stage provisioning fails. I would like to be able to remotely resolve this problem without pulling the CMOS battery. Because ConfigMgr is setting a randomized remote MEBx password during first-stage provisioning (correct me if I'm wrong), I'm wondering if there's some way that I can retrieve that password, and use it to connect to the system. At this point, if I were able to authenticate to AMT, I could perform an unprovision command on the system, and reset its provisioning state.
There is a property called AdminPassword in the SMS_AMTMachineInfo WMI class on the ConfigMgr site server that attempted to provision the target device. This is a long string of characters, which I would assume is either a hashed, or symmetrically-encrypted, password that is the remote MEBx password. Am I correct in this thinking?
How else can I remotely unprovision a partially provisioned device?
If first stage provisioning completed successfully and the certificate was properly generated & pushed to the vPro client, you should be able to re-perform second stage provisioning by right clicking on the click and selecting "Out of Band Management" -> "Update Provisioning Data in Management Controller Memory". You could also try performing a remote unprovision by right clicking on the client and selecting "Out of Band Management" -> "Delete Provisioning Data in Management Controller Memory"; "Remove Configuration data..." is equivalent to a Partial unprovision, while "Remove All data..." is equivalent to a Full unprovision. SCCM will use the remote admin digest user / password to authenticate and perform these functions; however, both update and delete are dependent on successful first stage provisioning of the client.
In terms of the AMT remote admin password… To my knowledge, Microsoft has not released their encryption algorithm.
Thanks for the response. Perhaps I was incorrect about it completing first-stage provisioning, because it does not have a certificate in the firmware (this is the situation I'm dealing with in another discussion thread). The MEBx password is changed though, and the device still seems to show as being partially provisioned.
I was hoping to have some method of accessing the AMT firmware via its network interface, but without the randomly generated MEBx password, I can't do this
I guess you're no longer interested in retrieving those passwords, but if anyone else stops by:
Get-WmiObject SMS_AMTMachineInfo -namespace "root\sms\site_MAZ" |
$deskeyHex = $_.AdminPassword.Substring(8, 80)
$adminHex = $_.AdminPassword.SubString(128, 144)
$deskey = new-object byte ($deskeyHex.length/2)
for($i = 0; $i -lt $deskeyHex.Length; $i += 2)
$deskey[$i/2] = [byte]::Parse($deskeyHex.Substring($i, 2), `
$admin = new-object byte ($adminHex.length/2)
for($i = 0; $i -lt $adminHex.Length; $i += 2)
$admin[$i/2] = [byte]::Parse($adminHex.Substring($i, 2), `
$tdes = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider
$tdes.IV = new-object byte 8
$tdes.Key = (new-object System.Security.Cryptography.PasswordDeriveBytes $deskey, $null `
).CryptDeriveKey("TripleDES", "SHA1", $tdes.KeySize, $tdes.IV)
$d = $tdes.CreateDecryptor()
$ms = new-object IO.MemoryStream @(,$admin)
$cs = new-object Security.Cryptography.CryptoStream $ms, $d, "Read"
$buffer = new-object byte 64
[void]$cs.Read($buffer, 0, 64)
$pw = [System.Text.Encoding]::Unicode.GetString($buffer)
add-member NoteProperty "DecodedPassword" -InputObject $_ $_
$_.DecodedPassword = $pw
select FQDN,DecodedPassword |
# export-csv vpro.csv
ft FQDN,DecodedPassword -wrap
The decoded password doesn't work for the Web-GUI, but the Webservices can be accessed just fine.