Difference Between ESXi 5.0/5.1/5.5 and 6.0

Features	5.0	5.1	5.5	6.0
VM HW Version	8	9	10	11
vCPU	32 vCPUs	64 vCPUs	64 vCPUs	128 vCPUs
VM Memory	1 TB	1 TB	1 TB	4 TB
Graphics Support	SW based 3D Graphics	HW Based 3D Graphics	Improved 3D graphics support	WDDM 1.1 GDI graphics acceleration
Cluster Nodes	32 Nodes	32 Nodes	32 Nodes	64 Nodes
VM's per cluster	3000	4000	4000	8000
Max CPU per Host	160	160	320	480
Max mem per Host	2 TB	2 TB	4 TB	12 TB
Max vCPU per FT VM	1 vCPU	1 vCPU	1 vCPU	4 vCPU
VCSA with Embedded database	5 Hosts and 50 VMs	5 Hosts and 50 VM's	300 Hosts and 1000 VM's	1000 Hosts and 10000 VM's
Content Library	NA	NA	NA	Yes
VSAN	N/A	N/A	VSAN 5.5	VSAN 6.0
VSAN  Scale			32 Nodes	64 Nodes
All-Flash VSAN			No	Yes
VSAN Fault Domains			No	Yes
vMotion Enhancements	vMotion Supported	vMotion without shared storage	vMotion without shared storage Long Distance vMotion (10 ms  RTTs)	vMotion access vCenters                            vMotion access virtual switches                                  Long Distance vMotion (100+ ms RTTs)
Virtual Volumes	NA	NA	NA	Available with vSphere 6.0
NFS Support	NFS v3	NFS v3	NFS v3	NFS 4.1 supports Multipathing and kerberos Authentication
vCenter Single-Sign-On	NA	Introduced with 5.1	SSO with improved Architecture	SSO included as part of Platform Services Controller
FT Supported Disk Types			Eager-Zeroed	Lazy-Zeroed, Eager Zeroed and Thin Provision
FT Supported Features			HA, DPM, SRM, VDS	HA, DPM, SRM, VDS, Hot Configuration FT, H/W Virtualization, Snapshot, Paravirtual Devices, Storage Redundancy
VMFS Version			5.60	5.61

How to Configure NIC Teaming in ESXi

A NIC Team can share the load traffic between physical and virtual networks among the some are all of its members, as well as provide passive failover in the event of a hardware failure or network outage.

To utilize NIC teaming, two or more network adapters must be uplinked to a virtual switch. The main advantages of NIC teaming are:

• Increased network capacity for the virtual switch hosting the team.
• Passive failover in the event one of the adapters in the team goes down.

Following are the NIC Teaming policy:

• Route Based on the originating port ID: Choose an uplink based on the virtual port where the traffic entered the virtual switch.
• Route Based on an IP hash: Choose an uplink based on a hash of the source and destination IP addresses of each port. For Non-IP packets, whatever is at those offsets is used to compute the hash.
• Route Based on a source MAC hash: Choose an uplink based on a hash of the source ethernet.
• Use explicit failover order: Always use the highest order uplink from the list of Active adapters which passes failover detection criteria.
• Route Based on physical NIC load ( Only available on distributed switch): Choose an uplink based on the current loads of Physical NIC's.
• The default load balancing policy is Route based on the originating virtual port ID. If the physical switch is using link aggregation, Route based on IP hash load balancing must be used.
• Ensure VLAN and link aggregation protocol (if any) are configured correctly on the physical switch ports.

To configure NIC teaming for standard vSwitch using the vSphere / VMware Infrastructure Client:

1. Highlight the host and click the Configuration tab.
2. Click the Networking link.
3. Click Properties.
4. Under the Network Adapters tab, click Add.
5. Select the appropriate (unclaimed) network adapter(s) and click Next.
6. Ensure that the selected adapter(s) are under Active Adapters.
7. Click Next > Finish.
8. Under the Ports tab, highlight the name of the port group and click Edit.
9. Click the NIC Teaming tab.
10. Select the correct Teaming policy under the Load Balancing field.
11. Click OK.

To configure NIC teaming for standard vSwitch using the vSphere Web Client:

1. Under vCenter Home, click Hosts and Clusters.
2. Click on the host.
3. Click Manage > Networking > Virtual Switches.
4. Click on the vSwitch.
5. Click Manage the physical network adapters.
6. Select the appropriate (unclaimed) network adapter(s) and use the arrow to move the adapter(s) to Active Adapters.
7. Click Edit settings.
8. Select the correct Teaming policy under the Load Balancing field.
9. Click OK.

To configure NIC teaming for Distributed portgroup for vSphere Distributed Switch (VDS) using the vSphere Client:

1. From Inventory, go to Networking.
2. Click on the Distributed switch.
3. Click the Configuration tab.
4. Click Manage Hosts. A window pops up.
5. Click the host.
6. From the Select Physical Adapters option, select the correct vmnics.
7. Click Next for the rest of the options.
8. Click Finish.
9. Expand the Distributed switch.
10. Right-click the Distributed Port Group.
11. Click Edit Settings.
12. Click Teaming and Failover.
13. Select the correct Teaming policy under the Load Balancing field.
14. Click OK.

To configure NIC teaming for Distributed portgroup for VDS using the vSphere Web Client:

1. Under vCenter Home, click Networking.
2. Click on the Distributed switch.
3. Click the Getting Started tab.
4. Under Basic tasks, click Add and manage hosts. A window pops up.
5. Click Manage host networking.
6. Click Next > Attached hosts.
7. Select the host(s).
8. Click Next.
9. Select Manage physical adapters and deselect the rest.
10. Click Next
11. Select the correct vmnics.
12. Click Assign Uplink > Next.
13. Click Next for the rest of the options.
14. Click Finish.
15. Expand the Distributed Switch.
16. Click Distributed Port Group. > Manage > Settings.
17. Under Properties, click Edit.
18. Click Teaming and failover.
19. Select the correct Teaming policy underthe Load Balancing field.
20. Click OK.

  

How to Install and Configure VMware ESXi 5.5

VMware ESXi 5.5 is the bare metal hypervisor from VMware. This is the software we install onto physical servers in Datacenter.

1. Bare-Metal Hypervisors - Run directly on the host server hardware to control resources and manage guest operating systems. Ex. VMware ESXi, Citrix Xen Server, Microsoft Hyper-V
2. Hosted Hypervisors - Run on-top of an existing operating system. This type of hypervisor runs as a separate layer on-top of the existing operating system as an application. Usually this type of hypervisor is for testing/lab purpose we use. Ex. VMware workstation, Microsoft Virtual PC, etc..

Following are the system resources required to install ESXi 5.5:

• ESXi 5.5 will install and run only on servers with 64-bit x86 CPUs.
• ESXi 5.5 requires a host machine with at least two cores.
• ESXi 5.5 supports only LAHF(Load AH From Flags) and SAHF(Store AH Into Flags)  CPU instructions.
• ESXi 5.5 requires the NX/XD bit to be enabled for the CPU in the BIOS.
• ESXi requires a minimum of 4GB of Physical RAM. Provide at least 8GB of RAM to take full advantage of ESXi features and run virtual machines in typical production environments.
• To support 64-bit virtual machines, support for hardware virtualization (Intel VT-x or AMD RVI) must be enabled on x64 CPUs.
• One or more Gigabit or 10GB Ethernet Controllers.

LAHF & SAHF: LAHF stands for Load AH from Flags and SAHF stands for Store AH into Flags. LAHF & SAHF are used to load and store instructions for certain status flags. Instructions are basic commands composed of one or more symbols that that are passed to a CPU as input. These instructions related to LAHF & SAHF are used for virtualization and floating-point condition handling.

NX(Never eXecute)/XD(eXecute Disable):  The NX/XD bit is a CPU feature called Never eXecute, hence the NX name. What the NX bit does is enable the ability to mark certain areas of memory as non-executable with a flag. When this happens the processor will then refuse to execute any code that resides in those areas of memory. Any attempt to execute code from a page that is marked as no execute will result in a memory access violation. This feature adds a layer of security to a computer by providing a protected area against malicious code such as viruses and buffer overflow attacks.

So you may be wondering about the XD part, well that is simply Intel’s name for the same feature which they refer to as eXecute Disable.

Install ESXi 5.5:

Download the ESXi 5.5 ISO image from the Vmware Download Center and burn it in DVD or CD if we are going to install in Physical Servers.

1. Insert the Vmware ESXi 5.5 CD/DVD and Power on the server. The first option we see is to either boot from the local drive or run the installer. Run the Vmware 5.5 Installer.

Once done the installer loads the required files into memory  to install Vmware ESXi 5.5.

Once all the modules are loaded successfully, you will get following screen with server configuration.

It shows welcome screen. To continue the installation, just press the enter key.

By default, you have to accept the license to continue the installation by pressing F11.

Select the disk in which you would like to install VMware ESXi 5.5. It requires minimum 4 to 5 GB space. Enter to continue.

Select the keyboard layout. Here I am selecting "US Default".

Its time to secure ESXi by providing the complex root password. Enter to continue.

Here the installer gathers the system information before start copying the files to the disk.

Here will be the final confirmation you need to give before destroying any data on the disk. Press F11 to continue the installation.

Installation begins.

Reboot the system to complete the installation. Make sure that you have removed the installation media from the server.

Some of the console message while rebooting the system.

Now Vmware ESXi 5.5 will boot from hard disk and you will get the below screen, once its completely up.

Many of them wonder that, how to login to the system. You can get login screen by just pressing F2.

Configure - Hostname, IP address, Gateway, DNS, Password on ESXI 5.5:

• Once reboot is completed, your installation is now complete. The next step is to configure ESXi  5.5 Host.
• Press F2 to enter the configuration mode
• You will promoted for the password which you provided during the installation ( note - the default user name is root
• The next step is to configure the management network interface. Select "Configure Management Network" > Press Enter.

Select IP configuration and Press Enter.

Select "Set Static IP Address and Network Configuration" -> Type the static IP address/Subnet mask and default gateway for ESXi host.

Select "DNS Configuration" and Press Enter.

Type the Primary DNS Server / Alternate DNS Server and Hostname for ESXi.

You will currently be in the "Configuration Management Network" Menu. You have completed all configuration required for ESXi5.5. To exit this menu and save configuration -> Press ESC -> Type [Y] to "Apply changes and restart management network". This will allow you to successfully exit the ESXi 5.5 configuration menu, back to home screen.

Integrate RHEL6 Server with Windows AD

Component Overview:

Following are the components are required to integrate Red Hat Linux Server with Windows AD for Single-Sign-On.

Red Hat Enterprise Linux 6:

Red Hat Enterprise Linux 6, the latest release of Red Hat's trusted datacenter platform, delivers advances in application performance, scalability, and security. With Red Hat Enterprise Linux 6, physical, virtual and cloud computing resources can be deployed within the data center.

Windows Server 2008 R2:

Windows Server 2008 R2 is Microsoft's enterprise operating system for businesses and provides features for virtualization, power savings, manageability and mobile access. Windows Server 2008 R2 is available in several editions – Foundation, Standard, Enterprise, Datacenter, Web and HPC (High Performance Computing). Windows Server 2008 R2 Enterprise Edition is used for the configurations described in this reference architecture.

Active Directory Domain Services (ADDS):

Active Directory Domain Services is a suite of directory services developed by Microsoft.

Active Directory utilizes customized versions of industry standard protocols including:

• Kerberos

• Domain Name System (DNS)

• Lightweight Directory Access Protocol (LDAP)

Active Directory allows Windows system administrators to securely manage directory objects

from a scalable, centralized database infrastructure. Directory objects (users, systems, groups, printers, applications) are stored in a hierarchy consisting of nodes, trees, forests and domains.

Prior to Windows Server 2008 R2, Active Directory Domain Services was known as Active Directory. Active Directory Domain Services is included with Windows Server 2008 R2.

Samba:

Samba is an open source suite of programs that can be installed on Red Hat Enterprise Linux

6 systems to provide file and print services to Microsoft Windows clients. Samba provides two daemons that run on a Red Hat Enterprise Linux 6 system:

• smbd (primary daemon providing file and print services to clients via SMB)

• nmbd (NetBIOS name server - not required for integration purposes)

When combined with the reliability and simplified management capabilities of Red Hat Enterprise Linux 6, Samba is the application of choice for providing file and print sharing to Windows clients. Samba version 3.5 is used in the Samba based configurations detailed within this reference architecture.

SMB/CIFS:

Both Server Message Block (SMB) and Common Internet File System (CIFS) are network protocols developed to facilitate client to server communications for file and print services. The SMB protocol was originally developed by IBM and later extended by Microsoft as the CIFS protocol.

Samba supports both the SMB and CIFS protocols with SMB provided for client connections

to older, legacy Windows servers (Windows 2000 or earlier). The terms SMB and CIFS are often interchanged but from a functional perspective, both are protocols used by Samba.

Winbind:

Winbind is a component of the Samba suite of programs that allows for unified user logon.

Winbind uses an implementation of Microsoft RPC (Remote Procedure Calls), PAM (Pluggable Authentication Modules), and Red Hat Enterprise Linux 6 nsswitch (Name Service Switch) to allow Windows Active Directory Domain Services users to appear and operate as local users on a Red Hat Enterprise Linux machine. Winbind minimizes the need for system administrators to manage separate user accounts on both the Red Hat Enterprise Linux 6 and Windows Server 2008 R2 environments.

Winbind provides three separate functions:

• Authentication of user credentials (via PAM). This makes it possible to log onto a Red Hat Enterprise Linux 6 system using Active Directory user accounts. Authentication is responsible for identifying “Who” a user claims to be.

• ID Tracking/Name Resolution via nsswitch (NSS). The nsswitch service allows user and system information to be obtained from different database services such as LDAP or NIS. ID Tracking/Name Resolution is responsible for determining “Where” user identities are found.

• ID Mapping represents the mapping between Red Hat Enterprise Linux 6 user (UID), group (GID), and Windows Server 2008 R2 security (SID) IDs. ID Mappings are handled through an idmap “backend

” that is responsible for tracking “What” ID's users are known by in both operating system environments.

Following figure represents Winbind Authentication, ID Components and Backend relationship between Winbind and Active Directory:

Kerberos:

Developed at the Massachusetts Institute of Technology (MIT), Kerberos is a network authentication protocol that uses symmetric key cryptography to provide highly secure authentication between client and server applications. Both Red Hat Enterprise Linux 6 and Windows server 2008 R2 are based on the current release of Kerberos - version 5. Kerberos operates on the basis of “tickets” that are granted by a trusted third-party called a key distribution center (KDC). The KDC maintains a secure database of secret keys that are known only to the KDC itself and the client requesting a ticket. Tickets have a configurable expiration date and must be refreshed by the client on a regular basis. Kerberos authentication is significantly safer than normal password-based authentication because passwords are never sent over the network - even when services are accessed on other machines.

Lightweight Directory Access Protocol (LDAP):

The Lightweight Directory Access Protocol (LDAP) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500 standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as "X.500 Lite." The X.500 standard is a directory that contains hierarchical and categorized information, which could include information such as names, addresses, and phone numbers.

Like X.500, LDAP organizes information in a hierarchy based on the use of directories. These

directories can store a variety of information and can even be used in a manner similar to the

Network Information Service (NIS), enabling anyone to access their account from any machine on the LDAP enabled network.

In many cases, LDAP is used as a virtual phone directory, allowing users to easily access contact information for other users. However, LDAP is much more flexible and capable of referring a query to other LDAP servers throughout the world, providing an ad-hoc global repository of information. Currently, LDAP is more commonly used within individual organizations, like universities, government departments, and private companies.

LDAP is a client/server system. The server can use a variety of databases to store a directory,

each optimized for quick and copious read operations. When an LDAP client application connects to an LDAP server, it can either query a directory or attempt to modify it. In the event of a query, the server either answers the query locally, or it can refer the query to an LDAP server which does have the answer. If the client application is attempting to modify information within an LDAP directory, the server verifies that the user has permission to make the change and then adds or updates the information.

The main benefit of using LDAP is that information for an entire organization can be

consolidated into a central repository.

System Security Services Daemon ( SSSD):

The System Security Services Daemon (SSSD) provides access to different identity and authentication providers. SSSD is an intermediary between local clients and any configured data store. The local clients connect to SSSD and then SSSD contacts the external providers. This brings a number of benefits for administrators:

•  Offline authentication: SSSD can optionally keep a cache of user identities and credentials that it retrieves from remote authentication/identification services. This allows users to authenticate to resources successfully, even if the remote identification server is offline or the local machine is offline.

•  Reduced load on authentication/identification servers. Rather than having every client contact the identification server directly, all local clients can contact SSSD which can connect to the identification server or check its cache.

•  Single user account. Remote users frequently have multiple user accounts, such as one for their local system and one for the organizational system. Since SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials.

SSSD recognizes domains, which are associated with different identity servers. Domains are a combination of an identity provider and an authentication method. SSSD works with LDAP identity providers (OpenLDAP, Red Hat Directory Server, IdM in RHEL, Microsoft Active Directory) and native LDAP authentication or Kerberos authentication.

Domain Name System (DNS:

Domain Name System (DNS) is a hierarchical, distributed naming system for managing the mappings between human-friendly domain, host and service names to IP addresses. DNS also defines the protocol for DNS communication exchanges as part of the Internet Protocol (IP) suite. On Red Hat Enterprise Linux 6, DNS is configured in the file /etc/resolv.conf.

Network Time Protocol (NTP):

Network Time Protocol (NTP) is an Internet protocol used to synchronize computer system clocks to a reference time source. On Red Hat Enterprise Linux 6, the ntpd daemon handles synchronization. NTP parameters are configured in the file /etc/ntp.conf.

Name Service Switch (NSS):

Name Service Switch (NSS) service allows user and system information (passwd, shadow, group, hosts, etc.) to be obtained from different database services such as DNS, LDAP, NIS or local files. On Red Hat Enterprise Linux 6, NSS parameters are configured in the file /etc/nsswitch.conf.

Log Files:

Log files are essential for monitoring application activity and troubleshooting. Following are the Component Log Files provides a summary of the default log file locations on RHEL 6 Systems.

Selecting a Configuration:

There are many criteria to consider when selecting a configuration that best meets the integration the needs for a specific environment.

Deployment Prerequisites:

Following are the deployment prerequisites for integrating Red Hat Enterprise Linux 6 systems into an Active Directory domain. The following deployment prerequisites must first be completed.

Windows Server 2008 R2 server:

• Deploy Windows Server 2008 R2

• Configure Active Directory Domain Services

Red Hat Enterprise Linux 6 systems:

• Deploy Red Hat Enterprise Linux 6

• Configure SELinux Security Parameters

• Synchronize Time Services

• Configure DNS

• Install/Configure Kerberos Client

NOTE: Do not proceed with the integration tasks until each of these components have been fully

configured and deployed.

Deploy Windows 2008 Server R2:

The following Microsoft TechNet article contains the most current and comprehensive details

on installing and deploying Windows Server 2008 R2:

http://technet.microsoft.com/en-us/library/dd283085.aspx

Configure Active Directory Domain Services:

If Active Directory Domain Services is already deployed and configured, proceed to Section 5.3

Deploy Red Hat Enterprise Linux 6 below.

If Active Directory Domain Services is not deployed, please consult the following Microsoft TechNet article for the most current and  comprehensive details:

http://technet.microsoft.com/en-us/library/cc770946.aspx

Deploy RHEL 6:

The Red Hat Enterprise Linux 6 Installation Guide provides complete details on the installation of Red Hat Enterprise Linux 6 for Intel, AMD, and IBM architectures. Red Hat Enterprise Linux 6 systems can be deployed as either physical or virtual machines. Regardless of whether physical or virtual machines are used, a Red Hat Enterprise Linux 6 installation involves the following series of stages:

• Install Red Hat Enterprise Linux 6
• FirstBoot
• Apply updates

After the operating system has been installed the system reboots and enters what is referred to as

FirstBoot. During FirstBoot, administrators are guided through the process of setting date and time, configuring software updates, registering with Red Hat Network (RHN), initial user account creation and options for Kernel (Kdump) crash dumps. The system then reboots to activate the changes. After login has been completed under the newly created user account, updates to the system are applied to bring the Red Hat Enterprise Linux 6 system to the latest versions of all software. Updates to apply the most recent patches and security updates for Red Hat Enterprise Linux 6 can be performed at any time by running:

# yum update

Configure SELinux Security Parameters:

By default, SELinux is enabled during the Red Hat Enterprise Linux 6 installation process. For

maximum security, Red Hat recommends running Red Hat Enterprise Linux 6 with SELinux enabled. 

1. Verify whether or not SELinux is enabled using the getenforce utility:

2. If getenforce returns "Permissive" then set to "Enforcing" and verify:

3. Edit the file /etc/selinux/config and set Selinux to be persistent across reboots:

Synchronize Time Services:

It is essential that the time service on the Red Hat Enterprise Linux 6 systems and Active Directory (Windows 2008) server are synchronized, otherwise Kerberos authentication may fail due to clock skew. In environments where time services are not reliable, best practice is to configure the Red Hat Enterprise Linux 6 systems to synchronize time from the Windows Server 2008 R2 server.

1. Edit the file /etc/ntp.conf so that the RHEL6 system time is synchronized from a known, reliable time service.

2. Activate the change on the RHEL6 systems, by stopping the ntp daemon, updating the time, then starting the ntp daemon. Verify the change on both servers.

RHEL6 System:

Windows Server 2008 Server R2:

Configure the ntpd daemon to start on server reboot.

Configure DNS:

Proper resolution of DNS hostnames from both the Red Hat Enterprise Linux 6 systems and the Active Directory (Windows 2008) server are an essential prerequisite. Improperly resolved hostnames are one of the leading causes for integration failures. In environments where DNS lookups are not reliable,

best practice is to configure the Red Hat Enterprise Linux 6 systems to perform DNS lookups from the Windows Server 2008 R2 Active Directory server.

1. Edit the /etc/resolv.conf so that the fully qualified domain name (FQDN) of the DNS servers is specified:

2. Similarly, the hostname of the RHEL6 system should be set to the FQDN. Edit the file /etc/sysconfig/network and set the hostname to use the FQDN.

Install/Configure Kerberos Client:

To install and configure the Kerberos client (krb5-workstation) to insure Kerberos is able to properly authenticate to Active Directory on the Windows Server 2008 R2 server. This step is optional but highly recommended as it is useful for troubleshooting Kerberos authentication issues.

Verify the kerberos client is installed

If not, install it as follows:

If Kerberos has not been previously configured, modify the Kerberos configuration file (/etc/krb5.conf) by adding entries for the new Kerberos and Active Directory realms. Note the differences in the Kerberos [realms] and Active Directory [domain_realm] realm entries.

Create a safety copy of the kerberos configuration file.

Edit the file /etc/krb5.conf as follows - changes are highlighted  bold:

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true [realms] REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM = { kdc = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM admin_server = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM } [domain_realm] .refarch-ad.cloud.lab.eng.bos.redhat.com = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM refarch-ad.cloud.lab.eng.bos.redhat.com = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM

Under Kerberos, [realms] is set to the Kerberos server definitions and [domain_realm] defines the Active Directory server. Both are in the Active Directory REFARCH-AD domain.

Verify the kerberos configuration. First, clear out any existing tickets:

Obtain a new kerberos ticket:

Verify a new Kerberos ticket was granted.

At this point kerberos is fully functional and the client utilities (kinit, klist, kdestroy) can be used for testing and verifying kerberos functionality.

Install oddjob-mkhomedir:

Install the oddjob-mkhomedir package to ensure that user home directories are created with the proper SELinux file and directory contexts:

Start the oddjobd service and enable it to start on boot.

Configuration - SSSD/Kerberos/LDAP:

This configuration is for environments looking to integrate one or more RHEL 6 systems into an Active Directory domain or forest with the enhanced authentication and caching capabilities offered by SSSD. Login access is the only service provided.

Configuration Summary:

Systems Overview:

Following figure provides overview of the systems and services utilized by configuration.

Authentication and AD Components:

Following shows the Authentication and ID Tracking for following configuration.

Integration Tasks:

Integrating Red Hat Enterprise Linux 6 into an Active Directory Domain for following configuration involves the following series of steps.

1. Install packages
2. Configure Kerberos
3. Configure Samba
4. Obtain Kerberos ticket
5.  Join Active Directory domain and obtain keytab
6. Verify keytab
7. Obtain Kerberos ticket using keytab
8. Verify Active Directory LDAP searches (optional)
9. Configure SSSD authentication
10. Modify SSSD configuration

The following provides a step-by-step guide to the integration process.

Install Packages:

The default installation of RHEL 6.5 includes the following packages.

• SSSD
• Kerberos Client
• Samba Common
• Authconfig

If any of above packages are not available, install them as follows.

The Samba Common Package provides a library that facilitates AD access.

Configure Kerberos.

Modify the Kerberos configuration file (/etc/krb5.conf) by adding entries for the new Kerberos and Active Directory realms. Note the differences in the Kerberos [realms]and Active Directory domain_realm] realm entries.

Create a backup copy of the Kerberos configuration file:

Edit and Save the /etc/krb5.conf file as follows - changes are highlighted in bold:

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true [realms] REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM = { kdc = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM admin_server = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM } [domain_realm] .refarch-ad.cloud.lab.eng.bos.redhat.com = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM refarch-ad.cloud.lab.eng.bos.redhat.com = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM

Configure Samba

Samba provides libraries to facilitate access to AD. In order for an SSSD based configuration to use a library, a minimal Samba configuration file must be created.

Create a backup copy of the existing Samba configuration file.

Edit and Save the /etc/samba/smb.conf file as follows - Changes are highlighted in bold.

Since most of the entries in the default /etc/samba/smb.conf file are only comments and the smb service is not in use, the file can be simplified to only contain the entries above.

Verify the Samba configuration changes:

# testparm Load smb config files from /etc/samba/smb.conf Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions [global] workgroup = REFARCH­AD realm = REFARCH­AD.CLOUD.LAB.ENG.BOS.REDHAT.COM security = ADS kerberos method = secrets and keytab log file = /var/log/samba/log.%m max log size = 50 client signing = Yes idmap config * : backend = tdb

Note that it is common for testparm to display rlimit_max warning.

This warning is caused by the default value for the maximum number of open files being lower than the default Windows limit. Correct the warning by adding the entry:

to the file /etc/security/limits.conf. The change is activated immediately for all new sessions. Existing sessions do not utilize the change until users logout and login again to the Red Hat Enterprise Linux 6 server.

Obtain Kerberos ticket:

Obtain and verify a new ticket using the modfied Kerberos configuration:

Join Active Directory domain and obtain keytab.

Join the Active Directory domain using the Kerberos ticket by specifying the -k option: 

Verify keytab:

Verify the keytab by specifying the -k option.

Obtain Kerberos ticket using keytab.

Use the keytab to obtain a new Kerberos ticket.

Note that the Default principal has been changed from a user to host based principal

Before:

After:

Verify Active Directory LDAP searches (optional):

This step is optional but useful to verifying LDAP searches can be successfully performed against the Active Directory domain:

If ldapsearch is not available, install the openldap-clients package:

Configure SSSD authentication:

The authconfig tool simplifies configuring nsswitch.conf and the configuration files for the PAM libraries (/etc/pam.d/password-auth-ac, /etc/pam.d/system-auth-ac) for use by SSSD. Invoke the tool as follows:

The oddjobd daemon is restarted to permit the creation of user home directories on first login.

Modify SSSD Configuration:

Next, parameters are modified within the SSSD configuration file to use the AD provider. Following table provides a summary of the configuration file parameter changes:

The AD provider for SSSD is a back end specifically designed to connect to Active Directory on Windows Server 2008 R2 or later. Earlier versions of Windows Server and Active Directory may work but are not supported by Red Hat. In environments where the POSIX attributes (aka - Identity Management for UNIX) have been enabled on the Active Directory server, set ldap_id_mapping = false on the Red Hat Enterprise Linux clients. This disables UID/GID to SID mappings and uses the values that have been set in the UNIX Attributes tab on the Windows Active Directory server.

If there is an existing SSSD configuration file, make a backup copy:

Edit and save the SSSD configuration as follows.

Start the SSSD daemon and enable it to start on boot:

This completes the configuration tasks

Verification Of Services:

Verify the services provided by Configuration by performing the tasks outlined in the following sections:

Login Access:

Verify access from another Red Hat Enterprise Linux 6 system, using a different Active

Directory user account: