Home > Intel Communities > Open Port IT Community > Intel® vPro™ Expert Center > Blog > Tags > ad

Intel vPro Expert Center Blog

3 Posts tagged with the ad tag
0

If you have having problems accessing the WebUI of a provisioned system using an Active Directory User ID review the data in my latest document....  Access to the Intel® vPro™ Web UI with Active Directory User IDs

0 Comments Permalink
0

Some of you might find that you need to provision your vPro systems with hostname only as opposed to the generally recommended and accepted fully qualified domain name - FQDN. The typical reason for using hostname only would be because the FQDN that appears at the OS level of a client will not match what will appear in the DNS forward and reverse lookup zones.

 

You might ask - how can that be? An example from one of my customers is that they have a network domain that is appended to entries in DNS via DHCP option 15. However, their DNS/DHCP is not integrated with their Active Directory and a different AD domain exists. Therefore when using the activator tool to extract the FQDN of the system and write it into the SCS DB as part of the provisioning process, it will conflict with the FQDN that appears in DNS. This will not cause a problem for provisioning per se, but for trying to access the machine later on using a management tool/interface it probably will.

 

Note: if you are using TLS certificates (server or mutual authentication) then hostname only provisioning will probably not be a viable option for you in any case because of the scrutiny of certificate exchanges that check whether domain suffices match.

 

So what does all this have to do with SCS 5.0? In 3.x versions of SCS there wasn't anything special you needed to do to allow hostname only provisioning, but with SCS 5.0 there is. When you construct your provisioning profile, in the optional settings you will need to select domains and make sure you select the checkbox of ‘Allow configuration when platform has no domain name'.

 

What if you are doing AD Integration?

If you are opting for AD Integration (as many will), you will have a problem with SCS 5.0. The reason for this is that the Kerberos protocol will insist that the request ticket will rely on DNS for your FQDN entry, whereas your object within the AMT OU in Active Directory will have a service principle name field (SPN) that will not match that FQDN - the SPN will have hostname and the request ticket will be whatever it is in DNS and at that point the kerberos negotiation will fail. It is important to stress that provisioning will work fine and you will see no hint to these issues, however once you try and access the machines via WebUI or any management console, you will have a problem.

 

 

The fix for (for now) will be to edit the SPN field for each provisioned machine's object in AD to what will appear in DNS. The SPN field has an entry for each port number that could potentially be used for AMT purposes (16992,16993,16994,16995,623,664) but if you are not using SOL/IDER and are not using certificates (you won't if you've opted for hostname only in any case) then the only field you should need to change is for the 16992 port. You can edit this field manually using ADSIedit. A more scalable solution will require a script to run as a post provisioning step to edit the SPN. A solution within SCS 5.0 is not available at present.

 

 

Ta

 

0 Comments Permalink
2

Welcome and Future Topics

 

This blog posting is being created to discuss/highlight the key areas you should be aware of when implementing and activating vPro and Centrino Pro Technology within your environment. To start we will focus on Infrastructure, Requirements and Dependencies, and The Setup and Configuration Server.

 

If you have any additional topics you would like to see that fall under implementation and activation, please let me know.

 

Infrastructure:

 

In general an enterprise looking to deploy Intel® Active Management Technology will require at a minimum three servers in addition to your existing management framework to take full advantage of these capabilities. It is also recommended that for a fully functional enterprise that these servers be redundant as appropriate for their service to provide for high availability. Most, if not all enterprises require the robustness of service that can only be attained via high availability configurations. The three additional servers are as follows:

 

    1. One to host the Microsoft Certificate Authority

    2. One to host the Intel® AMT Setup & Configuration Server (depending on your ISV of choice)

    3. One to host the Microsoft SQL® Server Database

 

If an enterprise already has a SQL Server database or database farm in place, it could possibly be utilized eliminating the need to standup a separate service. Similarly, if an enterprise has an existing PKI in place, it could possibly be utilized for the Intel® AMT deployment. However, in this case it is likely that a successful startup of a pilot within an enterprise would be bolstered by implementing the PKI in standalone mode and then migrating to the existing PKI.

 

Another option for the enterprise that has a fully supported virtualization environment is to place the Microsoft Certificate Authority and the Intel® AMT Setup & Configuration Server in within that environment. The caveat is that the environment must be supported just like standard physical server environment. Process and procedures should account for standard server support in the virtual environment. Note: Virtualization of the SQL Server database cluster is not recommended.

 

It is assumed that a fully functional Windows networking infrastructure is in place prior to the deployment of Intel® AMT management capabilities. These assumptions include the highly available configurations most common to enterprise deployments of Windows Active Directory, Domain Name Servers, DHCP servers, and your Manageability Software that was support for Intel® vPro Technology.

Windows Server 2003 Active Directory (AD)

Microsoft Active Directory is assumed to be part of the overall network infrastructure supporting the existing Windows network environment. This architecture requires AD as the authentication mechanism allowing the Intel® Setup & Configuration Server, vPro ISV enabled Software, and potential web clients to logon to Intel® AMT hosts. AD should inherently be designed in a high availability configuration as prescribed by the existing environment and geographic requirements as well as best practices for AD in general.

Domain Name Server (DNS)

A domain name server is used to supply the name to IP resolution for the Intel® AMT hosts as well as resolving the Setup & Configuration server IP address for provisioning purposes. The name and IP address of each Intel® AMT host will be automatically registered in the DNS by the DHCP server.

 

Each Intel® AMT host will try to resolve the static name "ProvisionServer" during the initial activation process. ProvisionServer will be manually registered in the DNS and assigned to the Setup & Configuration Server IP address.

 

DNS is expected to be integral to the existing Windows network infrastructure. DNS should inherently be designed in a high availability configuration as prescribed by the existing environment and geographic requirements as well as best practices for DNS in general.

 

Dynamic Host Configuration Protocol (DHCP) Server

DHCP services must be in place to properly register Intel® AMT hosts within the enterprise. The hosts require that the DHCP server register their fully qualified domain name (FQDN) with the DNS. If the Microsoft DHCP server is employed it should be configured to automatically register the hosts in the DNS. Standard DHCP option 81 should be used to accomplish the task of registering the Intel® AMT hosts in the DNS as the FQDN is required as part of the PKI certificate generated for the device. The DNS is queried by the configuration server or add-on to compare against the certificate received in order to properly accept the TLS encryption with the Intel® AMT host.

Microsoft Certificate Authority (CA)

At a minimum a stand-alone PKI certificate authority would need to be in place to enable encrypted and secure communication with the Intel® AMT hosts. The Microsoft certificate authority (CA) is required to properly interoperate with the Intel® Setup & Configuration Server. The CA is required to issue certificates to the Intel® AMT hosts, the Setup & Configuration Server, and in the case of Mutual Transport Layer Security (MTLS) the vPro enabled ISV software (that using the Intel SCS). These certificates allow for SSL encryption and Transport Layer Security (TLS) and MTLS.

A certificate can be purchased from an outside vendor such as Verisign®. This enables easier provisioning (Remote Configuration) of the Intel® AMT 3.0 hosts as the Verisign root certificate hash is already defined in the host. This will be covered in later when we focus on Intel® AMT 3.0 devices.

 

These servers may be considered for virtual hosting environments. It is a requirement that the virtual hosting environment be fully supported within the environment through standard operating procedures. It is expected that if these servers are virtually hosted they will receive equivalent operational support as if they were hosted in a physical environment.

2 Comments Permalink