DevOps知识中心
DevOps知识中心

本地用户与集中式身份验证：选择正确的 Linux 设置

探索在 Linux 环境中，本地 `/etc/passwd` 用户管理与使用 LDAP 或 Active Directory 进行集中式身份验证之间的关键决策。本指南详细介绍了两种设置的优缺点、可伸缩性挑战和安全影响。了解何时选择本地的简便性，以及目录服务所提供的强制一致性，包括 SSSD 的作用。

45 浏览量

本地用户与集中式身份验证：选择正确的 Linux 设置

用户身份和访问控制的管理是 Linux 系统管理中的一项基本任务。对于任何不断发展的环境，关键的决策通常归结为用户如何进行身份验证：是在每台机器上单独管理用户（本地身份验证），还是从单一、权威的源进行管理（集中式身份验证）？

本文对这两种主要方法进行了全面比较——依赖传统的 /etc/passwd 文件结构与集成 LDAP 或 Active Directory 等目录服务。理解可扩展性、安全性和管理开销方面的权衡，对于为您的特定组织需求选择最佳身份验证策略至关重要。

理解本地身份验证（/etc/passwd 模型）

本地用户管理是独立 Linux 机器上处理用户帐户的默认且最简单的方法。所有用户和组信息都直接存储在本地文件系统中。

本地身份验证的工作原理

用户凭据、用户 ID (UID)、组 ID (GID)、主目录和默认 shell 存储在特定的系统文件中：

  • /etc/passwd: 存储基本的用户帐户信息（用户名、UID、GID、主目录、shell）。
  • /etc/shadow: 存储加密的密码哈希和密码老化信息（此文件仅 root 可读）。
  • /etc/group: 存储组信息。

本地身份验证的优点

  1. 简单快捷: 对于一两台机器来说，设置极其简单。添加用户就像使用 useradd 等工具或手动编辑文件一样简单（尽管更推荐使用工具）。
  2. 离线可用: 即使网络中断或中央身份验证服务器不可达，用户也可以登录。
  3. 无外部依赖: 不需要额外的基础设施、专用服务器或复杂的网络配置。

本地身份验证的缺点

  1. 可扩展性噩梦: 在拥有数十或数百台服务器的环境中，保持一致性变得不可能。如果用户需要访问 20 台服务器，他们必须拥有 20 个独立的、相同的帐户。
  2. 安全风险: 撤销访问权限需要单独登录到每台受影响的机器。忘记一台服务器就会留下一个未经授权的活动帐户。
  3. UID/GID 不一致: 在多台系统上手动管理 UID 常常会导致冲突，在使用共享文件系统（如 NFS）时引起权限问题。

实际示例：添加本地用户

要在本地添加一个名为 analyst1 的新用户：

sudo useradd -m -s /bin/bash analyst1
sudo passwd analyst1
# 提示时设置密码

理解集中式身份验证

集中式身份验证将验证用户身份的责任委托给一个专用的、可网络访问的服务。当用户尝试登录 Linux 机器时，该机器会查询中央目录服务器进行验证。

关键的集中式技术

两种主要技术主导着 Linux 环境的集中式身份验证领域：

  1. LDAP（轻量级目录访问协议）: 一种供应商中立的协议，通常使用 OpenLDAP 等工具实现。它非常灵活，但需要大量的设置和知识。
  2. Active Directory (AD): 微软的专有目录服务。Linux 机器主要使用 Kerberos 进行主要身份验证，并使用 SSSD 或 Winbind 将 AD 用户映射到本地 POSIX 属性来集成 AD。

集中式身份验证的优点

  1. 单一事实来源: 用户创建、修改和删除在一个地方完成，确保所有连接系统立即保持一致。
  2. 可扩展性: 轻松从五台服务器扩展到五千台，而无需增加每个用户的管理开销。
  3. 增强的安全性和合规性: 跨企业即时撤销访问权限。集中式系统易于与高级安全策略（例如，MFA、复杂密码要求）集成。
  4. UID/GID 一致性: 集中式系统集中管理 POSIX 属性（UID、GID、主目录），在使用共享存储时消除冲突。

集中式身份验证的缺点

  1. 网络依赖性: 如果目录服务器或网络连接失败，仅依赖集中式凭据的用户可能无法登录（可通过缓存缓解，请参阅下文的 SSSD）。
  2. 复杂性: 初始设置需要专用基础设施、网络配置和专用客户端软件（如 SSSD 或 Kerberos 库）。
  3. 初始成本: 虽然 LDAP 可以是开源的，但设置和维护一个健壮的 AD 环境涉及许可和专业知识。

选择正确的策略：环境规模和需求

最佳选择很大程度上取决于您组织的规模、复杂性和安全要求。

特征 本地身份验证 (/etc/passwd) 集中式身份验证 (LDAP/AD)
环境规模 1–5 台服务器 5+ 台服务器 / 企业
管理开销 高（每台服务器维护） 低（单一控制点）
安全策略执行 难以强制执行一致性 优秀（全局策略）
离线访问 优秀 需要缓存（例如 SSSD）
初始设置难度 非常低 高

何时使用本地身份验证

本地身份验证最适合：

  • 小型实验室或个人工作站: 仅一两个受信任的个人需要访问的环境。
  • 隔离系统: 气隙机器或 IoT 设备，其中与目录服务器的网络连接不可能或不希望发生。
  • 临时跳板主机: 简短使用的系统，部署完整的目录集成堆栈过于繁琐。

何时实施集中式身份验证

集中式身份验证是必需的，适用于：

  • 企业环境: 用户需要访问多台服务器、网络共享或服务的任何环境。
  • 合规性需求: 受审计或严格合规性要求约束的环境，要求一致的访问控制和审计跟踪。
  • 大规模部署: 当用户生命周期管理（入职/离职）必须即时且自动化时。

实施集中式身份验证：关键工具

对于与 AD 或 LDAP 集成的现代 Linux 系统，sssd（System Security Services Daemon）软件包是行业标准的客户端。它取代了 nss_ldap 和 pam_ldap 等旧工具。

SSSD 的作用

SSSD 作为本地系统服务和远程目录提供商（LDAP 或 AD）之间的桥梁。其主要功能包括：

  1. 缓存: SSSD 在本地缓存身份验证数据。如果与目录服务器的连接丢失，最近登录过的用户仍可在配置的时间内本地进行身份验证，从而解决了离线访问的缺点。
  2. PAM/NSS 集成: 它与可插拔身份验证模块 (PAM) 和名称服务切换 (NSS) 无缝集成，允许标准的 Linux 命令（login、ssh）与远程帐户透明地工作。

实际示例：SSSD 配置片段（概念性）

与 Active Directory 集成通常涉及配置 SSSD 使用 Kerberos 进行身份验证，并链接到 AD 域。尽管配置文件很庞大，但核心思想是建立连接：

# /etc/sssd/sssd.conf AD 集成片段
[domain/example.com]
cache_credentials = True
ldap_search_base = dc=example,dc=com
auth_to_local = match_user

[sssd]
services = nss, pam
domain_blacklist = 169.254.169.254

用户管理最佳实践

无论您选择哪条路径，都请遵循以下最佳实践：

  • 避免使用 Root: 切勿将本地 root 帐户用于日常管理任务。请使用集中式帐户和 sudo 机制。
  • 定期审计: 如果使用本地帐户，请定期审计 /etc/passwd 和 /etc/shadow，查找未经授权或过期的条目。
  • 最小权限原则: 确保用户仅获得其角色所需的最低权限。集中式系统通过组成员身份更易于执行此策略。
  • UID 标准化: 如果您必须在集中式帐户旁边使用本地帐户，请确保本地 UID 不与为集中式用户保留的标准范围（例如 1000+）重叠。

结论

对于小型、静态的环境，本地 /etc/passwd 管理的简单性很具吸引力。然而，一旦组织需要在多台 Linux 系统之间实现一致的访问管理，通过 LDAP 或 Active Directory 进行的集中式身份验证就成为必需，而非奢侈。

通过利用 SSSD 等现代工具，管理员可以在获得目录服务的可扩展性和安全性的同时，降低完全网络故障的风险，从而为构建强大且可管理的 Linux 基础设施铺平道路。