用户管理

系统的根用户始终可以通过Linux PAM领域登录，并且是一个不受限制的管理员。这个用户不能被删除，但是属性仍然可以被修改。系统邮件将会发送到分配给该用户的电子邮件地址。

由于Linux PAM对应于主机系统用户，因此必须在每个允许用户登录的节点上存在一个系统用户。用户使用他们通常的系统密码进行认证。这个领域是默认添加的，不能被移除。在可配置性方面，管理员可以选择要求从该领域登录的双因素认证，并将该领域设置为默认的认证领域。

{pve} 认证服务器领域是一个简单的类Unix密码存储。该领域默认会被创建，与Linux PAM一样，唯一可配置的项目是要求领域的用户使用双因素认证，并将其设置为登录的默认领域。

与其他{pve}领域类型不同，用户完全通过{pve}创建和验证，而不是针对另一个系统进行验证。因此，在创建此类型的用户时，您需要为其设置密码。

您也可以使用外部LDAP服务器进行用户认证（例如，OpenLDAP）。在这种领域类型中，用户会在“基础域名”（base_dn）下被搜索，使用在“用户属性名”（user_attr）字段中指定的用户名属性。

可以配置一个服务器和一个可选的备用服务器，且连接可以通过SSL加密。此外，还可以为目录和群组配置过滤器。过滤器允许您进一步限制领域的范围。

例如，如果一个用户通过以下LDIF数据集表示：

''基础域名为`ou=People,dc=ldap-test,dc=com`，用户属性为`uid`。''

如果 {pve} 需要在能够查询和认证用户之前认证（绑定）到LDAP服务器，可以通过 /etc/pve/domains.cfg 文件中的 bind_dn 属性配置绑定域名。然后，其密码必须存储在 /etc/pve/priv/ldap/<realmname>.pw 中（例如，/etc/pve/priv/ldap/my-ldap.pw）。这个文件应该包含一个单行的原始密码。

要验证证书，你需要设置`capath`。你可以直接将其设置为你的LDAP服务器的CA证书，或者设置为包含所有受信任CA证书的系统路径(/etc/ssl/certs)。此外，你还需要设置`verify`选项，这也可以通过Web界面完成。

LDAP服务器领域的主要配置选项如下：

要将Microsoft AD设置为一个领域，需要指定服务器地址和认证域。活动目录支持大多数与LDAP相同的属性，例如可选的后备服务器、端口和SSL加密。此外，配置后，可以通过同步操作自动将用户添加到{pve}。

就像LDAP一样，如果 {pve} 需要在绑定到AD服务器之前进行认证，你必须配置 Bind User (bind_dn) 属性。这个属性通常是Microsoft AD默认要求的。

Microsoft Active Directory的主要配置设置是：

可以自动同步基于LDAP的领域（LDAP和Microsoft Active Directory）的用户和组，而不必手动将它们添加到{pve}中。您可以从网页界面的`认证`面板的添加/编辑窗口访问同步选项，或通过`pveum realm add/modify`命令访问。然后，您可以从GUI的`认证`面板执行同步操作，或使用以下命令：

用户和组被同步到集群范围的配置文件`/etc/pve/user.cfg`中。

主要的OpenID Connect配置选项包括：

你可以设置多个二次验证因素，以避免丢失智能手机或安全密钥导致你永久无法访问你的账户的情形。

除了领域强制执行的TOTP和YubiKey OTP外，还可用以下两因素认证方法：

在支持WebAuthn之前，用户可以设置U2F。现有的U2F因素仍然可以使用，但建议一旦在服务器上配置了WebAuthn，就切换到WebAuthn。

这可以通过在添加或编辑认证领域时，通过’TFA’下拉框选择一个可用的方法来完成。当一个领域启用了双因素认证（TFA）后，它变成一个要求，只有配置了双因素认证的用户才能登录。

目前有两种可用的方法：

请参考[YubiKey OTP]文档了解如何使用[YubiCloud]或者[托管您自己的验证服务器]。

第二因素的目的是在用户的密码被泄露或猜出时保护用户。然而，一些因素仍可能被蛮力破解。因此，如果第二因素登录尝试失败次数过多，用户将被锁定。

对于TOTP，8次失败的尝试将会禁用用户的TOTP因素。它们在用恢复密钥登录时被解锁。如果TOTP是唯一可用的因素，需要管理员介入，并且强烈推荐要求用户立即更改密码。

由于FIDO2/Webauthn和恢复密钥对暴力攻击的抵抗性较强，因此那里的尝试次数限制更高（100次），但是当超出限制时，所有的第二因素都会被阻止一小时。

管理员可以随时通过用户界面中的用户列表或命令行解锁用户的双因素认证：

用户可以选择通过用户列表中的“TFA”按钮，在登录时启用“TOTP”或“WebAuthn”作为第二重验证因素（除非领域强制执行“YubiKey OTP”）。

用户始终可以添加并使用一次性的“恢复密钥”。

在打开’TFA’窗口后，用户将看到一个对话框来设置’TOTP’认证。'Secret’字段包含密钥，可以通过’Randomize’按钮随机生成。可以添加一个可选的’Issuer Name’以提供信息给’TOTP’应用，说明密钥属于什么。大多数’TOTP’应用会显示发行者名称以及相应的’OTP’值。用户名也包含在’TOTP’应用的二维码中。

生成密钥后，将会显示一个二维码，该二维码可以与大多数OTP应用程序（如FreeOTP）一起使用。用户然后需要验证当前用户密码（除非作为‘root’登录），以及正确使用‘TOTP’密钥的能力，通过在‘验证码’字段中输入当前的‘OTP’值并按下‘应用’按钮来完成。

不需要任何服务器设置。只需在您的智能手机上安装一个TOTP应用程序（例如，https://freeotp.github.io/[FreeOTP]），然后使用Proxmox Backup Server网络界面添加TOTP因素即可。

为了WebAuthn能够工作，你需要有两样东西：

一旦您满足了这两个要求，您就可以在*数据中心 → 权限 → 两步验证*下的*两步验证*面板中添加一个WebAuthn配置。

恢复密钥代码不需要任何准备；你可以简单地在*数据中心 → 权限 → 两步验证*下的*两步验证*面板中创建一组恢复密钥。

要允许用户使用’WebAuthn’身份验证，必须使用一个有效的域名和有效的SSL证书，否则一些浏览器可能会发出警告或完全拒绝认证。

这是通过 /etc/pve/datacenter.cfg 完成的。例如：

要允许用户使用’U2F’验证，可能需要使用一个有效的域名和有效的SSL证书，否则，某些浏览器可能会显示警告或完全拒绝U2F的使用。最初，需要配置一个’AppId' 脚注：[AppId https://developers.yubico.com/U2F/App_ID.html]。

这是通过 /etc/pve/datacenter.cfg 完成的。例如：

对于单个节点，AppId 可以简单地是Web接口的地址，就像在浏览器中使用的那样，包括 https:// 和端口号，如上所示。请注意，某些浏览器在匹配 AppIds 时可能比其他浏览器更严格。

当使用多个节点时，最好有一个单独的 https 服务器提供一个 appid.json 文件，文件脚注为[多面应用程序: https://developers.yubico.com/U2F/App_ID.html]，因为这似乎与大多数浏览器兼容。如果所有节点使用同一顶级域名的子域名，使用TLD作为’AppId’可能就足够了。但应该注意，有些浏览器可能不接受这种做法。

要启用“U2F”身份验证，请打开“TFA”窗口的“U2F”选项卡，输入当前密码（除非以root身份登录），然后按“注册”按钮。如果服务器设置正确且浏览器接受服务器提供的“AppId”，将出现一条消息提示用户按下“U2F”设备上的按钮（如果是“YubiKey”，按钮灯应该稳定地开关切换，大约每秒两次）。

Firefox 用户可能需要在 about:config 中启用 security.webauth.u2f 之后才能使用 U2F 令牌。

角色就是一系列权限的列表。Proxmox VE附带了许多预定义的角色，这些角色能满足大多数需求。

您可以在图形用户界面中查看全部预定义的角色。

你可以通过图形用户界面或命令行添加新角色。

从图形用户界面(GUI)，导航到“数据中心(Datacenter)”下“权限 → 角色(Roles)”标签，并点击“创建(Create)”按钮。在那里，您可以设置一个角色名称，并从“权限(Privileges)”下拉菜单中选择任何所需的权限。

要通过命令行添加角色，您可以使用’pveum' CLI工具，例如：

特权是执行特定操作的权利。为了简化管理，特权列表被分组到角色中，然后可以在权限表中使用。请注意，特权不能直接分配给用户和路径，除非它们是角色的一部分。

我们目前支持以下权限：

访问权限被分配给例如虚拟机、存储或资源池等对象。我们使用类文件系统的路径来定位这些对象。这些路径形成了一个自然的树结构，而且高层级的权限（更短的路径）可以可选地在这个层次结构中向下传播。

路径可以是模板化的。当一个API调用需要对模板路径的权限时，该路径可能包含对API调用参数的引用。这些引用在大括号中指定。有些参数是隐式地从API调用的URI中取得的。例如，在调用'/nodes/mynode/status’时，权限路径`/nodes/{node}需要对/nodes/mynode`的权限，而在对`/access/acl`发起PUT请求时，路径`{path}`指的是方法的`path`参数。

一些例子包括：

资源池可以用来对一组虚拟机和数据存储进行分组。然后，你可以简单地对资源池(/pool/{poolid})设置权限，这些权限会被所有资源池成员继承。这是简化访问控制的一个好方法。

所需的API权限为每个单独的方法记录，并可在 https://pve.proxmox.com/pve-docs/api-viewer/ 找到。

权限被指定为一个列表，可以解释为逻辑和访问检查函数的树：

可能有管理员想创建一个拥有完整管理员权限的用户组（而不使用root账户）。

要做到这一点，首先定义组：

然后分配角色：

最后，你能够将用户添加到新的’admin’群组：

你可以通过给用户或群组分配`PVEAuditor`角色来赋予他们只读访问权限。

示例 1: 允许用户 joe@pve 查看所有内容

示例 2: 允许用户 joe@pve 查看所有虚拟机

如果你想要将用户管理权限委托给用户 joe@pve，你可以通过以下方式来实现：

用户 joe@pve 现在可以添加和删除用户，以及更改其他用户属性，例如密码。这是一个非常强大的角色，你很可能希望将其限制在选定的领域和群组中。以下示例允许 joe@pve 修改领域 pve 内的用户，如果他们是群组 customers 的成员的话：

API 令牌的权限始终是其对应用户权限的子集，这意味着 API 令牌不能用于执行后备用户没有权限执行的任务。本节将演示如何使用具有独立权限的 API 令牌，以进一步限制令牌所有者的权限。

给用户`joe@pve`在所有虚拟机上赋予PVEVMAdmin角色：

添加一个具有单独权限的新API令牌，该令牌只允许查看虚拟机信息（例如，用于监控目的）：

验证用户和令牌的权限：

企业通常被结构划分为几个较小的部门，通常你会希望为每个部门分配资源并委派管理任务。假设你想为软件开发部门建立一个资源池。首先，创建一个组：

现在我们创建一个新用户，该用户是那个群组的成员：

然后我们为开发部门创建一个资源池供其使用：

最后，我们可以对那个池分配权限：

我们的软件开发人员现在可以管理分配给那个池的资源了。