|
Kerberos
|
88
|
UDP 和 TCP
|
如果从 Kerberos 分发中心(KDC)
发送的数据过大，libkrb5
库将使用 UDP 并退回到 TCP 协议。Activeactive Directorynbsp;Directory 将 Privilege Attribute Certificate(PAC)附加到 Kerberos 票据中，这会增加大小，多数情况下需要使用 TCP 协议。为避免回退和重新发送请求，默认情况下，Red Hat Enterprise Linux 7.4 及之后的版本中的 SSSD 使用 TCP 进行用户身份验证。要在
libkrb5
使用 TCP 前配置大小，请在
/etc/krb.5.conf
文件中设置
udp_preference_limit
。详情请查看
krb5.conf
(5)
man page。
有关如何打开所需端口的建议，请参阅
Linux 域身份、身份验证和策略指南
中的端口
要求
。
IdM 系统必须在内核中启用 IPv6 协议。如果禁用 IPv6，IdM 服务使用的 CLDAP 插件将无法初始化。
ActiveActive Directorynbsp;Directory 服务器和 IdM 服务器都必须有其时钟同步。
5.2.1.7. 在 AD 中为 IdM 域创建条件 Forwarder
准备 AD DNS 服务器，以将 IdM 域的查询转发到 IdM DNS 服务器：
在 Windows AD 域控制器上，打开 Active Directory(AD)
DNS
控制台。
右键单击 Conditional
，再选择
New Conditional Forwarder
。
输入 IdM DNS 域名和 IdM DNS 服务器的 IP 地址
在
Active Directory 中选择 Store this conditional forwarder 并将其复制如下
，然后选择与您的环境匹配的复制设置。
点
确定
。
要验证 AD 域控制器(DC)是否可以解析 IdM 域中的 DNS 条目，请打开命令提示并输入：
C:\> nslookup server.idm.example.com
如果命令返回 IdM 服务器的 IP 地址，条件转发器可以正常工作。
5.2.1.8. 在 IdM 中为 AD 域创建转发区
准备 IdM DNS 服务器，以将 AD 域的查询转发到 AD DNS 服务器：
在 IdM 服务器上，为 AD DNS 域创建一个正向区条目。有关在 IdM 中创建 DNS 转发区的详情，
请参考
Linux 域身份、身份验证和策略指南
中的配置转发区部分。
如果 AD DNS 服务器不支持 DNSSEC，在 IdM 服务器上禁用 DNSSEC 验证：
编辑
/etc/named.conf
文件，将
dnssec-validation
参数设置为
no
：
dnssec-validation no;
重启
named-pkcs11
服务：
# systemctl restart named-pkcs11
要验证 IdM 服务器是否可以解析 AD 域中的 DNS 条目，请输入：
# host server.ad.example.com
如果命令返回 AD DC 的 IP 地址，则 forward 区域可以正常工作。
要为与 AD 的信任关系设置 IdM 服务器，请按照以下步骤执行：
安装所需的 IdM、信任和 Samba 软件包：
[root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
配置 IdM 服务器以启用信任服务。如果您使用
ipa-replica-install --setup-adtrust
命令安装服务器，您可以跳过这一步。
运行
ipa-adtrust-install
工具：
[root@ipaserver ]# ipa-adtrust-install
实用程序添加 AD 信任所需的 DNS 服务记录。如果 IdM 安装了集成的 DNS 服务器，则会自动创建这些记录。
如果 IdM 安装时没有集成 DNS
服务器，ipa-adtrust-install
会输出您必须手动添加到 DNS 的服务记录列表，然后才能继续。
红帽强烈建议在每次运行
ipa-adtrust-install 后验证 DNS 配置，如
“验证 DNS 配置”一节
所述，特别是在 IdM 或 AD 不使用集成 DNS 服务器时。
脚本会提示配置
slapi-nis
插件，这是一个兼容插件，允许较旧的 Linux 客户端与受信任的用户一起工作。
Do you want to enable support for trusted domains in Schema Compatibility plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
Enable trusted domains support in slapi-nis? [no]: y
首次安装 目录时，至少有一个用户（IdM 管理员）存在。SID 生成任务可以为任何现有用户创建一个 SID，以支持信任环境。这是一个资源密集型任务；对于大量用户而言，这可以单独运行。
Do you want to run the ipa-sidgen task? [no]: yes
[root@ipaserver ~]# systemctl start smb
另外，还可在系统引导时配置
smb
服务自动启动：
[root@ipaserver ~]# systemctl enable smb
（可选）使用
smbclient
实用程序验证 Samba 是否从 IdM 端响应 Kerberos 身份验证。
[root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k
lp_load_ex: changing to config backend registry
Sharename Type Comment
--------- ---- -------
IPC$ IPC IPC Service (Samba 4.9.1)
Reconnecting with SMB1 for workgroup listing.
Server Comment
--------- -------
Workgroup Master
--------- -------
使用
ipa trust-add
命令为 Active Directory 域和 IdM 域创建信任协议：
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
[root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --admin Administrator --password --two-way=true
Active Directory domain administrator's password:
-------------------------------------------------------
Added Active Directory trust for realm "ad.example.com"
-------------------------------------------------------
Realm-Name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19,
S-1-5-18
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19,
S-1-5-18
Trust direction: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified
5.2.2.2. 使用共享 Secret 创建信任
共享 secret 是一种密码，它为受信任的同级服务器所知，可供其他域用于加入信任。共享 secret 可以在 Active Directory(AD)中配置单向和双向信任。在 AD 中，共享 secret
作为信任配置中的可信域对象
(TDO)存储。
IdM 支持使用共享 secret 而不是 AD 管理员凭证创建单向或双向信任。设置这种信任需要管理员在 AD 中创建共享 secret，并在 AD 端手动验证信任关系。
5.2.2.2.1. 使用共享 secret 创建双向信任
使用 Microsoft Windows Server 2012 R2 或 2016 的共享 secret 创建双向信任：
为信任准备 IdM 服务器，如
第 5.2.2.1.1 节 “为信任准备 IdM 服务器”
所述。
如果 IdM 和 AD 主机使用无法解析这两个域的 DNS 服务器，请为 DNS 区域设置转发：
准备 AD DNS 服务器，以将 IdM 域的查询转发到 IdM DNS 服务器。详情请查看
第 5.2.1.7 节 “在 AD 中为 IdM 域创建条件 Forwarder”
。
准备 IdM DNS 服务器，以将 AD 域的查询转发到 AD DNS 服务器。详情请查看
第 5.2.1.8 节 “在 IdM 中为 AD 域创建转发区”
。
配置
Active Directory 域和信任控制台的信任
。特别是：
创建新信任.
为信任的 IdM 域名指定，如
idm.example.com
。
指定这是林类型的信任
。
指定这是双向信任类型
。
指定这是林范围的身份验证
。
设置信任密码
。
在配置 IdM 中的信任时，必须使用相同的密码。
当系统要求确认进入的信任时，请选择
No
。
创建信任协议，如
第 5.2.2.1.2 节 “创建信任协议”
所述。运行
ipa trust-add 命令时
，请使用
--type
、--trust-secret
和
--two-way=True
选项，并省略
--admin
选项。例如：
[root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --trust-secret --two-way=True
Shared secret for the trust:
-------------------------------------------------------
Added Active Directory trust for realm "ad.example.com"
-------------------------------------------------------
Realm-Name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6,
S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,
S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11,
S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6,
S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16,
S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11,
S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18
Trust direction: Trusting forest
Trust type: Active Directory domain
Trust status: Waiting for confirmation by remote side
检索域列表：
[root@ipaserver ~]# ipa trust-fetch-domains ad_domain
在 IdM 服务器上，使用
ipa trust-show
命令验证是否已建立信任关系。
[root@ipaserver ~]# ipa trust-show
ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
Trust direction: Trusting forest
Trust type: Active Directory domain
另外，还可搜索可信域：
[root@ipaserver ~]# ipa trustdomain-find ad.example.com
Domain name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
Domain enabled: True
5.2.2.2.2. 使用共享 secret 创建一Way Trust
使用 Microsoft Windows Server 2012 R2 或 2016 的共享 secret 创建单向信任：
为信任准备 IdM 服务器，如
第 5.2.2.1.1 节 “为信任准备 IdM 服务器”
所述。
如果 IdM 和 AD 主机使用无法解析这两个域的 DNS 服务器，请为 DNS 区域设置转发：
准备 AD DNS 服务器，以将 IdM 域的查询转发到 IdM DNS 服务器。详情请查看
第 5.2.1.7 节 “在 AD 中为 IdM 域创建条件 Forwarder”
。
准备 IdM DNS 服务器，以将 AD 域的查询转发到 AD DNS 服务器。详情请查看
第 5.2.1.8 节 “在 IdM 中为 AD 域创建转发区”
。
配置
Active Directory 域和信任控制台的信任
：
右键单击域名，然后选择
。
在
Trusts
选项卡上，单击
New Trust
。
输入 IdM 域名，点
Next
。
选择
Forest trust
，然后单击
Next
。
选择单向：传入
，然后单击"下一步"。
选择"仅此域
"，然后单击"下一步"。
输入共享 secret（信任密码），然后单击
Next
。
验证设置，再单击
Next
。
当系统询问您是否要确认传入的信任时，请选择
No，不要确认传入的信任
，然后单击
Next
。
点
Finish
。
创建信任协议：
[root@ipaserver ~]# ipa trust-add --type=ad --trust-secret ad.example.com
Shared secret for the trust: password
-------------------------------------------------------
Added Active Directory trust for realm "ad.example.com"
-------------------------------------------------------
Realm name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-1762709870-351891212-3141221786
Trust direction: Trusting forest
Trust type: Active Directory domain
Trust status: Waiting for confirmation by remote side
输入您在 AD 域和信任控制台中设置的共享机密。
验证
Active Directory 域和信任控制台的信任
：
右键单击域名，然后选择
。
在
Trusts
选项卡上，选择域中信任此域（传入信任）窗格中的域
，然后单击
Properties
。
单击
Validate
按钮。
选择
Yes，验证进入的信任
，并输入 IdM
admin
用户的凭据。
更新可信域列表：
[root@ipaserver ~]# ipa trust-fetch-domains ad.example.com
----------------------------------------------------------------------------------------
List of trust domains successfully refreshed. Use trustdomain-find command to list them.
----------------------------------------------------------------------------------------
----------------------------
Number of entries returned 0
----------------------------
列出可信域：
[root@ipaserver ~]# ipa trustdomain-find ad.example.com
Domain name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-1762709870-351891212-3141221786
Domain enabled: True
----------------------------
Number of entries returned 1
----------------------------
（可选）验证 IdM 服务器是否可以从 AD 域检索用户信息：
[root@ipaserver ~]# getent passwd administrator@ad.example.com
administrator@ad.example.com:*:610600500:610600500:Administrator:/home/ad.example.com/administrator:
验证 ID 映射：
在 Windows ActiveActive Directorynbsp;Directory 域控制器(DC)上运行以下命令，以列出最高 ID：
C:\> dcdiag /v /test:ridmanager /s:ad.example.com
Available RID Pool for the Domain is 1600 to 1073741823
列出 IdM 服务器上的 ID 范围：
[root@ipaserver ~]# ipa idrange-find
----------------
1 range matched
----------------
Range name: AD.EXAMPLE.COM_id_range
First Posix ID of the range: 610600000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-796215754-1239681026-23416912
Range type: Active Directory domain range
----------------------------
Number of entries returned 1
----------------------------
在后续步骤中，您需要第一个 POSIX ID 值。
在 ActiveActive Directorynbsp;Directory DC 上，显示安全标识符(SID)或用户。例如，显示管理员的 SID：
C:\> wmic useraccount where name="administrator" get sid
S-1-5-21-796215754-1239681026-23416912-500
SID 的最后一部分是相对标识符(RID)。在下一步中，您需要用户的 RID。
如果 RID 大于默认 ID 范围(200000)，请使用 ipa idrange-mod 命令扩展范围。例如：
# ipa idrange-mod --range-size=1000000 AD.EXAMPLE.COM_id_range
显示 IdM 服务器中同一用户的用户 ID：
[root@ipaserver ~]# id ad\\administrator
uid=610600500([email protected])...
如果您将第一个 POSIX ID 值(610600000)添加到 RID(500)，它必须与 IdM 服务器中显示的用户 ID(610600500)匹配。
当为现有 IdM 实例配置信任时，IdM 服务器及其域中条目的某些设置已被配置。但是，您必须设置 Active Directory 域的 DNS 配置，并将 Active Directory SID 分配给所有现有的 IdM 用户和组。
为信任准备 IdM 服务器，如
第 5.2.2.1.1 节 “为信任准备 IdM 服务器”
所述。
创建信任协议，如
第 5.2.2.1.2 节 “创建信任协议”
所述。
为每个 IdM 用户生成 SID。
如果使用
ipa-adtrust-install
实用程序建立信任时生成 SID，则不要执行这个步骤。
通过在后端 LDAP 目录中运行
ipa-sidgen-task
操作，为每个条目自动添加新的
ipaNTSecurityIdentifier
属性，其中包含 SID。
[root@ipaserver ]# ldapmodify -x -H ldap://ipaserver.ipa.example.com:389 -D "cn=directory manager" -w password
dn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config
changetype: add
objectClass: top
objectClass: extensibleObject
cn: sidgen
nsslapd-basedn: dc=ipadomain,dc=com
delay: 0
adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
任务成功完成后，会在 SID 生成任务
（Sidgen 任务
）结束状态为零(0)的错误日志中记录一条消息。
[root@ipaserver ]# grep "sidgen_task_thread" /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors
[20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ...
[20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
https://ipaserver.example.com
打开
IPA 服务器主选项卡
，然后选择"信任"子选项卡
。
在
Trusts
子选项卡中，单击
Add 以打开新的信任配置窗口
。
填写有关信任的所需信息：
在
Domain
字段中提供 AD 域名。
要将信任设置为双向，请选择双向信任复选框
。
要将信任设置为单向，请不要选择双向信任
。
有关单向和双向信任的更多信息，请参阅
第 5.1.4 节 “一次性和双向信任”
。
要在另一个林中建立对某个域的外部信任，请选中
External Trust 复选框
。
如需更多信息，请参阅
第 5.1.5 节 “外部 Trusts 到 ActiveActive Directorynbsp;Directory”
。
使用 的
Establish 部分定义如何建立信任：
要使用 AD
管理员的用户名和密码建立信任，请选择管理帐户并提供所需的凭证
。
或者，若要通过共享密码建立信任，请选择
Pre-shared password
并提供信任密码。
为信任定义 ID 配置：
Range 类型选项允许您选择
ID 范围类型。如果您希望 IdM 自动检测要使用的 ID 范围，请选择
Detect
。
要定义 ID 范围的起始 ID，请使用
Base ID
字段。要定义 ID 范围的大小，请使用
Range size
字段。如果您希望 IdM 在 ID 范围中使用默认值，请不要指定这些选项。
有关 ID 范围的详情请参考
“ID 范围”一节
。
5.2.3.1. Active Directory Trust 的潜在行为问题
5.2.3.1.1. Active Directory 用户和 IdM 管理
目前，Active Directory(AD)用户和管理员只能在登录 IdM Web UI 后查看其自助服务页面。AD 管理员无法访问 IdM Web UI 的管理员视图。详情请参阅
Linux 域身份、身份验证和策略指南中的
验证
IdM Web UI 作为 AD 用户
部分。
另外，AD 用户目前无法管理自己的 ID 覆盖。只有 IdM 用户才能添加和管理 ID 覆盖。
5.2.3.1.2. 验证 Deleted ActiveActive Directorynbsp;Directory 用户
默认情况下，每个 IdM 客户端使用 SSSD 服务缓存用户身份和凭证。如果 IdM 或 AD 后端供应商暂时不可用，SSSD 可让本地系统为已经成功登录一次的用户引用身份。
因为 SSSD 会在本地维护一个用户列表，所以后端上所做的更改可能不会立即对运行 SSSD 的客户端可见。在这样的客户端中，之前登录 IdM 资源且哈希密码存储在 SSSD 缓存中的用户能够再次登录，即使其用户帐户已在 AD 中删除。
如果满足上述条件，则会将用户身份缓存在 SSSD 中，即使删除了用户帐户，AD 用户也可以登录到 IdM 资源。在 SSSD 在线并能够针对 AD 域控制器验证 AD 用户登录前，此问题会一直存在。
如果客户端系统在线运行 SSSD，则用户提供的密码由 AD 域控制器验证。这样可保证不允许已删除的 AD 用户登录。
5.2.3.1.3. credential Cache Collections 和 Selecting ActiveActive Directorynbsp;Directory Principals
Kerberos 凭证缓存尝试根据以下标识符将客户端主体与服务器主体匹配：
realm name
当客户端和服务器映射基于主机名或真实名称和凭据缓存集合时，可能会作为 AD 用户绑定发生意外行为。这是因为 ActiveActive Directorynbsp 的 realm 名称与 IdM 系统的域名称不同。
如果 AD 用户使用
kinit
实用程序获取 ticket，然后使用 SSH 连接到一个 IdMnbsp;IdM 资源，则这个主体不会被选择用于资源票据。一个 IdMnbsp;IdM 主体会被使用，因为 IdM 主体与资源名称匹配。
例如，如果 AD 用户是
Administrator
，且域是
ADEXAMPLE.ADREALM
，则主体是
[email protected]
。
[root@server ~]# kinit [email protected]
Password for [email protected]:
[root@server ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected]
Valid starting Expires Service principal
27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/[email protected]
renew until 28.11.2015 11:25:16
在 ActiveActive Directorynbsp;Directory ticket 缓存中设置为默认主体。但是，如果任何 IdM 用户也具有 Kerberos ticket（如
admin
），则有一个单独的 IdM 凭证缓存，并有一个 IdMnbsp;IdM 默认主体。如果 ActiveActive Directorynbsp;Directory 用户使用 SSH 连接到资源，则 IdM 默认主体会被选择为主机 ticket。
[root@vm-197 ~]# ssh -l [email protected] ipaclient.example.com
[email protected]@ipaclient.example.com's password:
[root@vm-197 ~]# klist -A
Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected]
Valid starting Expires Service principal
27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/[email protected]
renew until 28.11.2015 11:25:16
Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected] >>>>> IdM user
Valid starting Expires Service principal
27.11.2015 11:25:18 28.11.2015 11:25:16 krbtgt/[email protected]
27.11.2015 11:25:48 28.11.2015 11:25:16 host/[email protected] >>>>> host principal
这是因为 IdM 主体的域名与 IdM 资源域匹配。
丢失 Kerberos 票据
运行 命令从 Samba 服务获取 SID（如
net getlocalsid 或
net getdomainsid
），会从 Kerberos 缓存中删除任何现有的管理票据。
您不需要为使用 Active Directory 信任而运行命令，如
net
getlocalsid
或 net getdomainsid
。
无法为用户验证组成员身份
无法验证特定可信用户是否与特定的 IdM 组（外部或 POSIX）关联。
无法为 ActiveActive Directorynbsp;Directory 组成员资格显示 Remote ActiveActive Directorynbsp;Directory User
请注意，如果 IdM 服务器和客户端在 Red Hat Enterprise Linux 7.1 或更高版本上运行，则此问题不再会发生。
id
实用程序可用于显示 Linux 系统用户的本地组关联。
但是，id
不显示 Active Directory 用户的 Active Directory 组成员资格，即使 Samba 工具确实显示了这些用户。
要临时解决这个问题，您可以使用
ssh
工具作为给定的 AD 用户登录到 anan IdMnbsp;IdM 客户端机器。在 AD
用户第一次成功登录后，id
搜索会检测并显示 AD 组成员资格：
[root@ipaserver ~]# id ADDOMAIN\user
uid=1921801107([email protected]) gid=1921801107([email protected]) groups=1921801107([email protected]),129600004(ad_users),1921800513(domain [email protected])
在信任环境中设置了新副本后，副本不会自动安装
AD 信任代理角色
。将副本配置为信任代理：
在现有的信任控制器中运行
ipa-adtrust-install --add-agents
命令：
[root@existing_trust_controller]# ipa-adtrust-install --add-agents
命令启动一个交互式配置会话，并提示您输入设置代理所需的信息。
有关
--add-agents
选项的详情请参考
ipa-adtrust-install
(1)
man page。
在新副本中：
重启 IdM 服务：
[root@new_trust_controller]# ipactl restart
从 SSSD 缓存中删除所有条目：
[root@new_trust_controller]# sssctl cache-remove
要使用
sssctl
命令，必须安装
sssd-tools
软件包。
（可选）验证副本是否安装了
AD 信任代理角色
：
[root@new_trust_controller]# ipa server-show new_replica.idm.example.com
Enabled server roles: CA server, NTP server, AD trust agent
IdM 支持使用用户主体名称(UPN)登录。UPN 是用于进行身份验证的用户名的替代选择，格式为
username@KERBEROS-REALM
。在 ActiveActive Directorynbsp;Directory 林中可以配置额外的 UPN 后缀。这些企业主体名称用于提供默认 UPN 的替代登录。
例如，如果公司使用 Kerberos 域
AD.EXAMPLE.COM
，用户的默认 UPN 为
[email protected]
。然而，公司常常希望其用户能够使用其电子邮件地址（如
[email protected]
）登录。在这种情况下，管理员将额外的 UPN 后缀
example.com
添加到 ActiveActive Directorynbsp;Directory 林，并在用户的帐户属性中设置新后缀。
只有在 AD 林根目录中定义时，UPN 后缀才对 IdM 可见。作为 AD 管理员，您可以使用
Active Directory 域和 Trust
utility 或
PowerShell
命令行工具来定义 UPN。
要为用户配置 UPN 后缀，红帽建议使用执行错误验证的工具，如
Active Directory 域和 Trust
实用程序。
红帽建议不要通过低级修改来配置 UPN，例如使用
ldapmodify
命令为用户设置
userPrincipalName
属性，因为 Active Directory 不验证这些操作。
当您在可信 AD 林中添加或删除 UPN 后缀时，您必须刷新 IdM master 上可信林的信息：
[root@ipaserver ~]# ipa trust-fetch-domains
Realm-Name: ad.example.com
-------------------------------
No new trust domains were found
-------------------------------
----------------------------
Number of entries returned 0
----------------------------
运行以下命令验证是否获取了替代 UPN：
[root@ipaserver ~]# ipa trust-show
Realm-Name: ad.example.com
Realm-Name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
Trust direction: Two-way trust
Trust type: Active Directory domain
UPN suffixes: example.com
域的 UPN 后缀存储在
cn=
trusted_domain_name
,cn=ad,cn=trusts,dc=idm,dc=example,dc=com
子树中的多值属性
ipaNTAdditionalSuffixes
中。
5.3.2. ActiveActive Directorynbsp 中的 IdM 客户端;Directory DNS 域
在 IdM 和 ActiveActive Directorynbsp;Directory 之间信任的一些环境中，您可以在属于 ActiveActive Directorynbsp 的主机上安装 IdM 客户端；Directory DNS 域。然后，主机可以从基于 Linux 的 IdM 功能中获益。
这不是推荐的配置，存在一些限制。红帽建议始终在与 ActiveActive Directorynbsp 拥有的 DNS 区域中部署 IdM 客户端；Directory 并通过 IdM 主机名访问 IdM 客户端。
5.3.2.1. 不要求使用 Kerberos 单点登录 IdM 客户端
对于在 ActiveActive Directorynbsp;Directory DNS 域中设置的 IdM 客户端，只有密码验证可用于访问这个 IdM 主机上的资源。针对这种情况配置客户端：
要确保客户端中的系统安全服务守护进程(SSSD)可以与 IdM 服务器通信，请使用
--domain=
IPA_DNS_Domain
选项安装 IdM 客户端：
[[email protected] ~]# ipa-client-install --domain=idm.example.com
这个选项禁用 ActiveActive Directorynbsp;Directory DNS 域的 SRV 记录自动探测。
在
/etc/krb5.conf
配置文件的
[domain_realm]
部分找到 ActiveActive Directorynbsp;Directory 域的现有映射：
.ad.example.com = IDM.EXAMPLE.COM
ad.example.com = IDM.EXAMPLE.COM
将这两个行替换为 ActiveActive Directorynbsp 中的 Linux 客户端完全限定域名(FQDN)的映射条目；Directory DNS 区到 IdM 域：
idm-client.ad.example.com = IDM.EXAMPLE.COM
替换默认映射可防止 Kerberos 将其对 ActiveActive Directorynbsp 的请求发送到 IdM Kerberos 发布中心(KDC)。相反，Kerberos 使用 SRV DNS 记录自动发现来查找 KDC。仅针对添加的主机
idm-client.ad.example.com
设置 IdM KDC。
只有使用用户名和密码才能对不属于 IdM 拥有 DNS 区的客户端进行身份验证。
处理 SSL 证书
基于 SSL 的服务需要一个包含所有系统主机名的 dNSName 扩展记录的证书，因为证书中必须同时存在原始(A/AAAA)和 CNAME 记录。目前，IdM 只发布证书来托管 IdM 数据库中的对象。
在没有可用单点登录的设置中，IdM 在数据库中已具有 FQDN
的主机对象，certmonger 可以为此名称请求证书
：
[[email protected] ~]# ipa-getcert request -r \
-f /etc/httpd/alias/server.crt \
-k /etc/httpd/alias/server.key \
-N CN=ipa-client.ad.example.com \
-D ipa-client.ad.example.com \
-K host/[email protected] \
-U id-kp-serverAuth
认证器服务使用
/etc/krb5.keytab
文件中存储的默认主机密钥来向 IdM 证书颁发机构(CA)进行身份验证。
5.3.2.2. 需要 Kerberos 单点登录 IdM 客户端
如果您需要 Kerberos 单点登录才能访问 IdM 客户端上的资源，客户端必须位于 IdM DNS 域中，如
idm-client.idm.example.com
。您必须在 ActiveActive Directorynbsp 中创建 CNAME 记录
idm-client.ad.example.com
；Directory DNS 域指向 IdM 客户端的 A/AAAA 记录。
对于基于 Kerberos 的应用程序服务器，MIT Kerberos 支持一种方法，允许接受应用的 key 选项卡中任何基于主机的主体。要禁用对将 Kerberos 主体作为 Kerberos 服务器的目标的严格检查，请在
/etc/krb5.conf
配置文件的
[libdefaults]
部分中设置以下选项：
ignore_acceptor_hostname = true
处理 SSL 证书
基于 SSL 的服务需要一个包含所有系统主机名的 dNSName 扩展记录的证书，因为证书中必须同时存在原始(A/AAAA)和 CNAME 记录。目前，IdM 只发布证书来托管 IdM 数据库中的对象。
在没有可用单点登录的设置中，IdM 在数据库中已具有 FQDN
的主机对象，certmonger 可以为此名称请求证书
：
创建新主机对象：
[[email protected] ~]# ipa host-add idm-client.ad.example.com --force
使用
--force
选项，因为主机名是 CNAME，而不是 A/AAAA 记录。
允许 IdM DNS 主机名管理 IdM 数据库中的 ActiveActive Directorynbsp;Directory 主机条目：
[[email protected] ~]# ipa host-add-managedby idm-client.ad.example.com \
--hosts=idm-client.idm.example.com
通过这个设置，IdM 客户端可以在 ActiveActive Directorynbsp 中为其主机名请求带有 dNSName 扩展记录的 SSL 证书；Directory DNS 域：
[[email protected] ~]# ipa-getcert request -r \
-f /etc/httpd/alias/server.crt \
-k /etc/httpd/alias/server.key \
-N CN=`hostname --fqdn` \
-D `hostname --fqdn` \
-D idm-client.ad.example.com \
-K host/[email protected] \
-U id-kp-serverAuth
5.3.3. 为 ActiveActive Directorynbsp 创建 IdM 组;Directory 用户
需要用户组来设置 IdM 用户的访问权限、基于主机的访问控制、sudo 规则和其他控制。这些组是授予 IdM 域资源访问权限并限制访问的方式。
AD 用户和 AD 组都可以直接添加到 IdM 用户组中。为此，首先将 AD 用户或组添加到非POSIX IdM 外部组中，然后添加到本地 IdM POSIX 组。然后，POSIX 组可用于 AD 用户的用户和角色管理。IdM 中处理非POSIX 组的原则请参考
第 5.1.3.2 节 “Active Directory 用户和身份管理组”
。
也可以将 AD 用户组添加为 IdM 外部组的成员。通过在单个 AD 域内保持用户和组管理，这可以更加轻松地为 Windows 用户定义策略。
可选。
在 AD 域中创建或选择要用于管理 IdM 域中的 AD 用户的组。多个组可用于 IdM 端的不同组并添加到不同的组中。
通过将
--external
选项添加到
ipa group-add
命令，在 IdM 域中为 ActiveActive Directorynbsp;Directory 用户创建一个外部组。
external 选项表示此组旨在包含
IdM 域外的成员。例如：
[root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
-------------------------------
Added group "ad_users_external"
-------------------------------
Group name: ad_users_external
Description: AD users external map
外部组必须链接到一组其他用户，而不是用户的主组。Activeactive Directorynbsp;Directory 将组成员存储在组的
member
属性中，IdM 使用此属性来解析成员。但是，ActiveActive Directorynbsp;Directory 将用户的主组群保存在用户条目的
primaryGroupID
属性中，该属性没有被解决。
创建一个新的 IdM POSIX 组，或选择一个现有组来管理 IdM 策略。例如，要创建新组：
[root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
----------------------
Added group "ad_users"
----------------------
Group name: ad_users
Description: AD users
GID: 129600004
将 AD 用户或组作为外部成员添加到 IdM 外部组中。AD
成员通过其完全限定名称标识，如DOMAIN\group_name 或
DOMAIN\username
。然后，AD 身份被映射到用户或组的 ActiveActive Directorynbsp;Directory SID。
例如，对于 AD 组：
[root@ipaserver ~]# ipa group-add-member ad_users_external --external "AD\Domain Users"
[member user]:
[member group]:
Group name: ad_users_external
Description: AD users external map
External member: S-1-5-21-3655990580-1375374850-1633065477-513 SID_DOM_GROUP (2)
-------------------------
Number of members added 1
-------------------------
将外部 IdM 组作为成员添加到 POSIX IdM 组。例如：
[root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
Group name: ad_users
Description: AD users
GID: 129600004
Member groups: ad_users_external
-------------------------
Number of members added 1
-------------------------
信任管理涉及多个领域，如全局信任配置、Kerberos 信任配置、DNS 域配置或向 Active Directory 用户分配的 ID 范围。
ipa-adtrust-install
程序自动为 IdM 域配置后台信息，这是使用 ActiveActive Directorynbsp;Directory 域创建信任所需要的信息。
全局信任配置包含五个属性：
Windows 样式的安全 ID(SID)；此属性是自动生成且无法修改
域 GUID；此属性是自动生成且无法修改
Kerberos 域名；此属性来自 IdM 配置，且无法修改
要添加 IdM 用户的默认组；可以修改此属性
NetBIOS 名称；不建议修改此属性
信任配置存储在
cn=
域
,cn=ad,cn=etc,dc=example,dc=com
子树中。
在大多数情况下，更改 NetBIOS 名称需要重新建立所有现有的信任。因此，红帽建议不要更改属性。
在运行
ipa-adtrust-install 实用程序时，为 IdM 服务器配置兼容 Active Directory 拓扑中的
NetBIOS 名称。要稍后更改，请再次运行
ipa-adtrust-install
，并使用
--netbios-name
选项指定新的 NetBIOS 名称：
[root@ipaserver ]# ipa-adtrust-install --netbios-name=NEWBIOSNAME
5.3.4.1.2. 更改 Windows 用户的默认组
当 Identity Management 配置为信任 Active Directory 林时，MS-PAC 记录会添加到 IdM 用户的 Kerberos 票据中。MS-PAC 记录包含 IdM 用户所属组的安全标识符(SID)。如果 IdM 用户的主要组没有分配
SID，则将使用为默认 SMB Group
定义的安全标识符值。当 AD 域控制器请求来自 IdM 信任控制器的用户信息时，Samba 套件也应用同样的逻辑。
默认 SMB 组是由
ipa-adtrust-install
实用程序自动创建的回退组。默认组无法被删除，但您可以使用全局信任配置指定另一个 IdM 组用作 IdM 用户主组的回退。
要从命令行设置默认组，请使用
ipa trustconfig-mod
命令：
[root@server ~]# kinit admin
[root@server ~]# ipa trustconfig-mod --fallback-primary-group="Example Windows Group"
从 IdM Web UI 设置默认组：
打开 IdM Web UI。
https://ipaserver.example.com
在
IPA 服务器主选项卡下
，选择信任子选项卡
，然后打开
Global Configuration
部分。
从
，选择一个新组。
单击
Save 以保存新配置
。
传递信任意味着信任路径可以跟随一系列域。它在
第 5.1.1 节 “信任关系的架构”
中进行了更详细的描述。
IdM 对林中的根域充满信任，并且由于传递性，它来自同一林的所有子域和来自同一林的其他域都会隐式包含在该信任中。IdM 遵循这个拓扑，因为 Windows 用户从林中的任何位置试图访问 IdM 资源。每个域和子域都是 IdM
信任配置中的信任域
。每个域存储在自己的条目
cn=
子域
,cn=
trust_name
,cn=ad,cn=trusts,dc=example,dc=com
中的 trusts 子树中。
当配置信任时，IdM 会尝试发现并映射完整的 ActiveActive Directorynbsp;Directory 拓扑，但在某些情况下需要 或 useful 来手动检索该拓扑。这可以通过
trust-fetch-domains
命令完成：
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trust-fetch-domains ad.example.com
--------------------------------------------
List of trust domains successfully refreshed
--------------------------------------------
Realm name: test.ad.example.com
Domain NetBIOS name: TEST
Domain Security Identifier: S-1-5-21-87535643-5658642561-5780864324
Realm name: users.ad.example.com
Domain NetBIOS name: USERS
Domain Security Identifier: S-1-5-21-91314187-2404433721-1858927112
Realm name: prod.ad.example.com
Domain NetBIOS name: PROD
Domain Security Identifier: S-1-5-21-46580863-3346886432-4578854233
----------------------------
Number of entries returned 3
----------------------------
当使用共享 secret 添加信任时，您需要手动检索 AD 林的拓扑。运行
ipa trust-add ad.domain --trust-secret
命令后，使用 AD 域和信任工具中的林信任属性验证在 AD 端的传入信任。然后，运行
ipa trust-fetch-domains ad.domain
命令。IdM 将接收关于信任的信息，这些信息将随后可用。
旦检索拓扑（通过自动或手动发现），就可以在 IdM 信任配置中完全启用、禁用或删除该拓扑中的个别域和子域。
例如，要禁止特定子域中用户使用 IdM 资源，请禁用该信任域：
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-disable test.ad.example.com
------------------------------------------
Disabled trust domain "test.ad.example.com"
------------------------------------------
可以使用
trustdomain-enable 命令重新启用该信任域
。
如果某个域应该从拓扑中永久删除，而不是将它从 IdM 信任配置中删除。
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-del prod.ad.example.com
-------------------------------------------------------------------
Removed information about the trusted domain " "prod.ad.example.com"
-------------------------------------------------------------------
5.3.4.3. 查看和管理与 IdM Kerberos 域关联的域
与 IdM Kerberos 域关联的域存储在 IdM 目录中的
cn=Realm Domains,cn=ipa,cn=etc,dc=example,dc=com
子树中。IdM 在与 Active Directory 建立信任时会使用域列表。知道由 IdM 管理的域的完整列表，使 AD 域控制器能够知道将哪些身份验证请求路由到 IdM KDC。使用
realmdomains-show
命令显示与 IdM 域关联的域列表：
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-show
Domain: ipa.example.org, ipa.example.com, example.com
在带有集成 DNS 的 IdM 设置中：
在使用
ipa dnszone-add
命令将新 DNS 区域添加到 IdM 后，域会自动添加到域列表中。运行
ipa realmdomains-show
在 IdM KDC 控制的域列表中显示新域：
# kinit admin
# ipa dnszone-add ipa2.example.com
# ipa realmdomains-show
Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
与 IdM Kerberos 域关联的域删除和其他类型的修改也会自动处理。
在没有集成 DNS 的 IdM 设置中：
如果添加了属于 IdM Kerberos 域一部分的 DNS 区域，则必须手动将新域添加到 IdM KDC 控制的 IdM 域列表中。使用
ipa realmdomains-mod
命令及
--add-domain
选项添加新域：
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-mod --add-domain=ipa2.example.com
Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
如果删除了 DNS 区域，您需要手动删除与 IdM Kerberos 域关联的域，同时：
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-mod --del-domain=ipa2.example.com
Domain: ipa.example.org, ipa.example.com, example.com
如果要对域列表进行多项更改，可以使用
--domain
选项修改和替换列表本身。
[root@ipaserver ~]# ipa realmdomains-mod --domain={ipa.example.org,ipa2.example.com}
5.3.4.4. 在透明信任中为 UID 和 GID 号添加范围
“ID 范围”一节
中描述了在最初配置信任时创建 ID 范围。要在以后添加 ID 范围，请使用
ipa idrange-add
命令及以下选项：
base-id
选项设置 POSIX 范围的基本 ID，即起始数
range-size
选项设置 IdM 使用的 POSIX ID 范围的大小。IdM 将可信 AD 域中的用户和组的 RID 映射到 POSIX ID。
--range-size
选项定义 IdM 创建的最大 ID 数。AD 对您创建的每个用户和组使用一个新的 RID。如果您删除了用户或组，AD 不会为将来的 AD 条目重复使用 RID。因此，范围必须足够大，以便 IdM 为每个现有的 AD 用户和组分配 ID，以及您以后创建的 ID。例如，如果管理员删除了 50000 个 AD 用户并且在此期间将创建 10000 个新帐户，则范围必须至少设置为 60000 个。但是，重要的是，范围中还包含足够的预留。在您期望默认(200000)范围大小不足的大型环境中，将
--range-size
设置为更高的值。
rid-base
选项设置 RID 的起始数，这是 SID 中最右侧的数字；该值表示要添加到基本 ID 的范围，以防止冲突
dom-sid
选项设置域 SID，因为可能会为信任配置了多个域
在以下示例中，基本 ID 是 1,200,000，RID 为 1,000。得到的 ID 号为 1,201,000。
[root@server ~]$ kinit admin
[root@server ~]$ ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=0 --dom-sid=S-1-5-21-123-456-789 trusted_dom_range
确保手动定义的 ID 范围与 IdM 使用的 ID 范围不重叠。
在某些情况下，您可能需要手动调整现有副本的分布式 Numeric Assignment（强制）ID 范围，例如恢复分配给非有效副本的 DNA ID 范围，或者扩展已耗尽 ID 的范围。
在手动调整 DNA ID 范围时，请确保新调整后的范围包含在 IdM ID 范围内。您可以使用
ipa idrange-find
命令检查它。如果 IdM ID 范围内没有包含新调整的范围，命令会失败。
要从非破坏性副本恢复 DNA ID 范围，请使用
ipa-replica-manage dnarange-show
命令来查看当前分配的 DNA 范围。要查看当前分配的 on-deck DNA 范围，请使用
ipa-replica-manage dnanextrange-show
命令。
不要创建重叠的 ID 范围。如果您分配给服务器或副本重叠的任何 ID 范围，可能会导致两个不同的服务器分配相同的 ID 值到不同的条目。
要为指定服务器定义当前的 DNA ID 范围，请使用
ipa-replica-manage dnarange-set
命令：
# ipa-replica-manage dnarange-set masterA.example.com 1250-1499
要为指定服务器定义下一个 DNA ID 范围，请使用
ipa-replica-manage dnanextrange-set
命令：
# ipa-replica-manage dnanextrange-set masterB.example.com 1500-5000
5.3.4.6. 用于服务和主机的 Kerberos 标记
访问可信域中的服务或主机可能需要 Kerberos 票据(TGT)的特殊标志。例如，如果要使用单点登录与带有 ActiveActive Directorynbsp;Directory(AD)帐户的 IdM 客户端登录，则需要 Kerberos TGT 标志
OK_AS_DELEGATE
。
如需更多信息以及如何设置 Kerberos 标记，请参阅
Linux 域身份、身份验证和策略指南
中的服务及
主机的 Kerberos 标记
。
在 IdM 资源中，如果 ActiveActive Directorynbsp;Directory 用户请求一个服务的 ticket，则 IdM 会将请求转发到 ActiveActive Directorynbsp;Directory 以检索用户信息。与 ActiveActive Directorynbsp 关联的访问数据;Directory 组分配由用户发送，由 ActiveActive Directorynbsp 发送；Directory 并嵌入到 Kerberos ticket 中。
ActiveActive Directorynbsp 中的组信息；Directory 存储在 ActiveActive Directorynbsp 的每个 Kerberos 票据列表中；Directory 用户存储在称为
特权访问证书
或 MS-PAC 的特殊数据集中。PAC 中的组信息必须映射到 ActiveActive Directorynbsp;Directory 组，然后指向对应的 IdM 组来帮助确定访问权限。
当用户第一次尝试对域服务进行身份验证时，IdM 服务可以配置为为每个身份验证请求生成 PAC。
IdM 服务器配置定义服务默认生成哪些 PAC 类型。可以通过更改特定服务的本地设置来覆盖全局设置。
打开
IPA Server
选项卡。
选择
Configuration
子选项卡。
滚动到
Service Options
区域。
要使用 PAC，请选中
MS-PAC
复选框，该复选框会添加一个可供 AD 服务使用的证书。如果没有选择复选框，则不会在 Kerberos 票据中添加任何 PAC。
如果您选中
nfs:NONE
复选框，则 MS-PAC 记录不会添加到针对 NFS 服务器发布的服务票据中。
您可以忽略PAD 复选框
。IdM 中尚不提供此功能。
单击页面顶部的更新链接
，以保存更改。
如果没有为该服务明确设置任何设置，全局策略会设置要用于服务的 PAC 类型。但是，全局设置可以在本地服务配置中覆盖。
要从命令行更改 PAC 设置，请使用
ipa service-mod
命令和
--pac-type
选项。有关如何使用该命令的详情，请在添加
--help
选项的情况下运行该命令：
$ ipa service-mod --help
Usage: ipa [global-options] service-mod PRINCIPAL [options]
Modify an existing IPA service.
Options:
-h, --help show this help message and exit
更改 Web UI 中的 PAC 设置：
打开"身份 "选项卡，然后选择"服务 "子选项卡。
单击要编辑的服务的名称。
在 Service Settings 区域，选中覆盖继承的 settings 选项，然后选择 MS-PAC 复选框来添加可供 AD 服务使用的证书。
如果没有选择复选框，则不会在 Kerberos 票据中添加任何 PAC。
您可以忽略PAD 复选框。IdM 中尚不提供此功能。
单击页面顶部的更新链接，以保存更改。
5.3.6. 使用在 Active Directory 中定义的 POSIX Attributes
5.3.6.1. 为 Active Directory 用户定义 UID 和 GID 属性
如果 Windows 管理员手动为用户定义了 POSIX UID 和 GID 属性，请在 IdM 服务器上为用户创建具有相同 GID 的匹配组。
创建组可确保该用户与主要用户组关联。如果这样的组不存在，IdM 服务器将无法查找用户所属的所有组。
5.3.6.2. 传输登录 Shell 和主目录属性
该客户端必须注册到一个基于 Red Hat Enterprise Linuxnbsp 的 IdM 服务器 ;Hat Enterprise Linuxnbsp;Linux 7.1 或更高版本才能从此功能中受益。
SSSD 可以从与 IdM 信任关系的 Active Directory 服务器读取以下属性值：
loginShell
属性，用于指定 AD 用户的 shell
unixHomeDirectory
属性，它指定 AD 用户的主目录
当使用这些属性在 AD 服务器上定义自定义 shell 或主目录值时，会将自定义值显示给 AD 用户的 IdM 客户端。因此，AD 用户和 IdM 端会显示相同的用户 shell。
请注意，要将 AD 用户主目录显示 IdM 客户端，IdM 服务器中的
/etc/sssd/sssd.conf
文件的
[domain]
部分中的
subdomain_homedir
选项必须设置为
%o
。
%o
值表示从身份提供程序检索的主目录。例如：
[domain/example.com]
subdomain_homedir = %o
如果 AD 管理员修改 AD 端的
loginShell
或
unixHomeDirectory
，则更改也会自动反映在 IdM 端。如果 AD 服务器上未定义这些属性，SSSD 会使用模板默认值。然后，这个默认值被显示到 IdM 客户端。
5.3.7. 从 ActiveActive Directorynbsp 使用 SSH;Directory Machine for IdM 资源
配置信任后，ActiveActive Directorynbsp;Directory 用户可以使用 SSH 及其 AD 凭证访问 IdM 主机上的机器、服务和文件。
IdM 客户端没有直接连接到 ActiveActive Directorynbsp;Directory 域控制器(DC)以检索用户属性。客户端会连接到缓存此信息的 IdM 服务器。因此，如果您在 ActiveActive Directorynbsp;Directory 中禁用用户，用户仍然可以使用 SSH 密钥身份验证对 IdM 客户端进行身份验证，直到用户记录在 IdM 数据库中过期。
IdM 在以下情况下更新用户记录：
该条目已自动过期。
使用
sss_cache
实用程序手动使用户条目在缓存中过期：
# sss_cache --user user_name
用户使用
kinit
实用程序或 Web UI 向 IdM 服务器进行身份验证。
用于本地授权的
localauth
Kerberos 插件确保 Kerberos 主体自动映射到本地 SSSD 用户名。通过
localauth
，在使用 Kerberos 登录时不会提示来自可信 AD 域的 Windows 用户输入密码，因此无需密码即可使用 SSH。
插件提供跨多个域和信任的可靠映射机制：当
sssd
连接到 Kerberos 库以将主体映射到本地 POSIX 身份时，SSSD 插件会根据 IdM 中定义的信任协议对其进行映射。
在某些情况下，用户可以使用 SSH 堡垒主机访问其他 Red Hat Enterprise Linuxnbsp;Hat Enterprise Red Hat Enterprise Linuxnbsp;Linux 机器。默认情况下，如果您使用 Kerberos 验证堡垒主机上的 SSH，则无法使用 Kerberos 向其他 Red Hat Enterprise Linuxnbsp 转发到其他 Red Hat Enterprise Linuxnbsp;Hat Enterprise Linuxnbsp;Linux 主机。要启用这样的转发身份验证，请在 bastions 主机主体中添加
OK_AS_DELEGATE
Kerberos 标志：
# ipa host-mod bastion_host.idm.example.com --ok-as-delegate=true
Red Hat Enterprise Linuxnbsp 上的 AD 用户 Kerberos 身份验证;Hat Enterprise Red Hat Enterprise Linuxnbsp;Linux 7.1 and newer Systems
在 Red Hat Enterprise Linuxnbsp;Hat Enterprise Linuxnbsp;Linux 7.1 和更新的系统中，SSSD 自动配置
localauth
Kerberos 插件。
SSSD 允许使用
[email protected]
、
ad.domain\user 和
AD\user
格式的用户名。
在具有
localauth
的系统中，不需要在
/etc/krb5.conf
文件中设置
auth_to_local
选项，或者在.k5login
文件中列出 Kerberos 主体。
localauth
插件使得之前用于登录的配置不会过时的密码。
为 AD 用户手动配置 Kerberos 身份验证
在没有
localauth
插件的系统中，SSH 提示输入 ActiveActive Directorynbsp 的用户密码 ;Directory 域用户即使用户获取正确的 Kerberos ticket。
要启用 Active Directory 用户在这种情况下使用 Kerberos 进行身份验证，请在
/etc/krb5.conf
文件中配置
auth_to_local
选项，或在用户主目录中的.k5login
文件中列出用户 Kerberos 主体。
-
配置
/etc/krb5.conf
-
以下流程描述了如何在 Kerberos 配置中配置域映射。
打开
/etc/krb5.conf
文件。
在
[realms]
部分中，按名称标识 IdM 域，然后添加两个
auth_to_local
行来定义 Kerberos 主体名称映射：
在一个规则中，包含用于映射不同 Active Directory 用户名格式和特定 Active Directory 域的规则。
在另一条规则中，为标准 Unix 用户名设置
DEFAULT
值。
[realms]
IDM = {
auth_to_local = RULE:[1:$1@$0](^.*@ADDOMAIN$)s/@ADDOMAIN/@addomain/
auth_to_local = DEFAULT
重新启动 KDC 服务。
[root@server ~]# systemctl restart krb5kdc.service
请注意，如果您使用 auth_to_local 选项配置 Kerberos 身份验证，用于 SSH 访问的用户名必须满足以下条件：
用户名必须具有格式 ad_user@ad_domain。
域名必须是小写。
用户名的大小写必须与 ActiveActive Directorynbsp;Directory 中的用户名匹配。例如，用户和用户 ，因为存在不同的情况。
有关设置 auth_to_local 的详情，请查看 krb5.conf(5) man page。
configure.k5login
以下步骤将系统配置为查找本地用户名的 Kerberos 主体名称。
在用户的主目录中创建.k5login
文件。
列出用户在 文件中使用的 Kerberos 主体。
如果身份验证用户与现有 Kerberos 票据中的主体匹配，则允许用户使用票据登录，而且不会提示用户输入密码。
请注意，如果您使用.k5login
配置配置 Kerberos 身份验证，用于 SSH 访问的用户名必须具有
ad_user@ad_domain
格式。
有关配置
.k5login
文件的详情请参考
.k5login
(5)
man page。
无论哪种配置过程都会导致 AD 用户能够使用 Kerberos 登录。
5.3.8. 使用启用了 Kerberos 的 Web 应用程序的信任
任何现有的 Web 应用程序都可配置为使用 Kerberos 身份验证，该身份验证引用可信 ActiveActive Directorynbsp;Directory 和 IdM Kerberos 域。有关完整的 Kerberos 配置指令，请参阅
mod_auth_kerb 模块的配置页面
。
更改 Apache 应用程序配置后，重启 Apache 服务：
[root@ipaserver ~]# systemctl restart httpd.service
例如，对于 Apache 服务器，有几个选项可定义 Apache 服务器如何连接到 IdM Kerberos 域：
-
KrbAuthRealms
-
KrbAuthRealms
选项为 IdM 域的名称提供应用程序位置。这是必需的。
-
Krb5Keytab
-
Krb5Keytab
选项提供 IdM 服务器 keytab 的位置。这是必需的。
-
KrbServiceName
-
KrbServiceName
选项设置用于 keytab(HTTP)的 Kerberos 服务名称。这是推荐的。
-
KrbMethodK5Passwd
和
KrbMethodNegotiate
-
KrbMethodK5Passwd
Kerberos 方法选项为有效用户启用基于密码的身份验证。如果有一个有效的 Kerberos ticket 可用，该
KrbMethodNegotiate
选项启用单点登录(SSO)。
建议为许多用户使用这些选项。
-
KrbLocalUserMapping
-
例 5.1. Apache Web 应用程序中的 Kerberos 配置
<Location "/mywebapp">
AuthType Kerberos
AuthName "IPA Kerberos authentication"
KrbMethodNegotiate on
KrbMethodK5Passwd on
KrbServiceName HTTP
KrbAuthRealms IDM_DOMAIN
Krb5Keytab /etc/httpd/conf/ipa.keytab
KrbLocalUserMapping on
KrbSaveCredentials off
Require valid-user
</Location>
5.3.9. 将 IdM 服务器配置为用于 Active Directory Kerberos 通讯的 Kerberos 分发中心代理
在某些情况下，网络限制或防火墙规则阻止身份管理(IdM)客户端将 Kerberos 流量发送到 Active Directory(AD)域控制器上的端口 88。解决方法是设置 Kerberos 代理，如身份管理服务器上，以将来自 IdM 客户端的流量中继到 AD。
在 IdM 客户端上，将 Active Directory 域添加到
/etc/krb5.conf
文件的 [realms] 部分。将
kdc
和
kpasswd_server
参数设置为指向 IdM 服务器的完全限定域名，后接
/KdcProxy
':
AD.EXAMPLE.COM = {
kdc = https://server.idm.example.com/KdcProxy
kpasswd_server = https://server.idm.example.com/KdcProxy
在 IdM 客户端上，禁用创建 /var/lib/ss/pubconf/kdcinfo.* 文件，这些文件可覆盖上一步中的 /etc/krb5.conf 规格。编辑 /etc/sssd/sssd.conf 文件，将 krb5_use_kdcinfo 设置为 False:
[domain/example.com]
krb5_use_kdcinfo = False
在 IdM 服务器中，将 /etc/ipa/kdcproxy/kdcproxy.conf 文件中的 use_dns 选项设置为 true，以利用 DNS 服务(SRV)记录来查找 AD 服务器以便与之通信：
use_dns = true
另外，如果您不想使用 DNS SRV 记录，在 /etc/krb5.conf 文件的 [realms] 部分添加显式 AD 服务器：
AD.EXAMPLE.COM = {
kdc = ad-server.ad.example.com
kpasswd_server = ad-server.ad.example.com
您可以通过运行脚本来执行流程的第 2 和 3 步，例如 Ansible 脚本。这在多个系统上进行更改时特别有用。
在 IdM 服务器中，重启 IPA 服务：
# ipactl restart
要验证这个过程是否成功，请在 IdM 客户端中运行以下命令：
# rm /var/lib/sss/pubconf/kdcinfo*
# kinit [email protected]
Password for [email protected]:
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected]
Valid starting Expires Service principal
[... output truncated ...]
5.4. 更改受信任的 Active Directory 域中的用户和组的 LDAP 搜索库
作为管理员，您可以在可信 Active Directory 域中为用户和组设置不同的搜索基础。例如，这可让您从不活跃的组织单元中过滤用户，以便只有活跃的 Active Directory 用户和组对 SSSD 客户端系统可见。
-
为确保 SSSD 不解析用户所属的所有组，请考虑在 Active Directory 端禁用对
tokenGroups
属性的支持。
启用
tokenGroups
时，SSSD 会解析用户所属的所有组，因为 属性包含 SID 的扁平列表。有关属性的详情，请参阅 Microsoft Developer Network 上的
Token-Groups 属性
。
这个步骤描述了通过编辑
/etc/sssd/sssd.conf
文件将 SSSD 中的搜索限制为特定的子树。
如果您的 SSSD 客户端直接加入 Active Directory 域，请对所有客户端执行此步骤。
如果您的 SSSD 客户端位于与 Active Directory 信任的身份管理域中，则仅在身份管理服务器上执行此步骤。
确保受信任的域在
sssd.conf
中有一个单独的
[domain]
部分。可信域部分的标题遵循此模板：
[domain/main_domain/trusted_domain]
[domain/idm.example.com/ad.example.com]
编辑
sssd.conf
文件，将搜索基础限制为特定的组织单元(OU)。例如：
ldap_search_base
选项会更改所有对象的搜索基础。
[domain/idm.example.com/ad.example.com]
ldap_search_base = ou=finance,dc=ad,dc=example,dc=com
您还可以使用
ldap_user_search_base
、
ldap_group_search_base
、
ldap_netgroup_search_base
和
ldap_service_search_base
选项。有关这些选项的详情请参考
sssd-ldap
(5)
man page。
重启 SSSD。
# systemctl restart sssd.service
要验证，请在 SSSD 客户端上解析几个 Active Directory 用户。例如，测试用户搜索库和组群搜索库的更改：
# getent passwd ad_user@ad.example.com
# getent group ad_group@ad.example.com
如果正确配置了 SSSD，您可以只从配置的搜索库解析对象。
如果您能够从其他搜索域解析用户，请通过检查 SSSD 日志对问题进行故障排除：
SSSD 缓存过期。
# sss_cache --everything
在
sssd.conf
的常规
[domain]
部分，将
debug_level
选项设置为
9
。
重复 命令以解析用户。
在
/var/log/sssd/ 的
SSSD
日志中，查找来自sdap_get_generic_* 功能的消息
。功能记录用户搜索中使用的过滤器和搜索基础。
有关您可以在
sssd.conf
的可信域部分使用的选项列表，请查看
sssd.conf
(5)
man page 中的 TRUSTED
SECTION
。
5.6. 将身份管理或 SSSD 限制为受信任的 Active Directory 域中的选定 Active Directory 服务器或站点
作为管理员，您可以在可信 Active Directory 域中禁用自动发现 Active Directory 服务器和站点，并手动列出服务器、站点或两者，以便您可以限制 SSSD 与之通信的 Active Directory 服务器列表。例如，这可让您避免联系无法访问的网站。
5.7. 为传统 Linux 客户端提供 Active Directory 信任
运行 Red Hat Enterprise Linuxnbsp 的 Linux 客户端;Hat Enterprise Linuxnbsp;带有 SSSD 版本 1.8 或更早版本（
传统客户端
）不会为 IdM 跨林信任提供 IdM 跨林信任。因此，要使 AD 用户能够访问 IdM 服务器提供的服务，必须正确配置旧的 Linux 客户端和 IdM 服务器。
旧客户端不需要使用 SSSD 版本 1.9 或更高版本与 IdM 服务器通信来获取 LDAP
信息，而是使用其他实用程序来实现这一目的，如nss_ldap
、nss-pam-ldapd
或 SSSD 版本 1.8 或更早版本。运行以下版本的 Red Hat Enterprise Linuxnbsp;Hat Enterprise Linuxnbsp;Linux 不使用 SSSD 1.9，因此被视为旧客户端：
RedRed Hat Enterprise Linuxnbsp;Hat EnterpriseRed Hat Enterprise Linuxnbsp;Linux 5.7 or later
RedRed Hat Enterprise Linuxnbsp;Hat EnterpriseRed Hat Enterprise Linuxnbsp;Linux 6.0 – 6.3
不要将本节中描述的配置用于非传统客户端，即运行 SSSD 版本 1.9 或更高版本的客户端。SSSD 1.9 或更高版本为 IdM 与 AD 的跨林信任提供原生支持，这意味着 AD 用户可以在无需额外配置的情况下正确访问 IdM 客户端上的服务。
当一个传统客户端在与 AD 信任关系中加入 IdM 服务器的域时，
compat LDAP 树会为
AD 用户提供所需的用户和组数据。但是，compat 树使 AD 用户只能访问有限数量的 IdM 服务。
旧客户端不提供以下服务的访问权限
：
Kerberos 身份验证
基于主机的访问控制(HBAC)
SELinux 用户映射
sudo
规则
即使在存在旧客户端的情况下
，也可以访问以下服务：
确保 IdM 服务器满足以下配置要求：
已安装 IdM 的
ipa-server
软件包以及 IdM 信任附加组件的
ipa-server-trust-ad
软件包。
ipa-server-install
工具已运行来设置 IdM 服务器。
ipa-adtrust-install --enable-compat
命令已运行，它会确保 IdM 服务器支持与 AD 域信任，以及兼容 LDAP 树可用。
如果您在过去没有
--enable-compat 选项运行 ipa-adtrust-install
，请再次运行它，这一次添加
--enable-compat
。
ipa trust-add
ad.example.org
命令已运行来建立 AD 信任。
如果禁用了基于主机的访问控制(HBAC)
allow_all
规则，请在 IdM 服务器上启用
system-auth
服务，该服务允许对 AD 用户进行身份验证。
您可以使用
ipa hbacrule-show
命令从命令行直接确定
allow_all
的当前状态。如果该规则被禁用，输出中会显示
Enabled: FALSE
：
[user@server ~]$ kinit admin
[user@server ~]$ ipa hbacrule-show allow_all
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: FALSE
5.7.2. 使用
ipa-advise
实用程序进行客户端配置
ipa-advise
程序提供配置指令，用于为 AD 信任设置旧的客户端。
要显示
ipa-advise
可以提供配置说明的完整场景列表，请在没有任何选项的情况下运行
ipa-advise
。运行
ipa-advise
会打印所有可用配置指令集的名称，以及每个集合的作用以及建议使用它的描述。
[root@server ~]# ipa-advise
config-redhat-nss-ldap : Instructions for configuring a system
with nss-ldap as a IPA client.
This set of instructions is targeted
for platforms that include the
authconfig utility, which are all
Red Hat based platforms.
config-redhat-nss-pam-ldapd : Instructions for configuring a system
(...)
要显示一组指令，运行
ipa-advise
工具，并将指令设置为参数：
[root@server ~]# ipa-advise
config-redhat-nss-ldap
#!/bin/sh
# ----------------------------------------------------------------------
# Instructions for configuring a system with nss-ldap as a IPA client.
# This set of instructions is targeted for platforms that include the
# authconfig utility, which are all Red Hat based platforms.
# ----------------------------------------------------------------------
# Schema Compatibility plugin has not been configured on this server. To
# configure it, run "ipa-adtrust-install --enable-compat"
# Install required packages via yum
yum install -y wget openssl nss_ldap authconfig
# NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was
# introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not
# be able to interoperate with IPA server 3.x.
# Please note that this script assumes /etc/openldap/cacerts as the
# default CA certificate location. If this value is different on your
# system the script needs to be modified accordingly.
# Download the CA certificate of the IPA server
mkdir -p -m 755 /etc/openldap/cacerts
wget http://idm.example.com/ipa/config/ca.crt -O /etc/openldap/cacerts/ca.crt
(...)
您可以使用
ipa-advise
实用程序配置 Linux 客户端，方法是将显示的说明作为 shell 脚本运行，或者手动执行说明。
以 shell 脚本的形式运行指令：
创建 脚本文件。
[root@server ~]# ipa-advise config-redhat-nss-ldap > setup_script.sh
使用
chmod
实用程序向 文件添加执行权限。
[root@server ~]# chmod +x setup_script.sh
使用
scp
实用程序将 脚本复制到客户端。
[root@server ~]# scp setup_script.sh root@client
在客户端上运行 脚本。
[root@client ~]# ./setup_script.sh
在客户端上运行脚本文件之前，请务必仔细阅读和查看脚本文件。
要手动配置客户端，请从命令行执行
ipa-advise
显示的说明。
本节介绍跨林信任环境中可能的问题以及解决问题的方法。
5.8.1. 对 ipa-extdom 插件进行故障排除
IdM 域中的 IdM 客户端，它信任的 ActiveActive Directorynbsp;Directory(AD)无法直接从 AD 接收用户和组的信息。另外，IdM 不会将 AD 用户的信息存储在 IdM master 上运行的目录服务器中。相反，IdM 服务器使用
ipa-extdom
接收 AD 用户和组的信息，并将它们转发到请求客户端。
设置 ipa-extdom 插件的 Config Timeout
ipa-extdom
插件针对 AD 用户的数据向 SSSD 发送请求。但是，并非所有请求的数据都可能已在 SSSD 缓存中。在本例中，SSSD 从 AD 域控制器(DC)请求数据。这对于某些操作可能非常耗时。配置超时值定义
ipa-extdom
插件在插件取消连接前等待 SSSD 回复的时间（以毫秒为单位），并为调用者返回超时错误。
默认情况下，配置超时为
10000
毫秒（10 秒）。
如果您设置了一个太小的值，如
500
毫秒，SSSD 可能没有足够的时间来响应，请求将始终返回超时。
如果该值太大，如30000
毫秒（30 秒），则单个请求可能会在这段时间内阻止与 SSSD 的连接。由于一次只能有一个线程连接到 SSSD，来自插件的所有其他请求都必须等待。
如果 IdM 客户端发送了大量请求，它们可能会阻止为目录服务器配置的所有可用工作程序，因此服务器可能在某些情况下无法响应任何类型的请求。
在以下情况下更改配置超时：
如果在请求 AD 用户和组信息时达到自己的搜索超时前，IdM 客户端经常收到超时错误，配置超时值太小。
如果 IdM 服务器上的 Directory 服务器经常被锁定，并且
pstack
实用程序报告很多或所有 worker 线程目前正在处理
ipa-extdom
请求，则该值太大。
例如，要将配置值设置为20000
毫秒（20 秒），请输入：
# ldapmodify -D "cn=directory manager" -W
dn: cn=ipa_extdom_extop,cn=plugins,cn=config
changetype: modify
replace: ipaExtdomMaxNssTimeout
ipaExtdomMaxNssTimeout: 20000
为 NSS 调用设置 ipa-extdom 插件使用的 maximum Size
ipa-extdom
插件使用调用，这些调用使用与典型名称服务交换机(NSS)调用相同的 API 来请求 SSSD 中的数据。这些调用使用 SSSD 可以存储请求数据的缓冲。如果缓冲区太小，SSSD 会返回一个
ERANGE
错误，插件会使用更大的缓冲区重试请求。
cn=ipa_extdom_extop,cn=plugins,cn=config
条目的 IdM master 中的
ipaExtdomMaxNssBufSize
属性定义缓冲区的最大大小，以字节为单位。
默认情况下，缓冲区为
134217728
字节(128 MB)。例如，如果组中包含如此多的成员，所有名称都不适合到缓冲区中，并且 IPA 客户端无法解析组，则仅增加该值。
例如，要将缓冲区设置为
268435456
字节(256 MB)，请输入：
# ldapmodify -D "cn=directory manager" -W
dn: cn=ipa_extdom_extop,cn=plugins,cn=config
changetype: modify
replace: ipaExtdomMaxNssBufSize
ipaExtdomMaxNssBufSize: 268435456
部分 III. 将 Linux 域与 Active Directory 域集成：同步
这部分提供了有关如何同步
Active Directory
和
Identity Management
用户的说明，如何将现有环境从同步迁移到信任，以及如何在
Active Directory
环境中使用
ID Views
。
第 6 章 同步 ActiveActive Directorynbsp;Directory 和 IdentityIdentity Managementnbsp;Management Users
6.2. 关于 Active Directory 和 IdentityIdentity Managementnbsp;Management
在 IdM 域中，通过在数据 master（服务器和副本）之间可靠地复制该信息，在服务器和副本之间共享信息。
此过程是复制
。
相似的过程可用于在 IdM 域和 Microsoft Active Directory 域之间共享数据。
这是同步
。
同步是指在 Active Directory 和 IdentityIdentity Managementnbsp 之间复制用户数据；Management。当用户在 ActiveActive Directorynbsp;Directory 和 IdentityIdentity Managementnbsp 之间同步时，会使用目录同步(DirSync)LDAP 服务器扩展控制来搜索已更改对象的目录。
同步在 aan IdMnbsp;IdM 服务器和 ActiveActive Directorynbsp;Directory 域控制器之间定义。
协议定义识别可以同步的用户条目所需的所有信息，如要同步的子树，以及定义帐户属性的处理方式。使用默认值创建同步协议，这些默认值可以调整以满足特定域的需求。
当两台服务器参与同步时，它们就称为同级服务器
。
表 6.1. 同步协议中的信息
|
Windows 信息
|
IdM 信息
|
-
用户子树
(cn=Users,$SUFFIX
)
Activeactive Directorynbsp;Directory 管理员用户名和密码
密码同步服务密码
CA 证书
用户子树（ou=People、$SUFFIX
）
同步通常是双向的
。在一个与 IdM 服务器和副本共享信息非常相似的进程中，在 IdM 和 Windows 域之间来回发送信息。新用户条目除外，它们仅从 Windows 域添加到 IdM 域。可以将同步配置为仅同步一种方式。
这是单向同步
。
为防止数据冲突的风险，只有一个目录应源自或移除用户条目。这通常是 Windows 目录，它是 IT 环境中的主要身份存储，然后新帐户或帐户删除会同步到 IdentityIdentity Managementnbsp;Management peer。两个目录都可以修改条目。
然后，同步配置了一个 IdentityIdentity Managementnbsp;Management server 和一个 ActiveActive Directorynbsp;Directory 域控制器。IdentityIdentity Managementnbsp;Management 服务器在整个 Windows 域中传播至 IdM 域，而域控制器则在整个 Windows 域中传播更改。
IdM 同步有几个关键功能：
同步操作每五分钟运行一次。要修改频率，请在 Active Directory 对等 DN 中设置
winSyncInterval
属性：
cn=meTowinserver.ad.example.com,cn=replica,cn=dc\3Didm\,dc\3Dexample\,dc\3Dcom,cn=mapping tree,cn=config
-
同步只能配置一个 ActiveActive Directorynbsp;Directory 域。
同步只能
配置一个
ActiveActive Directorynbsp;Directory 域控制器。
仅同步用户信息；组信息不.
用户属性和密码都可以同步。
虽然修改是双向的（从 ActiveActive Directorynbsp;Directory 到 IdM，从 IdM 到 ActiveActive Directorynbsp;Directory）时，创建帐户只能从 ActiveActive Directorynbsp;Directory 到 IdentityIdentity Managementnbsp;Management.在 ActiveActive Directorynbsp 中创建的新帐户；Directory 会自动同步到 IdM。但是，在 IdM 中创建的用户帐户还必须在 ActiveActive Directorynbsp;Directory 中创建，然后才能同步。在这种情况下，同步进程会尝试找到与 IdM 中
uid
属性相同的匹配帐户，而不是在 ActiveActive Directorynbsp;Directory 中找到
sAMAccountName
属性。如果找到匹配项，IdM
ntUserDomainId
属性被设置为 ActiveActive Directorynbsp;Directory
objectGUID
值。这些属性全局唯一且不可变，并且条目保持同步，即使它们被移动或重命名。
默认情况下，帐户锁定信息同步，因此一个域中禁用的用户帐户在另一个域中被禁用。
密码同步更改将立即生效。如果在一个对等上添加或更改了用户密码，该更改将立即传播到其他同级服务器。
Password Synchronization 客户端会同步新密码或密码更新。
现有密码以 IdM 和 ActiveActive Directorynbsp 的散列形式存储；Directory，当安装 Password Synchronization 客户端时，无法解密或同步现有密码。必须更改用户密码，以启动对等服务器之间的同步。
虽然只能有一个协议，但 PassSync 服务必须安装在每个 ActiveActive Directorynbsp;Directory 服务器上。
当 ActiveActive Directorynbsp;Directory 用户与 IdM 同步时，某些属性（包括 Kerberos 和 POSIX 属性）将自动添加到用户条目中。这些属性供 IdM 在其域中使用。它们不会在对应的 ActiveActive Directorynbsp;Directory 用户条目中同步。
同步中的一些数据可以在同步过程中修改。例如，某些属性可以自动添加到 ActiveActive Directorynbsp;Directory 用户帐户与 IdM 域同步时。这些属性更改定义为同步协议的一部分，如
第 6.5.2 节 “更改同步用户帐户属性的行为”
中所述。
IdentityIdentity Managementnbsp;Management 同步 IdM 和 ActiveActive Directorynbsp;Directory 用户条目之间的用户属性子集。条目中存在的任何其他属性（在 IdentityIdentity Managementnbsp;Management 或 ActiveActive Directorynbsp 中）都会被同步忽略。
大多数 POSIX 属性都不会同步。
虽然 ActiveActive Directorynbsp;Directory LDAP 模式和 389389 Directory Servernbsp;Directory389 Directory Servernbsp;Directory389 Directory Servernbsp;Server LDAP schema used by IdentityIdentity Managementnbsp;Management 有很多属性。这些属性只需在 ActiveActive Directorynbsp;Directory 和 IdM 用户条目之间同步，且不会影响属性名称或值格式。
用户架构，在 IdentityIdentity Managementnbsp 中是一样的 Same；管理和 Windows 服务器
对于
initials
属性，Active Directory 会对六个字符的最大长度限制，但 389389 Directory Servernbsp;Directory389 Directory Servernbsp;Server 没有长度限制。如果在 IdentityIdentity Managementnbsp;Management 中添加大于 6 个字符的
initials
属性，则该值会在与 Active Directory 条目同步时进行修剪。
Activeactive Directorynbsp;Directory 允许在没有 surname 属性的情况下创建
人员
条目。但是，RFC 4519 将
人员
对象类定义为需要 surname 属性，这是 DirectoryDirectory Servernbsp;Server 中使用的定义。
如果在没有 surname 属性的情况下创建了 ActiveActive Directorynbsp;Directory
人员
条目，则该条目不会与 IdM 同步，因为它会失败并显示对象类违反情况。
6.3.2. Activeactive Directorynbsp;Directory Entries 和 POSIX Attributes
当 Windows 用户帐户包含
uidNumber
和
gidNumber
属性的值时，WinSync 不会将这些值同步到 Identity Management。相反，它会在 Identity Management 中创建新的 UID 和 GID 值。
因此，
uidNumber
和
gidNumber
的值在 Active Directory 和 Identity Management 中有所不同。
cn
的处理方式与其他同步属性不同。当从 IdentityIdentity Managementnbsp 同步;Management 到 ActiveActive Directorynbsp;Directory 时，它会被直接映射到
cn
。
cn
从 ActiveActive Directorynbsp 同步;Directory 到 IdentityIdentity Managementnbsp;Management 时，
cn
从 Windows 上的
name
属性映射到 IdentityIdentity Managementnbsp;Management 中的
cn
属性。
6.4. 设置 ActiveActive Directorynbsp;Directory 用于同步
在 IdM 中启用了同步用户帐户。只需要设置同步协议(
第 6.5.1 节 “创建同步协议”
)。但是，ActiveActive Directorynbsp;Directory 确实需要配置为允许 IdentityIdentity Managementnbsp;Management server 连接到它。
6.4.1. 创建 ActiveActive Directorynbsp;Directory 用户进行同步
在 Windows 服务器上，需要创建 IdM 服务器将用于连接 Active Directory 域的用户。
在 Active Directory 中创建用户的流程涵盖在 Windows
服务器文档中，该文档位于：
新用户帐户必须具有正确的权限：
为同步用户帐户复制目录更改授予同步
Active Directory 子树的权限。同步用户需要副本权限才能执行同步操作。
副本权利如下所述：
添加同步用户，作为帐户操作员
和企业只读域控制器组的成员
。用户不需要从属于
Domain Admins
组。
6.4.2. 设置 ActiveActive Directorynbsp;Directory 证书颁发机构
IdentityIdentity Managementnbsp;Management server 使用安全连接连接到 ActiveActive Directorynbsp;Directory 服务器。这要求 ActiveActive Directorynbsp;Directory 服务器具有可用的 CA 证书或 CA 证书链，可导入到 IdentityIdentity Managementnbsp;Management 安全数据库，以便 Windows 服务器是一个信任的对等点。
虽然从技术上来说，这可以通过外部（到 ActiveActive Directorynbsp;Directory）CA 来完成，但大多数部署都应该使用 ActiveActive Directorynbsp;Directory 提供的证书服务。
在 ActiveActive Directorynbsp 中设置和配置证书服务的步骤包括在 Microsoft 文档中
http://technet.microsoft.com/en-us/library/cc772393(v=WS.10).aspx
。
同步协议是使用
ipa-replica-manage connect
命令在 IdM 服务器上创建，因为它与 ActiveActive Directorynbsp;Directory 域创建连接。
要建立到 ActiveActive Directorynbsp 的加密连接，IdM 必须信任 Windows CA 证书。
将根证书颁发机构(CA)证书复制到 IdM 服务器中：
如果您的 ActiveActive Directorynbsp;Directory CA 证书是自签名的：
在 Windows 服务器上导出 ActiveActive Directorynbsp;Directory CA 证书。
Super 键
+
R
组合键打开运行对话框
。
输入
certsrv.msc
并单击"确定"。
右键单击本地证书颁发机构的名称，然后选择属性
。
在
General
选项卡上，选择要在
CA 证书字段中导出的证书
，然后单击查看证书
。
在
Details
选项卡中，单击
Copy to File 以启动
证书导出向导
。
单击
Next
，然后选择
Base-64 编码 X.509(.CER)。
为导出的文件指定合适的目录和文件名。单击
Next
以导出证书，然后单击
Finish
。
将导出的证书复制到 IdM 服务器机器。
如果您的 ActiveActive Directorynbsp;Directory CA 证书由外部 CA 签名：
要找出 CA root 证书是什么证书，显示证书链：
# openssl s_client -connect adserver.example.com:636
CONNECTED(00000003)
depth=1 C = US, O = Demo Company, OU = IT, CN = Demo CA-28
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate chain
0 s:/C=US/O=Demo Company/OU=IT/CN=adserver.example.com
i:/C=US/O=Demo Company/OU=IT/CN=Demo CA-1
1 s:/C=US/O=Demo Company/OU=IT/CN=Demo CA-1
i:/C=US/O=Demo Company/OU=IT/CN=Demo Root CA 2
上例显示 ActiveActive Directorynbsp;Directory 服务器的 CA 证书由
CN=Demo CA-1
签名，它由
CN=Demo Root CA 2
签名。这意味着
CN=Demo Root CA 2
是根 CA。
将 CA 证书复制到 IdM 服务器。
删除 IdM 服务器中的任何现有 Kerberos 凭据。
$ kdestroy
使用
ipa-replica-manage
命令创建 Windows 同步协议。这需要
--winsync
选项。如果密码与用户帐户同步，则也使用
--passsync
选项，并设置用于密码同步的密码。
--binddn
和
--bindpw
选项在 ActiveActive Directorynbsp 上为系统帐户提供用户名和密码；Directory 服务器将用于连接到 ActiveActive Directorynbsp;Directory 服务器。
$ ipa-replica-manage connect --winsync \
--binddn cn=administrator,cn=users,dc=example,dc=com \
--bindpw Windows-secret \
--passsync secretpwd \
--cacert /etc/openldap/cacerts/windows.cer \
adserver.example.com -v
-
--WinSync
：将此识别为 Windows 同步协议。
--bind
DN : IdM 使用此 ActiveActive Directorynbsp 的 DN；Directory 帐户绑定到远程目录和同步属性。
--bindpw
：同步帐户的密码。
--cacert
：完整路径和文件名：
Activeactive Directorynbsp;Directory CA 证书（如果 CA 已被自签名）。
外部 CA 证书，如果 ActiveActive Directorynbsp;Directory CA 由一个外部 CA 签名。
--win-subtree
：包含要同步用户的 Windows 目录子树的 DN。默认值为
cn=Users,$SUFFIX
。
AD_server_name
： ActiveActive Directorynbsp 的全限定域名(FQDN)；Directory 域控制器。
出现提示时，输入 Directory Manager 密码。
可选。
配置密码同步，如
第 6.6.2 节 “设置密码同步”
中所示。如果没有 Password Synchronization 客户端，用户属性会在对等服务器之间同步，但密码则不会。
密码同步客户端捕获密码更改，然后在 ActiveActive Directorynbsp;Directory 和 IdM 之间同步它们。这意味着它将同步新密码或密码更新。
现有密码以 IdM 和 ActiveActive Directorynbsp 的散列形式存储；Directory，当安装 Password Synchronization 客户端时，无法解密或同步现有密码。必须更改用户密码，以启动对等服务器之间的同步。
创建同步协议时，它定义了同步进程在同步期间如何处理用户帐户属性的某些默认行为。这些类型的行为如如何处理锁定属性或如何处理不同的 DN 格式。可以通过编辑同步协议来更改此行为。
同步协议作为特殊的插件条目存在于 LDAP 服务器中，每一属性行为通过 LDAP 属性来设置。要更改同步行为，请使用
ldapmodify
命令直接修改 LDAP 服务器条目。
例如，帐户锁定属性在 IdM 和 ActiveActive Directorynbsp 之间同步。默认情况下，可以使用
ipaWinSyncAcctDisable
属性来禁用它。（更改意味着，如果在 ActiveActive Directorynbsp 中禁用了帐户，它仍然在 IdM 中活跃，反之亦然。）
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password
dn: cn=ipa-winsync,cn=plugins,cn=config
changetype: modify
replace: ipaWinSyncAcctDisable
ipaWinSyncAcctDisable: none
modifying entry "cn=ipa-winsync,cn=plugins,cn=config"
以下是同步设置属性的概述：
常规用户帐户参数 用户帐户锁定参数
6.5.3. 更改 Synchronized Windows Subtree
创建同步协议会自动设置两个子树，以用作同步的用户数据库。在 IdM 中，默认值为
cn=users,cn=accounts,$SUFFIX
, and for ActiveActive Directorynbsp;Directory，默认值为
CN=Users，$SUFFIX
.
当使用
--win-subtree
选项创建同步协议时，ActiveActive Directorynbsp;Directory 子树的值可设为非默认值。在协议被创建后，可以使用
ldapmodify
命令编辑同步协议条目中的
nsds7WindowsReplicaSubtree
值来更改 ActiveActive Directorynbsp;Directory 子树。
使用
ldapsearch
获取同步协议的名称。此搜索只会返回
dn
和
nsds7WindowsReplicaSubtree
属性的值，而不是整个条目。
[jsmith@ipaserver ~]$ ldapsearch -xLLL -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com -b cn=config objectclass=nsdswindowsreplicationagreement dn nsds7WindowsReplicaSubtree
dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: cn=users,dc=example,dc=com
... 8< ...
修改同步协议
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -W -p 389 -h ipaserver.example.com <<EOF
dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsds7WindowsReplicaSubtree
nsds7WindowsReplicaSubtree: cn=alternateusers,dc=example,dc=com
modifying entry "cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
新子树设置会立即生效。如果同步操作当前正在运行，则它将在当前操作完成后立即生效。
6.5.4. 配置 Uni-ward Synchronization
默认情况下，所有修改和删除都是双向的。ActiveActive Directorynbsp 的改变;Directory 被同步到 IdentityIdentity Managementnbsp;Management，以及对 IdentityIdentity Managementnbsp 中的条目更改;Management 同步到 ActiveActive Directorynbsp;Directory。这基本上是一个明显的、多主关系，其中 ActiveActive Directorynbsp;Directory 和 IdentityIdentity Managementnbsp;Management 都是同步的对等点，且同时是数据 master。
但是，在某些数据结构或 IT 设计中，可能只有一个域应当是一个数据主域，另一个域应接受更新。这会将同步关系从多主关系（对等服务器等效）转变为主消费者关系。
这可以通过在同步协议中设置
oneWaySync
参数来完成。可能的值有
fromWindows
（用于 ActiveActive Directorynbsp;Directory 到 IdentityIdentity Managementnbsp;Management 同步）和
toWindows
（用于 IdentityIdentity Managementnbsp;Management to ActiveActive Directorynbsp;Directory 同步）。
例如，将 ActiveActive Directorynbsp 的更改同步;Directory 到 IdentityIdentity Managementnbsp;Management:
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com
dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
add: oneWaySync
oneWaySync: fromWindows
启用单向同步不会自动阻止对未同步服务器上的更改
，这可能会导致同步更新之间的同步对等点不一致。例如，单向同步配置为来自 ActiveActive Directorynbsp;Directory 到 IdentityIdentity Managementnbsp;Management, so ActiveActive Directorynbsp;Directory is(essence)data master.如果在 IdentityIdentity Managementnbsp;Management 上修改甚至删除了条目，则 IdentityIdentity Managementnbsp;Management 信息不同，这些更改永远不会被传递给 ActiveActive Directorynbsp;Directory。在下一次同步更新过程中，DirectoryDirectory 服务器nbsp 上将覆盖编辑；Server 和已删除的条目将被重新添加。
可以通过删除
断开
IdM 和 ActiveActive Directorynbsp;Directory 服务器的同步协议来停止同步。在创建同步协议中，删除同步协议使用
ipa-replica-manage disconnect
命令，然后是 ActiveActive Directorynbsp;Directory 服务器的主机名。
删除同步协议。
# ipa-replica-manage disconnect adserver.ad.example.com
列出 IdM 目录证书数据库中的证书：
# certutil -L -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
IDM.EXAMPLE.COM IPA CA CT,C,C
CN=adserver,DC=ad,DC=example,DC=com C,,
Server-Cert u,u,u
从 IdM 服务器数据库中删除 ActiveActive Directorynbsp;Directory CA 证书：
# certutil -D -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -n "CN=adserver,DC=ad,DC=example,DC=com"
6.5.6. WinSync Agreement 失败
"Windows PassSync entry exists, not resetting password"
这不是错误。当没有更改 Password Synchronization 用户（Password Synchronization 用户）时，会发生此消息。Password Synchronization 用户是服务用来更改 IdM 中的密码的操作用户。
通过同步协议配置用户条目同步。但是，ActiveActive Directorynbsp 中的密码：Directory 和 IdentityIdentity Managementnbsp;Management 不是普通用户同步过程的一部分。必须在 ActiveActive Directorynbsp 上安装单独的客户端；Directory 服务器若要以用户帐户创建或密码捕获密码，然后使用同步更新转发该密码信息。
密码同步客户端捕获密码更改，然后在 ActiveActive Directorynbsp;Directory 和 IdM 之间同步它们。这意味着它将同步新密码或密码更新。
现有密码以 IdM 和 ActiveActive Directorynbsp 的散列形式存储；Directory，当安装 Password Synchronization 客户端时，无法解密或同步现有密码。必须更改用户密码，以启动对等服务器之间的同步。
6.6.1. 设置 Windows Server for Password Synchronization
同步密码需要以下条件：
Activeactive Directorynbsp;Directory 必须在 SSL 中运行。
在企业根模式中安装 Microsoft 证书系统.Activeactive Directorynbsp;Directory 将自动注册来检索其 SSL 服务器证书。
密码同步服务必须安装到
每个
ActiveActive Directorynbsp;Directory 域控制器。要从 Windows 同步密码，PassSync 服务需要访问未加密的密码才能通过安全连接与 IdM 同步。由于用户可以在每个域控制器上更改密码，因此需要在每个域控制器上安装 PassSync 服务。
密码策略必须在 IdM 和 ActiveActive Directorynbsp;Directory 端设置相似。当同步目的地收到更新的密码时，它仅被验证为与源上的策略匹配。同步目的地上未重新验证它。
要验证 ActiveActive Directorynbsp;Directory 密码复杂性策略是否已启用，请在 ActiveActive Directorynbsp;Directory 域控制器上运行：
> dsquery * -scope base -attr pwdProperties
pwdProperties
如果将 attribute pwdProperties 的值设为 1，则会为该域启用密码复杂性策略。
如果您不确定组策略是否为组织单元定义了开发密码设置（注意），请询问您的组策略管理员。
启用 ActiveActive Directorynbsp;Directory 密码复杂性设置：
从命令行运行 gpmc.msc。
选择 。
→
右键单击 条目，再选择 。
Group Policy Management Editor 会自动打开。
→
启用密码必须满足复杂性要求选项并保存。
在 ActiveActive Directorynbsp;Directory 域中的每个域控制器上安装密码同步服务，以同步 Windows 密码。
将
RedHat-PassSync-*.msi
文件下载到 Active Directory 域控制器：
登录客户门户网站。
单击页面顶部的
Downloads。
选择
Red Hat Enterprise Linuxnbsp;Hat Enterprise Red Hat Enterprise Linuxnbsp;Linux
from the product list.
选择 Red Hat Enterprise Linuxnbsp 的最新版本;Hat Enterprise Linuxnbsp;Linux 6 或 Red Hat Enterprise Linuxnbsp;Hat Enterprise Linuxnbsp;Hat Enterprise Linuxnbsp;Linux 7 and architecture.
在 ActiveActive Directorynbsp;Directory 域控制器架构中下载
WinSync Installer
，方法是点
Download Now
按钮。
双击MSI
文件进行安装。
此时将显示 Password Synchronrization Setup
窗口。
按下一步开始安装
。
填写信息以建立与 IdM 服务器的连接。
IdM 服务器连接信息，包括主机名和安全端口号。
ActiveActive Directorynbsp;Directory 用来连接到 IdM 机器的系统用户的用户名。当 IdM 服务器上配置同步时，此帐户会自动配置。
默认帐户为uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com.
同步协议创建时在
--passsync
选项中设置的密码。
IdM 服务器上的 People 子树的搜索基础。ActiveActive Directorynbsp;Directory 服务器连接到与
ldapsearch
或 replication 操作类似的 IdM 服务器，因此它必须知道在 IdM 子树中查找用户帐户的位置。用户子树为
cn=users,cn=accounts,dc=example,dc=com
。
此时不使用证书令牌，因此该字段应当留空。
按下一步
，然后完成以安装密码同步
。
将 IdM 服务器的 CA 证书导入到 PassSync 证书存储中。
从
http://ipa.example.com/ipa/config/ca.crt
下载 IdM 服务器的 CA 证书。
将 IdM CA 证书复制到 ActiveActive Directorynbsp;Directory 服务器。
在 Password Synchronization 数据库中安装 IdM CA 证书。例如：
cd "C:\Program Files\Red Hat Directory Password Synchronization"
certutil.exe -d . -A -n "IPASERVER.EXAMPLE.COM IPA CA" -t CT,, -a -i ipaca.crt
重新启动 Windows 计算机以启动密码同步。
必须重新引导 Windows 机器。
如果不重新启动，PasswordHook.dll
则未启用，密码同步将无法正常工作。
如果应当同步现有帐户的密码，请重置用户密码。
密码同步客户端捕获密码更改，然后在 ActiveActive Directorynbsp;Directory 和 IdM 之间同步它们。这意味着它将同步新密码或密码更新。
现有密码以 IdM 和 ActiveActive Directorynbsp 的散列形式存储；Directory，当安装 Password Synchronization 客户端时，无法解密或同步现有密码。必须更改用户密码，以启动对等服务器之间的同步。
安装 Password Synchronization 应用时第一次尝试同步密码始终会失败，因为 DirectoryDirectory 服务器nbsp;Server 和 Active Directory 同步实体之间的 SSL 连接将始终失败。
创建证书和密钥数据库的工具与.msi
一起安装。
密码同步客户端无法同步 IdM
admin
组的成员的密码。这种行为旨在防止密码同步代理或低级用户管理员更改顶级管理员的密码。
仅在同步源上验证密码，以匹配密码策略。要验证并启用 ActiveActive Directorynbsp;Directory 密码复杂性策略，请参阅
第 6.6.1 节 “设置 Windows Server for Password Synchronization”
。
7.1. 使用
ipa-winsync-migrate
自动从 Synchronization 迁移到 Trust
ipa-winsync-migrate
实用程序仅在运行 Red Hat Enterprise Linux 7.2 或更高版本的系统上可用。
7.1.1. 如何使用
ipa-winsync-migrate Works 进行迁移
ipa-winsync-migrate
实用程序将所有同步的用户从 AD 林迁移，同时保留 Winsync 环境中的现有配置，并将其传送到 AD 信任中。对于 Winsync 协议创建的每个 AD
用户，ipa-winsync-migrate
在 Default Trust View 中创建了一个 ID 覆盖（请参阅
第 8.1 节 “Active Directory 默认信任视图”
）。
迁移完成后：
AD 用户的 ID 覆盖具有以下从 Winsync 中的原始条目复制的属性：
登录名
(uid
)
UID
号（uid 号
）
GID
号(gid number
)
主目录（主目录
）
GECOS
条目(gecos
)
AD 信任中的用户帐户将其原始配置保留在 IdM 中，其中包括：
POSIX 属性
基于角色的访问控制规则
基于主机的访问控制规则
SELinux 成员资格
sudo
规则
新 AD 用户添加为外部 IdM 组的成员。
删除原始 Winsync 复制协议、原始同步用户帐户和用户帐户的所有本地副本。
7.1.2. 如何使用
ipa-winsync-migrate 进行迁移
# ipa-winsync-migrate --realm example.com --server ad.example.com
如果在
ipa-winsync-migrate
创建的覆盖中发生冲突，则会显示有关冲突的信息，但迁移继续进行。
从 AD 服务器卸载 Password Sync 服务。这会从 AD 域控制器移除同步协议。
有关该实用程序的详情，请查看
ipa-winsync-migrate
(1)
man page。
7.2. 使用 ID 视图手动从同步迁移到 Trust
第 8 章 在 Active Directory 环境中使用 ID 视图
通过 ID 视图，您可以为 POSIX 用户或组属性指定新值，并定义要在其上应用新值的客户端或主机。
身份管理(IdM)以外的集成系统有时会根据与 IdM 中使用的算法不同的算法生成 UID 和 GID 值。通过覆盖之前生成的值使其与 IdM 中使用的值兼容，曾作为另一个集成系统的客户端可以完全与 IdM 集成。
本章仅介绍与 Active Directory(AD)相关的 ID 视图功能。有关 ID 视图的常规信息，请参阅
Linux 域身份、身份验证和策略指南
。
您可以在 AD 环境中使用 ID 视图来满足以下目的：
-
覆盖 AD 用户属性，如 POSIX 属性或 SSH 登录详情
-
-
从同步迁移到基于信任的集成
-
-
执行每个主机组覆盖 IdM 用户属性
-
8.1. Active Directory 默认信任视图
Default Trust View 是默认 ID 视图，始终应用到基于信任的设置中的 AD 用户和组。当您使用
ipa-adtrust-install 建立信任且无法删除时
，它会自动创建。
使用 Default Trust View，您可以为 AD 用户和组定义自定义 POSIX 属性，从而覆盖 AD 中定义的值。
表 8.1. 应用默认信任视图
|
|
AD 中的值
|
默认信任视图
|
|
结果
|
|
login
|
ad_user
|
ad_user
|
→
|
ad_user
|
|
UID
|
111
|
222
|
→
|
222
|
|
GID
|
111
|
（无值）
|
→
|
111
|
Default Trust View 仅接受 AD 用户和组的覆盖，而不接受 IdM 用户和组的覆盖。它适用于 IdM 服务器和客户端，因此只需要为 ActiveActive Directorynbsp;Directory 用户和组提供覆盖。
8.1.2. 使用其他 ID 视图覆盖默认信任视图
如果另一个应用到主机的 ID 视图覆盖 Default Trust View 中的属性值，IdM 将在 Default Trust View 之上应用特定于主机的 ID 视图中的值。
如果在特定于主机的 ID 视图中定义了属性，IdM 将应用此视图中的值。
如果在特定于主机的 ID 视图中未定义属性，IdM 将应用 Default Trust View 中的值。
默认信任视图始终应用到 IdM 服务器和副本，以及 AD 用户和组。您无法为他们分配不同的 ID 视图：它们始终应用 Default Trust View 中的值。
表 8.2. 在默认信任视图上应用主机特定 ID 视图
|
|
AD 中的值
|
默认信任视图
|
主机特定视图
|
|
结果
|
|
login
|
ad_user
|
ad_user
|
（无值）
|
→
|
ad_user
|
|
UID
|
111
|
222
|
333
|
→
|
333
|
|
GID
|
111
|
（无值）
|
333
|
→
|
333
|
IdM 主控机始终从 Default Trust View 应用 ID 覆盖，无论 IdM 客户端如何检索值：使用 SSSD 或使用 Schema 兼容性树请求。
但是，特定于主机的 ID 视图中的 ID 覆盖的可用性有限：
-
旧客户端：RHEL 6.3 及更早版本（SSSD 1.8 及更早版本）
-
客户端可以请求应用特定的 ID 视图。
要在传统客户端上使用特定于主机的 ID 视图，请将客户端上的基本 DN
更改为：cn=
id_view_name
,cn=views,cn=compat,dc=
example
,dc=
com.
-
RHEL 6.4 到 7.0（SSSD 1.9 到 1.11）
-
不支持客户端上的特定于主机的 ID 视图。
-
RHEL 7.1 及更高版本（SSSD 1.12 及更高版本）
-
完全支持.
IdM 使用
ID 范围来避免来自不同域的
POSIX ID 冲突。有关 ID 范围的详情，请查看
Linux 域身份、身份验证和策略指南中的
ID 范围
。
ID 视图中的 POSIX ID 不使用特殊范围类型，因为 IdM 必须允许与其他类型的 ID 范围重叠。例如，通过同步创建的 AD 用户具有与 IdM 用户相同的 ID 范围内的 POSIX ID。
POSIX ID 在 IdM 侧的 ID 视图中手动管理。因此，如果 ID 冲突发生，可以通过更改冲突 ID 来修复它。
通过 ID 视图，您可以更改 AD 中定义的用户属性值。如需属性的完整列表，请参阅属性
View Can Override
。
例如：如果您要管理混合的 Linux-Windows 环境，并希望手动为 AD 用户定义 POSIX 属性或 SSH 登录属性，但 AD 策略不允许它，您可以使用 ID 视图覆盖属性值。当 AD 用户对运行 SSSD 的客户端进行身份验证或使用兼容 LDAP 树进行身份验证时，身份验证过程中会使用新值。
只有 IdM 用户可以管理 ID 视图。AD 用户无法.
覆盖属性值的过程遵循以下步骤：
创建新的 ID 视图。
在 ID 视图中添加用户 ID 覆盖，并指定 require 属性值。
将 ID 视图应用到特定的主机。
有关如何执行这些步骤的详情，请参阅
Linux 域身份、身份验证和策略指南中的
在不同主机上
为用户帐户
定义不同的属性值。
8.5. 使用 Short Names 进行解析和验证用户和组的配置选项
本节论述了配置选项，允许您使用简短的用户名或组名称，而不是
user_name@domain
或
domain\user_name
完全限定名称格式，以在 Active Directory(AD)环境中解析和验证用户和组。您可以配置它：
在信任 AD 的 Identity Management(IdM)中
在 Red Hat Enterprise Linux 中使用 SSSD 加入 AD
您可以使用域解析顺序选项指定搜索域列表的顺序
，以返回给定用户名的匹配项。您可以设置选项：
服务器上的.请参阅：
第 8.5.2.1 节 “全局设置域解析顺序”
第 8.5.2.2 节 “为 ID 视图设置域解析顺序”
在客户端上.请查看
第 8.5.3 节 “在 IdM 客户端中配置域解析顺序”
在具有 Active Directory 信任的环境中，建议应用一个或多个基于服务器的选项。
从特定客户端的角度来看，可以在以上三个位置中的多个位置中设置域解析顺序选项
。客户端检查这三个位置的顺序是：
本地
sssd.conf
配置
id 视图配置
全局 IdM 配置
将仅使用首先找到的域解析顺序设置。
在 Red Hat Enterprise Linux 直接集成到 AD 的环境中，您只能在客户端上设置域解析顺序。
如果出现以下情况，则必须使用限定名称：
用户名存在于多个域中
SSSD 配置包括
default_domain_suffix
选项，您想要向未使用该选项指定的域发出请求
如果域或子域中的大量客户端应使用相同的域解析顺序，请选择基于服务器的配置。
选择此选项将域解析顺序设置为信任中的所有客户端。要做到这一点，请使用
ipa config-mod
命令。例如，在 IdM 域中，它与多个子域信任 AD 林：
$ ipa config-mod --domain-resolution-order='idm.example.com:ad.example.com:subdomain1.ad.example.com:subdomain2.ad.example.com'
Maximum username length: 32
Home directory base: /home
Domain Resolution Order: idm.example.com:ad.example.com:subdomain1.ad.example.com:subdomain2.ad.example.com
通过以这种方式设置域解析顺序，来自 IdM 域和可信 AD 林的用户只能使用短名称登录。
选择此选项以将设置应用到特定域中的客户端。
例如，在子域服务器上
server.idm.example.com
，您会看到来自
subdomain2.ad.example.com 的子域比来自
subdomain1.ad
.example.com
的更多登录。
但是，全局解析顺序指出，在解析用户名时，subdomain1.ad.example.com
子域用户数据库在
subdomain2.ad.example.com
之前被尝试。要为特定服务器设置不同的顺序，为特定视图设置域解析顺序：
使用域解析顺序选项集创建一个
ID 视图：
$ ipa idview-add example_view --desc "ID view for custom shortname resolution on server.idm.example.com" --domain-resolution-order subdomain2.ad.example.com:subdomain1.ad.example.com
---------------------------------
Added ID View "example_view"
---------------------------------
ID View Name: example_view
Description: ID view for custom shortname resolution on server.idm.example.com
Domain Resolution Order: subdomain2.ad.example.com:subdomain1.ad.example.com
在客户端上应用视图。例如：
$ ipa idview-apply example_view --hosts server.idm.example.com
-----------------------------------
Applied ID View "example_view"
-----------------------------------
hosts: server.idm.example.com
---------------------------------------------
Number of hosts the ID View was applied to: 1
---------------------------------------------
有关 ID 视图的详情请参考
第 8 章
在 Active Directory 环境中使用 ID 视图
。
如果要在较少数量的客户端上设置客户端的域解析顺序，或者客户端直接连接到 AD，请设置域解析顺序。
在
/etc/sssd/sssd.conf
文件的 [sssd] 部分中设置
domain_resolution_order
选项，例如：
domain_resolution_order = subdomain1.ad.example.com, subdomain2.ad.example.com
有关配置
domain_resolution_order
选项的详情请参考 sssd.conf(5)手册页。
请注意，修订号与本手册的版本相关，与 Red Hat Enterprise Linux 的版本号无关。
|
修订历史
|
|
修订 7.0-51
|
Thu Mar 4 2021
|
Florian
Delehaye
|
|
7.9 GA 版指南.添加了有关手动调整 DNA ID 范围的新部分。
|
|
|
修订 7.0-50
|
Wed May 27 2020
|
Florian
Delehaye
|
|
|
|
修订 7.0-49
|
Tue Aug 06 2019
|
Marc
Muehlfeld
|
|
|
|
修订 7.0-48
|
Wed Jun 05 2019
|
Marc
Muehlfeld
|
|
更新了配置信任代理
，添加了
AD 提供程序如何处理受信任域
，以及更改 SSSD 显示的用户名格式
.
|
|
|
修订 7.0-47
|
Tue Apr 08 2019
|
Marc
Muehlfeld
|
|
|
|
修订 7.0-46
|
Mon Oct 29 2018
|
Filip
Hanzelka
|
|
|
|
修订 7.0-45
|
Mon Jun 25 2018
|
Filip
Hanzelka
|
|
添加了
SSSD 和 Winbind 之间的交换，用于 SMB 共享访问.
|
|
|
修订 7.0-44
|
Thu Apr 5 2018
|
Filip
Hanzelka
|
|
|
|
修订 7.0-43
|
Wed Feb 28 2018
|
Filip
Hanzelka
|
|
|
|
修订 7.0-42
|
Mon Feb 12 2018
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-41
|
Mon Jan 29 2018
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-40
|
Fri Dec 15 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-39
|
Mon Dec 6 2017
|
Aneta
Šteflová Petrová
|
|
使用 Samba 进行 Active Directory 集成更新
.
|
|
|
修订 7.0-38
|
Mon Dec 4 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-37
|
Mon Nov 20 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-36
|
Mon Nov 6 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-35
|
Mon Oct 23 2017
|
Aneta
Šteflová Petrová
|
|
更新了
Active Directory 条目和 POSIX
属性，以及配置将 ID 映射作为 SSSD 提供程序的
AD 域.
|
|
|
修订 7.0-34
|
Mon Oct 9 2017
|
Aneta
Šteflová Petrová
|
|
添加用于使用短名称的配置选项.
更新了信任控制器和信任代理.
|
|
|
修订 7.0-33
|
Tue Sep 26 2017
|
Aneta
Šteflová Petrová
|
|
更新了 SSSD 章节中的自动发现部分。添加了有关配置可信域的两个部分。
|
|
|
修订 7.0-32
|
Tue Jul 18 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-31
|
Tue May 23 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-30
|
Mon Apr 24 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-29
|
Mon Apr 10 2017
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-28
|
Mon Mar 27 2017
|
Aneta
Šteflová Petrová
|
|
迁移允许用户将其他用户的密码完全更改为 Linux 域身份指南，作为启用密码重置.更新了信任支持的 Windows 平台.修复了损坏的链接。其他次要更新.
|
|
|
修订 7.0-27
|
Mon Feb 27 2017
|
Aneta
Šteflová Petrová
|
|
更新了信任的端口要求。轻微调整信任和同步.其他次要更新.
|
|
|
修订 7.0-26
|
Wed Nov 23 2016
|
Aneta
Šteflová Petrová
|
|
添加了 ipa-winsync-migrate。信任、SSSD 和同步章节的小修复。
|
|
|
修订 7.0-25
|
Tue Oct 18 2016
|
Aneta
Šteflová Petrová
|
|
|
|
修订 7.0-24
|
Thu Jul 28 2016
|
Marc
Muehlfeld
|
|
更新了图表，为服务和主机添加了 Kerberos 标志，以及其他次要修复.
|
|
|
修订 7.0-23
|
Thu Jun 09 2016
|
Marc
Muehlfeld
|
|
更新了同步章节。删除了 Kerberos 章节。其他小修复.
|
|
|
修订 7.0-22
|
Tue Feb 09 2016
|
Aneta
Petrová
|
|
更新了 realmd，删除索引，将 ID 视图的一部分移到 Linux 域身份指南和其他次要更新中。
|
|
|
修订 7.0-21
|
Fri Nov 13 2015
|
Aneta
Petrová
|
|
|
|
修订 7.0-20
|
Thu Nov 12 2015
|
Aneta
Petrová
|
|
|
|
修订 7.0-19
|
Fri Sep 18 2015
|
Tomáš
Čapek
|
|
|
|
修订 7.0-18
|
Thu Sep 10 2015
|
Aneta
Petrová
|
|
|
|
修订 7.0-17
|
Mon Jul 27 2015
|
Aneta
Petrová
|
|
添加了基于 GPO 的访问控制，其他一些细微变化。
|
|
|
修订 7.0-16
|
Thu Apr 02 2015
|
Tomáš
Čapek
|
|
添加了 ipa-advise，通过 SSSD 扩展扩展的 CIFS 共享，提醒 UNIX 扩展的身份管理。
|
|
|
修订 7.0-15
|
Fri Mar 13 2015
|
Tomáš
Čapek
|
|
|
|
修订 7.0-13
|
Wed Feb 25 2015
|
Tomáš
Čapek
|
|
|
|
修订 7.0-11
|
Fri Dec 05 2014
|
Tomáš
Čapek
|
|
|
|
修订 7.0-7
|
Mon Sep 15 2014
|
Tomáš
Čapek
|
|
|
|
修订 7.0-5
|
June 27, 2014
|
Ella Deon
Ballard
|
|
改进 Samba+Kerberos+Winbind 章节.
|
|
|
修订 7.0-4
|
June 13, 2014
|
Ella Deon
Ballard
|
|
|
|
修订 7.0-3
|
June 11, 2014
|
Ella Deon
Ballard
|
|
|
|
|
