Red Hat Enterprise Linux 7 Windows Integration Guide - Free Download PDF

11d ago
1 Views
0 Downloads
5.20 MB
117 Pages
Transcription

Red Hat Enterprise Linux 7Windows Integration GuideIntegrating Linux Systems with Active Directory EnvironmentsElla Deon BallardTomáš ČapekAneta Petrová

Red Hat Enterprise Linux 7 Windows Integration GuideIntegrating Linux Systems with Active Directory EnvironmentsElla Deo n BallardRed Hat Custo mer Co ntent [email protected] mTo máš ČapekRed Hat Custo mer Co ntent [email protected] mAneta Petro váRed Hat Custo mer Co ntent Servicesapetro [email protected] m

Legal NoticeCo pyright 20 15 Red Hat.This do cument is licensed by Red Hat under the Creative Co mmo ns Attributio n-ShareAlike 3.0Unpo rted License. If yo u distribute this do cument, o r a mo dified versio n o f it, yo u must pro videattributio n to Red Hat, Inc. and pro vide a link to the o riginal. If the do cument is mo dified, all RedHat trademarks must be remo ved.Red Hat, as the licenso r o f this do cument, waives the right to enfo rce, and agrees no t to assert,Sectio n 4 d o f CC-BY-SA to the fullest extent permitted by applicable law.Red Hat, Red Hat Enterprise Linux, the Shado wman lo go , JBo ss, MetaMatrix, Fedo ra, the InfinityLo go , and RHCE are trademarks o f Red Hat, Inc., registered in the United States and o therco untries.Linux is the registered trademark o f Linus To rvalds in the United States and o ther co untries.Java is a registered trademark o f Oracle and/o r its affiliates.XFS is a trademark o f Silico n Graphics Internatio nal Co rp. o r its subsidiaries in the UnitedStates and/o r o ther co untries.MySQL is a registered trademark o f MySQL AB in the United States, the Euro pean Unio n ando ther co untries.No de.js is an o fficial trademark o f Jo yent. Red Hat So ftware Co llectio ns is no t fo rmallyrelated to o r endo rsed by the o fficial Jo yent No de.js o pen so urce o r co mmercial pro ject.The OpenStack Wo rd Mark and OpenStack Lo go are either registered trademarks/servicemarks o r trademarks/service marks o f the OpenStack Fo undatio n, in the United States and o therco untries and are used with the OpenStack Fo undatio n's permissio n. We are no t affiliated with,endo rsed o r spo nso red by the OpenStack Fo undatio n, o r the OpenStack co mmunity.All o ther trademarks are the pro perty o f their respective o wners.AbstractHetero geneo us IT enviro nments o ften co ntain vario us different do mains and o peratingsystems that need to be able to seamlessly co mmunicate. Red Hat Enterprise Linux o ffersmultiple ways to tightly integrate Linux do mains with Active Directo ry (AD) o n Micro so ftWindo ws. The integratio n is po ssible o n different do main o bjects that include users, gro ups,services, o r systems. This guide also co vers different integratio n scenario s, ranging fro m lightweight AD pass-thro ugh authenticatio n to full-fledged Kerbero s trusted realms.

T able of Cont ent sT able of Contents. .hapt C. . . .er. .1. . Ways. . . . . t.o. .Int. . egrat. . . . .e. Act. . . ive. . . Direct. . . . . .ory. . .and. . . .Linux. . . . . Environment.s. . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . 1.1. Defining Wind o ws Integ ratio n3 1.2. Direc t Integ ratio n4 1.3. Ind irec t Integ ratio n5. .art P. . .I. Adding. . . . . . .a. Single. . . . . . Linux. . . . . .Syst. . . .em. . .t .o. an. . .Act. . .ive. . .Direct. . . . . ory. . . .Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. . . . . . . . . . .hapt C. . . .er. .2. . Using. . . . . .Act. . .ive. . .Direct. . . . . ory. . . as. . .an. . .Ident. . . . it. .y. Provider. . . . . . . .for. . .SSSD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . . 2 .1. Ab o ut SSSD8 2 .2. Enviro nments fo r SSSD10 2 .3. Ho w SSSD Integ rates with an Ac tive Direc to ry Enviro nment10 2 .4. Co nfig uring an Ac tive Direc to ry Do main with ID Map p ing16 2 .5. Co nfig uring an Ac tive Direc to ry Do main with PO SIX Attrib utes18 2 .6 . Ad d itio nal Co nfig uratio n Examp les23. .hapt C. . . .er. .3. .Using. . . . . .realmd. . . . . .t.o. Connect. . . . . . . . t. o. .an. . .Act. . .ive. . .Direct. . . . .ory. . . Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. 7. . . . . . . . . . 3 .1. Ab o ut realmd27 3 .2. realmd Co mmand s27 3 .3. Dis c o vering and Jo ining Ac tive Direc to ry Do mains28 3 .4. Manag ing Us er Lo g ins fro m Ac tive Direc to ry31 3 .5. Ad d ing Default Us er Co nfig uratio n32 3 .6 . Ad d itio nal Co nfig uratio n fo r the Ac tive Direc to ry Do main Entry32. .hapt C. . . .er. .4. . Using. . . . . .Samba,. . . . . . .Kerberos,. . . . . . . . and. . . . Winbind. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34. 4 .1. Ab o ut Samb a and Ac tive Direc to ry Authentic atio n34 4 .2. Summary o f Co nfig uratio n Files , O p tio ns , and Pac kag es37 4 .3. Co nfig uring a Do main Memb er Us ing authc o nfig38. .art P. . .II. .Int. . egrat. . . . .ing. . . a. .Linux. . . . .Domain. . . . . . . wit. . .h. an. . . Act. . . ive. . . Direct. . . . . ory. . . .Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. 5. . . . . . . . . . .hapt C. . . .er. .5. .Creat. . . . .ing. . .Cross. . . . . .Realm. . . . . .T.rust. . . .s. wit. . .h. Act. . . ive. . . Direct. . . . . .ory. . . and. . . .Ident. . . . .it.y. Management. . . . . . . . . . . . . . . . . .4. 6. . . . . . . . . . 5 .1. Intro d uc tio n to Trus ts46 5 .2. Enviro nment and Mac hine Req uirements to Set up Trus ts57 5 .3. Creating Id M G ro up s fo r Ac tive Direc to ry Us ers59 5 .4. Maintaining Trus ts61 5 .5. Verifying That Id M Mac hines Have Res o lvab le Names65 5 .6 . Setting PAC Typ es fo r Servic es 5 .7. Us ing SSH fro m Ac tive Direc to ry Mac hines fo r Id M Res o urc es 5 .8 . Us ing Trus t with Kerb eriz ed Web Ap p lic atio ns 5 .9 . Ac tive Direc to ry Trus t fo r Leg ac y Linux Clients67707172. .hapt C. . . .er. .6. . Set. . . t.ing. . . up. . . Kerberos. . . . . . . . Cross. . . . . . Realm. . . . . . Aut. . . hent. . . . icat. . . .ion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7. 6. . . . . . . . . . 6 .1. A Trus t Relatio ns hip76 6 .2. Setting up a Realm Trus t79. .hapt C. . . .er. .7. . Synchroniz. . . . . . . . . . ing. . . Act. . . ive. . . Direct. . . . . .ory. . . and. . . .Ident. . . . .it.y. Management. . . . . . . . . . . . Users. . . . . . . . . . . . . . . . . . . . . . .8. 0. . . . . . . . . . 7 .1. Sup p o rted Wind o ws Platfo rms80 7 .2. Ab o ut Ac tive Direc to ry and Id entity Manag ement80 7 .3. Ab o ut Sync hro niz ed Attrib utes83 7 .4. Setting up Ac tive Direc to ry fo r Sync hro niz atio n86 7 .5. Manag ing Sync hro niz atio n Ag reements87 7 .6 . Manag ing Pas s wo rd Sync hro niz atio n95. .hapt C. . . .er. .8. . ID. . Views. . . . . .and. . . .Migrat. . . . . ing. . . .Exist. . . . ing. . . .Environment. . . . . . . . . . .s. t. o. .T. rust. . . . . . . . . . . . . . . . . . . . . . . . . . . .1.0. 2. . . . . . . . . . 8 .1. Us er O verrid es and G ro up O verrid es10 31

Red Hat Ent erprise Linux 7 Windows Int egrat ion G uide 8 .1. Us er O verrid es and G ro up O verrid es10 3 8 .2. Manag ing ID Views10 3 8 .3. Mig rating fro m the Sync hro niz atio n-Bas ed to the Trus t-Bas ed So lutio n111 I.ndex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1. 1. . . . . . . . . . . . . . . . . .HistRevision. . . ory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. 1. 3. . . . . . . . . .2

Chapt er 1 . Ways t o Int egrat e Act ive Direct ory and Linux Environment sChapter 1. Ways to Integrate Active Directory and LinuxEnvironmentsIT environments have a structure. The systems in them are arranged with a purpose. Integrating twoseparate infrastructures requires an assessment of the purpose of each of those environments andan understanding of how and where they interact.1.1. Defining Windows Int egrat ionWindows integration can mean very different things, depending on the desired interaction betweenthe Linux environment and the Windows environment. It could mean that individual Linux systems areenrolled into a Windows domain, it could mean that a Linux domain is configured to be a peer to theWindows domain, or it could simply mean that information is copied between environments.There are several points of contact between a Windows domain and Linux systems. Each of thesepoints revolve around identifying different domain objects (users, groups, systems, services) and theservices which are used in that identification.Use r Ide nt it ie s and Aut he nt icat io nWhere are user accounts located; in a central authentication system running on Windows (ADdomain) or in a central identity and authentication server running on Linux?How are users authenticated on a Linux system; through a local Linux authentication system or acentral authentication system running on Windows?How is group membership configured for users? How is that group membership determined?Will users authenticate using a username/password pair, Kerberos tickets, certificates, or acombination of methods?POSIX attributes are required to access services on Linux machines. How are these attributesstored: are they set in the Windows domain, configured locally on the Linux system, ordynamically mapped (for UID /GID numbers and Windows SID s)?What users will be accessing what resources? Will Windows-defined users access Linuxresources? Will Linux-defined users access Windows resources?In most environments, the Active D irectory domain is the central hub for user information, whichmeans that there needs to be some way for Linux systems to access that user information forauthentication requests. The real question then is how to obtain that user information and how muchof that information is available to external systems. There also needs to be a balance betweeninformation required for Linux systems (POSIX attributes) and Linux users (certain applicationadministrators) and how that information is managed.Ho st and Se rvice PrincipalsWhat resources will be accessed?What authentication protocols are required?How will Kerberos tickets be obtained? How will SSL certificates be requested or verified?Will users need access to a single domain or to both Linux and Windows domains?3

Red Hat Ent erprise Linux 7 Windows Int egrat ion G uideDNS Do m ains, Que rie s, and Nam e Re so lut io nWhat will be a D NS configuration?Is there a single D NS domain? Are there subdomains?How will system host names be resolved?How will service discovery be configured?Se curit y Po licie sWhere are access control instructions set?What administrators are configured for each domain?Change Manage m e ntHow frequently are systems added to the domain?If the underlying configuration for something related to Windows integration is changed, forexample the D NS service, how are those changes propagated?Is configuration maintained through domain-related tools or a provisioning system?D oes the integration path require additional applications or configuration on the Windowsserver?As important as which elements in the domains are integrated, is how that integration is maintained. Ifa particular instrument of integration is heavily manual, yet the environment has a large number ofsystems which are frequently updated, then that one instrument may not work for that environmentfrom a maintenance standpoint.The following sections outline the main scenarios for integration with Windows. In direct integration,Linux systems are connected to Active D irectory without any additional intermediaries. Indirectintegration, on the other hand, involves an identity server that centrally manages Linux systems andconnects the whole environment to Active D irectory of the server-to-server level.1.2. Direct Int egrat ionYou need two components to connect a Linux system to Active D irectory (AD ). One componentinteracts with the central identity and authentication source, which is AD in this case. The othercomponent detects available domains and configures the first component to work with the rightidentity source. There are different options that can be used to retrieve information and performauthentication against AD . Among them are:N at ive LD AP an d K erb ero s PAM an d N SS mo d u lesAmong these modules are nss l d ap, pam l d ap, and pam krb5. As PAM and NSSmodules are loaded into every application process, they directly affect the executionenvironment. With no caching, offline support, or sufficient protection of access credentials,use of the basic LD AP and Kerberos modules for NSS and PAM is discouraged due to theirlimited functionality.Samb a Win b in dSamba Winbind had been a traditional way of connecting Linux systems to AD . Winbindemulates a Windows client on a Linux system and is able to communicate to AD servers.4

Chapt er 1 . Ways t o Int egrat e Act ive Direct ory and Linux Environment sThe recent versions of the System Security Services D aemon (SSSD ) closed a feature gapbetween Samba Winbind and SSSD and SSSD can now be used as a replacement forWinbind. In certain corner cases, Winbind might still be necessary to use but it is no longerthe first choice in general.Syst em Secu rit y Services D aemo n ( SSSD )The primary function of SSSD is to access a remote identity and authentication resourcethrough a common framework that provides caching and offline support to the system.SSSD is highly configurable; it provides PAM and NSS integration and a database to storelocal users, as well as core and extended user data retrieved from a central server. SSSD isthe recommended component to connect a Linux system with an identity server of yourchoice, be it Active D irectory, Identity Management (IdM) in Red Hat Enterprise Linux, or anygeneric LD AP and/or Kerberos server.The main reason to transition from Winbind to SSSD is that SSSD can be used for both direct andindirect integration and allows to switch from one integration approach to another without significantmigration costs. The most convenient way to configure SSSD or Winbind in order to directly integratea Linux system with AD is to use the real md service. It allows callers to configure networkauthentication and domain membership in a standard way. The real md service automaticallydiscovers information about accessible domains and realms and does not require advancedconfiguration to join a domain or realm.D irect integration is a simple way to introduce Linux systems to AD environment. However, as theshare of Linux systems grows, the deployments usually see the need for a better centralizedmanagement of the identity-related policies such as host-based access control, sudo, or SELinuxuser mappings. At first, the configuration of these aspects of the Linux systems can be maintained inlocal configuration files. With a growing number of systems though, distribution and management ofthe configuration files is easier with a provisioning system such as Red Hat Satellite. This approachcreates an overhead of changing the configuration files and then distributing them. When directintegration does not scale anymore, it is more beneficial to consider indirect integration described inthe next section.1.3. Indirect Int egrat ionThe main advantage of the indirect integration is to manage Linux systems and policies related tothose systems centrally while enabling users from Active D irectory (AD ) domains to transparentlyaccess Linux systems and services. There are two different approaches to the indirect integration:T ru st - b ased so lu t io nThe recommended approach is to leverage Identity Management (IdM) in Red Hat EnterpriseLinux as the central server to control Linux systems and then establish cross-realmKerberos trust with AD , enabling users from AD to log on to and to use single sign-on toaccess Linux systems and resources. This solution uses the Kerberos capability toestablish trusts between different identity sources. IdM presents itself to AD as a separateforest and takes advantage of the forest-level trusts supported by AD .In complex environments, a single IdM forest can be connected to multiple AD forests. Thissetup enables better separation of duties for different functions in the organization. ADadministrators can focus on users and policies related to users while Linux administratorshave full control over the Linux infrastructure. In such a case, the Linux realm controlled byIdM is analogous to an AD resource domain or realm but with Linux systems in it.5

Red Hat Ent erprise Linux 7 Windows Int egrat ion G uideNoteIn Windows, every domain is a Kerberos realm and a D NS domain at the same time.Every domain managed by the domain controller needs to have its own dedicatedD NS zone. The same applies when IdM is trusted by AD as a forest. AD expects IdMto have its own D NS domain. For the trust setup to work, the D NS domain needs tobe dedicated to the Linux environment.Syn ch ro n iz at io n - b ased so lu t io nAn alternative to a trust-based solution is to leverage a user synchronization capability,also available in IdM or Red Hat D irectory Server (RHD S). The synchronization allows useraccounts (and with RHD S also group accounts) to be synchronized from AD to IdM orRHD S. However, this approach has a set of limitations, including:duplication of usersthe need to synchronize passwords, which requires a special component on all domaincontrollers in an AD domain,to be able to capture passwords, all users must first manually change them,synchronization supports only a single domain,only one domain controller in AD can be used to synchronize data to one instance ofIdM or RHD S.In some integration scenarios, the user synchronization may be the only available option, but ingeneral, use of the synchronization approach is discouraged in favor of the cross-realm trust-basedintegration.6

P art I. Adding a Single Linux Syst em t o an Act ive Direct ory Domain Part I. Adding a Single Linux System to an Active DirectoryDomain7

Red Hat Ent erprise Linux 7 Windows Int egrat ion G uideChapter 2. Using Active Directory as an Identity Provider forSSSDThe System Security Services D aemon (SSSD ) provides access to different identity andauthentication providers. This service ties a local system to a larger back-end system. That can be asimple LD AP directory, domains for Active D irectory (AD ) or Identity Management (IdM) in Red HatEnterprise Linux, or Kerberos realms.SSSD configures a way to connect to an identity store to retrieve authentication information and thenuses that to create a local cache of users and credentials. SSSD can also pull in group information.Authorization information is gathered by SSSD by using HBAC (Host-Based Access Control) in IdMand GPO (Group Policy Object) in AD .2.1. About SSSDThe SSSD service is an intermediary between local applications and any configured data store. Thisrelationship brings a number of benefits for administrators:Reduced load on identification and authentication servers. Rather than having every applicationservice attempt to contact the identification server directly, each local application can contactSSSD , which in turn connects to the identification server or checks its cache.Option for offline authentication. SSSD keeps a cache of user identities (and optionally also usercredentials) that it retrieves from remote services. This allows users to authenticate even if theremote identification server or the local machine is offline.Single user account. Users can have two or more user accounts. For example, one for their localsystem and another for the organizational system. This is necessary to connect to a virtual privatenetwork (VPN). Because SSSD supports caching and offline authenticati

If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity