BCU Encrypted password files

[Adrian1]

Until recently, we have been using BCU 2.60.13 to manage our BIOS configurations and passwords via our build process which utilises SCCM 2012 SP1. We now have a requirement to encrypt the Bios passwords which meant that we needed to upgrade BCU to a newer release which uses encrypted password files. We are now using version 3.0.3.1. I have created the bin files and have been able to successfully run the new version of the BCU via the same task sequence and set/remove passwords as well as update the Bios configurations. This was until about a week ago when I tried re-running the task sequence and am now getting an error 10. The error message explains that the wrong password has been supplied, even though I know that it's correct.

This happens on the same machines and using the same task sequence that previously worked. The commandline failing is as follows: biosconfigutility.exe /cspwdfile:"password_file.bin" /nspwdfile:""

In troubleshooting, I have done the following:

1. Running the BCU in Windows 7(local Admin account), using the same command as the task sequence returns the same error code. 

2. Removing the bios password manually and then setting the bios password using the following commandline biosconfigutility.exe /nspwdfile:"password_file.bin" completes successfully. However, the password fails to unlock the bios when entering via the F10 key at boot time. The only way to remove the password is to then use the same bin file as the cspwdfile and use nspwdfile:""

3. Re-created the encrypted password files using the HPQPswd utility to ensure that the correct password was supplied. Did this a few times (both using the GUI and commandline), but the same result

4. Used the newest version of the HPQPswd utility but again, same result

It seems to me that the issue is around decrypting the password file as this would explain why the utility thinks that the wrong password has been supplied when trying to remove the current password. It would also explain why the wrong password is being set when applying a password using the BCU and encrypted password file.

The thing that confuses me the most is why BCU worked when it was first run, but is now failing.

To summarise, we are using SCCM 2012 SP1 and deploying Windows 7 SP1 Enterprise across a number of different model HPs (7700, 7800, 7900, 8000, 8200, 8300). 

Thanks in advance.

Regards,

Adrian

[richard429]

Hi,

Is this only failing in the SCCM task sequence?

       Does it fail if you run BCU manually from the command line?

If it has not been run on the command line without the task sequence - try command line only.

This is to help identify if the issue involves working with SCCM.

I do not see why the behavior changed but have a couple of other suggestions.

The one clue that I see at the moment is failure to unlock in F10 using the same password in the encrypted file.

Couple of possibilities

1st - 

It may be a bug in the encryption with regards to one or more special characters in the password. 

By this I mean that perhaps HPQFlash is not encrypting or BCU is not decrypting a character correctly.

BCU versions before 2012 sometimes had trouble with special character depending upon whether the BIOS used keyboard scan codes or generated unicode.  This is not the case with version 3.x and above but perhaps there is a similar issue.

As an experiment, clear the password on a single system and then replace it with something simple such as    abcd1234

I recomend 8 characters because I am not certain what the default minimum password length is on the systems you are using and do not have quick access to the default value at the moment.

Encrypt   abcd1234   into a file and add this as the password on the single system.

Now attempt to unlock using F10 with the password.

Does this work?

Can you set this password using F10 and then remove it using BCU?

2nd -

Newest version of BCU available on the HP website is 3.0.13.1  which supersedes 3.0.3.1.

And a parting question -

        What is the version number of the flash utility?

Client management utilities such as BCU, SSM and SDM can be found at:

     Client Management Solutions

     Client Management Solutions - Download Library

Thanks,

Richard

I work for HP but am not a company spokesperson. Participation in the community forums is voluntary.

[richard429]

I did some checks today.

You have a range of platforms that date from approximately 2007 through 2012.

Approximately 2006, HP began change the BIOS in systems to use Unicode in the setup password.

Depending upon platform design time frame and development organization involved, the completion for moving all commercial platform BIOSes to Unicode is reported to have occurred some time in the 2008 - 2009 time frame.

One of our groups confirmed today that a 7900 cannot be unlocked or changed using F10 from the keyboard if the setup password was set using the new BCU with an encrypted setup password.  I believe the 7900 is a 2008 based design.

The BIOS setup passwords in the earlier systems are input using keyboard scancodes.

If I recall correctly,  using keyboard scancodes allowed companies to deal with deployment across multiple countries and languages.  An admin in Germany setting a password across their network to an office in Italy or Spain would potentially lock out any Spanish or Italian IT person trying to service a unit in their local office if the password contained a character only  present on the German keyboard.  With the BIOS using scancodes,  it provided the ability to access locally where needed. -- Granted the character might be different but the location & placement of the key would be available.

BCU 2.60.13.1 and lower versions use clear text to set the password. 

These versions perform a check of the BIOS and pass the setup password based upon the BIOS support for Unicode.

If a target BIOS does not support Unicode, BCU will use the keyboard scan codes and pass it to BIOS through WMI.

Doing this allows the password set/used by BCU to match an entry used in F10.

On newer systems using Unicode, the old BCU will pass the Unicode characters to BIOS which would match the Unicode characters entered in F10.

Versions of BCU 3.0.x.x and higher use an encrypted file.  The encryption utility encrypts the password based upon the Unicode characters input into it. 

The encrypted file does not contain any indication of which language keyboard was used to create the password, nor does it contain an encrypted version of the scancode sequence.

With the change to an encrypted file, support for keyboard scancodes is no longer provided in the newer versions of BCU.  There is no means of identifying which keyboard is used to create the encrypted password.

BCU 2.60.13.1 continues to be available for older systems.

Neither BCU nor the encryption utility will contain support for scan code based passwords in versions that use an encrypted password file.

For organizations that contain a mix of older systems using keyboard scan codes and newer ones using Unicode, there are three primary options--

1 - use clear text passwords and BCU version 2.60.13.1 for all models ( old & new platforms )

2 - use encrypted passwords and BCU version 3.x.x.x or higher for all systems - but give up the ability to set/clear/change the password or BIOS configuration using F10 setup directly on the older model target systems.

        BCU would be a required utility any time an admin needed to access BIOS setup on the older systems.

        ex. - while sitting at the end user's system, an admin could clear the password, then update BIOS settings, then restore the password using BCU.

3 - split the usage such that older systems use clear text passwords and the old BCU while newer systems use an encrypted password with the new BCU.

        If this path were chosen, it may be best for Unicode base systems to have a different password than scancode based systems.

OK - all this explains is how BCU works with different year model systems, scan codes and why F10 entry may not work if the password is set using certain versions of BCU.

We still have not discovered why you are seeing a change in behavior  described in your posting.

"I have created the bin files and have been able to successfully run the new version of the BCU via the same task sequence and set/remove passwords as well as update the Bios configurations. This was until about a week ago when I tried re-running the task sequence and am now getting an error 10. The error message explains that the wrong password has been supplied, even though I know that it's correct."

Restating in slightly different words--

A task sequence was used in SCCM 2012 to set/remove passwords

At that time BIOS configurations were also updated.

All changes were successful. 

        It is not clear but somewhat implied the configuration was set or changed on the same commandline as the setting/changing of the password.  ( i.e. - one command line had password and settings file ).

Then recently ( about a week ago )

Running this same task sequence in SCCM 2012 results in an error 10 ( incorrect password ). 

According to the posting, you are deploying Win 7 Enterprise edition.

Are the task sequences running in WinPE or a full version of Windows?

Does WinPE match BCU ( 32bit WinPE + 32 bit BCU ) or  ( 64 bit WinPE + 64 bit BCU )?

Does the WinPE image contain the WMI support?

Can you confirm the task sequence also fails on each of the 8000, 8200 and 8300 series of systems?

Or does it only fail on the 7x00 series ( with scancode based setup passwords ) ?

Is TPM enabled on failing systems?  ( should not matter,  i am just collecting data & looking for clues )

Here again - it may be usefull to experiment with a single system and see if using a simple password will work ( abcd1234 ).

This helps determine if there is an issue with special characters in the password.

Even if setting or changing the password fails, it is still valid to execute and get a config file

     BCU.exe /getconfig "filename.txt"

     Note the missing semicolon above - - The user forum complains about html code if I try to use a semicolon in the text.

 Versions of BCU begining with version 3.0.13.1 will add a comment section near the top of a config file similar to the following--

;

;      Settings file originally created by BIOS Config Utility

;      Version 3.0.13.1

;      Date 2014.08.20

;

Since users may edit the file to achieve a specific configuration, the comment section can only convey it's original creation information but this does allow a user to log or track which version is actually in use.

Is it possible the task sequence is somehow calling the old version of BCU?

    - unlikely because I don't believe there is any version of BCU that supports both password methods in the same version 

             ( clear text passwords and an encrypted password file ).

BCU has a verbose flag command line option ( /verbose ).

I don't believe it will provide any additional help in this particular circumstance, but any clues may help.

Try adding /verbose to the commands and capturing the output.

Any other additional information that you can think of may be of help in determining the cause or finding a solution.

Hopefully, this has been informative and perhaps even helpful.

Client management utilities such as BCU, SSM and SDM can be found at--

     Client Management Solutions

     Client Management Solutions - Download Library

Thanks,

Richard

I work for HP but am not a company spokesperson. Participation in the community forums is voluntary.

[Adrian1]

Hi Richard,

Let me start by thanking you for taking the time and effort to firstly research and then respond to the issue I am currently facing. The information provided help me understand a little more why this issue is appearing as well as some of the potential ways to resolve the problem. Before I go to much further, I would like to answer some of the questions you had for me.

1. The BIOS configuration takes place after Windows Setup, so happens in the full OS and not WinPE.

2. The same behaviour can be seen when running via the task sequence or via the command prompt (both within the task sequence and post build when logging in to Windows)

3. All components are 32-bit

4. Tests have been performed with and without the TPM module enabled, but the results are always the same

5. The simple password also produced the same result

6. I was successfully able to create a configuration file as well as use the file to set the configuration (as long as there was no bios password)

I was able to finally get my hands on an 8200 today and the good news is that I was able to successfully run the task sequence with the encrypted password files. This result goes hand in hand with the information regarding the older and newer bios password handling techniques you mentioned in your post.

Tomorrow I will verify that each of the systems I have access to currently have the latest version of their bios installed and test to see if that makes any difference. If not, I think we may have to look at the hybrid option whereby we use the two different versions of BCU to set the bios configurations as well as passwords.

Thanks again for your assistance. Although not as neat as we were hoping for, we still have a way of going forward.

Regards,

Adrian