Problem accessing AMT webgui

[idata]

I am running into an issue where i am trying to log into the webgui of my vpro computers that have been configured through sccm. When i try accessing the web interface from my computer; https://computer.domain.com:16993/ https://computer.domain.com:16993

i get the Intel Active Management Technology webpage and after clicking the 'log On...' button it brings me to the actual control webpage. One thing i have noticed is that on this computer the page is listed as 'Local intranet'.

If i go on my SCCM server (or pretty much any other computer) and try the same thing, i get the initial page, but after clicking the log on button it displays 'Internet Explorer cannot display the webpage' plus it is showing as in the 'internet' zone.

The certs used are installed the same on these computers (Root to Issuing CA to computer), and on the initial page the little lock symbol in IE confirms that the chain is trusted.

Trying the same thing from firefox gives a bit more detail that the connection is untrusted;

'computer.domain.com uses an invalid security certificate'

'The certificate is not trusted because no issuer chain was provided'

(Error code: sec_error_unknown_issuer)

It seems (at least partially) that the issue is for some reason on my machine it is detecting the vpro machines as local and on other machines they are detected as internet, and i've added in the settings that domain.com plus computer.domain.com should be included in the 'Local intranet' zone but it seems on the problem computers that the initial webgui page comes in as 'Local intranet' and then when you click the 'Log on' button it then goes to the

'Internet Explorer cannot display the webpage' which is listed as the Internet zone.

I hope someone has some insights about what is going on

Thanks

[Joseph_O_Intel]

First off the Local Intranet would be correct when accessing the WebUI locally. Remotely should be Internet Zone from within Internet Explorer.

Since you were able to provision the system using SCCM, the certificates shouldn't be an issue for your SCCM server.

I would suggest checking your proxy settings within IE, if you are using a proxy server and you feel your settings are correct. I would suggest that you disable the proxy settings from within IE and see if that doesn't alleviate the problem.

Le me know what you find out

Joe

[idata]

When you say local i take it you mean on the actual machine? When i access the webgui of another computer from my notebook (persumably remotely) it appears in the initial page (with the log on button) and the subsequent page (the amt webgui interface) as Intranet. So from my notebook things work normally.

When i go to my SCCM server or pretty much any other workstation the initial page is Intranet, but when you click on the 'Log on' button it displays 'Internet Explorer Cannot display the webpage' and is in the Internet zone.

This is all internal, different vlans but i've tested with computers that work on the same vlan and they still either work or don't work from the various vlans, so it doesn't seem to be affected by the networking.

We aren't using any proxing so that isn't a factor.

It seems it is related to either internet settings or cert related.

Other ideas?

[Joseph_O_Intel]

Your description of local vs remote is correct.

Default for IE is using Integrated Windows Authentication. This is fine if you are trying to log into the WebUI using domain credentials, but I suspect you are using digest credentials of admin/ if that is the case change your will need to alter your IE settings.

Tools>Internet Options>Advanced tab... Scroll down to the security section and un-check the box for "Enable Integrated Windows Authentication"

Let me know if that helps,

Joe

[idata]

Just tried on the SCCM server - some progress

I now get a 'Windows Security' window stating:

The server computer.domain.com at

Digest: {some hash number} requires a username and password

It has the username and password box where i have tried every possible account i can think of and none of them work. When it fails i get;

Log on failed. Incorrect user name or password, or user account temporarily locked.

Another weird thing i just tried is logging into my notebook with the domain admin account and the connection fails while in my profile it works. So it seems like it is even profile related.

[Joseph_O_Intel]

Lets just talk about the server for the moment. It sounds like all you have is a password issue.

By default the MEBx Digest username is "admin", the password is the one you provide within the SCS profile, that is being used to provision the client.

Within the SCS profile, this password can be a specific string that you assign or can be set as a random string that the unit is to be provisioned with.

If you have full access to SCS, just go to the profile, select edit and hit until you get to the System Settings page, click the show password check box and it will reveal the static passwords.

If the profile has the is set to supply random passwords and it was installed in Database mode. Open up SCS Select Monitoring>All Systems>"System under review">right click "Get configured password".

If SCS was set up in a non database mode, the above option won't be available and if random passwords for provisioning was used then, you will not be able to use the WebUI, as the password will be in the SCCM DB and can't be viewed. In this instance just re-provision the system using a different profile with the static password set to a known static password string.

I hope this helps

Joe

[idata]

The Computer have all been provisioned through the 'Out of Band Management' component of SCCM, i have not used SCS at all. In the SCCM OOB configuration you specify the accounts you wish to include for access to AMT in the 'AMT user accounts' under the 'AMT settings' tab. I have 2 domain user accounts plus a domain group account and my username in the domain group. I have tried logging into the AMT with all the credentials of those accounts but they all result in the same issue as mentioned previously.

What i find weird is that when i log into the AMT settings under 'User accounts' is that the list is empty. I assume that when i get to the AMT settings i have logged in with my domain credentials but i don't see anywhere where it states what user is logged on.

For an experiment i just logged into my sccm server using my domain account and it gives me the same issue trying to log into the AMT webgui.

Thanks for all your help so far!

[Cohei_K_Intel]

Did you create registry key feature_include_pot_in_spn_kb908209 to eanble ssl connection other than port 443?

http://support.microsoft.com/kb/908209/en-us http://support.microsoft.com/kb/908209/en-us

[idata]

Yes the registry entry was added - although it seems that is mostly IE6 related i've added the key anyways - however since it is a machine registry entry and the connection was already working in my profile but not in the domain admin profile then it was profile specific and not a machine specific issue.

This really does seem to be an issue of credentials;

I added the domain admnistrator into the AD group that is added into the AMT user accounts when provissioned in SCCM, and when the Integrated Authentication is checked I can log into the AMT webgui, when i uncheck the integrated authentication when connect to another computer's webgui it presents me with the login window - however I've tried;

1) Administrator [Password]

2) domain\administrator [Password]

3) administrator@domain [Password]

So why does the integrated authentication work but the same credentials entered in the login window don't see to work - is the login window only for digest authentication? Is there any way to see the AD groups that are set to work with kerberos for authentication?

[idata]

This is still very wierd - Since I added the domain administrator account into the AD group with AMT login permissions, now the domain administrator can log in (with integrated authentication), as expected, and now also my SCCM admin domain account (SCCMAdmin) which previously wasn't working even when it was specifically added as one of the 3 accounts that SCCM is suppose to configure on provissioning.

I still cannot login without using the integrated authentication - any idea why the same domain credentials work with authenticated credentials but don't work when entered in the login prompt for the webgui?

Also i did a scan of a group of the machines (since for testing purposes i have been using a handful (3-4) of computers, the scan reports that i have about 10 computers that are not responding at all to any credentials. Even my credentials on my laptop that has has the most sucess for accessing the webgui isn't working.

Its like the kerberos authentication for AMT isn't working for some or all of the 3 accounts used in the provissioning at some times since i as pretty sure the SCCMAdmin account worked before and that computers that i no longer have access to the webgui were working before.

[Joseph_O_Intel]

In summary your issue is with a few clients that communication to webUI is failing and you don't know the provisioned password from SCCM.

Use SCCM to re-provision the client, and you should be able to use the current credentials

[idata]

Sorry for the delays - Thanks again Joe

I did finally track down the password that was used to provision the AMT, I verified it by logging into the AMT on a few computers, ones that are working fine and the ones that are not displaying the WebGUI.

So in the AMT i can see the initial provisionning information. Here are the 2 things;

1) For most computers the login to the WebGUI works with the integrated Authentication on. However if I disable it I get the window asking for the username & password. Now from what you told me, no domain credentials will work like this because it is just authenticating Digest users. Now from my understanding the default 'admin' user is the only digest account and given that i have the password to log into the AMT, so I have tried logging in with all the combinations i can think of;

admin /

[Blank] /

But none of them let me in, the only way i have been able to get in is if I create a digest user and log in with those credentials but I can't seem to get in with the default admin account.

2) there are still some computers that I can get into the AMT settings on the actual machine, but the problem accessing the WebGUI is as stated before, i get the initial Log On WebGUI page but then it fails right away with the 'Internet Explorer cannot display the webpage'.

Thanks

[Joseph_O_Intel]

Lets check the actual AMT settings. Please use the Intel diagnostic tool on one of the clients that is failing, this tool is located here:

Once you run this tool on your client, please send me a copy via Private Messaging, so I can review your profile settings. I will need a scan of both the client mentioned in # 1 and from # 2 from your previous post.

[idata]

I just did a bit of a test - I took one of the machines that i can't access the WebGUI and did an AMT firmware update (6.0.2 -> 6.2.20). Before after clicking the 'Log On' button I would immediately get the 'Internet Explorer cannot display the webpage'. Now after the firmware update i get like the issue on some of my Notebooks where after clicking the 'Log On' i get a window asking for username & password credentials, again there are no credentials that i enter which work.

Does the firware update erase the AMT provissioning?

[Joseph_O_Intel]

Can you get into the MEBx during boot up? Most systems use Ctrl+P to access to access the MEBx, use the password that you beleive is good for the digest user for the webUI. If you cannot get access, use the password of "admin". If that doesn't work, re-provision the client and try accessing the WebUI and or MEBx again.

[BEydt]

Hi Joe

Apologies for the delays - as I mentioned last time, there always seems to be fires to put out and my vpro only gets attention when I can either sneek time in or if it becomes a critical problem.

So after talking with you and Kyle I confirmed that Root CA and Issuing CA was part of the issue. The initial configurations of the Root CA was not done properly and there seems to have been a break in the trust or expired certificate. In either case I have hopefully reconfigured the Root CA properly this time and re-issued the certificate to the issuing CA. From what I can see the trust chain is working.

I could tell that this was part of the problem since we had several new computers that had unconfigured amt settings, and as soon as the CA trust was re-established SCCM configured the vpro/AMT. Part of the problem seems to be that the computers that have already been configured don't respond on the webgui like the newly configured machines. I have taken some of the older machines and unconfigured the AMT and let SCCM reconfigure it and then the webgui works.

While not great I can live with the fact that I have to unconfigure (flush) the AMT on each computer and let sccm reconfigure it.

What is the real problem for me is that I used VNC viewer plus to view the KVM of the AMT computers. Now when I try to connect to machines that have been newly configured VNC viewer plus returns with the error "The connection closed unexpectedly". If I try to connect to one of the older machines where the webgui isn't working I get the error "Security failure. The secure connection failed due to an invalid or missing certificate. (12175)".

I've searched the VNC documentation but it isn't very helpful for solutions or causes.

I'd appreciate if you have any suggestions on how I could get this last piece of the puzzle in place.

thanks

[Joseph_O_Intel]

Greetings

Please run the diagnostic tool below and email me the .nfo file that it creates

/docs/DOC-5582 http://communities.intel.com/docs/DOC-5582

[BEydt]

hi again

Thanks for the offer of running the diagnostic tool but everything is working now. To complete the story just in case it is useful to someone to resolve their issues.

The login problems I originally had were due to the fact that my intermediate CA couldn't reach the crl (certificate revocation list) of the Root CA. I had to reconfigure the Root CA to publish the crl to different locations and then re-issue the intermediate cert used to configure the AMT settings. After that was done - unconfigured amt machines were properly configured, however machines that were already configured seem to have the old intermediate cert would be either unresponsive (for the AMT / AMT GUI) or would show a cert error when trying to log into the amt gui. I ended up needing to unprovision the AMT and then SCCM would reprovision it with the correct certs.

The second part was that my RealVNC Viewer Plus was giving an error when trying to connect to the KVM of the vpro. I contacted RealVNC tech support and we were finally able to determine that I still had the old intermediate cert on my machine in the computer profile AND the user profile - so it was necessary to delete the old one and import the new intermediate cert and then the KVM connection worked again.

So many thanks Joe - i'm sorry it took so long on my side to do and try the things you suggested, but it was very helpful your input and suggestions.

I'm not sure if I can mark this answered, if I can't please mark it so.