AMT - Password Issues

[Brian_P_]

Hi, I've been tinkering with AMT lately and thinking about using it in our environment. I've made a little test environment just to try out host-based provisioning, but I'm having some weirdness and was hoping someone could explain this behavior. One thing I can't figure out is how to get into the MEBx after I've provisioned the device. I can log into the WebUI remotely using the Digest admin username and new password, but the MEBx doesn't seem to use this password...? I thought it was the same thing, however I've tried it multiple times and can't seem to get back into MEBx. Any ideas? Another weird issue I was having was that I could log into the WebUI only through Firefox and Chrome -- Internet Explorer (11) would prompt me for credentials but would not take them... similar to how MEBx seems to be responding. However, I managed to eventually get IE to do this right by using the FQDN in the address bar instead of the IP address. The reason I'm trying to get back into MEBx is to see if the settings I imported into it from ACUConfig all took. Obviously some portion of them did because the WebUI is up, the ME service said it was provisioned, the ACUConfig log said it was successful, and so on. The reason I'm wondering if something is not-right is because I can't seem to do any Remote Control (toggle power) with the machine in any state. The WebUI seems to send the command but nothing happens. I also tried Manageability Commander Tool ME and when I try sending it a power off or reset it returns me an "INTERNAL_ERROR" response. So that's where I am so far. Let me know if you guys have any insight to the behavior I'm experiencing. Here's some of the information on my test machine: Dell Latitude E6520 Intel AMT ver. 7.1 Windows 8.1 Intel SCS 9.1.1.125b

[Brian_P_]

I've tried a different keyboard on the machine. I've also verified I can log into the WebUI locally from that machine using the loopback address. It's a mystery to me.

If I do a full Unconfigure via ACUConfig, does that change the admin password back to default? Assuming it accepts the password this way...

[Gael_H_Intel]

It sounds as though you may ave modified your AMT Admin/user password in your configuration process?  

I'm pretty sure that a full unconfig does not return the MEBx password back to the default (but you can test that easily - if you sign on and "admin" works, then it set it back to factory mode and you will need to change the password.

Are you using Kerberos? Do you have any screen shots that might be helpful to look at?

Here is a blog that might help: https://software.intel.com/en-us/blogs/2014/05/20/intel-amt-login-issues

[Brian_P_]

Thanks Gael,

I thought I changed the AMT admin password in the profile wizard:

Since this a test environment, the Intel AMT admin password is just a temporary one: @PPle_314

Your link has given rise to more questions. I assumed the MEBx password used the Digest (?) "admin" user and that changing the "Intel AMT admin" above was affecting the same thing. But the thread you linked says that they can become unsynced. Are these two separate accounts then...?

I never logged into the MEBx prior to provisioning this laptop via ACUConfig. But that doesn't mean someone else had not previously went in and changed the default password (since it makes you if you log into it). It's not my laptop so I can't be certain. I didn't think it would let me provision the laptop if the admin account had a non-default password (unless I specified it in advance somewhere?).

I don't have TLS or Kerberos setup in the profile; it's about as basic as it gets for beginning testing purposes.

[Brian_P_]

Just found the link you had in the other post discussing passwords. So it looks like the ME is its own thing and isn't linked with the Digest users (which I'm assuming are the ones within AMT).

Hmm. It looks like I won't be able to get into the MEBx portion then unless I can find the previous user and if they know the password.

Does not being able to log into the MEBx hinder any of the features? For instance, I still can't figure out how to get remote power-up/power-off to work despite being able to log into the WebUI or through Commander and wonder if this might have something to do with it?

[Gael_H_Intel · Accepted solution]

The MEBX/Admin password issue is sort of tricky.  The first time you enable AMT (changing the password from "admin" to your chosen secure password, the two will be in sync.  If you then, for example, go into the WebUI and change the AMT user/admin password, you are now changing the AMT Admin password, but not the MEBx password.  

I am noticing a couple things about your configuration:

You might want to sync the AMT clock with the system clock.  I'm not sure why anyone wouldn't want that, but it is an option that the admin can check.  Also, I like it if my AMT client will respond to ping (nice to have in a troubleshooting situation where you may be having connection issues - if you can ping it, that is one less thing to check.)  The other thing I noticed was, indeed, your password: @PPle_314  You might try unprovisioning your system and getting rid of the "_" this character might be causing some problems.  The @ should work (although some interfaces don't want the special character to be in the front - I have not tested this.  The ACU config also may not be checking to make sure the user enters a valid password.

I would suggest unprovisioining your system and trying a different password (P@ssw0rd is a good one to try) - see if you are still having connection problems.  

PW requirements:

• Contain at least one 7-bit ASCII non alpha-numeric character, above 32, (e.g. '!', '$', '~'). Note that “_” is considered alphanumeric.

[Brian_P_]

Thanks Gael.

I didn't figure out why I couldn't do power management on the laptop but using that profile on a different AMT enabled machine (with version 9 this time) allows me to so it must be something weird. That laptop has lots of UEFI security features turned on (TPM, Computrace, fingerprint scanner, etc.) so maybe one of those things is interfering.

I'm not going to worry about it because it's not really the target computers we were thinking of using AMT on; it was just the most accessible one with a high enough AMT version to do some quick testing with. And while I couldn't change or reset the MEBx password, I did get it from the previous owner.

But since this thread is about passwords and such, I do have another relevant question: is there a way to reset the MEBx password back to default? For example, if we were going to donate equipment to someone and wanted to return the ME to default... is there a way to get it back to "admin"? It seems like once you change it, it only wants a relatively complex password.

I know one method for BIOS systems is to remove the CMOS battery. But I don't think this method would work for (all?) UEFI systems, and may be too much of a hassle for (U)SFF/laptops. And working in IT for schools also makes us fairly reliable on donated equipment which means we might encounter previously-configured ME environments with no straightforward way to reset it. Just wondering if there are reliable ways to do so.

[Gael_H_Intel]

According to the Implementation and Reference Guide, performing a "Full Unprovision" should set the system back to factory mode.  (Search for "Full Unprovision" when you open the doc and you should be able to find it.  While removing the CMOS battery works great, it is difficult to get to it on a notebook so it's best to do it programmatically, if possible.  Sometimes if AMT is just not working right and you can't figure out why, removing the CMOS battery resets the system - I have had a few occasions where a simple CMOS removal is what was needed to get my system working.  (Maybe that is the issue with your other system. I have also had systems where I had to reflash the firmware to get things working.)

Selecting the Full Unprovision option performs the following actions:

•   Non-Volatile Memory (NVM) is cleared.

•   Event log is cleared.

•   All Access Control Lists (ACL) are cleared, the administrator username is set to the default (“admin”), and the Intel AMT password is set to the password that was used in the Intel AMT MEBx. (The MEBx password is not restored to the default).

•   Hardware asset information is erased. (In Releases 4.2 and 5.0 and later releases, the hardware asset information from the last power on is retained.)

•   The Intel AMT network device is reset and the Intel AMT device is put back into Factory Mode.

•   All Intel AMT configuration data is erased (certificates, CIRA, wireless profiles, wired 802.1x profiles, etc.). From Release 8.0, all OEM secure settings are maintained, including custom hashes (+ inactive default hashes in Releases 6.x and 7.x), DNS suffix and configured server FQDN.

Partial Unprovision

Selecting the Partial Unprovision option performs all of the Full Unprovision actions, with the following exceptions:

•   The Admin ACL, containing the administrator username and password, is not restored to the default.

•   The hostname is not erased.

•   The provisioning server IP and port are not erased.

•   The domain name is not erased.

•   All data needed for the next setup and configuration attempt is retained (OTP, PKI DNS Suffix, SCA FQDN, Customized hashes [+ inactive default hashes in Releases 6.x and 7.x], and PID-PPS pair).

•   Beginning in Release 6.2, if there is an OEM-configured secure DSN suffix, it is reverted to and any post-provisioning DSN settings are erased.

[Brian_P_]

Gael Hofemeier (Intel) wrote:
All Access Control Lists (ACL) are cleared, the administrator username is set to the default (“admin”), and the Intel AMT password is set to the password that was used in the Intel AMT MEBx. (The MEBx password is not restored to the default).

Hmm, so as far as I can tell, the only way to reset the MEBx password is to remove the CMOS battery (or maybe via some motherboard jumper). Oh well, I suppose as long as the AMT admin is reset, the system can be re-provisioned through that user.

[Gael_H_Intel]

Some oem systems have an option in the BIOS that allow you to "Disable AMT" - this does the same thing as a cmos removal.  

[Brian_P_]

Thanks Gael! More notes: 1. It appears (on this system at least) provisioning the computer via ACUConfig with an XML profile didn't sync the MEBx password -- it just changed the AMT "admin" password. When I attempted to log into MEBx at boot, it refused my provisioned admin password and only accepted the default "admin". I exited out without changing the password and verified that I can only log into the web UI as "admin" with my provisioned (non-default) password. A little confusing, and from Gael's post it doesn't sound like this is always the case so it may be different depending on the AMT version or system model? Edit: Or maybe my understanding is just backwards? Upon re-read it sounds like if you enable AMT via MEBx, then the AMT admin and MEBx passwords are initially the same. But, in my case, I enabled and provisioned AMT entirely through ACUConfig and so it only touched the AMT admin part. That probably makes more sense. Edit2: Looks like changing the MEBx password didn't change the AMT admin password. Maybe because the AMT admin password had already been set and/or was not default anymore (in my case where I had already did a host-based provision). Almost need a flow chart to keep track of these scenarios. 2. Just to confirm Gael's post above: when I was in the BIOS of the system, there was an AMT section and it had its own "Reset to factory defaults" option right there which said it would also reset the MEBx password to default. Very handy (in our case anyway) for donating/donated machines. Obviously YMMV depending on the model!

[Gael_H_Intel]

The Admin/MEBx password issue is very confusing and I have to admit, I really only provision via the MEBx because I'm just enabling one system that I use for checking things out. It sounds like is it possible to enable amt without resetting the MEBx password?  The MEBx password is only used to get into the MEBx menus so I can see why you don't really need to have that changed to enable AMT - especially since you are using a utility do do so.

I'm figuring that when you specifically set the Admin User password, it is doing so through an API which affects only that password (it has nothing to do with the MEBx menus.)  So when you enter a password in that field in the configuration menus, you are indeed, only setting that password. If you configure using the MEBx menus, the passwords are automatically synced until the admin user password is changed.  

[Chris_S_2]

@Brian P.

I have the same issue on a Dell E6520 and somehow one of the passwords on the Intel AMT isn't working but isn't the standard "admin", so I need to reset. You mention that the BIOS has its own Intel AMT section, however, I can't seem to find this!!! I can try to login to the AMT engine from the boot-up options, but of course I then need to supply a password, which is incorrect.

I've been going round in circles on the Intel website on this one - can you provide any help?

Cheers

Chris

[Colleen_C_Intel]

In most cases, you can shutdown, pull the power cord (or power source) and remove the coin battery (at least 15 seconds I believe) to do a reset of the password to default). (Search on AMT password reset.)

[Chris_S_2]

Thanks Colleen, but the Dell E6520 is a laptop, which essentially mean dismantling the whole thing. If you check out Gael's response above, she says:

"According to the Implementation and Reference Guide, performing a "Full Unprovision" should set the system back to factory mode.  (Search for "Full Unprovision" when you open the doc and you should be able to find it.  While removing the CMOS battery works great, it is difficult to get to it on a notebook so it's best to do it programmatically, if possible."

However, there is no real set of instruction that I could find that point to a way of doing this. Her continue quote (the page from the above link) outlines what you need to do, but not how it should be done. The links lead you on a merry dance until you eventually get to a page https://software.intel.com/en-us/blogs/2012/01/20/how-to-configure-your-system-to-run-the-intelvpro-powershell-module which stepped you through setting up PowerShell to interact with vPro, but the instruction where broken (Edit - Gael has just fixed this, so maybe now I can get the Code snipit to work.....)

[Chris_S_2]

Well, I managed to get the PowerShell script to run to Unconfigure the AMT Device, but what does it require - of course, the user name and password! So no dice here.