Linux 统一身份登录和查询

在前面的章节里我们解释了保持 Linux UID 统一的重要性。在这一节里我们介绍统一 Linux 主机的用户 UID, 并使得用户可以用统一的域账号和密码登录 Linux 主机的方法。

我们首先指出一个事实，在具有多台 Linux 主机的环境中，无论用户采用了何种网络文件系统为用户提供个人目录，都需要解决统一用户 UID 的问题。所以统一身份登录不仅仅是部署 OpenAFS 的需要，而是所有 Linux 集群的需要。

如果用户采用了 NFS 或者 SMB 协议部署网络文件系统，用户的个人目录可能位于 /server1 或者 /filer2 这样的目录下，这样的情况也同样面临统一账户管理的问题。

我们在这里介绍的基于 SSSD 的统一身份登录方案不仅适用于 AFS，稍作调整以后也适用于其他网络文件系统。

统一身份管理长期以来是企业用户关心的问题。面向 Linux 的解决方案也经历了多代演变。

Unix最初的用户账号都是本地，其信息存储于

/etc/passwd
/etc/shadow 
/etc/groups 

等本地文件下。创建一个Unix 用户的过程本质上就是向上述文件增添相应的记录。

20 世纪 90 年代时，人们开始使用 Network Information Service (NIS) 系统提供网络黄页（Yellow Page）服务，在 Sun 公司的推动下，Unix 主机可以通过 NIS 协议向中心数据库获取用户账户信息，以登录/etc/passwd下没有登记的非本地用户.

在 DNS 协议没有推广前， NIS 还提供了早期的域名解析服务。

进入21世纪以后，DNS 取代 NIS 成为网络域名解析的标准协议，而 LDAP (Lightweight Directory Access Protocol) 则取代了 NIS 协议里身份目录服务的部分。Linux 世界开始使用 OpenLDAP 系统提供非本地用户的身份数据，而基于 LDAP 协议的微软 Active Directory 系统在 Windows 世界得以广泛应用。

为了支持 Linux 主机向 Active Directory 的集成，Samba 在21世纪初变得流行。Linux 主机在安装了 Samba 以后可以像 Windows 主机一样加入 Active Directory 的域，访问域里的存储和打印资源。

进入00 年代末尾， Samba 增加了 winbind 组件。Winbind 可以使用 LDAP 协议向 Active Directory 获取用户身份信息，并转换成 Linux 主机可以理解的用户格式。比如 Winbind 可以按照用户的要求实现从 Active Directory 的 SID 向 Linux UID 的映射，使得用户可以在部署了 winbind 的所有主机上获得统一的 UID。Winbind 还可以用类似 /home/%U 的格式统一用户的个人目录路径。许多 Linux 管理员对 Samba 和 Winbind 都“情有独钟”。

进入 10 年代末期，即本文成文的时候，Linux 世界的统一身份管理迈入了 SSSD （System Security Service Daemon）的年代。SSSD 作为最主要的身份管理组件进入 Red Hat Enterprise Linux 7 和 8.

使用 SSSD, Linux 系统管理员可以允许非本地用户以统一的 UID 登录 Linux，并且像本地用户一样使用 Linux 客户端。而 Linux 系统管理员不需要负担管理非本地用户账户的责任。非本地用户的账户名、密码、UID和个人目录路径由组织统一部署的中心数据库负责维护。

关于 SSSD 的原理和与 Winbind 的比较有很多公开的资料，比如

https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/

https://www.redhat.com/en/blog/sssd-vs-winbind

我们此处不对 SSSD 的工作原理和实现方式进行详细讨论，而只介绍其和部署相关的部分。

SSSD 作为一个服务运行于 Linux 操作系统环境中，其守护进程分为前端和后端。前端负责接收来自操作系统的名称解析请求，而后端则负责和相应的身份数据库通信获取解析请求的答复。

SSSD 既可以和 Active Directory 通信以支持 Linux 向 AD 的集成，也可以和 Linux 世界的 FreeIPA/IdM 通信，支持纯 Linux 实现的统一身份管理。

当SSSD 的后端与 Active Directory 通信时，将采取 LDAP 协议获取用户的信息，除了 Kerberos 密码以外，这些用户信息并不敏感，所以不加密的 LDAP 通信就可以满足需要。这个过程可以图解如下（https://www.redhat.com/en/blog/overview-direct-integration-options）：

对于我们的部署，简单来说，就是用户的账户属性，包括其 UID, GID, Home Directory 和 Shell 等信息存储于 Active Directory 数据库中，我们使用 SSSD 以 LDAP 协议查询和获取用户的这些属性，并且以 Kerberos 协议验证用户身份。

POSIX 属性 (POSIX Attributes)

我们前面提到的用户账号的信息：UID, GID, 个人目录的路径位置以及偏好的 Shell 在Active Directory 里被归于一类属性，称为用户的 POSIX 属性（POSIX Attributes）。对于 Linux 本地用户账号，以上信息都是存储在 /etc/passwd 文件中。而对非本地用户，它们将由遵循 LDAP 协议的身份数据库提供。

当我们在 Active Directory 里查询一个用户的属性时，就可以看到这些内容.

我们的部署将使用 SSSD 查询其中最基本的4个属性：

POSIX 属性名	取值举例	含义
uidNumber	2002	Linux UID，必须和 AFS ID 一致
gidNumber	100	Linux GID
unixHomeDirectory	/afs/hq.company.com/user/t/testuser	用户的个人 $HOME 目录
loginShell	/bin/bash	用户偏好的登录 $SHELL

下面的图片举例显示了一个用户在 Active Directory 里的 POSIX 属性


在创建 AFS 用户账号时，AFS 系统管理员除了需要在 Active Directory 里创建用户，还需要填入该用户的上述 4 个 POSIX 属性值，其中 uidNumber 的值必须和用户的 AFS ID 一致。后者在 AFS 系统管理员以 “pts createuser” 命令向 Protection Database 里增添用户时被唯一固定。

安装组件程序

在这一步和下一步里，我们的目标是使用 Samba 将 Linux 主机加入 AD 域以获得查询 AD 用户的权限，并使用 SSSD 来查询 AD 获取用户信息。

在进入操作步骤之前，请确定主机已经连入网络，可以和 AD 的域控制器通信。尤其需要注意相应的端口已经打开

在 CentOS 7 里，可以使用如下命令安装需要的程序包:
[xmsguan@client1 openafs]$ sudo yum install samba-common-tools sssd-ad sssd samba

加入 AD 域

为了将主机加入 Active Directory 域以获得查询用户 POSIX 属性的权限，我们对 Samba 做基本的配置，告知其 AD 域和 Kerberos Realm 的信息。
编辑

/etc/samba/smb.conf 

文件的 [global] 一节，其内容如下：

[global]workgroup = ADclient signing = yesclient use spnego = yeskerberos method = secrets and keytablog file = /var/log/samba/%m.logpassword server = AD.COMPANY.COMrealm = AD.COMPANY.COMsecurity = ads#passdb backend = tdbsam#printing = cups#printcap name = cups#load printers = yes#cups options = raw

其中 AD.COMPANY.COM 是域名的大写形式，即 Kerberos Realm 名称。

配置好以上信息以后，Samba 就有了足够的信息可以将我们的主机加入 AD 域。

我们首先需要以 kinit 命令、用一个具有加域权限的域账号登录（xguanafsadmin），然后执行 net ads join 命令将主机加入 AD 域，获得属于主机的 Kerberos 密钥。

[root@eda01 xmsguan]# kinit xguanafsadmin
Password for xguanafsadmin@AD.COMPANY.COM:
[root@eda01 xmsguan]# net ads join -k
Using short domain name -- AD
Joined 'EDA01' to dns domain 'ad.company.com'
No DNS domain configured for eda01. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETER
[root@eda01 xmsguan]#

此处我们只需要获得查询 AD 的权限，即获得 Kerberos 密钥，而我们忽略了 DNS 记录更新失败的信息。

我们可以确认主机已经获得了属于自己的 Kerberos 密钥：

[root@eda01 xmsguan]# ls /etc/krb5.keytab
/etc/krb5.keytab
[root@eda01 xmsguan]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------1 restrictedkrbhost/eda01.ad.company.com@AD.COMPANY.COM1 restrictedkrbhost/EDA01@AD.COMPANY.COM1 restrictedkrbhost/eda01.ad.company.com@AD.COMPANY.COM1 restrictedkrbhost/EDA01@AD.COMPANY.COM1 restrictedkrbhost/eda01.ad.company.com@AD.COMPANY.COM1 restrictedkrbhost/EDA01@AD.COMPANY.COM1 host/eda01.ad.company.com@AD.COMPANY.COM1 host/EDA01@AD.COMPANY.COM1 host/eda01.ad.company.com@AD.COMPANY.COM1 host/EDA01@AD.COMPANY.COM1 host/eda01.ad.company.com@AD.COMPANY.COM1 host/EDA01@AD.COMPANY.COM1 EDA01$@AD.COMPANY.COM1 EDA01$@AD.COMPANY.COM1 EDA01$@AD.COMPANY.COM

我们可以使用 net ads testjoin 命令在 Linux 主机端确认加域已经成功：

[root@eda01 xmsguan]# net ads testjoin
Join is OK
[root@eda01 xmsguan]#

同时我们也可以在域控制器上确认域里确实已经加入该主机的记录。

测试 LDAP 查询

在进行 SSSD 配置之前，首先用底层的 LDAP 协议测试一下手动查询 AD 是否可以顺利通过, 这对于此后的配置和排错十分有益。这是因为当我们配置完成以后，SSSD 将使用同样的 LDAP 协议来查询用户信息，以登录非本地用户。事先将管道疏通好，有利于之后的部署和排查。

如果手动 LDAP 查询可以通过，说明 AD 的域控制器和 AFS 客户端主机之间可以顺利通信，那么如果之后的配置出错，则错误不在底层的通信。

相反，如果手动查询不能通过，则不应该进入 SSSD 配置步骤，而需要排除造成 LDAP 查询失败的底层原因，比如防火墙端口是否打开，路由是否顺利，域控制器的服务是否正常，DNS 配置是否正确等等。

手动 LDAP 查询需要使用的命令是 ldapsearch，这个命令可以通过安装 openldap-client 客户端获得。
安装openldap-clients， 以使用 ldapsearch：

[root@eda01 xmsguan]# yum install openldap-clients

接着我们使用 ldapsearch 命令向域控制器查询一个已经存在的用户的记录，比如 testuser.

需要特别注意的是，命令的 -H 参数后面应该使用域控制器的全程域名(FQDN)，而非 IP 地址。-b 参数后面应该使用被查询用户对应的基础专有名称(base distinguished name, base DN)。如果域的名称是 ad.company.com，则这个参数值可以是 “dc=ad,dc=company,dc=com”。注意不能有空格。

如果查询顺利，得到的结果一般如下，注意可以看到一些关键属性的值，比如 uidNumber, loginShell 等等。

[root@eda01 xmsguan]# ldapsearch -H ldap://dc1.ad.company.com -Y GSSAPI -N -b "dc=ad,dc=company,dc=com" "(&(objectClass=user)(sAMAccountName=testuser))"
SASL/GSSAPI authentication started
SASL username: testuser@AD.COMPANY.COM
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
…
# testuser, AFS, ad.company.com
dn: CN=testuser,OU=AFS,DC=ad,DC=company,DC=com
…
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: testuser
givenName: testuser
distinguishedName: CN=testuser,OU=AFS,DC=ad,DC=company,DC=com
instanceType: 4
…
sAMAccountName: testuser
…
userPrincipalName: testuser@ad.company.com
…
uidNumber: 2002
unixHomeDirectory: /afs/hq.company.com/u/t/testuser
loginShell: /bin/bash

上述查询如果成功，说明主机通过 LDAP 协议和存储了用户账户数据的 AD 域控制器之间的通信已经没有障碍。如果查询失败，则需要检查域服务是否运行正常，主机的网络是否正常，以及主机上相应的网络端口是否已经打开。

配置 NSS 和 PAM

在这一步里，我们的目标是告知 Linux 操作系统这样的信息：

除了使用本地文件 /etc/passwd，请另外使用 SSSD 和 Kerberos 服务解析非本地用户名并登录这些用户。

如何做到这一点呢？Unix/Linux 系统通过一个叫 Name Service Switch （NSS）的组件实现这一点。NSS 长期以来属于 Unix/Linux 系统的基本组件，由 C 语言的标准库 libc (glibc) 提供。其配置文件的位置固定为：

/etc/nsswitch.conf

这个文件的格式十分简单，除了注释和空行以外，每一行描述了某种类型的名称应该以何种顺序和方式解析。比如：

hosts:      files dns

其中 hosts 指明了这是一条针对主机地址的解析规则，冒号之后的部分规定了名称的解析顺序。在上面这个例子中，因为 files 文件当先，所以每当操作系统需要解析一个主机的地址时，首先会查询本地文件记录（这个文件一般是 /etc/hosts）如果查询失败，则接着使用 DNS 协议解析主机地址。而 DNS 服务的地址一般通过查询 /etc/resolv.conf 文件获得。

对我们而言，感兴趣的记录类型是 passwd, shadow 和 group. 我们希望将 SSSD 增加到这些记录中，这样当 Linux 遇到一个本地文件不存在的用户名时，就会使用 SSSD 查询用户的 POSIX 属性。

我们可以通过手动方式修改 /etc/nsswitch.conf 文件实现这一点，但更安全可靠的方式是通过自动配置命令，比如 authconfig 或者 authselect 实现。

类似的，我们需要告知 Linux 操作系统：

除了使用本地文件 /etc/shadow，请使用 Kerberos 协议验证非本地用户的身份。

这同样是通过配置一个 Unix/Linux 的基本组件实现，这个组件称为 PAM (Pluggable Authentication Modules). PAM 组件由位于

/etc/pam.d/

目录下的文件来配置。其规则比 NSS 复杂不少。

修改 PAM 配置文件需要**特别小心**，因为 PAM 文件的改动会即时生效。

如果 PAM 修改错误，往往会立刻导致用户无法远程登录系统。因此对于新手而言，一般不建议手动修改这些文件，而是通过自动配置工具，比如 authconfig 或者 authselect 实现。如果不得不远程登录并手动修改文件，一般的做法是同时保持两个 root 登录终端进程，以其中一个进行修改和调试，如果出错，则另外一个已经登录的 root 终端还可以恢复修改之前的备份。

我们将使用自动配置命令 authconfig 对 NSS 和 PAM 进行修改，以支持 SSSD 和 Kerberos 协议。

以 CentOS 7 为例，需要执行的命令如下：

[xmsguan@client1 ~]$ sudo authconfig --update --enablesssd --enablesssdauth
[xmsguan@client1 ~]$

在 CentOS 8 或者 RHEL 8 里， authconfig 被 authselect 取代，需要执行的命令和其返回的结果则是：

[root@eda01 xmsguan]# authselect select sssd --force
Profile "sssd" was selected.
The following nsswitch maps are overwritten by the profile:
- passwd
- group
- netgroup
- automount
- servicesMake sure that SSSD service is configured and enabled. See SSSD documentation for more information.[root@eda01 xmsguan]#

执行完上述命令，可以看到 /etc/nsswitch.conf 文件里增加了 SSSD 的解析模块 (sss)：

passwd:     files sss
shadow:     files sss
group:      files sss
…
services:   files sss
…

另外，

/etc/pam.d/system-auth 

也得到了更新，增加了对 pam_sss 模块的调用：

auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_fprintd.so
auth        [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet
auth        [default=1 ignore=ignore success=ok] pam_localuser.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.soaccount     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.sopassword    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.sosession     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

我们在后面还会进一步修改 PAM 配置，此处显示的不是最终结果。

配置 SSSD

在告知 Linux 操作系统需要使用 SSSD 来解析用户属性之后，显然我们需要配置 SSSD，使其可以顺利查询 Active Directory 获得用户的账户信息。

SSSD 的配置文件是

/etc/sssd/sssd.conf

初始情况下这个文件可能不存在。创建这个文件时需要注意其所有者 (root:root) 和访问权 (600) 的设定，如果设定错误则后面 SSSD 的服务将无法正常启动和运行。

创建 sssd.conf 并设定其所有者和访问权:

[root@eda01 xmsguan]# touch /etc/sssd/sssd.conf
[root@eda01 xmsguan]# ll /etc/sssd
total 8
drwx--x--x. 2 sssd sssd 4096 Apr 24 11:48 conf.d
drwx--x--x. 2 root root 4096 Apr 24 11:48 pki
-rw-r--r--. 1 root root    0 Jun 22 05:16 sssd.conf
[root@eda01 xmsguan]# chmod 600 /etc/sssd/sssd.conf
[root@eda01 xmsguan]# ll /etc/sssd
total 8
drwx--x--x. 2 sssd sssd 4096 Apr 24 11:48 conf.d
drwx--x--x. 2 root root 4096 Apr 24 11:48 pki
-rw-------. 1 root root    0 Jun 22 05:16 sssd.conf
[root@eda01 xmsguan]#

编辑 sssd.conf 文件的内容，使得 SSSD 可以正确地向 AD 发起用户信息查询并获得其 POSIX 属性。下面的例子显示了编辑完成以后的 sssd.conf 文件的全部内容：

[root@eda01 xmsguan]# cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
domains = ad.company.com
services = nss, pam
#default_domain_suffix = AD.COMPANY.COM[nss][domain/ad.company.com]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
#enumerate = true
#debug_level=10# defines user/group schema type
ldap_schema = ad# using explicit POSIX attributes in the Windows entries
ldap_id_mapping = False# caching credentials
cache_credentials = true# access controls
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true# performance
ldap_referrals = false[root@eda01 xmsguan]#

注意在上面的配置里，我们将 ldap_id_mapping 的值设为 False. SSSD 提供一种动态生成用户 UID 的方法。我们不希望使用动态生成的 UID, 而是要求使用写入用户 POSIX 属性 uidNumber 里的值作为用户的 Linux UID.

另外，我们通过将 cache_credentials 参数设置为 true, 打开了 SSSD 的缓冲功能，使得用户重复登录时主机可以减少重复执行 AD 查询的次数。

完成上述配置以后，就可以启动 sssd 服务了。注意我们说过 SSSD 是以服务守护进程的形式存在的，所以配置文件改动后需要重启服务才能生效。

[root@eda01 xmsguan]# systemctl restart sssd

验证 SSSD 配置

一旦 SSSD 正常运转，NSS 也配置正确，则通过命令 “id” 就可以看到一个非本地用户的信息，就像用同样的命令可以从 /etc/passwd 里抽取本地用户的信息一样。此时应该使用 id 命令确认SSSD 可以获取用户信息:

[root@eda01 sssd]# id testuser
uid=2002(testuser) gid=100(users) groups=100(users)

可以看到，我们在前文中显示的 testuser 的 POSIX 属性被顺利映射成了 Linux UID, 和 GID

注意，如果查询失败需要排查错误，除了 SSSD 可能配置出错以及之前的测试 LDAP 查询可能出错以外，另一个可能出错的地方是被查询用户的 POSIX 属性没有正确设置。

如果 id 命令能够正常返回非本地用户的信息，则说明 SSSD 配置正确，主机可以利用 AD 域控制器来登录组织内的用户。

针对 AFS 进一步配置 PAM

如果读者使用的不是 AFS 系统，而是 NFS 或者 SMB 等其他网络文件系统，则不需要再执行本步骤。

对于以 AFS 文件系统提供用户个人 $HOME目录的组织，完成上述主机配置以后，仍然需要执行本步骤以完成客户端主机的配置。

我们已经完成了 AFS 客户端的配置，允许本地用户手动登录和访问 AFS.

我们已经通过配置 SSSD 和 PAM 实现了 Linux 在登录非本地用户时对其身份的验证。这相当于在用户登录 Linux 时，系统自动为其执行前文 提到的 kinit 命令.

我们也已经通过配置 SSSD 和 NSS 实现了在 Linux 完成非本地用户的身份验证以后，自动从 AD 里抽取用户的 POSIX 属性的目标。特别的，Linux 会获得其在 /afs 下的个人目录(unixHomeDirectory) 的路径地址，并尝试在登录完成时将用户放置于该目录下。

然而如果我们止步于此，则会在用户登录时遇到一个错误，系统在尝试将用户放置于其个人目录下时，无法获得访问其个人 AFS 目录的权限，为什么呢？原来Linux 主机还没有为用户获得 AFS token.

在前文中我们已经介绍过 AFS token 的含义，以及手动登录获取 AFS token 的命令 aklog. 我们的配置虽然已经能够完成对用户身份的验证，却还缺少手动登录中的第二步，即在执行 kinit 命令以后，还需要使用 aklog 命令获取用户的 AFS token.

我们目前的情况相当于付了钱并出示了身份证（Kerberos），得到了车厢和座位号 (unixHomeDirectory)，但还没有实际取得火车票 (AFS token)。我们只需要再去取个票。

如何做到这一点呢？只需要对 PAM 配置文件稍作改动，增加一个模块调用 aklog 命令。这个模块叫做 pam_afs_session, 最初由斯坦福大学的系统管理员 Russ Albery 开发。它的目的很简单，就是在 PAM 栈里增加一个动作 —— 在Kerberos (SSSD) 完成身份验证、获取了用户的 Kerberos Ticket (Ticket Granting Ticket) 以后，继续执行 aklog 命令，以已经获取的 Kerberos Ticket为凭据，为用户获取 AFS token。简单理解，这个模块就是一个取票代理。

为此，我们需要安装 pam_afs_session 模块。这个模块在 Red Hat/CentOS 标准源里已经存在多年。

[root@client1 pam.d]# yum install pam_afs_session

安装完成以后，需要修改 PAM 配置，调用该模块为我们获取 AFS token.

如前所述，配置 PAM 需要特别小心，除非管理员能轻易地访问主机的本地 Console，否则在大部分远程登录的情况下，为了防止出现错误后将所有用户包括管理员本人锁在登录环境以外，管理员应该预先做到如下两条:

1. 对 /etc/pam.d 目录做一个整体备份，比如将其打包成一个 .tar 文件放在个人目录下。
2. 额外增加一个 root 登录窗口放在旁边。如果配置测试失败，还可以通过这个登录窗口恢复上述备份。

做到上述两点以后，就可以修改 /etc/pam.d/ 下的文件内容了。

以 CentOS或者 RHEL 系统为例，我们需要修改的是如下两个文件的内容:

/etc/pam.d/system-auth
/etc/pam.d/password-auth

注意这两个文件可能是指向 SSSD 配置目录下的符号链接（symbolic link）。这种情况下我们修改的将是符号链接指向的源文件的内容。上述两个文件的修改方式完全相同，所以我们只描述第一个文件的修改步骤。

打开

/etc/pam.d/system-auth

文件，找到之前配置 SSSD 时增加的一行：

auth        sufficient    pam_sss.so forward_pass

将其修改为如下两行：

auth        [success=ok default=1]    pam_sss.so forward_pass
auth        [default=done] pam_afs_session.so program=/usr/bin/aklog

然后找到之前配置 SSSD 时增加的一行:

session     optional      pam_sss.so

保持其不变，并在其后增加一行，即变成

session     optional      pam_sss.so
session     required      pam_afs_session.so program=/usr/bin/aklog

对 /etc/pam.d/password-auth 做同样的修改。

登录验证

完成上述所有配置步骤以后，我们用在预备条件中已经准备好的一个 AFS 账号（非本地用户）登录 Linux 主机。

下面这个例子以 testuser 为用户名登录一台叫 eda01 的服务器，并且在登录之后查看当前目录及环境变量的值，并确定 AFS token:

login as: testuser
testuser@172.16.1.21's password:
Last login: Mon Jun 29 08:35:06 2020 from 172.16.255.254
[testuser@eda01 ~]$ pwd
/afs/hq.company.com/user/t/testuser
[testuser@eda01 ~]$ echo $SHELL
/bin/bash
[testuser@eda01 ~]$ echo $HOME
/afs/hq.company.com/user/t/testuser
[testuser@eda01 ~]$ id testuser
uid=2002(testuser) gid=100(users) groups=100(users)
[testuser@eda01 ~]$ tokensTokens held by the Cache Manager:User's (AFS ID 2002) rxkad tokens for hq.company.com [Expires Jun 29 18:36]--End of list--
[testuser@eda01 ~]$ touch test
[testuser@eda01 ~]$ ls -l
total 0
-rw-r--r--. 1 testuser users 0 Jun 29 08:40 test
[testuser@eda01 ~]$

可以看到，非本地用户 testuser 可以顺利登录该 Linux 主机并获得 AFS token，其登录之后就被置于自己的 AFS Home 目录下，且登录后得到的 Shell 是自己偏好的 Bash. 当其查看自己目录下的文件时，系统可以正确地显示文件的所有者，而不是显示 AFS ID 整数。

至此我们就完成了一个 AFS 客户端的基本配置。可以看到，当组织内每一台应用服务器都按照这样的方式配置时，用户登录任何一台应用服务器都可以使用同样的密码和用户名，登录以后看到同样的环境和目录。账户的管理不是通过修改每一台服务器上的 /etc/passwd 文件实现，而是通过修改域账号和 AFS 账号统一进行，这样就实现了用户账户的统一管理。