About Intel AMT > Integration with Active Directory > Microsoft Active Directory and Kerberos Support

Microsoft Active Directory and Kerberos Support

Microsoft Active Directory provides Kerberos-based mutual authentication, along with other security services that ease implementation of a network that supports Kerberized clients and servers.

These include:

• Single Sign On

• Windows authorization

• A database of users, computers and network devices

• Multiple domains

Active Directory allows a user to enter a password once per session and uses the Windows group-based authorization approach to define user privileges.

note-icon Note:

Kerberos authentication does not work when an Enterprise Portal uses a non-standard port. Details

User Identification within Active Directory

Users are added to Active Directory by an administrator. Users are added to Groups, which, in turn, have privileges in the form of access to services. A group can be a sub-group of another group. Each user, group, sub-group, and service has a unique Security Identifier (SID). SIDs are never reused, so uniqueness is guaranteed indefinitely.

For example, an administrator group defines a group called PlatformMgt. All users who are allowed to manage Intel AMT platforms are added to this group. Application software (e.g., an ISV Management Console application) is used to add the SID of PlatformMgt to the relevant Access Control List in all Intel AMT devices to be managed by this group. The Intel AMT device saves the ACL in non-volatile memory. When a user attempts to access a platform, Intel AMT verifies that the user’s SID is in its ACL before granting the user access. Intel AMT does not use Active Directory directly for authentication or authorization.

Kerberos Authentication with Active Directory

Once Active Directory “knows” each user, each platform (client and server platforms), and each service, then the following sequence is followed to connect a client to a service:

• Each platform authenticates with Active Directory after it is booted.

• Each user authenticates with Active Directory by logging on only once with a user ID and password. The user receives a “Ticket Granting Ticket” that contains:

• The user’s identity

• SIDs that the user is allowed to access based on the groups and sub-groups that the user is in

The ticket is good for the duration of the logon session or typically up to eight hours.

• The user authenticates to a service by supplying the Ticket Granting Ticket to the Ticket Granting Server.

• The Ticket Granting Server validates the ticket. If the user has the privilege of accessing the requested service, according to Active Directory criteria, the Ticket Granting Server returns a ticket with the user’s SID and all the SIDs to which he is a member.

• The user’s client application sends the ticket to the service.

• The service validates the ticket and sends back an authenticator where mutual authentication is required.

The validation and authorization sequence performed between a client and an Intel AMT server is summarized in the following figure.

1. The ISV application sends an HTTP POST WS-MAN request message to an Intel AMT device named “AMT01”.

2. The device responds with a HTTP 401 “Unauthorized” Authenticate/negotiate message.

3. The application sends Kerberos request to access AMT01 with the SPN embedded in it. The SPN in this case is HTTP/AMT01.intel.com:16992 (the WS-MAN over HTTP service to the selected device).

4. The Active Directory KDC responds with a ticket containing the application user’s accesses (SIDs).

5. The application workstation sends a POST message with a Negotiate response, indicating that a Kerberos authentication is required. At this point, AMT01 can authenticate the application user and authorize access if the user’s SID is in AMT01’s ACL for the requested realm.

6. AMT01 returns an HTTP 200 OK to authenticate with the application platform.