Intel vPro® Platform
Intel Manageability Forum for Intel® EMA, AMT, SCS & Manageability Commander
2942 Discussions

Intel SCS Kerberos Issue

MFish6
Novice
1,890 Views

Hello All!

----------------

First off, Digest Authentication works without ANY issue

----------------

Im running into an issue with Kerberos Authentication. I was hoping someone could provide some insight as to whats going on.

 

Below is the environment im working with

1) Intel SCS Server v11.1 (Windows Server 2012)

2) Lenovo X1 Carbon Gen 4 (Windows 10 1703)

I am using the most basic Profile possible for AD Integration with ACL Groups

No other options are being selected as of now (NO TLS, NO Home Domains, NO Remote, NO Network, etc)

For the AD Integration piece, i performed the following:

1) I created the OU in our active directory

2) I gave the SCS Admin user FULL CONTROL to the OU

For the ACL piece, i performed the following

1) I created a SCS Admin Domain Local Group in Active Directory and added the SCS Admin user to the group

2) I added the SCS Admin Group to the ACL in the profile (Permissions are EVERYTHING except Access Monitor)

2) I added the SCS Admin User itself to the ACL in the profile (Permissions are EVERYTHING except Access Monitor)

The profile has 2 entries, 1 is the SCS admin, and the other is the group

----------------

When I remote_configure the X1 Carbon Laptop, everything succeeds and the system is Configured in Admin Control Mode

I see the system report to the SCS server, and I am able to hit the AMT Web UI @ http://laptop.domain.com:16992

Furthermore, I am able to access ALL AMT functions including KVM using the Intel Manageability Commander (Mesh Edition)

BUT....

ONLY with the DIGEST authentication (admin / ******)

----------------

Kerberos is NOT working....

I have performed the following troubleshooting steps for Kerberos

1) I verified the computer account is being created in the OU (samAccountName = LAPTOP$iME)

2) I verified the servicePrincipalName on the above object contains the following SPN's

HTTP/LAPTOP.DOMAIN.COM:664

HTTP/LAPTOP.DOMAIN.COM:623

HTTP/LAPTOP.DOMAIN.COM:16995

HTTP/LAPTOP.DOMAIN.COM:16994

HTTP/LAPTOP.DOMAIN.COM:16993

HTTP/LAPTOP.DOMAIN.COM:16992

3) I verified there are NO duplicate SPN's in our environment (setspn -X)

As far as I can tell, that is all that's required to get AD / Kerberos up and running

----------------

When I try to hit the AMT Web UI using Internet Explorer or Chrome, I get a challenge for Username / Password

If i type incorrect domain credentials, it goes to the Intel Login page and says (Incorrect Password)

If i type correct domain credentials, I get a HTTP 400 - Bad Request

---------------

When i use the Intel Manageability Commander (Kerberos NO TLS), I get "Error # 400"

When i use the Intel Manageability Commander (Digest), It works perfectly

---------------

Im not sure whats going on here.

I have the environment stripped down to the very minimum required to get a system provisioned via SCS with AD intefgration

What am i missing?

 

Any assistance is much appreciated!

Thanks!

0 Kudos
1 Solution
MFish6
Novice
897 Views

All,

The issue has been identified and resolved.

Root cause was Token Bloat

The maximum Kerberos token size allowable by vPro / AMT is located here

https://software.intel.com/en-us/node/631441 https://software.intel.com/en-us/node/631441

When testing the above setup using an account with a token size within the allowable limits, the issue has been resolved.

I confirmed that Kerberos is now working as expected, along with Kerberos with TLS

Thanks!

View solution in original post

0 Kudos
1 Reply
MFish6
Novice
898 Views

All,

The issue has been identified and resolved.

Root cause was Token Bloat

The maximum Kerberos token size allowable by vPro / AMT is located here

https://software.intel.com/en-us/node/631441 https://software.intel.com/en-us/node/631441

When testing the above setup using an account with a token size within the allowable limits, the issue has been resolved.

I confirmed that Kerberos is now working as expected, along with Kerberos with TLS

Thanks!

0 Kudos
Reply