Red Hat Enterprise Linux 7与Windows集成指南

需积分: 9 74 浏览量更新于2024-07-20 收藏 4.68MB PDF 举报

"Red_Hat_Enterprise_Linux-7-Windows_Integration_Guide-en-US.pdf" 是一份由Red Hat公司发布的文档，专门针对Red Hat Enterprise Linux 7与Windows系统的集成提供指导。该指南主要关注如何将Linux系统（尤其是RHEL 7）与Active Directory环境进行整合，以便在跨平台的企业环境中实现统一的身份验证、授权和管理。文档的主要内容可能包括以下几个关键知识点： 1. **Active Directory集成**：详细介绍了如何配置Red Hat Enterprise Linux 7系统以加入到Windows Active Directory域。这通常涉及设置Samba服务器，配置Kerberos认证，以及安装必要的AD工具如`realmd`和`sssd`。 2. **Kerberos认证**：Kerberos是一种网络认证协议，用于在不安全的网络环境中提供安全的身份验证。在Linux与Windows集成中，Kerberos用于在Linux客户端和Active Directory之间建立信任关系，实现无密码登录。 3. **Samba服务**：Samba是Linux和Unix系统上实现SMB/CIFS网络文件共享协议的软件，使得Linux系统可以与Windows网络无缝协作。文档可能会涵盖如何配置Samba服务器以支持域用户身份验证和文件共享。 4. **Realmd工具**：Realmd是一个简化Linux系统加入Active Directory域过程的工具。它可以帮助系统自动发现和加入域，减少了手动配置的工作量。 5. **SSSD（System Security Services Daemon）**：SSSD是负责处理身份验证和信息提供服务的守护进程。在与Active Directory集成的场景中，SSSD处理用户和组信息的查询，提供单点登录功能。 6. **网络及DNS配置**：为了确保Linux系统能正确识别和连接到Windows AD环境，文档可能会包含有关配置网络设置和DNS条目的指导。 7. **安全和权限管理**：讨论如何在跨平台环境中保持一致的安全策略，包括文件权限、访问控制列表（ACLs）的配置，以及如何利用Active Directory的组策略对象（GPOs）来管理Linux系统。 8. **故障排查**：提供了解决集成过程中可能出现的问题的步骤和技巧，帮助管理员诊断和修复认证、网络或配置问题。 9. **案例研究和最佳实践**：可能包含真实世界集成案例，以及推荐的最佳实践，帮助用户避免常见陷阱并优化系统性能。 10. **更新和维护**：介绍如何在系统更新和补丁管理中保持与Active Directory的兼容性，以及如何处理版本升级。此文档对于那些需要在企业环境中整合Linux（特别是RHEL 7）和Windows系统的管理员来说，是一份宝贵的资源，能够帮助他们实现高效、安全的跨平台协作。

A GID is created for the user, which is identical to the UID.

A shell attribute is used according to SSSD settings.

If the user belongs to any groups in the Active Directory domain, SSSD uses the SID to add the

user to those groups on the Linux system.

2.3.1.2. Abo ut SSSD and POSIX At t ribut es

Active Directory can be configured to create and store POSIX attributes such as uidNumber,

gidNumber, unixHomeDirectory, and loginShell. As with all user attributes, these are

originally stored in the local domain, but they can be replicated to the global catalog. Once they are

in the global catalog, they are available to SSSD and any application which uses SSSD for its

identity information.

Replicating the attributes is beneficial for performance but is not required. SSSD tries to detect if

POSIX attributes are present and if not, SSSD connects to the individual domain controllers directly

on the LDAP port instead of requiring POSIX attributes to be replicated to the global catalog.

Note

Note that it is possible to use ID mapping even when POSIX attributes are defined on the

server. In such a case, SSSD ignores the POSIX attributes.

To use existing POSIX attributes for the best performance, ensure the following:

publish the POSIX attributes to Active Directory's global catalog,

disable ID mapping in SSSD by setting l d ap_i d _mappi ng = Fal se in the Active Directory

domain entry.

2.3.1.3. Accessing a CIFS share wit h SSSD

SSSD is able to handle ID mapping between Windows security IDs (SIDs) and POSIX IDs. An SSSD

client can therefore access and fully use a Common Internet File System (CIFS) share.

Note

In order to use a CIFS share for proper access control, it is necessary to translate the Windows

SIDs to Linux POSIX UIDs and GIDs. Previously, only Winbind provided this functionality.

Now, SSSD clients are no longer required to run Winbind alongside SSSD for this purpose.

The CIFS file-sharing protocol is widely deployed on Windows machines; SSSD enables seamless

use of CIFS in environments with a trust between Identity Management and Active Directory as if it

was a standard Linux file system. The SID-to-ID or SID-to-name algorithm that the SSSD client uses

for system identity information can now also be used for a CIFS share. For example, accessing the

Access Control Lists (ACLs) no longer requires to run Winbind in parallel to SSSD.

It is recommended to use SSSD for accessing a CIFS share instead of Winbind. IdM clients use

SSSD by default to map AD users to UNIX users; using SSSD for the CIFS mapping avoids the

possibility of inconsistent mapping, which can occur when IdM clients use Winbind. If a Linux client

uses SSSD instead of Winbind for general AD user mappings in an environment with direct AD

Windows Int egrat ion Guide

# yum install sssd-libwbclient

The package provides the l i bwbcl i ent. so . 0 .11-6 4 library, which is the SSSD

alternative to the library provided by the libwbclient package used by the Winbind service.

After installing sssd-libwbclient, you can verify that your system uses the SSSD implementation with

the alternatives tool. The tool displays the currently used alternative:

# alternatives --list | grep -E cifs\|libwbclient

cifs-idmap-plugin auto /usr/lib64/cifs-utils/cifs_idmap_sss.so

l i bwbcl ient. so . 0 .11-6 4 auto

/usr/l ib6 4 /sssd /mo d ul es/l i bwbcl ient. so . 0 .11. 0

Swit ching Bet ween SSSD and Winbind

To find out if you are currently using SSSD or Winbind for accessing a CIFS share, use the

al ternati ves tool.

# alternatives --display cifs-idmap-plugin

cifs-idmap-plugin - status is auto.

l ink currentl y po ints to /usr/l ib/ci fs-uti l s/ci fs_i d map_sss. so

/usr/lib/cifs-utils/cifs_idmap_sss.so - priority 20

/usr/lib/cifs-utils/idmapwb.so - priority 10

Current `best' version is /usr/lib/cifs-utils/cifs_idmap_sss.so.

If the SSSD plug-in (cifs_i dmap_sss.so ) is installed, it has a higher priority than the Winbind

plug-in (id mapwb. so ) by default.

To switch to a different plug-in, run the al ternatives --set ci fs-i d map-pl ug i n command

and provide the path to the plug-in. For example, to switch to Winbind:

# alternatives --set cifs-idmap-plugin /usr/lib/cifs-utils/idmapwb.so

Important

It is recommended that IdM clients always use the SSSD plug-in.

If you want to switch to the Winbind plug-in, make sure that Winbind is running on the system.

Similarly, if you want to switch to SSSD, make sure that SSSD is running.

2.3.2. Active Directory Users and Range Retrieval Searches

Microsoft Active Directory has an attribute, MaxValRange, which sets a limit on how many values for

a multi-valued attribute is returned. This is the range retrieval search extension. The extension runs

multiple partial searches, each returning a subset of the results within a given range, until all

matches are returned.

For example, when doing a search for the member attribute, each entry could have multiple values,

and there can be multiple entries with that attribute. If there are 1500 matching results or more, then

MaxValRange limits how many are displayed at once. The given attribute has an additional flag set,

showing which range in the set the result is in:

Windows Int egrat ion Guide

attribute;range=low-high:value

For example, to display results 100 to 500 in a search, use:

member;range=99-499: cn=John Smith...

SSSD supports range retrievals with Active Directory providers as part of user and group

management, without any additional configuration.

When the search base in SSSD specifies a custom filter or scope, some LDAP provider attributes

which are available to configure searches (such as ldap_user_search_base) cannot be used

with range retrievals. When configuring search bases in the Active Directory provider domain, be

aware what searches may trigger a range retrieval.

2.3.3. Linux Clients and Active Directory DNS Sites

SSSD connects a local Linux system to a larger Active Directory environment. This requires SSSD to

have an awareness of possible configurations within the Active Directory forest and work with them

so that the Linux client is cleanly integrated.

Active Directory forests can be very large, with numerous different domain controllers, domains and

subdomains, and physical sites. To increase client performance, Active Directory uses a special kind

of DNS record to identify domain controllers within the same domain but at different physical

locations. Clients connect to the closest domain controller.

Active Directory extends normal DNS SRV records to identify a specific physical location or site for its

domain controllers. Clients such as SSSD can determine which domain controllers to use based on

their own site configuration. SSSD can determine which domain controller to use by querying the

Active Directory domain first for its site configuration, and then for the domain controller DNS

records:

1. SSSD attempts to connect to the Active Directory domain and looks up any available domain

controller through normal DNS discovery.

2. SSSD sends an LDAP search to a domain controller which looks for the DNS domain,

domain SID, and version:

(& (& (DnsDomain=ad.domain)(DomainSid=S-1-5-21-1111-2222-3333))

(NtVer=0x01000016))

This is used to retrieve the information about the client's site if one is configured.

3. If a site is configured for the client, then the reply contains extended DNS SRV records for the

primary server, containing the site name (site-name._sites.):

_tcp._ldap.site-name._sites.domain.name

The backup server record is also sent, as a standard SRV record:

_tcp._ldap.domain.name

If no site is configured, then a standard SRV record is sent for all primary and backup

servers.

4. SSSD retrieves a list of primary and fallback servers.

⁠Chapt er 2 . Using Act ive Direct ory as an Ident it y Provider for SSSD

2.4. Configuring an Act ive Direct ory Domain wit h ID Mapping

When configuring an Active Directory domain, the simplest configuration is to use the ad value for all

providers (identity, access, password). Also, load the native Active Directory schema for user and

group entries, rather than using the default RFC 2307.

Other configuration is available in the general LDAP provider configuration ⁠ and Active Directory-

specific configuration ⁠ . This includes setting of LDAP filters for a specific user or group subtree,

filters for authentication, and values for some account settings. Some additional configuration is

covered in Section 2.6, “Additional Configuration Examples”.

Note

Note that the following procedure covers the manual configuration of an Active Directory

domain. By using real md , steps 3 to 7 below can be done automatically by using the realm

jo in command. See Chapter 3, Using realmd to Connect to an Active Directory Domain for

details.

1. Make sure that both the Active Directory and Linux systems have a properly configured

environment.

Name resolution must be properly configured, particularly if service discovery is used with

SSSD.

The clocks on both systems must be in sync for Kerberos to work properly.

2. On the Linux client, add the Active Directory domain to the client's DNS configuration so that

it can resolve the domain's SRV records.

search adserver.example.com

nameserver 198.68.72.1

3. Set up the Linux system as an Active Directory client and enroll it within the Active Directory

domain. This is done by configuring the Kerberos and Samba services on the Linux system.

a. Set up Kerberos to use the Active Directory Kerberos realm.

a. Open the Kerberos client configuration file.

[root@ server ~]# vim /etc/krb5.conf

b. Configure the [l o g g i ng ] and [l ibd efaul ts] sections so that they

connect to the Active Directory realm.

[logging]

default = FILE:/var/log/krb5libs.log

[libdefaults]

default_realm = EXAMPLE.COM

dns_lookup_realm = true

dns_lookup_kdc = true

[1]

[2]

Windows Int egrat ion Guide

剩余116页未读，继续阅读

爆竹

粉丝: 0
资源: 19

Red Hat Enterprise Linux 7与Windows集成指南

Red_Hat_Enterprise_Linux_4安装指南与特性解析

Red_Hat_Enterprise_Linux DNS服务器配置教程

RED_HAT_Enterprise_AS4.0与ORACLE_10G安装指南

Red_Hat_Enterprise_Linux-5-Installation_Guide-en-US.pdf

Red_Hat_Enterprise_Linux-7-Performance_Tuning_Guide-en-US.pdf

red_hat_enterprise_linux-8-customizing_anaconda-en-us.pdf

Red_Hat_Enterprise_Linux-5-Cluster_Administration-en-US.pdf

Red_Hat_Enterprise_Linux-6-Technical_Notes-en-US.pdf

Red_Hat_Enterprise_Linux-4-Reference_Guide-en-US

Red_Hat_Enterprise_Linux-7-Security_Guide.zip_guide_red hat_secu

最新资源