Книга: Mastering VMware® Infrastructure3

Kerberos Authentication for ESX Server

Kerberos Authentication for ESX Server

ESX Servers, by default, use local users and groups to assign permissions to directories and files. With VI3, there is no longer a need for large numbers of these local accounts. But, even in enterprise datacenters, two or three accounts are needed for those rare instances when a task cannot be accomplished through VirtualCenter. Some examples of these instances are:

? VirtualCenter is not available or is down.

? You are troubleshooting ESX Server boot and configuration problems.

? You are setting up specific services that weren't set up during the basic installation, such as NTP.

? You are auditing the ESX Server configuration and remote access by comparing archived files with live versions of the same files.

This list is not exhaustive, but does give some insight into why logging locally into an ESX Server is sometimes necessary. With a few changes to the underlying authentication module, user accounts can be authenticated against Active Directory (AD). This allows for a consistent way to apply security polices as they relate to user management by allowing AD administrators to set policies on password complexity, expiration, and user account changes at an AD level, bypassing local ESX Server setup.

Service Console User Accounts

Even with AD integration, user accounts must be created locally on the ESX Server. When creating those accounts, make sure the names for those accounts match the names in Active Directory. By default, there is no mechanism for reconciling local ESX accounts with AD users. If a user is deleted in AD, you must manually delete the user on the ESX Server.

The easiest way to implement AD authentication is to use the esxcfg-auth tool. This valuable tool can be used to set local user security policies, such as password complexity, reuse, and length. In this case, esxcfg-auth hands over the authentication process to AD by modifying the krb5.conf file, creating the kdc.conf file, and modifying the pam.d file so that VI Client and ssh connections use Kerberos authentication.

Perform the following steps to set up Active Directory authentication:

1. Log into the Service Console as root.

2. Issue the following command as shown in Figure 12.28:

# esxcfg-auth --enablead --addomain domain_name --addc domain_name 


Figure 12.28 The first authentication attempt by the ESX Server is handled by Active Directory.

Accessing Local and Remote Domain Controllers

In this example, the assumption is that a local domain controller will handle the authentication. In some cases, if there is a firewall between the ESX servers and the domain controller, the ports listed in krb5.conf may need to be opened. Also, Active Directory DNS should return the local domain controller for this operation. Although you can specify a domain controller in the above command, it's better to just name the domain and let DNS sort out the local DC. 

3. Check the krb5.conf file to see if the necessary changes have been made as shown in Figure 12.29.


Figure 12.29 Double-check the file to be sure the correct information was added.

4. Create only the necessary administrative user accounts that match existing Active Directory accounts. Do not set the passwords for these accounts as shown in Figures 12.30 and 12.31.


Figure 12.30 Check the existing user account in Active Directory.


Figure 12.31 Create the local Service Console account that matches the name in AD.

5. Log in with one of the administrative accounts as shown in Figure 12.32.


Figure 12.32 Log in with a local account to check that Active Directory authenticated the user.

6. Check the logs to see if the process is working without errors as shown in Figure 12.33.


Figure 12.33 Review the system logs for any errors with the Kerberos authentication process.

Оглавление книги


Генерация: 0.047. Запросов К БД/Cache: 0 / 0
поделиться
Вверх Вниз