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:
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:
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
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.
- Install packages
- Configure Kerberos
- Configure Samba
- Obtain Kerberos ticket
- Join Active Directory domain and obtain keytab
- Verify keytab
- Obtain Kerberos ticket using keytab
- Verify Active Directory LDAP searches (optional)
- Configure SSSD authentication
- 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
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 = REFARCHAD
realm = REFARCHAD.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:
No comments:
Post a Comment