异构 ? 系统差异应该成为过去式, 专注在应用和数据 - 异构平台整合策略之1 - SSSD

在当前的IT技术趋势下，云技术容器技术的广泛推行催生了平台包容性的发展。独守一隅只会越做越小，做生态，做兼容，在合作中以运营和研发来定分别成了各大厂家的基本策略。比如微软最终弱化系统差异拥抱Linux, 甚至急于证明Linux在微软的虚拟化以及Azure 平台上面运行的优势和规模，来吸引一部分*nix用户强化微软的技术覆盖.  厂家为什么要这么做呢 ？这是一个很有意思的话题，云化之后最有价值的产出就是数据, 数据作为下一阶段的差异化原料是大数据，人工智能的必要养料，因此但凡有些策略的公司都亟待扩大自己的数据抓取面为下一轮竞争奠定基础 -- 摩拜OFO的共享单车就是这个例子, 还在说流量/入口的同志们应该醒过来了。世界已经悄然改变;

 

那么既然系统的差异化如此需要弱化，异构平台的并存整合就开始提上日程。 Windows 平台和 *nix 平台在公司不同比例并存是很多公司常态：比如研发大规模使用linux/unix, 办公大规模使用Windows/OA应用。所以解决异构平台的整合自然而然是很多公司需要去考虑和解决的问题。该系列文章旨在从行业，技术，管理和成本的角度来给这个目的提供一些思路和参考。

 

先说SSSD是什么:

==========

SSSD (System Security Services Daemon) 系统安全服务守护进程。是红帽推出的一个中间进程，用来连接用户和验证数据库。它与NSS/PAM 模块相结合解决了传统ldap认证/kerberos认证的一些短板，比如离线认证，通过缓存提升性能等。与之前的Winbind方案相比：

1. 它更加符合 Direct integrate - Indirect integrate的技术升级路线，可以无缝过渡；

2. 提供了集中的管理策略，这是Winbind 不具备也是很多管理员一直想要的;

3. 提供了多账户源的支持，不仅仅支持AD;

 

与商业方案相比，SSSD在很多场景上有很大成本优势。功能上比商业方案少一些; 比如Quest, BeyondTrust, Centrify 就提供了功能强大的商业解决方案. SSSD作为一个免费的解决方案基本可以覆盖 异构平台整合的大部分需求了. 因此还是很有考虑和研究的价值。而且免费方案的完善通常都需要一个过程。我们期待SSSD担负起异构平台整合的润滑剂这样一个历史使命，简化IT架构和管理。

 

通过一张图来了解下 SSSD的定位: 

客户端与SSSD交互，SSSD代理客户端与AD/其他验证数据库交互。

先把简单的安装配置过程撒完，有问题的欢迎大家留言。本文以Ubuntu 14为例:

1. 安装所需组件:

 sudo apt install krb5-user samba sssd ntp

 

2. 配置Kerberos Client: 编辑 /etc/krb5.conf ：

[libdefaults]

default_realm = MYUBUNTU.EXAMPLE.COM
ticket_lifetime = 24h #
renew_lifetime = 7d

3. 配置Samba: 编辑 /etc/samba/smb.conf

[global]

workgroup = MYUBUNTU
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = MYUBUNTU.EXAMPLE.COM
security = ads

 

4. 配置SSSD, 编辑/etc/sssd/sssd.conf (该文件可能不存在，就是新建)

 [sssd]
services = nss, pam
config_file_version = 2
domains = MYUBUNTU.EXAMPLE.COM

[domain/MYUBUNTU.EXAMPLE.COM]
id_provider = ad
access_provider = ad

# Use this if users are being logged in at /.
# This example specifies /home/DOMAIN-FQDN/user as $HOME.  Use with pam_mkhomedir.so
override_homedir = /home/%d/%u

# Uncomment if the client machine hostname doesn't match the computer object on the DC.
# ad_hostname = mymachine.myubuntu.example.com

# Uncomment if DNS SRV resolution is not working
# ad_server = dc.mydomain.example.com

# Uncomment if the AD domain is named differently than the Samba domain
# ad_domain = MYUBUNTU.EXAMPLE.COM

# Enumeration is discouraged for performance reasons.
# enumerate = true

 

注：文件新建后需要改一下owner以及权限:

 sudo chown root:root /etc/sssd/sssd.conf

sudo chmod 600 /etc/sssd/sssd.conf

 

５.　确认nsswitch.conf配置， 编辑/etc/nsswitch.conf

 passwd:        compat sss
group:         compat sss
...
netgroup:      nis sss
sudoers:       files sss

 

6. 启动服务，加域:

service ntp restart

service smbd restart

service nmbd restart

service sssd restart

 

运行该命令查看是否可以连接到AD获取Kerberos ticket:  sudo kinit administrator

成功的话可以运行klist命令看到结果; 并且加域基本可以成功 (名称解析，时间同步没有问题)

加域可以使用realm 命令，也可以使用net ads 命令来做:

 

net ads join -k

realm -v join -U user EXAMPLE.COM

加域成功会有提示;

 

7. 验证:

可以用 Id 命令来查看是否可获取AD账户信息:

id domainuseralias    会返回用户名，UID/GID等信息;

getent passwd username   会返回NIS/本地格式的账户信息

su - domainuser             切换到域账户context，该命令成功用户登录基本也可; 可以直接登录域账户了;

SSH 命令

 

方案虽好，也不要迷信。 该方案目前发现的一些问题:

 

1. 在有改动的情况下不稳定。表现为和AD失去连接，AD账户信息无法获取或者其他症状。一般需要重启服务或者重新配置可以解决，比如很多人遇到了 id no such user 问题；

 

2. RFC2307 属性的识别支持： 虽然官方说明支持RFC2307 属性，但在实际配置实验过程中，一些RFC2307属性如UID/GID 并不能被很好的识别，ID Mapping 的功能无法实现, 对于从NIS迁移出来的用户来说，会带来一些不便;

 

3. 对于Solaris/Aix不支持。这会限制一部分用户选用 SSSD. 作为定位要与 Winbind以及商业方案比肩的方案，兼容性是很重要的。目前仍有很多应用跑在 Solaris/AIX上，这一部分的缺失是一个硬伤;

 

综上: SSSD作为一个性价比极高的异构平台集成方案，解决了Redhat/Ubuntu/Centos等主流linux平台与Windows 以及其他验证域集成的问题，它所提供的功能可以覆盖绝大部分系统应用场景。是一个值得管理员研究与参考的方案;