这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

客户端身份验证

身份验证记录及其相关方法用于定义用户/客户端应用程序必须提供哪些凭据才能访问数据库。例如，hash 身份验证方法要求用户提供密码，而 oauth 身份验证方法要求用户提供访问令牌。

客户端身份验证概述

Vertica 按照以下过程对用户进行身份验证：

  1. 如果客户端尝试以来自本地连接的 dbadmin（即与数据库位于相同的节点上）身份进行身份验证：

    • 如果 dbadmin 没有密码，Vertica 会使用 trust 方法对客户端进行身份验证。

    • 如果 dbadmin 具有密码，Vertica 会使用 hash 方法对客户端进行身份验证。

  2. 如果客户端尝试以没有密码的数据库用户身份进行身份验证，且定义的唯一身份验证记录为默认记录，则 Vertica 会使用 trust 方法对客户端进行身份验证。有关详细信息，请参阅隐式身份验证。

  3. 如果客户端尝试以具有密码和身份验证记录的用户身份进行身份验证，则 Vertica 会尝试使用该记录对客户端进行身份验证。如果某个用户或角色存在多个身份验证记录，Vertica 将选择优先级最高的记录。

  4. 如果客户端使用所选身份验证方法验证失败，且身份验证 fallthrough 已启用，Vertica 将尝试使用下一个优先级最高的身份验证方法来对客户端进行身份验证。否则，客户端将被拒绝。

  5. 除此之外，如果身份验证记录不存在，且默认身份验证记录已被删除；则所有用户（来自本地连接的 dbadmin 除外）均不能访问数据库。

身份验证管理

具有 DBADMIN 角色的用户可以执行以下身份验证任务：

1 - 默认身份验证记录

Vertica 会自动创建以下默认身份验证记录并将其授予 public 角色。这些记录具有最低的优先级 (-1)，因此用户创建的身份验证记录将优先于这些默认记录：

=> SELECT auth_name,is_auth_enabled,auth_host_type,auth_method,auth_priority,is_fallthrough_enabled FROM client_auth;
         auth_name         | is_auth_enabled | auth_host_type | auth_method | auth_priority | is_fallthrough_enabled
---------------------------+-----------------+----------------+-------------+---------------+------------------------
 default_hash_network_ipv4 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_network_ipv6 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_local        | True            | LOCAL          | PASSWORD    |            -1 | False
(3 rows)

如果未定义身份验证记录（且默认身份验证记录已被删除），则只有 dbadmin 和没有密码的用户可以访问数据库。有关详细信息，请参阅隐式身份验证。

2 - 配置客户端身份验证

您可以限制数据库用户与身份验证记录之间的连接方式。Vertica 数据库使用客户端身份验证方法确立发出连接请求的客户端的身份，并确定是否授权该客户端使用提供的凭据从其主机地址连接到 Vertica 数据库。

基本身份验证配置工作流

通常情况下，配置客户端身份验证的工作流如下所示：

  1. 创建身份验证记录。身份验证记录在创建后会自动启用。有关详细信息，请参阅创建身份验证记录。

  2. 将身份验证记录授予指定用户或角色。

要查看现有的身份验证记录，请查询系统表 CLIENT_AUTH。

用于客户端身份验证的 IPv4 和 IPv6

Vertica 支持客户端使用 IPv4 或 IPv6 协议连接到数据库服务器。数据库服务器之间的内部通信必须一致地使用一个地址系列（IPv4 或 IPv6）。但是，客户端可以从任一类型的 IP 地址连接到数据库。

如果客户端将从 IPv4 和 IPv6 进行连接，必须创建两种身份验证方法，每种方法对应一种地址。任何使用 HOST 身份验证的身份验证方法都需要 IP 地址。

例如，第一个语句允许用户从任何 Ipv4 地址连接。第二个语句允许用户从任何 IPv6 地址连接：

=> CREATE AUTHENTICATION <name> METHOD 'gss' HOST '0.0.0.0/0'; --IPv4
=> CREATE AUTHENTICATION <name> METHOD 'gss' HOST '::/0'; --IPv6

如果在 URL 中使用字面量型 Ipv6 地址，必须将 Ipv6 地址括在方括号中，如以下示例中所示：

=> ALTER AUTHENTICATION Ldap SET host='ldap://[1dfa:2bfa:3:45:5:6:7:877]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[fdfb:dbfa:0:65::177]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[fdfb::177]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[::1]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[1dfa:2bfa:3:45:5:6:7:877]:5678';

如果您使用多节点群集，(HOST, HOST TLS, HOST NO TLS) 中的任何 IP/网络掩码设置都必须匹配群集中的所有节点。此设置允许数据库所有者对群集中的每个节点进行身份验证和管理。例如，指定 10.10.0.8/30 允许 CIDR 地址范围 10.10.0.8–10.10.0.11。

有关 IPv6 地址的详细信息，请参阅 RFC 1924 和 RFC 2732。

支持的客户端身份验证方法

Vertica 支持以下客户端身份验证方法：

  • trust：用户可以使用有效的用户名（即无需密码）进行身份验证。

  • reject：拒绝连接尝试。

  • hash：用户必须提供有效的用户名和密码。有关详细信息，请参阅哈希身份验证。

  • gss：授权使用 MIT Kerberos 实现连接到 Vertica 的客户端。密钥分发中心 (KDC) 必须使用 GSS-API 支持 Kerberos 5。非 MIT Kerberos 实施必须使用 GSS-API。有关详细信息，请参阅Kerberos 身份验证。

  • ident：根据 Ident 服务器中的用户名对客户端进行身份验证。有关详细信息，请参阅Ident 身份验证。

  • ldap：使用 LDAP 或 Active Directory 服务器验证客户端及其用户名和密码。有关详细信息，请参阅LDAP 身份验证。

  • tls：对提供具有指定有效数据库用户名的通用名称 (CN) 证书的客户端进行身份验证。必须为相互模式 TLS 配置 Vertica，才能使用此方法。有关详细信息，请参阅 TLS 身份验证

  • oauth：使用访问令牌对客户端进行身份验证。有关详细信息，请参阅OAuth 2.0 身份验证。

本机和主机身份验证

您可以将客户端身份验证方法定义为：

  • 本机：与数据库进行本机连接。

  • 主机：从其他主机与数据库进行远程连接，每个主机都有自己的 IPv4 或 IPv6 地址和主机参数。有关详细信息，请参阅上面的用于客户端身份验证的 IPv4 和 IPv6。

某些身份验证方法只能指定为本机或主机，如下表中所列：

对关联的用户和角色进行身份验证

Vertica 支持创建关联的用户和角色，您可以将 ROLE2 权限授予 ROLE1。ROLE1 中的所有用户使用分配给 ROLE2 的相同身份验证。例如：

=> CREATE USER user1;
=> CREATE ROLE role1;
=> CREATE ROLE role2;
=> CREATE AUTHENTICATION h1 METHOD 'hash' LOCAL;
=> GRANT AUTHENTICATION h1 to role2;
=> GRANT role2 to role1;
=> GRANT role1 to user1;

上面示例中的用户和角色关联可以表示为以下方式：

auth1 -> role2 -> role1 -> user1

在此示例中，由于 role2 权限已授予 role1，您仅需要对 role2 授予身份验证，这样就可以对 role1 启用。

3 - Fallthrough 身份验证

通常情况下，如果用户使用所选的第一个身份验证记录验证失败，该用户将被拒绝。但是，可以指定某些身份验证方法在失败时“贯穿”到优先级较低的身份验证记录。当使用多个 LDAP 搜索属性时，这可能很有用。

对于新记录，默认情况下禁用身份验证 fallthrough。

身份验证方法兼容性

下表显示了每种身份验证方法与 fallthrough 身份验证的兼容性。值“yes”表示列中的方法可以贯穿并验证其贯穿到的行方法。值“no”表示您无法贯穿到该方法，且身份验证将结束。

值“-”（破折号）表示虽然可以贯穿，但其没有实际意义。例如，一个 hash 身份验证记录可以贯穿到另一个 hash 身份验证记录，但身份验证始终会失败，因为您无法贯穿到正确的密码：

例如，假设将以下启用了 fallthrough 的身份验证记录授予用户 Bob：

=> CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0' FALLTHROUGH;

此外，Bob 具有 public 角色，因此具有默认身份验证记录：

=> SELECT auth_name,is_auth_enabled,auth_host_type,auth_method,auth_priority,is_fallthrough_enabled FROM client_auth;
         auth_name         | is_auth_enabled | auth_host_type | auth_method | auth_priority | is_fallthrough_enabled
---------------------------+-----------------+----------------+-------------+---------------+------------------------
 default_hash_network_ipv4 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_network_ipv6 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_local        | True            | LOCAL          | PASSWORD    |            -1 | False
(3 rows)

如果从远程地址发起连接的 Bob 使用 v_tls_auth 验证失败，Vertica 会尝试使用下一个（按优先级顺序）身份验证记录 default_hash_network_ipv4 对其进行身份验证。

记录身份验证失败

只有当所有授予的身份验证记录都失败，导致用户被拒绝时，才会记录登录失败。只会记录最后一个失败。

例如，假设一个用户被授予 tls 和 password 两个身份验证记录，并且 tls 记录可以贯穿到 password 记录。

如果用户使用 tls 记录和 password 记录均验证失败，则只会在 LOGIN_FAILURES 中记录 password 失败。

但是，如果用户使用 tls 记录验证失败，但使用 password 记录验证成功，则不会在 LOGIN_FAILURES 中记录失败。因为用户在记录链的末尾没有被拒绝。

示例

要在新的身份验证记录上启用 fallthrough，请使用 CREATE AUTHENTICATION：

=> CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0' FALLTHROUGH;

要在现有身份验证记录上切换 fallthrough，请使用 ALTER AUTHENTICATION：

=> ALTER AUTHENTICATION v_tls_auth NO FALLTHROUGH; -- disable
=> ALTER AUTHENTICATION v_tls_auth FALLTHROUGH; -- enable

4 - 隐式身份验证

Vertica 为 dbadmin 和没有密码的用户保留隐式的（即不反映在 CLIENT_AUTH 系统表中）身份验证记录。这些记录不能删除。

对于 dbadmin 用户：

  • 如果满足以下所有条件，则使用 trust 方法：

    • dbadmin 没有密码。

    • 连接是本地的（即来自 Vertica 节点）。

  • 如果满足以下所有条件，则使用 hash 方法：

    • dbadmin 具有密码。

    • 连接是本地的（即来自 Vertica 节点）。

对于非 dbadmin 用户，如果满足以下所有条件，则使用 trust 方法：

  • 用户没有密码。

  • 未启用自定义（即非默认）身份验证方法。

5 - Dbadmin 身份验证访问

Dbadmin 用户必须随时可访问数据库。Vertica 自动确保客户端可以以来自本地连接的 dbadmin 身份进行身份验证。

如果您需要以来自远程连接的 dbadmin 身份进行身份验证，则 dbadmin 必须具有密码。您可以使用以下方法：

  • 使用 fallthrough 身份验证。

  • 创建特定于 dbadmin 的自定义身份验证方法。

通过本地连接进行身份验证

您始终可以以来自本地连接的 dbadmin 身份隐式进行身份验证。这些特定于 dbadmin 的身份验证记录是隐式记录，因此它们不会列在 CLIENT_AUTH 系统表中，也不能删除。

如果 dbadmin 用户没有密码，Vertica 会使用 trust 方法对其进行身份验证。否则，Vertica 会使用 password 方法对其进行身份验证。

在此示例中，dbadmin 没有密码并通过本地连接连接到 Vertica：

=> SELECT authentication_method, client_authentication_name FROM vs_sessions;
 authentication_method | client_authentication_name
-----------------------+----------------------------
 ImpTrust              | default: Implicit Trust

通过远程连接进行身份验证

Fallthrough 身份验证

Vertica 自动创建以下身份验证记录并将其授予 public 角色（有关详细信息，请参阅客户端身份验证）：

=> SELECT auth_name,is_auth_enabled,auth_host_type,auth_method,auth_priority,is_fallthrough_enabled FROM client_auth;
         auth_name         | is_auth_enabled | auth_host_type | auth_method | auth_priority | is_fallthrough_enabled
---------------------------+-----------------+----------------+-------------+---------------+------------------------
 default_hash_network_ipv4 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_network_ipv6 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_local        | True            | LOCAL          | PASSWORD    |            -1 | False
(3 rows)

这些默认身份验证记录确保所有具有 public 角色的用户（包括 dbadmin）都可以访问数据库，前提是任何自定义身份验证记录都设置为贯穿（默认情况下禁用）到默认记录。

例如，下面的 ldap 身份验证启用了 fallthrough，因此如果 LDAP 服务器关闭，用户仍然可以使用 password 身份验证（由默认记录定义）进行身份验证。

=> CREATE AUTHENTICATION ldap1 METHOD 'ldap' LOCAL FALLTHROUGH;
=> ALTER AUTHENTICATION ldap1 SET host='ldap://localhost:5389',
    binddn='cn=Manager,dc=example,dc=com',
    bind_password='password',
    basedn='ou=dev,dc=example,dc=com',
    search_attribute='cn';

自定义身份验证记录

特定于 dbadmin 的身份验证记录应：

  • 使用 hash 身份验证方法（以便身份验证不依赖于某些外部服务）。

  • 具有较高的优先级（例如 10,000），以便它可以优先于所有其他身份验证记录。

以下示例创建了一个身份验证记录 v_dbadmin_hash 并将其授予 dbadmin 用户。hash 方法表示 dbadmin 在登录时必须提供密码。HOST '0.0.0.0/0' 访问方法表示 dbadmin 可以从任何 IPv4 地址进行远程连接：

=> CREATE AUTHENTICATION v_dbadmin_hash METHOD 'hash' HOST '0.0.0.0/0';
=> ALTER AUTHENTICATION v_dbadmin_hash PRIORITY 10000;
=> GRANT AUTHENTICATION v_dbadmin_hash TO dbadmin;

如果您想以来自本地连接的 dbadmin 身份进行身份验证，但想使用具有 HOST 访问方法的身份验证记录，请指定包含数据库主机名或 IP 地址的 --host 选项：

$ vsql database_name user --host hostname_or_ip;

6 - 创建身份验证记录

您可以使用 vsql 管理客户端身份验证记录。您必须以超级用户身份连接到数据库。

  1. 创建身份验证记录，并指定：

    • 身份验证记录的名称。

    • 身份验证方法，为以下之一：

      • trust：用户可以使用有效的用户名（即无需密码）进行身份验证。

      • reject：拒绝连接尝试。

      • hash：用户必须提供有效的用户名和密码。有关详细信息，请参阅哈希身份验证。

      • gss：授权使用 MIT Kerberos 实现连接到 Vertica 的客户端。密钥分发中心 (KDC) 必须使用 GSS-API 支持 Kerberos 5。非 MIT Kerberos 实施必须使用 GSS-API。有关详细信息，请参阅Kerberos 身份验证。

      • ident：根据 Ident 服务器中的用户名对客户端进行身份验证。有关详细信息，请参阅Ident 身份验证。

      • ldap：使用 LDAP 或 Active Directory 服务器验证客户端及其用户名和密码。有关详细信息，请参阅LDAP 身份验证。

      • tls：对提供具有指定有效数据库用户名的通用名称 (CN) 证书的客户端进行身份验证。必须为相互模式 TLS 配置 Vertica，才能使用此方法。有关详细信息，请参阅 TLS 身份验证

      • oauth：使用访问令牌对客户端进行身份验证。有关详细信息，请参阅OAuth 2.0 身份验证。

    • 访问方法，为以下之一，这些方法用于指定允许的连接类型：

      • LOCAL：对尝试从数据库运行所在的相同节点进行连接的用户或应用程序进行身份验证。

      • HOST：对尝试从 IPv4 或 IPv6 地址不同于数据库的节点进行连接的用户或应用程序进行身份验证。您可以使用 TLS 或 NO TLS 分别指定加密连接或明文连接。

    • 是否启用 Fallthrough 身份验证（默认情况下禁用）。

  2. 将身份验证记录授予用户或角色。

示例

以下示例显示了如何创建身份验证记录。

创建身份验证方法 localpwd，以便对尝试使用密码从本地主机登录的用户进行身份验证：

=> CREATE AUTHENTICATION localpwd METHOD 'hash' LOCAL;

创建身份验证方法 v_ldap，以便使用 LDAP over TLS 对从 IPv4 地址为 10.0.0.0/23 的主机登录的用户进行身份验证：

=> CREATE AUTHENTICATION v_ldap METHOD 'ldap' HOST TLS '10.0.0.0/23';

创建身份验证方法 v_kerberos，以便对尝试从网络 2001:0db8:0001:12xx 中的任何主机进行连接的用户进行身份验证：

=> CREATE AUTHENTICATION v_kerberos METHOD 'gss' HOST '2001:db8:1::1200/56';

以下 身份验证记录v_oauth 使用 OAuth 令牌（而不是用户名和密码）对来自任何 IP 地址的用户进行身份验证，并且使用以下参数。身份提供者是 Keycloak 18.0.0：

  • client_id：机密客户端 vertica 在 Keycloak 中注册。

  • client_secret：客户端密钥，由 Keycloak 生成。

  • discovery_url：也称为 OpenID 提供者配置文档，这是包含有关身份提供者的配置和端点的信息的端点。

=> CREATE AUTHENTICATION v_oauth METHOD 'oauth' HOST '0.0.0.0/0'
=> ALTER AUTHENTICATION v_oauth SET client_id = 'vertica';
=> ALTER AUTHENTICATION v_oauth SET client_secret = 'client_secret';
=> ALTER AUTHENTICATION v_oauth SET discovery_url = 'https://203.0.113.1:8443/realms/myrealm/.well-known/openid-configuration';
=> ALTER AUTHENTICATION v_oauth SET introspect_url = 'https://203.0.113.1:8443/realms/myrealm/protocol/openid-connect/token/introspect';

例如，要拒绝所有纯文本的客户端连接，按如下所示指定 reject 身份验证方法和 HOST NO TLS 访问方法：

=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '0.0.0.0/0';  --IPv4
=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '::/0';       --IPv6

另请参阅

7 - 修改身份验证记录

若要修改现有身份验证记录，您必须首先连接到数据库。以下示例显示了如何对身份验证记录进行更改。有关详细信息，请参阅ALTER AUTHENTICATION。

重命名身份验证记录

将 v_kerberos 身份验证方法重命名为 K5 并启用。所有与 v_kerberos 身份验证方法关联的用户现在都与授予的 K5 方法关联。

=> ALTER AUTHENTICATION v_kerberos RENAME TO K5 ENABLE;

指定身份验证方法的优先级

对 K5 身份验证指定优先级 10：

=> ALTER AUTHENTICATION K5 PRIORITY 10;

有关详细信息，请参阅身份验证记录优先级。

更改参数

将 system_users 身份验证的 ident1 参数设置为 root：

=> CREATE AUTHENTICATION ident1 METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION ident1 SET system_users='root';

更改 IP 地址并为名为 Ldap1 的 LDAP 身份验证方法指定参数。

在此示例中，为 LDAP 服务器指定绑定参数。Vertica 将连接到对 Vertica 客户端进行身份验证的 LDAP 服务器。如果身份验证成功，Vertica 将在指定 LDAP 服务器上对授予了 Ldap1 身份验证方法的任何用户进行身份验证：

=> CREATE AUTHENTICATION Ldap1 METHOD 'ldap' HOST '172.16.65.196';

=> ALTER AUTHENTICATION Ldap1 SET host='ldap://172.16.65.177',
   binddn_prefix='cn=', binddn_suffix=',dc=qa_domain,dc=com';

更改 IP 地址，并为名为 Ldap1 的 LDAP 身份验证方法指定参数。假设 Vertica 没有足够的信息为尝试进行身份验证的用户创建可分辨名称 (DN)。因此，在这种情况下，必须指定使用 LDAP 搜索和捆绑：

=> CREATE AUTHENTICATION LDAP1 METHOD 'ldap' HOST '172.16.65.196';

=> ALTER AUTHENTICATION Ldap1 SET host='ldap://172.16.65.177',
basedn='dc=qa_domain,dc=com',binddn='cn=Manager,dc=qa_domain,
dc=com',search_attribute='cn',bind_password='secret';

更改关联方法

将 localpwd 身份验证从信任更改为哈希：

=> CREATE AUTHENTICATION localpwd METHOD 'trust' LOCAL;
=> ALTER AUTHENTICATION localpwd METHOD 'hash';

ALTER AUTHENTICATION 可以验证您输入的参数。如果出现错误，会禁用您尝试修改的身份验证方法。

使用管理工具

使用管理工具 (Administration Tools) 的优势为：

  • 您无需连接到数据库。

  • 编辑器会验证记录的格式正确。

  • 编辑器会维护记录，以便于您在稍后编辑。

有关使用管理工具创建和编辑身份验证记录的信息，请参阅创建身份验证记录。

删除身份验证记录

若要删除身份验证记录，请使用 DROP AUTHENTICATION。若要使用此方法，必须连接到数据库。

若要删除 md5_auth 的身份验证记录，请使用以下命令：

=> DROP AUTHENTICATION md5_auth;

若要删除一个已授予用户的方法的身份验证记录，请使用 CASCADE 关键字：

=> CREATE AUTHENTICATION localpwd METHOD 'password' LOCAL;
=> GRANT AUTHENTICATION localpwd TO jsmith;
=> DROP AUTHENTICATION localpwd CASCADE;

另请参阅

8 - 身份验证记录优先级

每个身份验证记录都分配了优先级。如果用户获授多个身份验证记录，Vertica 会尝试使用优先级最高的身份验证记录对用户进行身份验证，并在身份验证失败时拒绝该用户。

如果启用身份验证 fallthrough（默认情况下禁用），当所选身份验证记录失败时，Vertica 将尝试使用下一个优先级最高的记录对用户进行身份验证。有关 fallthrough 身份验证的详细信息，请参阅 Fallthrough 身份验证。

确定身份验证优先级

以下因素会影响身份验证记录的优先级，如 CLIENT_AUTH 系统表中所示：

=> SELECT auth_name, auth_method, auth_priority, method_priority, address_priority FROM client_auth;
   auth_name   | auth_method | auth_priority | method_priority | address_priority
---------------+-------------+---------------+-----------------+------------------
 ldap_auth     | LDAP        |             5 |               5 |               96
 hash_auth     | HASH        |             5 |               2 |              126
 tls_auth      | TLS         |             0 |               5 |               96
 oauth_auth    | OAUTH       |             0 |               5 |               96
 gss_auth      | GSS         |             0 |               5 |               96
 trust_auth    | TRUST       |             0 |               0 |               96
 reject_auth   | REJECT      |             0 |              10 |               96
(7 rows)

优先级按层级划分并按重要性顺序列出；如果在某个优先级层级上的优先级相同，Vertica 会检查下一个优先级层级。例如，如果用户同时拥有 ldap 和 hash 身份验证记录，且 auth_priority 均为 5，Vertica 将尝试使用 ldap 身份验证记录，因为其 method_priority 值更大：

  1. auth_priority：使用 ALTER AUTHENTICATION 显式设置的优先级（默认值：0）。

  2. method_priority：特定于身份验证方法的优先级。这些优先级如下所示：

    • trust：0

    • hash：2

    • ldap：5

    • tls：5

    • oauth：5

    • gss：5

    • reject：10

  3. address_priority： HOST [ TLS | NO TLS ] 'host-ip-address' 中指定的 IP 地址的优先级。此优先级由地址的网络掩码大小决定；0 越少表示越具体，因此优先级越高。LOCAL 具有最低的优先级：0。

设置身份验证优先级

要设置身份验证优先级：

=> ALTER AUTHENTICATION authentication_name PRIORITY value;

另请参阅

9 - 查看有关客户端身份验证记录的信息

有关您为数据库配置的客户端身份验证记录的信息，请查询 V_CATALOG 架构中的以下系统表：

要确定用于特定用户会话的客户端身份验证背后的详细信息，请查询 V_MONITOR 架构中的以下表：

10 - 启用和禁用身份验证方法

在创建身份验证方法后，Vertica 会将其存储在编录中并自动启用该方法。要启用或禁用身份验证方法，请使用 ALTER AUTHENTICATION 语句。要使用这一方法，必须连接至数据库。

如果身份验证方法尚未启用，Vertica 则无法用它来对试图连接数据库的用户和客户端进行身份验证。

要启用身份验证方法：

ALTER AUTHENTICATION v_kerberos ENABLE;

要禁用此身份验证方法：

ALTER AUTHENTICATION v_kerberos DISABLE;

另请参阅

11 - 授予和撤销身份验证方法

在 Vertica 能够通过某一身份验证方法验证某一用户或客户之前，您必须首先使用 GRANT（身份验证） 将身份验证方法与需要使用该方法的用户或角色进行关联。当该用户或角色不再需要使用该方法连接到 Vertica 时，您可以使用 REVOKE AUTHENTICATION 取消该身份验证方法与用户的关联。

授予身份验证方法

您可以将身份验证方法授予特定用户或角色。您也可以通过向 PUBLIC 授予某一身份验证方法来指定默认身份验证方法，如以下示例中所示。

  • 将 v_ldap 身份验证与用户 jsmith 关联：

    => GRANT AUTHENTICATION v_ldap TO jsmith;

  • 将 v_gss 身份验证与角色 DBprogrammer 关联：

    
=> CREATE ROLE DBprogrammer;
=> GRANT AUTHENTICATION v_gss TO DBprogrammer;

  • 将客户端身份验证方法 v_localpwd 与角色 PUBLIC 关联，默认情况下会被分配给所有用户：

    => GRANT AUTHENTICATION v_localpwd TO PUBLIC;

撤销身份验证方法

如果您不想再使用指定的身份验证方法对用户或客户进行身份验证，请使用以下示例中的 REVOKE（身份验证） 语句。

  • 从用户 jsmith 撤销 v_ldap 身份验证：

    => REVOKE AUTHENTICATION v_ldap FROM jsmith;

  • 从角色 DBprogrammer 撤销 v_gss 身份验证：

    => REVOKE AUTHENTICATION v_gss FROM DBprogrammer;

  • 撤销 localpwd 作为默认客户端身份验证方法：

    => REVOKE AUTHENTICATION localpwd FROM PUBLIC;

12 - 隐藏数据库用户名

如果要对发起连接的客户端的某些数据库用户名进行保密，且您的身份验证记录不使用 Fallthrough 身份验证，则这两个用户组必须共享相同的身份验证方法（不一定是相同的身份验证记录）：

  • 用户名必须保密的用户。

  • 具有 PUBLIC 角色的用户。

如果您的身份验证记录使用 fallthrough，则对于私密用户和 PUBLIC 角色，请确保身份验证链中提示输入密码的第一个身份验证方法相同。以下方法将提示输入密码：

满足此条件的一种简单方法是使用相同的方法为两个组复制 fallthrough 链。例如，对于私密用户和 PUBLIC 角色，有效的身份验证链均为 tls > ldap。

对于私密用户，另一个有效的配置将为 tls > ldap > hash，而对于 PUBLIC，则为 ldap。

13 - 哈希身份验证

hash 身份验证方法使用密码对用户进行身份验证。

通常，您应该更喜欢其他身份验证方法而不是 hash。

13.1 - 密码哈希算法

Vertica 不存储 hash 身份验证方法的用户密码。相反，Vertica 存储密码的哈希值。哈希算法由两个参数决定：

  • 系统级别配置参数 SecurityAlgorithm：

    => ALTER DATABASE DEFAULT SET PARAMETER SecurityAlgorithm = 'hashing_algorithm';

  • 用户级别参数 SECURITY_ALGORITHM：

    => ALTER USER username SECURITY_ALGORITHM 'hashing_algorithm' IDENTIFIED BY 'new_password';

系统级别参数 SecurityAlgorithm 可以具有以下值：

  • SHA512 （默认值）

  • MD5

用户级别参数 SECURITY_ALGORITHM 可以具有以下值。非 NONE 值将优于系统级别参数：

  • NONE （默认使用通过系统级别参数 SecurityAlgorithm 指定的算法）

  • SHA512

  • MD5

用户的 EFFECTIVE_SECURITY_ALGORITHM 由系统级别参数和用户级别参数两者决定。如果将用户级别参数设置为 NONE，则系统级别参数的算法将作为有效的安全算法。您可以通过将用户级别参数设置为非 NONE 值来覆盖特定用户的系统级别参数。

您可以通过查询系统表 PASSWORD_AUDITOR 查看这些参数及其对每个用户的影响。

下表显示了系统级别参数和用户级别参数的各种组合以及每种组合的有效安全算法。

FIPS 模式将有效的安全算法强制设置为 SHA-512。

13.2 - 配置哈希身份验证

hash 身份验证方法允许用户使用密码进行身份验证。

Vertica 将存储密码的哈希值（默认为 SHA-512），而不是密码本身。有关详细信息，请参阅密码哈希算法。

  1. 使用 hash 方法创建身份验证记录。身份验证记录在创建后会自动启用。例如，要为从 IP 地址 192.0.2.0/24 登录的用户创建身份验证记录 v_hash：

    => CREATE AUTHENTICATION v_hash METHOD 'hash' HOST '192.0.2.0/24';

  2. 使用 GRANT 语句将 v_hash 身份验证方法与所需的用户或角色关联：

    => GRANT AUTHENTICATION v_hash to user1, user2, ...;

13.3 - 密码

向用户分配密码以允许用户使用密码保护连接至数据库。用户提供正确的密码后，将出现到数据库的连接。

Vertica 根据每个用户的 EFFECTIVE_SECURITY_ALGORITHM 对密码进行哈希处理。但是，经过哈希处理的密码采用明文形式从客户端传输到 Vertica。这样，“中间人”攻击可能会截取来自客户端的明文密码。

配置 哈希身份验证 可确保使用密码进行安全登录。

关于密码创建和修改

您必须是 超级用户才能使用 CREATE USER 语句为用户帐户创建密码。超级用户可以设置任何用户账户的密码。

  • 使用 ALTER USER 语句添加密码。

  • 要更改密码，请使用 ALTER USER 或 vsql 元命令 \password。

用户也可更改自己的密码。

要更加高效地进行密码身份验证，Vertica 建议执行密码策略以控制强制用户更改密码的频率以及密码所要求的内容。使用 配置文件.设置这些策略。

默认密码身份验证

当未指定任何身份验证方法时，Vertica 默认为具有密码的用户帐户使用密码身份验证。

如果创建身份验证方法（即使是为远程主机），密码身份验证将禁用。这种情况下，必须显式弃用密码身份验证。下列命令可创建 local_pwd 身份验证方法并设置为所有用户的默认方法。创建身份验证方法时，Vertica 会自动启用该方法：

=> CREATE AUTHENTICATION local_pwd METHOD hash' LOCAL;
=> GRANT AUTHENTICATION local_pwd To Public;

13.3.1 - 配置文件

您可以通过为用户分配配置文件来为其设置密码策略。您可以创建多个配置文件来管理多个类别用户的密码策略。例如，您可以为交互用户创建一个要求经常更改密码的配置文件，为用户帐户创建另一个从不要求更改密码的配置文件。

定义配置文件

您可以使用 CREATE PROFILE 创建配置文件，并使用 ALTER PROFILE 更改现有配置文件。这两个语句都允许您设置一个或多个配置文件参数，这些参数用于控制密码的最短有效期限、密码复杂性和密码重置规则等。

每个配置文件都可以指定以下一项或多项策略。

  • 用户必须更换密码的频率

  • 密码自设置到重置之前必须经过的时间

  • 在使用旧密码前用户必须更户密码的次数

  • 在帐户锁定之前，用户可登录失败的次数

  • 密码要求的长度和内容：

    • 最大和最小字符数

    • 密码中大写字母、小写字母、数字以及符号的最小数量

    • 新密码必须与旧密码不同的字符数

分配配置文件

定义配置文件后，您可以分别使用 CREATE USER 和 ALTER USER 将其分配给新用户和现有用户。

密码内容的配置文件策略（例如，PASSWORD_MAX_LENGTH 和 PASSWORD_MIN_SYMBOLS）的更改仅在用户更改密码时才会影响用户。Vertica 不会测试现有密码来验证其是否符合新的密码要求。要强制使其立即符合新的配置文件要求，请使用 ALTER USER...PASSWORD EXPIRE 立即终止当前用户的密码。用户下次登录时，Vertica 会提示他们提供新密码，该密码必须符合当前策略。

默认配置文件

每个数据库均包含一个 DEFAULT 配置文件。Vertica 将默认配置文件分配给未显式分配配置文件的用户。在以下两种情况下，默认配置文件还会设置非默认配置文件的参数：

  • 配置文件参数未通过 CREATE PROFILE 显式设置

  • 参数的 ALTER PROFILE 设置为 DEFAULT

默认配置文件中的所有参数最初都设置为 unlimited。您可以使用 ALTER PROFILE 来更改这些设置。例如，以下语句将修改默认配置文件参数 PASSWORD_MIN_SYMBOLS。此更改要求密码至少包含一个符号，例如 $、#、@。此更改会影响 PASSWORD_MIN_SYMBOLS 设置为 default 的所有配置文件：

ALTER PROFILE DEFAULT LIMIT PASSWORD_MIN_SYMBOLS 1;

配置文件设置和客户端身份验证

以下配置文件设置会影响客户端身份验证方法，例如 LDAP 或 GSS：

  • FAILED_LOGIN_ATTEMPTS

  • PASSWORD_LOCK_TIME

所有其他配置文件设置仅供 Vertica 用于管理其密码。

另请参阅

13.3.2 - 密码指导原则

为使密码发挥其有效性，必须使用强密码。密码应防范：

  • 字典样式，以防被暴力破解攻击

  • 掌握密码持有人相关信息的人（姓名、生日等）

使用 配置文件 来强制执行强密码策略（密码长度和所需的内容）确保数据库用户了解密码指导原则，并鼓励其不再密码中使用个人信息。

有关创建强密码的指导原则，请访问微软对创建强密码的一些提示。

另请参阅

13.3.3 - 密码过期

以下 PROFILE 参数用于控制密码过期、新密码和最短有效期限的条件：

  • PASSWORD_LIFE_TIME - 密码保持有效的天数

  • PASSWORD_MIN_LIFE_TIME - 密码自设置到更改之前必须经过的天数

  • PASSWORD_GRACE_TIME - 密码过期后可以继续使用的天数

  • PASSWORD_REUSE_MAX - 在重新使用较早的密码之前必须更改密码的次数

  • PASSWORD_REUSE_TIME - 从设置完密码后到可以重复使用该密码之前必须经过的天数

  • PASSWORD_MIN_CHAR_CHANGE - 必须与以前的密码不同的最小字符数

有关这些参数和其他参数的更多详细信息，请参阅 CREATE PROFILE 和 ALTER PROFILE。

密码过期和宽限期行为

配置文件参数 PASSWORD_LIFE_TIME 控制密码的有效期限（以天为单位）。默认情况下，DEFAULT 配置文件将 PASSWORD_LIFE_TIME 设置为 UNLIMITED，这会禁用密码过期。您可以使用 ALTER PROFILE 更改默认配置文件和自定义配置文件。

通常情况下，当密码过期后，Vertica 会强制用户在下次登录时更改密码。但是，您可以设置 PASSWORD_GRACE_TIME 以允许用户在密码过期后继续使用该密码登录。如果用户在宽限期内登录，Vertica 会警告用户其密码已过期。此宽限期结束后，Vertica 将发出标准提示，提示用户更改用户密码。

终止密码

可以使用 ALTER USER 语句的 PASSWORD EXPIRE 参数来立即终止密码。通过终止密码，可以：

  • 强制用户遵守密码更改策略。

  • 当用户忘记了旧密码时，要设置新密码。

13.3.4 - 帐户锁定

在配置文件中，您可以设置密码策略，确定在锁定用户帐户之前允许的连续失败登录尝试次数。该锁定机制有助于阻止通过字典式强力攻击尝试来猜测用户密码的行为。

设置帐户锁定

使用 FAILED_LOGIN_ATTEMPTS 参数（CREATE PROFILE 或 ALTER PROFILE 语句）设置该值。

如果用户帐户登录尝试连续失败次数超过 FAILED_LOGIN_ATTEMPTS 设置的值，则 Vertica 将锁定该帐户。即使用户提供正确的密码，也无法登录锁定的帐户。

解锁锁定的帐户

您可以通过以下两种方式之一解锁帐户，具体取决于您的权限。

  • 手动：如果您是 超级用户，则可以使用 ALTER USER 命令手动解锁帐户。

  • 密码锁定时间设置： PASSWORD_LOCK_TIME 指定在指定的登录尝试失败次数（可使用 FAILED_LOGIN_ATTEMPTS 进行配置）后将帐户锁定的天数（单位可使用 PasswordLockTimeUnit 进行配置）。经过指定的天数后，Vertica 将自动解锁帐户。

    如果将此参数设置为 UNLIMITED，则该用户的帐户永远不会自动解锁，必须由超级用户手动解锁。

14 - Ident 身份验证

RFC 1413 中定义的 Ident 协议使用系统用户名对数据库用户进行身份验证。要查看该系统用户是否可以在不指定密码的情况下登录，您需要将 Vertica 客户端身份验证配置为查询 Ident 服务器。借助此功能，DBADMIN 用户可以运行自动化脚本以在 Vertica 服务器上执行任务。

按照以下主题中的说明为您的数据库安装、设置和配置 Ident 身份验证：

示例

以下示例显示了配置 Ident 身份验证的几种方法。

允许 system_user1 以 Vertica vuser1 的身份连接到数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1';
=> GRANT AUTHENTICATION v_ident to vuser1;
=> ALTER AUTHENTICATION v_ident ENABLE;

允许 system_user1、system_user2 和 system_user3 以 vuser1 的身份连接到数据库。使用冒号 (:) 分隔用户名：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1:system_user2:system_user3';
=> GRANT AUTHENTICATION v_ident TO vuser1;
=> ALTER AUTHENTICATION v_ident ENABLE;

使用 GRANT AUTHENTICATION 语句将身份验证与 Public 相关联。用户 system_user1、system_user2 和 system_user3 现在可以以任意数据库用户身份连接到数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1:system_user2:system_user3';
=> GRANT AUTHENTICATION v_ident to Public;
=> ALTER AUTHENTICATION v_ident ENABLE;

将 system_users 参数设置为 *，以允许任何系统用户以 vuser1 的身份连接到数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='*';
=> GRANT AUTHENTICATION v_ident TO vuser1;
=> ALTER AUTHENTICATION v_ident ENABLE;

使用 GRANT 语句，将 v_ident 身份验证与 Public 相关联，以允许 system_user1 以任意数据库用户身份登录数据库：

=> CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;
=> ALTER AUTHENTICATION v_ident SET system_users='system_user1';
=> GRANT AUTHENTICATION v_ident to Public;
=> ALTER AUTHENTICATION v_ident ENABLE;

14.1 - 安装和设置 Ident 服务器

若要使用 Ident 身份验证，您必须安装一个或多个包，具体取决于您的操作系统，并在 Vertica 服务器上启用 Ident 服务器。oidentd是兼容 Vertica 并符合 RFC 1413 标准的 Ident 守护程序。

要安装和配置 Ident 身份验证以用于 Vertica 数据库，请按照适用于您的操作系统的相应步骤进行操作。

Red hat 7.x/CentOS 7.x

通过安装 authd 和 xinetd 包，在 Red Hat 7.x 或 CentOS 7.x 上安装 Ident 服务器：

$ yum install authd
$ yum install xinetd

Ubuntu/debian

通过运行此命令，在 Ubuntu 或 Debian 上安装 oidentd：

$ sudo apt-get install oidentd

SUSE Linux Enterprise Server

从以下位置安装 pidentd 和 xinetd RPM：

ubuntu/debian 的安装后步骤

在 Ubuntu/Debian 系统上安装 oidentd 后，请继续执行以下步骤：

  1. 验证 Ident 服务器接受 IPv6 地址，以防止身份验证失败。若要执行此操作，必须启用此功能。在脚本 /etc/init.d/oidentd 中，更改行：

    exec="/usr/sbin/oidentd"

    到

    exec="/usr/sbin/oidentd -a ::"

    然后，在 Linux 提示中，使用 oidentd 启动 -a ::。

  2. 使用以下命令重新启动服务器：

    $ /etc/init.d/oidentd restart

Red Hat 7.x/CentOS 7.x 和 SUSE Linux Enterprise Server 的安装后步骤

在 Red Hat 7.x/CentOS 7.x 或 SUSE Linux Enterprise Server 系统上安装所需的包之后，继续执行以下步骤：

  1. 通过在配置文件 /etc/xinetd.d/auth 中设置 disable = no 来启用 auth 服务。如果此文件不存在，请创建该文件。以下是一个示例配置文件：

    service auth
{
        disable = no
        socket_type = stream
        wait = no
        user = ident
        cps = 4096 10
        instances = UNLIMITED
        server = /usr/sbin/in.authd
        server_args = -t60 --xerror --os
}

  2. 使用以下命令重新启动 xinetd 服务：

    $ service xinetd restart

14.2 - 为数据库用户配置 Ident 身份验证

要配置 Ident 身份验证，请执行以下步骤：

  1. 创建使用 Ident 的身份验证方法。

    Ident 服务器必须和您的数据库安装在相同的计算机上，所以请指定关键字 LOCAL。Vertica 要求 Ident 服务器和数据库始终与您的数据库位于相同的计算机上。

    => CREATE AUTHENTICATION v_ident METHOD 'ident' LOCAL;

  2. 设置 Ident 身份验证参数，指定允许连接到您的数据库的系统用户。

    => ALTER AUTHENTICATION v_ident SET system_users='user1:user2:user3';

  3. 将身份验证方法与 Vertica 用户相关联。使用 GRANT 语句，允许系统用户 user1 使用 Ident 身份验证登录：

    => GRANT AUTHENTICATION v_ident TO user1;

15 - Kerberos 身份验证

Kerberos 身份验证使用以下组件来执行用户身份验证。

客户端程序包

Kerberos 5 客户端程序包用于与 KDC 服务器进行通信。此软件包并不作为 Vertica Analytics Platform 安装的一部分包含在内。Kerberos 软件内置在 Microsoft Windows 中。如果使用的是其他操作系统，必须获取并安装该客户端软件包。

如果您的系统上还没有 Kerberos 5 客户端程序包，请从 MIT Kerberos 分发页面下载。在 Kerberos 身份验证中使用的每个 Vertica 服务器和客户端上安装此程序包，KDC 本身除外。

有关安装说明，请参阅 Kerberos 文档。

服务主体

服务主体由主机名、服务名称和分配了一组凭据的领域组成 (service/hostname@REALM)。这些凭据会连接到服务，即您通过网络连接并使用 KDC 进行身份验证的主机。

要创建领域名，请参阅指定 KDC 信息并配置领域。主机名必须与操作系统提供的值匹配。通常，它是一个完全限定主机名。如果主体的主机名部分与操作系统提供的值不匹配，Kerberos 身份验证会失败。

有些系统使用主机文件（/etc/hosts 或 /etc/hostnames）来定义主机名。主机文件可以为一个主机定义多个名称。操作系统提供了第一个条目，因此，请在主体中使用此条目。例如，如果主机文件包含：

192.168.1.101 v_vmart_node0001.example.com v_vmart_node0001

则将 v_vmart_node0001.example.com 作为主机名值。

将以下内容配置为 Kerberos 主体：

  • 每一个客户端（连接到 Vertica 的用户或应用程序）

  • Vertica 服务器

有关详细信息，请参阅以下主题：

Keytab 文件

主体存储在加密 Keytab 文件中。Keytab 文件包含 Vertica 主体的凭据。它有助于 Vertica 服务器向 KDC 验证自身身份。您需要使用 Keytab，这样 Vertica 分析型数据库就不会提示您输入密码。

请为群集中的每个节点创建一个服务主体。然后，您可以创建各个 Keytab 文件（每个节点一个，其中仅包含该节点的主体），或创建一个包含所有主体的 Keytab 文件。

  • 创建一个包含所有主体的 Keytab 文件 可简化设置：所有节点具有相同的文件，可简化初始设置。如果在以后添加节点，则可以更新（和重新分发）全局 Keytab 文件或为新节点创建单独的 Keytab。如果某个主体受损，则该主体在包含它的所有节点的 Keytab 文件中也会受损。

  • 在每个节点中创建单独的 Keytab 文件 可简化维护工作。不过，初始设置时的工作量较大，因为您必须在每个节点中创建不同的文件，但主体不会在各个节点之间共享。如果在以后添加节点，则可以在新节点中创建 Keytab。每个节点的 Keytab 仅包含一个主体，即用于此节点的主体。

票证授予票证

票证授予票证 (TGT) 用于检索对域中服务器的用户进行身份验证的服务票证。随后的登录请求将使用缓存的 HTTP 服务票证进行身份验证，除非该票证已到 krb5.conf 中的 ticket_lifetime 参数中设置的过期时间。

多领域支持

Vertica 使用 ALTER AUTHENTICATION 中的 SET param=value 参数（REALM 作为参数）为 Kerberos 身份验证提供多领域支持：

=> ALTER AUTHENTICATION krb_auth_users set REALM='USERS.COM';
=> ALTER AUTHENTICATION krb_auth_realmad set REALM='REALM_AD.COM';

这允许您分配不同的领域，以便其他领域的用户可以向 Vertica 验证身份。

多领域支持仅适用于 GSS 身份验证类型。每种身份验证方法可以有一个领域。如果您有多种身份验证方法，则每种方法都可以有自己的领域：

=> SELECT * FROM client_auth;
auth_oid | auth_name | is_auth_enabled | auth_host_type | auth_host_address | auth_method | auth_parameters     | auth_priority
---------+-----------+-----------------+----------------+-------------------+-------------+-----------------+-----------------
45035996 | krb001    |   True          |   HOST         |  0.0.0.0/0        |  GSS        | realm=USERS.COM     |  0
45035997 | user_auth |   True          |   LOCAL        |                   |  TRUST      |                     |  1000
45035737 | krb002    |   True          |   HOST         |  0.0.0.0/0        |  GSS        | realm=REALM_AD.COM  |  1

15.1 - 为 Kerberos 身份验证配置 Vertica

Kerberos 针对设备提供强大的加密身份验证，使客户端和服务器能够以更安全的方式进行通信。从而解决了网络安全问题。

您的系统必须安装和配置一个或多个 Kerberos 密钥分发中心 (KDC)。必须可以从 Vertica 分析型数据库群集中的每个节点访问 KDC。

KDC 必须使用 GSS-API 支持 Kerberos 5。有关详细信息，请参阅 MIT Kerberos 分发页面。

此部分内容

15.1.1 - 在 Linux KDC 中创建 Vertica 主体和 Keytab

Vertica 使用服务主体进行系统级别的操作。这些主体用于标识 Vertica 服务，并按如下方式使用：

  • 当 Kerberized Vertica 客户端向数据库进行身份验证时，它们会请求访问此服务。

  • Tuple Mover 等系统进程向 Hadoop 等外部服务进行身份验证时，它们会使用此标识。

按如下所示创建主体和密钥：

  1. 启动 Kerberos 5 数据库管理实用程序（kadmin 或 kadmin.local）可在 Linux KDC 中创建 Vertica 主体。

    • 如果要访问远程服务器中的 KDC，请使用 kadmin。如果掌握 Kerberos 管理员密码，则可以在安装了 Kerberos 5 客户端包的任何计算机上使用 kadmin。启动 kadmin 时，实用程序会提示您输入 Kerberos 管理员密码。您可能需要具备客户端的 root 权限才能运行 kadmin。

    • 在以下情况下可以使用 kadmin.local：

      • KDC 位于您当前已登录的计算机中。

      • 您对该服务器具有 root 权限。

    kadmin.local 不需要管理员登录凭据。

    有关 kadmin 和 kadmin.local 命令的详细信息，请参阅 kadmin 文档。

  2. 在每个节点中，为 Vertica 创建一个服务主体。主机名必须与操作系统提供的值匹配。以下示例为名为 vertica 的节点创建了服务主体 v_vmart_node0001.example.com：

    $ sudo /usr/kerberos/sbin/kadmin.local
kadmin.local add_principal vertica/v_vmart_node0001.example.com

    为每个主体重复执行一次 ktadd 命令。您可以为每个主体用户创建单独的 Keytab，也可以将它们全部添加到一个 Keytab 文件（例如 krb5.keytab）。如要使用一个文件，请参阅 MIT Kerberos 文档中有关 -glob 选项的文档。

    您必须为使用 Kerberos 身份验证的每个 Vertica 分析数据库用户创建一个用户主体。例如：

    $ sudo /usr/kerberos/sbin/kadmin.local
kadmin.local add_principal [options] VerticaUser1

  3. 将每个 Keytab 文件复制到相应群集节点中的 /etc 文件夹。在所有节点中使用相同的路径和文件名。

  4. 在每个节点中，让 Keytab 文件可供正在运行数据库进程的文件所有者（通常是 Linux dbadmin 用户）读取。例如，您可以按照以下方式，将这些文件的所有权更改为 dbadmin：

    $ sudo chown dbadmin *.keytab

    创建 Keytab 文件之后，可以使用 klist 命令查看存储在文件中的密钥：

    $ sudo /usr/kerberos/bin/klist -ke -t
Keytab name: FILE:/etc/krb5.keytab
KVNO    Timestamp        Principal
---- ------------------- --------------------------------------------------------------------------
4     08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
4     08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)

  5. 在 Vertica 上运行以下命令，以确保正确设置 Kerberos 参数：

    => select parameter_name, current_value from configuration_parameters where parameter_name like 'Ker%';
parameter_name         |                      current_value
-----------------------+---------------------------------------------------------------------
KerberosHostname       | v_vmart_node0001.example.com
KerberosKeytabFile     | /etc/krb5.keytab
KerberosRealm          | EXAMPLE.COM
KerberosTicketDuration | 0
KerberosServiceName    | vertica
(5 rows)

  6. 确保所有客户端都使用 gss 身份验证方法。

    从 Vertica：

    => CREATE USER bob;
CREATE USER

=> CREATE AUTHENTICATION v_kerberos method 'gss' host '0.0.0.0/0';
CREATE AUTHENTICATION

=> ALTER AUTHENTICATION v_kerberos enable;
ALTER AUTHENTICATION

=> GRANT AUTHENTICATION v_kerberos to bob;
GRANT AUTHENTICATION

    从操作系统命令行：

    $ kinit bob

$ vsql -U bob -k vertica -K v_vmart_node0001.example.com -h v_vmart_node0001 -c "select client_authentication_name,
authentication_method from sessions;"
 client_authentication_name | authentication_method--
----------------------------+-----------------------
 v_kerberos                 |    GSS-Kerberos

(1 row)

  7. 在 Vertica 上，运行 KERBEROS_CONFIG_CHECK 以验证 Kerberos 配置。KERBEROS_CONFIG_CHECK 验证以下内容：

    • kinit 和 kb5.conf 文件是否存在。

    • keytab 文件是否存在且已设置

    • 数据库中设置的 Kerberos 配置参数：

      • KerberosServiceName

      • KerberosHostname

      • KerberosRealm

      • Vertica 主体

    • Kerberos 可以读取 Vertica 密钥

    • Kerberos 可以获得 Vertica 主体的票证

    • Vertica 可以使用 kinit 初始化密钥

15.1.2 - 指定 KDC 信息并配置领域

Kerberos 领域中的每个客户端和 Vertica 分析型数据库服务器都必须具有有效且配置相同的 Kerberos 配置 (krb5.conf) 文件。如果没有该文件，客户端不知道如何到达 KDC。

如果使用 Microsoft Active Directory，则无需执行此步骤。请参阅适用于您的平台的 Kerberos 文档，详细了解有关在 Active Directory 上的 Kerberos 配置文件信息。

您至少需要在 krb5.conf 文件中配置以下部分。

  • [libdefaults]—Kerberos 5 库使用的设置
  • [realms]—领域专用联系信息和设置
  • [domain_realm]—将服务器主机名映射到 Kerberos 领域

请参阅 Kerberos 文档，了解有关此配置文件中其它部分的信息。

您必须更新 /etc/krb5.conf 文件以反映您的站点的 Kerberos 配置。在 Kerberos 领域中的所有客户端与服务器当中强制执行一致性的最简单办法，就是从 KDC 复制 /etc/krb5.conf 文件。然后，将该文件放入每个 Vertica 群集节点上的 /etc 目录内。

15.1.3 - 通知 Vertica 有关 Kerberos 主体的信息

按照以下步骤通知 Vertica 有关主体名称和 keytab 位置的信息。

有关您在此过程中需要设置的参数的信息，请参阅 Kerberos 参数。

  1. 以管理员身份（通常为 dbadmin）登录到数据库。

  2. 设置 KerberosKeyTabFile 配置参数，以指向 keytab 文件的位置：

    => ALTER DATABASE DEFAULT SET PARAMETER KerberosKeytabFile = '/etc/krb5.keytab';

    在所有节点上，keytab 文件必须在相同位置（在此示例中为 /etc/krb5.keytab）。

  3. 设置 Vertica 主体的服务名称；例如，vertica：

    => ALTER DATABASE DEFAULT SET PARAMETER KerberosServiceName = 'vertica';

  4. 提供主体的领域部分，例如，EXAMPLE.COM。

    => ALTER DATABASE DEFAULT SET PARAMETER KerberosRealm = 'EXAMPLE.COM'

15.1.4 - 为所有客户端配置身份验证方法

为了确保所有客户端均使用 gss 身份验证方法，请运行以下语句：

=> CREATE AUTHENTICATION <method_name> METHOD 'gss' HOST '0.0.0.0/0';
=> GRANT AUTHENTICATION <method_name> TO Public;

有关详细信息，请参阅实施客户端身份验证。

15.1.5 - 在 Active Directory 中创建主体和 Keytab

Active Directory 存储有关 Windows 域成员的信息，包括用户和主机。

Vertica 使用 Kerberos 协议访问此信息，以便对 Vertica 数据库的 Windows 用户进行身份验证。Kerberos 协议使用主体来识别用户，并使用 keytab 文件来存储他们的加密信息。您需要将 keytab 文件安装到 Vertica 中，使 Vertica 数据库能够以加密方式验证 Windows 用户。

此过程描述：

  • 创建 Vertica 服务主体。

  • 导出这些主体的 keytab 文件

  • 在 Vertica 数据库中安装 keytab 文件。这将允许 Vertica 对 Windows 用户进行身份验证，并授予其访问 Vertica 数据库的权限。

  1. 为 Vertica 服务创建一个 Windows 帐户（主体），并为群集中的每个节点/主机创建一个 Vertica 主机。此过程将为在该节点上运行的主机 verticanode01 和服务 vertica 创建 Windows 帐户。

    创建这些帐户时，请选择以下选项：

    • 用户无法更改密码

    • 密码永不过期

  2. 如果您在 HDFS 上使用受 Kerberos 身份验证保护的外部表，则必须启用“委派 (Delegation)”。为此，请访问 Active Directory 用户和计算机对话框，右键单击 Vertica 服务的 Windows 帐户（主体），然后选择“委派 (Delegation)”。信任此用户以委派给任何服务。

  3. 运行以下命令为主机 verticanode01.dc.com 节点/主机创建密钥表：

    $ ktpass -out ./host.verticanode01.dc.com.keytab -princ host/verticanode01.dc.com@DC.COM -mapuser verticanode01
 -mapop set -pass secret  -ptype KRB5_NT_SRV_HST

  4. 运行以下命令为 vertica 服务创建 Keytab:

    $ ktpass -out ./vertica.verticanode01dc.com.keytab -princ vertica/verticanode01.dc.com@DC.COM -mapuser vertica
 -mapop set -pass secret  -ptype KRB5_NT_PRINCIPAL

    有关 Keytab 文件的详细信息，请参阅 Technet.Microsoft.com

  5. 运行以下命令以验证服务主体名称是否正确映射。您必须为群集中的每个节点运行以下命令：

    $ setspn -L vertica
    Registered ServicePrincipalNamefor CN=vertica,CN=Users,DC=dc,DC=com
      vertica/verticanode01.dc.com

$ setspn -L verticanode01
    Registered ServicePrincipalNamefor CN=verticanode01,CN=Users,DC=dc,DC=com
      host/verticanode01.dc.com

  6. 将您刚才创建的密钥表 vertica.verticanode01.dc.com.keytab 和 host.verticanode01.dc.com.keytab 复制到 Linux 主机 verticanode01.dc.com。

  7. 将多个 Keytab 文件组合成一个 Keytab：

    
[release@vertica krbTest]$ /usr/kerberos/sbin/ktutil
ktutil:  rkt host.verticanode01.dc.com.keytab
ktutil:  rkt vertica.verticanode01.dc.com.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
  1    3  host/verticanode01.dc.com@DC.COM
  2   16  vertica/verticanode01.dc.com@DC.COM
ktutil:  wkt verticanode01.dc.com.keytab
ktutil:  exit

    这将创建一个 Keytab 文件，其中包含用于身份验证的服务器主体。

  8. 将新的 Keytab 文件复制到编录目录。例如：

    $ cp verticanode01.dc.com.keytab /home/dbadmin/VMart/v_vmart_nodennnn_catalog

  9. 测试 Keytab 文件检索票证的能力，确保它可以从 Vertica 节点运行：

    
$ kinit vertica/verticanode01.dc.com -k -t verticanode01.dc.com.keytab
$ klist

Ticket cache: KFILE:/tmp/krb_ccache_1003
Default principal: vertica/verticanode01.dc.com@DC.COM

Valid starting Expires Service principal
04/08/2017 13:35:25 04/08/2017 23:35:25 krbtgt/DC.COM@DC.COM
                renew until 04/15/2017 14:35:25

    当票证过期或未自动取回时，您需要手动运行 kinit 命令。请参阅获取 Kerberos 票证并对 Vertica 进行身份验证。

  10. 对 Keytab 文件设置正确的权限和所有权：

    $ chmod 600 verticanode01.dc.com.keytab
$ chown dbadmin:verticadba verticanode01.dc.com.keytab

  11. 使用 ALTER DATABASE 设置以下 Kerberos 参数 通知 Vertica 有关 Kerberos 主体的信息： 

    KerberosKeytabFile=<CATALOGDIR>/verticanode01.dc.com.keytab
KerberosRealm=DC.COM
KerberosServiceName=vertica
KerberosTicketDuration = 0
KerberosHostname=verticanode01.dc.com

  12. 重新启动 Vertica 服务器。

  13. 按如下所示测试 Kerberos 设置，确保所有客户端都使用 gss 身份验证方法。

    从 Vertica：

    => CREATE USER windowsuser1;
CREATE USER

=> CREATE AUTHENTICATION v_kerberos method 'gss' host '0.0.0.0/0';
CREATE AUTHENTICATION

=> ALTER AUTHENTICATION v_kerberos enable;
ALTER AUTHENTICATION

=> GRANT AUTHENTICATION v_kerberos to windowsuser1;
GRANT AUTHENTICATION

    从操作系统命令行：

    $ kinit windowsuser1

$ vsql -U windowsuser1 -k vertica -K verticanode01.dc.com -h verticanode01.dc.com -c "select client_authentication_name,
authentication_method from sessions;"
 client_authentication_name | authentication_method--
----------------------------+-----------------------
 v_kerberos                 |    GSS-Kerberos

(1 row)

  14. 运行 KERBEROS_CONFIG_CHECK 以验证 Kerberos 配置。KERBEROS_CONFIG_CHECK 验证以下内容：

    • kinit 和 kb5.conf 文件是否存在。

    • keytab 文件是否存在且已设置

    • 数据库中设置的 Kerberos 配置参数：

      • KerberosServiceName

      • KerberosHostname

      • KerberosRealm

      • Vertica 主体

    • Kerberos 可以读取 Vertica 密钥

    • Kerberos 可以获得 Vertica 主体的票证

    • Vertica 可以使用 kinit 初始化密钥

15.1.6 - 获取 Kerberos 票证并对 Vertica 进行身份验证

如果您的机构使用 Kerberos 作为登录过程的一部分，在登录时会自动检索 Kerberos 票证。否则，您需要运行 kinit 来检索 kerberos 票证。

以下示例显示如何使用 kinit 命令检索票证并通过 KDC 对 Vertica 分析型数据库进行身份验证。域名为 EXAMPLE.COM。您必须使用该域名及您的用户名来检索 Kerberos 票证。请参阅指定 KDC 信息并配置领域。

$ kinit
Password for principal_user@EXAMPLE.COM: kpasswd

将会提示您当您创建主体和密钥文件（请参阅 在 Linux KDC 中创建 Vertica 主体和 Keytab）时创建的主体用户名的密码。

Kerberos 票证在预设时间长度内被缓存。请参阅 Kerberos 文档中的票证管理获取有关过期参数设置的更多信息。

过期后，您需要再次运行 kinit 指令来检索另外一张 Kerberos 票证。

15.2 - 为 Kerberos 身份验证配置客户端

各个支持的平台使用不同的安全框架。因此，不同客户端中配置和执行 Kerberos 身份验证所需的步骤也不尽相同。

在服务器端，需使用以下格式构建 Vertica Kerberos 服务名称主体：

Kerberos_Service_Name/Kerberos_Host_Name@Kerberos_Realm

对于每个客户端，GSS 库要求 Vertica 服务主体采用以下格式：

Kerberos_Service_Name@Kerberos_Host_Name

可以省略主体的领域部分，因为 GSS 库使用配置的默认 (Kerberos_Realm) 领域的领域名称。

有关客户端连接字符串的信息，请参阅以下主题：

此部分内容

15.2.1 - 在非 Windows 平台上配置 ODBC 和 vsql 客户端

要在 Linux 或 MAC OSX 上配置 ODBC 或 vsql 客户端，必须首先安装 Kerberos 5 客户端软件包。请参阅 配置 Kerberos 身份验证。

安装 Kerberos 5 客户端软件包后，必须向客户端提供有效的 Kerberos 配置文件 (krb5.conf)。要与 KDC 通信，参与 Kerberos 身份验证的每个客户端必须拥有配置相同的有效 krb5.conf 文件。Kerberos 配置文件的默认位置为 /etc/krb5.conf。

Kerberos 配置 (krb5.conf) 文件包含 Kerberos 特定的信息，包括：

  • 如何连接 KDC

  • 默认领域名称

  • 域

  • 指向日志文件的路径

  • DNS 查询

  • 要使用的加密类型

  • 票证使用期限

Kerberos 配置文件的默认位置为 /etc/krb5.conf。

如果配置正确，客户端可以使用 Kerberos 进行身份验证并通过 kinit 实用程序检索票证（请参阅以下获取 ODBC 身份验证请求和连接）。同样，服务器则可以使用 ktutil 在 keytab 文件中存储其凭据

在非 Windows 平台上对 ODBC 和 vsql 客户端进行身份验证

ODBC 和 vsql 使用 kinit 建立的客户端票证执行 Kerberos 身份验证。这些客户端依赖于安全库的默认机制来查找票证文件和 Kerberos 配置文件。

要按照 Kerberos 进行身份验证，请调用 kinit 实用程序以便从 Kerberos KDC 服务器获取票证。以下两个示例显示了如何使用 ODBC 和 vsql 客户端发送票证请求。

获取 ODBC 身份验证请求和连接

  1. 在 ODBC 客户端上，通过调用 kuser 实用程序获取 kinit 用户的票证。

    $ kinit kuser@EXAMPLE.COM
Password for kuser@EXAMPLE.COM:

  2. 连接到 Vertica，并在连接字符串中提供主体：

    char outStr[100];
SQLLEN len;
SQLDriverConnect(handle, NULL, "Database=VMart;User=kuser;
Server=myserver.example.com;Port=5433;KerberosHostname=vcluster.example.com",
SQL_NTS, outStr, &len);

获取 vsql 身份验证请求和连接

如果 vsql 客户端位于您所连接的同一台计算机中，vsql 将通过 UNIX 域套接字连接。此连接将绕过 Kerberos 身份验证。当使用 Kerberos 进行身份验证时，特别是客户端身份验证方法配置为“本地”时，必须包括 -h 主机名选项。请参阅命令行选项。

  1. 在 vsql 客户端上，调用 kinit 实用程序：

    $ kinit kuser@EXAMPLE.COM
Password for kuser@EXAMPLE.COM:

  2. 连接到 Vertica，并在连接字符串中提供主机和用户主体：

    $ ./vsql -K vcluster.example.com -h myserver.example.com -U kuser
Welcome to vsql, the Vertica Analytic Database
interactive terminal.

Type:  \h or \? for help with vsql commands
\g or terminate with semicolon to execute query
\q to quit

将来，以 kuser 身份登录 vsql 时，vsql 将使用您缓存的票证，而不提示您输入密码。

验证身份验证方法

通过查询 SESSIONS 系统表可以验证身份验证方法：

=> SELECT authentication_method FROM sessions;
 authentication_method
-----------------------
GSS-Kerberos
(1 row)

另请参阅

15.2.2 - 在 Windows 上配置 ADO.NET、ODBC 和 vsql 客户端

Vertica 客户端驱动程序支持使用 Windows SSPI 库进行 Kerberos 身份验证。Windows Kerberos 配置存储在注册表中。

对于 Windows 和 ADO.NET 上的 ODBC 和 vsql 客户端 Kerberos 身份验证，可以选择两种不同的设置方案：

在 Active Directory 中使用 Windows 内置 Kerberos 客户端和 Vertica 的 Windows KDC

在 Windows 上的 Kerberos 身份验证通常搭配 Active Directory（Microsoft 的企业目录服务/Kerberos 实施）使用。通常，由组织的网络或 IT 管理员执行设置。

Windows 客户端的 Kerberos 身份验证内置于身份验证进程中。无需任何其他软件。

在执行以下操作时，登录凭据可对您连接 Kerberos 服务器 (KDC) 进行身份验证：

  • 从客户机登录到 Windows

  • 使用配置为通过 Active Directory 使用 Kerberos 的 Windows 实例

要在 Windows 客户端上使用 Kerberos 身份验证，请以 REALM\user 身份登录。

使用 Windows 内置 Kerberos 客户端和 Vertica 的 Linux KDC

一种简单但不太常见的方案是配置 Windows 对非 Windows KDC 进行身份验证。在此实施中，使用 ksetup 实用程序在非 Active Directory KDC 中指出 Windows 操作系统本机 Kerberos 功能。通过登录到 Windows，可获取许可票证，与 Active Directory 实施类似。但在这种情况下，Windows 在内部与 Linux KDC 通信。有关详细信息，请参阅 Microsoft Windows Server Ksetup 页面。

当数据库/Windows 用户登录到 Windows 计算机（或在 Windows 上执行 kinit 之后）时，Kerberos 票证必须设置 ok_as_delegate 和 forwardable 标志才能访问基于 webhdfs 的外部表，如下所示：

$ CMD \> klist
#2>     Client: release @ VERTQA.LOCAL
Server: vertica/vqatest108.verticacorp.com @ VERTQA.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a50000 forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 9/27/2017 13:24:43 (local)
End Time:   9/27/2017 20:34:45 (local)
Renew Time: 10/3/2017 15:04:45 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: ADKDC01

配置 Windows 客户端以执行 Kerberos 身份验证

根据要配置的实施，请参阅 Microsoft Server 网站上的下列页面之一：

客户端身份验证和连接

KDC 可对 ADO.NET 和 a vsql 客户端进行身份验证。

验证 ADO.NET 身份验证请求和连接

本示例显示如何使用 IntegratedSecurity=true 设置指定通过 ADO.NET 驱动程序对呼叫用户的 Windows 凭据进行身份验证：

VerticaConnection conn = new
VerticaConnection("Database=VMart;Server=host.example.com;
Port=5433;IntegratedSecurity=true;
KerberosServiceName=vertica;KerberosHostname=vcluster.example.com");
conn.open();

验证 vsql 身份验证请求和连接

  1. 例如，以 EXAMPLE\kuser 身份登录到您的 Windows 客户端。

  2. 运行 vsql 客户端，并向 Vertica 提供连接字符串：

    C:\Users\kuser\Desktop>vsql.exe -h host.example.com -K vcluster -U kuser

Welcome to vsql, the Vertica Analytic Database interactive terminal.
Type:  \h or \? for help with vsql commands
\g or terminate with semicolon to execute query
\q to quit

另请参阅

15.2.3 - 在所有平台上配置 JDBC 客户端

JDBC 客户端上的 Kerberos 身份验证采用 Java 身份验证和授权服务 (JAAS) 获得初始 Kerberos 凭据。JAAS 是一种 API 框架，可隐藏平台特定的身份验证详细信息并为其他应用程序提供一致的界面。

通过 JAAS 登录配置文件可指定客户端登录过程。此文件包含指定用于 Kerberos 的身份验证方法和其他设置的选项。名为 LoginModule 的类定义配置文件中的有效选项。

JDBC 客户端主体设计为 jdbc-username@server-from-connection-string。

实施 LoginModule

Vertica 建议您使用 Java 运行时环境 (JRE) 中提供的 JAAS 公共类 com.sun.security.auth.module.Krb5LoginModul。

Krb5LoginModule 使用 Kerberos 协议验证用户身份，并且在非 Windows 和 Windows 平台上的实施方式不同：

  • 在非 Windows 平台上： Krb5LoginModule 遵从本机 Kerberos 客户端实施。因此，您可以使用用于在 Linux 和 MAC OSX 平台上配置 ODBC 和 vsql 客户端的相同 /etc/krb5.conf 设置。
  • 在 Windows 平台上： Krb5LoginModule 采用 Java 运行时环境 (JRE) 捆绑的自定义 Kerberos 客户端实施。Windows 设置存储在 %WINDIR%\krb5.ini 文件中，该文件的语法和约定与非 Windows krb5.conf 文件类似。可以从非 Windows 客户端复制 krb5.conf 到 %WINDIR%\krb5.ini 中。

您可以在 com.sun.security.auth 程序包和 Krb5LoginModule 网页上找到 LoginModules 的文档。

创建 JAAS 登录配置

JAASConfigName 连接属性用于标识包含 Krb5LoginModule 及其设置的 JAAS 配置中的特定配置。JAASConfigName 设置允许多个具有不同 Kerberos 设置的 JDBC 应用程序在一个主机中共存。默认配置名称为 verticajdbc。

您可以在 java.security 主安全属性文件中配置 JAAS 相关的设置。此文件位于 JRE 的 lib/security 目录中。有关详细信息，请参阅《JavaTM 身份验证和授权服务 (JAAS) 参考指南》中的附录 A。

创建 JDBC 登录上下文

以下示例显示如何为 JDBC 客户端上的 Kerberos 身份验证创建登录上下文。该客户端使用 JAASConfigName 的默认 verticajdbc，并指定：

  • 从票证缓存中获得许可票证

  • 如果无法从缓存、keytab 文件或通过共享状态获得凭据，系统不会提示用户输入密码。

verticajdbc {
  com.sun.security.auth.module.Krb5LoginModule
  required
  useTicketCache=true
  doNotPrompt=true;
};

JDBC 身份验证请求和连接

可以将 Krb5LoginModule 配置为使用缓存的票证或 keytab。另外，如果呼叫用户提供密码，驱动程序也可以自动获得票证或 keytab。

在上一示例中，登录进程之所以使用缓存的票证且不提示输入密码，是因为 useTicketCache 和 doNotPrompt 均设置为 true。如果设置 doNotPrompt=false 并在登录过程中提供用户名和密码，则驱动程序会向 LoginModule 提供该信息。然后，该驱动程序将代表您调用 kinit 实用程序。

  1. 在 JDBC 客户端上，调用 kinit 实用程序以获得票证：

    $ kinit kuser@EXAMPLE.COM

    如果您希望使用密码而不调用 kinit 实用程序，请参阅下一节。

  2. 连接到 Vertica：

    Properties props = new Properties();
props.setProperty("user", "kuser");
props.setProperty("KerberosServiceName", "vertica");
props.setProperty("KerberosHostName", "vcluster.example.com");
props.setProperty("JAASConfigName", "verticajdbc");
Connection conn = DriverManager.getConnection
"jdbc:vertica://myserver.example.com:5433/VMart", props);

通过驱动程序获取票证

有时，您可能希望自己绕过调用 kinit 实用程序，但仍使用加密的双向身份验证。在这些情况下，可以选择向驱动程序传递明文密码以便从 KDC 获取票证。密码在网络中发送时为加密状态。例如，在以下示例中，useTicketCache 和 doNotPrompt 均为 false。因此，无法通过票证缓存或 keytab 获得呼叫用户的凭据。

$ verticajdbc  {
  com.sun.security.auth.module.Krb5LoginModule
  required
  useTicketCache=false
  doNotPrompt=false;
};

上一示例演示了 JAAS 的灵活性。驱动程序不再查找缓存的票证，而您无需调用 kinit。相反，驱动程序将使用密码和用户名并代表您调用 kinit。

另请参阅

15.3 - Kerberos 身份验证故障排除

这些提示有助于您避免 Vertica 的 Kerberos 身份验证的相关问题，并对产生的任何问题进行故障排除。

JDBC 客户端身份验证失败

如果在 JDBC 客户端上进行 Kerberos 身份验证失败，请检查 JAAS 登录配置文件是否存在语法问题。如果语法不正确，身份验证会失败。

未配置工作域名服务 (DNS)

确认网络上的 DNS 条目和系统主机文件 (/etc/hosts or /etc/hostnames) 均针对您的环境进行了适当的配置。如果您使用的是完全限定域名，请确保其也已正确配置。有关详细信息，请参阅适用于您的平台的 Kerberos 文档。

系统时钟不同步

您网络中的系统时钟必须保持同步，Kerberos 身份认证才能正常进行。如果您访问 HDFS 中的数据，则 Vertica 节点还必须与 Hadoop 同步。

除 Red Hat 7/CentOS 7 之外的所有系统

要保持系统时钟同步，请执行以下操作：

  1. 在 Kerberos 服务器 (KDC) 上安装 NTP。

  2. 在您网络中的每台服务器上安装 NTP。

  3. 针对所有参与 Kerberos 领域，距离 KDC 以及其他每台服务器相隔仅数分钟的所有机器，同步其系统时钟

对于需要与 Windows Time Service 同步的 Linux 虚拟机，可能会存在时钟偏差问题。采用以下步骤保持时间同步：

  1. 使用任意文本编辑器，打开 /etc/ntp.conf。

  2. 在 Undisciplined Local Clock 部分下方，添加 Vertica 服务器的 IP 地址。然后，删除现有服务器条目。

  3. 以 root 身份登录到服务器，并设置一个 cron 作业，用来与添加的 IP 地址同步时间，每半小时同步一次或按需要的频率同步。例如：

    # 0 */2 * * * /etc/init.d/ntpd restart

  4. 或者，运行以下命令来强制立即同步时钟：

    $ sudo /etc/init.d/ntpd restart

有关详细信息，请参阅启用网络时间协议 (NTP)和网络时间协议网站。

Red Hat 7/CentOS 7 系统

在 Red Hat 7/CentOS 7 中，为了更侧重于 chrony，弃用了 ntpd。要使您网络中的系统时钟保持同步，以便 Kerberos 身份验证能正常进行，请执行以下操作：

  1. 在 Kerberos 服务器 (KDC) 上安装 chrony。

  2. 在您网络中的每台服务器上安装 chrony。

  3. 针对所有参与 Kerberos 领域，距离 KDC 以及其他每台服务器相隔仅数分钟的所有机器，同步其系统时钟。

Linux 虚拟机上的时钟偏差

对于需要与 Windows Time Service 同步的 Linux 虚拟机，可能会存在时钟偏差问题。采用以下步骤保持时间同步：

  1. 使用任意文本编辑器，打开 /etc/chrony.conf。

  2. 在 Undisciplined Local Clock 部分下方，添加 Vertica 服务器的 IP 地址。然后，删除现有服务器条目。

  3. 以 root 身份登录到服务器，并设置一个 cron 作业，用来与添加的 IP 地址同步时间，每半小时同步一次或按需要的频率同步。例如：

    # 0 */2 * * * systemctl start chronyd

  4. 或者，运行以下命令来强制立即同步时钟：

    $ sudo systemctl start chronyd

有关详细信息，请参阅 Red Hat chrony 指南。

Kerberos 票证有效，但 Hadoop 访问失败

Vertica 使用 Kerberos 票证获取 Hadoop 令牌。然后使用 Hadoop 令牌访问 Hadoop 数据。Hadoop 令牌会在一段时间后过期，所以 Vertica 会定期刷新。但是，如果您的 Hadoop 群集设定使得令牌频繁过期，则令牌可能无法及时刷新。如果令牌过期，您将无法访问数据。

通过设置 HadoopFSTokenRefreshFrequency 配置参数，您可以指定 Vertica 刷新令牌的频率。指定值（以秒为单位）应该小于设置的 Hadhoop 到期期限。例如：

=> ALTER DATABASE exampledb SET HadoopFSTokenRefreshFrequency = '86400';

有关 Hadoop 访问失败的另一个原因，请参阅系统时钟不同步。

加密算法选项

Kerberos 基于对称加密。要确保 Kerberos 领域中使用的 Kerberos 各方都同意使用某加密算法。如果不同意，身份验证就会失败。您可以在 vertica.log 中查看异常。

在 Windows 客户端上，要确保加密类型与在 Active Directory 上设置的类型相匹配。请参阅为 Kerberos 身份验证配置 Vertica。

请注意，Kerberos 仅用于保护登录进程的安全。在登录进程完成后，客户端和服务器之间的信息传输默认不加密。如果您想要对信息传输进行加密，请使用 SSL。有关详细信息，请参阅实施 SSL。

Kerberos 密码未能识别

如果您更改了 Kerberos ，则必须重新创建所有的 keytab 文件。

使用 ODBC 数据源配置实用程序

在 Windows vsql 客户端上，您可以选择使用 ODBC 数据源配置实用程序并为客户端提供数据源。若如此，请务必在“客户端设置 (Client Settings)”选项卡中输入 Kerberos 主机名，以避免客户端无法连接 Vertica 分析型数据库服务器。

备份、还原或管理工具身份验证失败

若配置中各 Vertica 节点使用其各自的 Kerberos 主体，则可能产生这个问题。（推荐此配置。）使用 VBR 或 admintools 时，您可能会看到诸如以下的错误：

$ vsql: GSSAPI continuation error: Miscellaenous failure
GSSAPI continuation error: Server not found in Kerberos database

备份/还原以及管理工具将使用用于验证的 Kerberos 主体中的 KerberosHostname 值（若设置了此值）。所有节点都使用相同的值。如果您如推荐的那样，为每个节点都定义了一个 Kerberos 主体，此值将不匹配。要予以更正，请取消设置 KerberosHostname 参数：

=> ALTER DATABASE DEFAULT CLEAR KerberosHostname;

服务器的主体名与主机名不匹配

若配置中所有节点都使用同一个 Kerberos 主体，则可能产生这个问题。Vertica 不推荐对所有节点使用同一个 Kerberos 主体。相反，请为每个节点使用不同的主体，而且不要设置 KerberosHostname 参数。

在某些情况下，连接客户端时，Vertica 服务器的主体名可能与连接字符串中的主机名不匹配。（另请参阅本主题中的使用 ODBC 数据源配置实用程序。）

在 Windows vsql 客户端上，您可以选择使用 ODBC 数据源配置实用程序并为客户端提供数据源。若如此，请务必在“客户端设置 (Client Settings)”选项卡中输入 Kerberos 主机名，以避免客户端无法连接 Vertica 服务器。

在 ODBC、JDBC 和 ADO.NET 客户端上，使用 KerberosHostName 连接字符串设置服务器主体的主机名部分。

主体/主机不匹配问题和解决方案

如果主体和主机不匹配，可能会出现以下问题。

KerberosHostName 配置参数被覆盖

例如，考虑以下连接字符串：

jdbc:vertica://v_vmart_node0001.example.com/vmart?user=kuser

由于此连接字符串不包含显式 KerberosHostName 参数，驱动程序默认其为 URL (v_vmart_node0001.example.com) 下的主机。如果您覆盖服务器端 KerberosHostName 参数，使之为“abc”，客户端将生成不正确的主体。

要解决这个问题，请将客户端 KerberosHostName 显式设置为连接字符串，如本例所示：

jdbc:vertica://v_vmart_node0001.example.com/vmart?user=kuser&kerberoshostname=abc

连接负载均衡功能已启用 ，但客户端进行验证的节点可能不是连接字符串中的节点。

在这种情况下，请考虑更改所有节点，以使用相同的 KerberosHostName 设置。当您使用最初在连接字符串中指定的默认主机时，负载均衡将无法干扰 Kerberos 身份验证。

DNS 名与 Kerberos 主机名不匹配

例如，假定群集中有六台服务器，您想让 hr-servers 和 finance-servers 连接到 Vertica 群集中的不同节点。但 Kerberos 身份验证发生在单个（相同的）KDC 上。在以下示例中，服务器的 Kerberos 服务主机名为 server.example.com。

假设您拥有下列示例服务器：

server1.example.com 192.16.10.11
server2.example.com 192.16.10.12
server3.example.com 192.16.10.13
server4.example.com 192.16.10.14
server5.example.com 192.16.10.15
server6.example.com 192.16.10.16

现在，假定您拥有下列 DNS 条目：

finance-servers.example.com 192.168.10.11, 192.168.10.12, 192.168.10.13
hr-servers.example.com 192.168.10.14, 192.168.10.15, 192.168.10.16

当您连接到 finance-servers.example.com 时，指定：

  • Kerberos -h 主机名选项为 server.example.com

  • hr-servers.example.com 的 -K 主机选项

例如：

$ vsql -h finance-servers.example.com -K server.example.com

未在客户端计算机上设置 DNS ，所以您只能通过 IP 连接

要解决这个问题，指定：

  • 该 IP 地址的 Kerberos -h 主机名选项

  • server.example.com 的 -K 主机选项

例如：

$ vsql -h 192.168.1.12 -K server.example.com

涉及到负载均衡器（虚拟 IP） ，但 VIP 没有 DNS 名

指定：

  • Virtual IP 地址的 Kerberos -h 主机名选项

  • server.example.com 的 -K 主机选项

例如：

$ vsql -h <virtual IP> -K server.example.com

您使用 IP 地址连接到 Vertica ，但没有用来构建 Kerberos 主体名的主机名。

如通知 Vertica 有关 Kerberos 主体的信息中所述，为 Vertica 提供实例或主机名

将服务器端 KerberosHostName 配置参数设置为 Vertica 节点主机名之外的名称 ，但客户端无法仅根据连接字符串中的主机名来确定主机名。

重置 KerberosHostName，以匹配 Vertica 节点的主机名的名称。有关详细信息，请参阅以下主题：

16 - LDAP 身份验证

轻型目录访问协议 (LDAP) 身份验证方法的工作原理与密码身份验证类似。主要差异在于，LDAP 方法通过 LDAP 或 Active Directory 服务器对尝试访问您的 Vertica 数据库的客户端进行身份验证。当您的数据库需要通过 LDAP 或 Active Directory 服务器验证用户身份时，请使用 LDAP 身份验证。

16.1 - LDAP 先决条件和定义

先决条件

在为 Vertica 数据库配置 LDAP 身份验证前，您必须具有：

  • LDAP 服务器的 IP 地址和主机名。Vertica 支持 IPv4 和 IPv6 地址。

  • 组织的 Active Directory 信息。

  • 用于搜索和捆绑的服务账户。

  • 对 Vertica 数据库的管理访问权限。

  • open-ldap-tools 程序包至少安装在一个节点上。该包包括 ldapsearch。

定义

对于 LDAP 身份验证，记住以下定义非常重要：

16.2 - LDAP 身份验证参数

LDAP 身份验证需要配置几个参数。

常规 LDAP 参数

使用下列参数配置 LDAP 绑定或 LDAP 绑定和搜索：

LDAP 绑定参数

以下参数将创建一个绑定名称字符串，用于指定并唯一标识 LDAP 服务器的用户。有关详细信息，请参阅配置 LDAP 捆绑的工作流程。

要创建绑定名称字符串，必须设置以下内容之一（且只能设置一项）：

  • binddn_prefix 和 binddn_suffix（必须一起设置）

  • domain_prefix

  • email_suffix

例如，如果您设置了 binddn_prefix 和 binddn_suffix，则不能设置 email_suffix。相反，如果设置了 email_suffix，则不能设置 binddn_prefix 和 binddn_suffix。

如果未设置绑定参数，Vertica 将执行绑定和搜索操作，而不是绑定操作。

以下示例使用身份验证记录 v_ldap：

=> CREATE AUTHENTICATION v_ldap METHOD 'ldap' HOST '10.0.0.0/23';

LDAP 搜索和绑定参数

使用 LDAP 搜索和绑定进行身份验证时，使用以下参数。有关详细信息，请参阅LDAP 搜索和捆绑配置工作流。

以下示例演示了如何设置这三个属性。在本例中，设置为：

  • binddn 到 cn=Manager,dc=example,dc=com

  • bind_password 到 secret

  • search_attribute 到 cn

=> ALTER AUTHENTICATION auth_method_name SET host='ldap://example13',
basedn='dc=example,dc=com',binddn='cn=Manager,dc=example,dc=com',
bind_password='secret',search_attribute='cn';

binddn 和 bind_password 参数是可选的。如果忽略，Vertica 将执行匿名搜索。

16.3 - LDAP 身份验证的 TLS

Vertica 在两个上下文中建立到 LDAP 服务器的连接，每个上下文都有一个对应的 TLS CONFIGURATION，用于控制每个连接是否应使用 TLS：

  1. LDAPLink：使用 LDAPLink 服务或其试运行功能在 Vertica 和 LDAP 服务器之间同步用户和组。

  2. LDAPAuth：当具有 ldap 身份验证方法的用户尝试登录 Vertica 时，Vertica 会尝试将该用户绑定到 LDAP 服务器中的匹配用户。如果绑定成功，Vertica 将允许用户登录。

查询 TLS_CONFIGURATIONS 以查看现有的 TLS CONFIGURATION：

=> SELECT * FROM tls_configurations WHERE name IN ('LDAPLink', 'LDAPAuth');
   name   |  owner  | certificate | ca_certificate | cipher_suites |  mode
----------+---------+-------------+----------------+---------------+----------
 LDAPLink | dbadmin | client_cert | ldap_ca        |               | VERIFY_CA
 LDAPAuth | dbadmin | client_cert | ldap_ca        |               | DISABLE
(2 rows)

本页介绍 LDAPAuth 上下文。有关 LDAPLink 上下文的详细信息，请参阅 LDAP Link 的 TLS。

请注意，为 LDAP 身份验证配置 TLS 不会使用 TLS 对 Vertica 与客户端之间的连接进行加密。要配置客户端-服务器 TLS，请参阅配置客户端-服务器 TLS。

配置 LDAP 身份验证

客户端与 Vertica 成功建立连接后，它们必须以用户身份进行身份验证，然后才能与数据库进行交互。如果用户具有 ldap 身份验证方法，Vertica 将连接到 LDAP 服务器以对用户进行身份验证。要为此上下文配置 TLS，请使用以下过程。

设置 LDAPAuth TLS 配置

LDAPAuth TLS 配置采用客户端证书和使用 CREATE CERTIFICATE 创建或导入的 CA 证书。Vertica 会将客户端证书提供给 LDAP 服务器以供其 CA 进行验证。Vertica 使用 CA 证书来验证 LDAP 服务器的证书。

有关密钥和证书生成的详细信息，请参阅生成 TLS 证书和密钥。

  1. 如果您希望 Vertica 在建立连接之前验证 LDAP 服务器的证书，请生成或导入 CA 证书并将其添加到 LDAPAuth TLS 配置中。

    例如，要导入现有的 CA 证书 LDAP_CA.crt：

    => \set ldap_ca '\''`cat ldap_ca.crt`'\''
=> CREATE CA CERTIFICATE ldap_ca AS :ldap_ca;
CREATE CERTIFICATE

    然后，将 ldap_ca CA 证书添加到 LDAPAuth：

    ALTER TLS CONFIGURATION LDAPAuth ADD CA CERTIFICATES ldap_ca;

  2. 如果您的 LDAP 服务器需要验证客户端证书，您必须生成或导入客户端证书及其密钥，并将其添加到 LDAPAuth TLS 配置中。Vertica 会将此证书提供给 LDAP 服务器以供其 CA 进行验证。

    例如，要导入现有的证书 client.crt（由导入的 CA 签名）和密钥 client.key：

    => \set client_key '\''`cat client.key`'\''
=> CREATE KEY client_key TYPE 'RSA' AS :client_key;
CREATE KEY

=> \set client_cert '\''`cat client.crt`'\''
=> CREATE CERTIFICATE client_cert AS :client_cert SIGNED BY ldap_ca KEY client_key;
CREATE CERTIFICATE

    然后，将 client_cert 添加到 LDAPAuth：

    => ALTER TLS CONFIGURATION LDAPAuth CERTIFICATE client_cert;

  3. 通过将 TLSMODE 设置为以下之一来启用 TLS 或 LDAPS（使用的确切协议取决于 AUTHENTICATION 对象中 host 的值）。 TRY_VERIFY 或更高版本需要 CA 证书：

    • ENABLE：启用 TLS。Vertica 不检查 LDAP 服务器的证书。

    • TRY_VERIFY：如果出现以下任一情况，则建立 TLS 连接：

      • LDAP 服务器提供一个有效的证书。

      • LDAP 服务器不提供证书。

      如果 LDAP 服务器提供无效证书，则使用纯文本连接。

    • VERIFY_CA：如果 Vertica 验证 LDAP 服务器的证书来自受信任的 CA，则连接成功。使用此 TLSMODE 会强制所有没有证书的连接使用纯文本。

    • VERIFY_FULL：如果 Vertica 验证 LDAP 服务器的证书来自受信任的 CA 并且 cn（通用名称）或 subjectAltName 属性与 LDAP 服务器的主机名或 IP 地址匹配，则连接成功。

      cn 用于用户名，因此 subjectAltName 必须与 LDAP 服务器的主机名或 IP 地址匹配。

    例如：

    => ALTER TLS CONFIGURATION LDAPAuth TLSMODE 'verify_ca';
ALTER TLS CONFIGURATION

  4. 验证 LDAPAuthConfigParameter 参数是否正在使用 TLS 配置：

    => SHOW CURRENT LDAPAuthTLSConfig;
  level  |       name        | setting
---------+-------------------+----------
 DEFAULT | LDAPAuthTLSConfig | LDAPAuth
(1 row)

  5. 启用身份验证记录：

    => ALTER AUTHENTICATION ldap_auth ENABLE;

创建 LDAP 身份验证记录

客户端与 Vertica 成功建立连接后，它们必须以用户身份进行身份验证，然后才能与数据库进行交互。如果用户具有 ldap 身份验证方法，Vertica 将连接到 LDAP 服务器并尝试绑定以对用户进行身份验证。

要查看现有的身份验证记录，请查询 CLIENT_AUTH。

有关此过程中引用的参数的详细信息，请参阅 LDAP 身份验证参数。

  1. 创建具有 LDAP 方法的身份验证记录。

    用于创建 LDAP 身份验证记录的语法：

    => CREATE AUTHENTICATION auth_record_name method 'ldap' HOST 'user_connection_source';

    例如，要创建适用于从任何主机连接的用户的 LDAP 身份验证记录：

    => CREATE AUTHENTICATION ldap_auth METHOD 'ldap' HOST '0.0.0.0/0';

  2. 更改身份验证类型，以设置 LDAP 服务器的主机和端口（可选）以及域名 (basedn)，并绑定可分辨名称 (binddn)。

    • 要在 Vertica 和 LDAP 服务器之间使用明文连接，请将 host URL 设置为以 ldap:// 开头，并将 LDAPAuth 的 TLSMODE 设置为 DISABLE。

    • 要使用 StartTLS，请将 host URL 设置为以 ldap:// 开头，并将 LDAPAuth 的 TLSMODE 设置为 ENABLE 或更高。

    • 要使用 LDAPS，请将 host URL 设置为以 ldaps:// 开头，并将 LDAPAuth 的 TLSMODE 设置为 ENABLE 或更高。

    例如，要在位于端口 5389 上且 IP 地址为 192.0.2.0 的 LDAP 服务器上搜索 Active Directory orgunit.example.com 中的用户：

    => ALTER AUTHENTICATION ldap_auth SET
    host='ldap://192.0.2.0:5389',
    basedn='ou=orgunit,dc=example,dc=com',
    binddn_prefix='cn=',
    binddn_suffix=',ou=orgunit,dc=example,dc=com';

    binddn_prefix 和 binddn_suffix 结合起来可创建完整 DN。也就是说，对于 Vertica 用户 asmith，' cn=asmith,ou=orgunit,dc=example,dc=com' 是 Vertica 尝试绑定时的完整 DN。

  3. 将身份验证记录授予用户或角色。

    例如：

    => GRANT AUTHENTICATION ldap_auth TO asmith;

    在这种情况下，当用户 asmith 尝试登录时，Vertica 会通过 ldap_auth 中指定的搜索库构建可分辨名称 'cn=asmith,ou=orgunit,dc=example,dc=com'，然后连接到 LDAP 服务器，并尝试将其绑定到 Vertica 用户。如果绑定成功，Vertica 将允许 asmith 登录。

16.4 - LDAP 的身份验证 fallthrough

要为单个 LDAP 服务器使用多个搜索属性或配置多个 LDAP 服务器，请为每个搜索属性或服务器创建单独的身份验证记录，并在每个 ldap 记录（最后一个除外）上启用身份验证 fallthrough（按优先级顺序）。

示例

以下示例创建了两个身份验证记录，vldap1 和 vldap2。它们一起指定 LDAP 服务器应首先搜索整个目录 (basedn=dc=example,dc=com) 中 OU 属性为 Sales 的 DN。如果第一个搜索没有返回结果或失败，LDAP 服务器接下来将搜索 OU 属性为 Marketing 的 DN：

=> CREATE AUTHENTICATION vldap1 method 'ldap' HOST '10.0.0.0/8' FALLTHROUGH;
=> ALTER AUTHENTICATION vldap1 PRIORITY 1;
=> ALTER AUTHENTICATION vldap1
      SET host='ldap://ldap.example.com/search',
      basedn='dc=example,dc=com',
      search_attribute='Sales';
=> GRANT AUTHENTICATION vldap1 to public;

=> CREATE AUTHENTICATION vldap2 method 'ldap' HOST '10.0.0.0/8';
=> ALTER AUTHENTICATION vldap2 PRIORITY 0;
=> ALTER AUTHENTICATION vldap2 SET
      host='ldap://ldap.example.com/search',
      basedn='dc=example,dc=com',
      search_attribute='Marketing';
=> GRANT AUTHENTICATION vldap2 to public;

16.5 - LDAP 绑定方法

您可以使用以下两种 LDAP 方法来在 LDAP 服务器上对 Vertica 数据库进行身份验证。

  • 绑定 — 当 Vertica 连接到 LDAP 服务器并使用 CN 和密码绑定时，使用 LDAP 绑定。（这些值是登录到数据库的用户的用户名和密码）。当您的 LDAP 帐户的 CN 字段与数据库中定义的用户名的 CN 字段匹配时，使用捆绑方法。有关详细信息，请参阅配置 LDAP 捆绑的工作流程。

  • 搜索和绑定 — 当您的 LDAP 帐户的 CN 字段是用户的全称或与数据库中定义的用户名不匹配时，使用 LDAP 搜索和绑定。对于搜索和捆绑，用户名通常在另一个字段中，如 标准 Active Directory 环境中的 UID 或 sAMAccountName。搜索和捆绑需要组织的 Active Directory 信息。这些信息能让 Vertica 登录到 LDAP 服务器并搜索指定的字段。有关详细信息，请参阅LDAP 搜索和捆绑配置工作流。

    如果您正在使用搜索和捆绑，可通过服务帐户简化服务器端配置。此外，您无需存储 Active Directory 密码。

LDAP 匿名绑定

Anonymous binding 是一个 LDAP 服务器函数。匿名捆绑不需要 binddn 和 bindpasswd，因此允许客户无需登录即可连接和搜索目录（捆绑和搜索）。

当您使用管理控制台 (Management Console) 配置 LDAP 身份验证时，也不需要登录。

16.5.1 - 配置 LDAP 捆绑的工作流程

要配置您的 Vertica 数据库，以使用 LDAP 捆绑对客户端进行身份验证，请遵循以下步骤：

  1. 获取服务帐户。有关信息，请参阅 [LDAP 产品文档](https://msdn.microsoft.com/en-us/library/aa772152(v=vs.85)。您无法使用连接参数中的服务帐户进行 LDAP 捆绑。

  2. 比较用户的 LDAP 帐户名及其 Vertica 用户名。例如，如果 John Smith 的 Active Directory (AD) sAMAccountName = jsmith，他的 Vertica 用户名必须是 jsmith。

    但是，LDAP 帐户不必与数据库用户名匹配，如以下示例中所示：

    => CREATE USER r1 IDENTIFIED BY 'password';
=> CREATE AUTHENTICATION ldap1  METHOD 'ldap' HOST '172.16.65.177';
=> ALTER AUTHENTICATION ldap1 SET HOST=
   'ldap://172.16.65.10',basedn='dc=dc,dc=com',binddn_suffix=',ou=unit2,dc=dc,dc=com',binddn_prefix='cn=use';
=> GRANT AUTHENTICATION ldap1 TO r1;

    \! ${TARGET}/bin/vsql -p $PGPORT -U r1 -w $LDAP_USER_PASSWD -h ${HOSTNAME} -c
   "select user_name, client_authentication_name from sessions;"
 user_name | client_authentication_name
-----------+----------------------------
 r1        | ldap
(1 row)

  3. 针对您的 LDAP 或 AD 服务器从一个 Vertica 节点运行 ldapsearch。验证到服务器的连接，并确定相关字段的值。运行 ldapsearch 有助于构建配置 LDAP 身份验证所需的客户端身份验证字符串。

    在下述示例中，对于其 CN 包含用户名 jsmith 的任何用户，ldapsearch 将返回 CN、DN 和 sAMAccountName 字段（若存在）。此搜索只有对允许匿名捆绑的 LDAP 服务器执行才会成功：

    $ ldapsearch -x -h 10.10.10.10 -b "ou=Vertica Users,dc=CompanyCorp,dc=com"
'(cn=jsmith*)' cn dn uid sAMAccountName

    ldapsearch 返回以下结果。LDAP 捆绑的相关信息显示为粗体：

    # extended LDIF
#
# LDAPv3
# base <ou=Vertica Users,dc=CompanyCorp,dc=com> with scope subtree
# filter: (cn=jsmith*)
# requesting: cn dn uid sAMAccountName
#
# jsmith, Users, CompanyCorp.com
dn:cn=jsmith,ou=Vertica Users,dc=CompanyCorp,dc=com
cn: jsmith
uid: jsmith
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

  4. 基于 ldapsearch 提供的信息创建新的身份验证记录。在 ldapsearch 条目中，CN 是用户名 jsmith，所以您无需设置它。Vertica 自动将 CN 设置为尝试建立连接的用户的用户名。Vertica 使用该 CN 捆绑 LDAP 服务器。

    => CREATE AUTHENTICATION v_ldap_bind METHOD 'ldap' HOST '0.0.0.0/0';
=> GRANT AUTHENTICATION v_ldap_bind TO public;
=> ALTER AUTHENTICATION v_ldap_bind SET
host='ldap://10.10.10.10/',
basedn='DC=CompanyCorp,DC=com',
binddn_prefix='cn=',
binddn_suffix=',OU=Vertica Users,DC=CompanyCorp,DC=com';

有关详细信息，请参阅 LDAP 捆绑参数。

16.5.2 - LDAP 搜索和捆绑配置工作流

要配置您的 Vertica 数据库，以使用 LDAP 搜索和捆绑对客户端进行身份验证，请遵循以下步骤：

  1. 获取服务帐户。有关信息，请参阅 [LDAP 产品文档](https://msdn.microsoft.com/en-us/library/aa772152(v=vs.85)。

  2. 从一个 Vertica 节点针对您的 LDAP 或 AD 运行 ldapsearch。验证到服务器的连接，并确定相关字段的值。运行 ldapsearch 有助于构建配置 LDAP 身份验证所需的客户端身份验证字符串。

    在下述示例中，对于其 CN 中包含用户名 John 的任何用户，ldapsearch 将返回 CN、DN 和 sAMAccountName fields 字段（若存在）。此搜索只有对允许匿名捆绑的 LDAP 服务器执行才会成功：

    $ ldapsearch -x -h 10.10.10.10 -b 'OU=Vertica Users,DC=CompanyCorp,DC=com' -s sub -D
'CompanyCorp\jsmith' -W '(cn=John*)' cn dn uid sAMAccountName

  3. 查看 ldapsearch 返回的结果。搜索和捆绑的相关信息显示为粗体：

    # extended LDIF
#
# LDAPv3
# base <OU=Vertica Users,DC=CompanyCorp,DC=com> with scope subtree
# filter: (cn=John*)
# requesting: cn dn sAMAccountName
#
# John Smith, Vertica Users, CompanyCorp.com
dn: CN=jsmith,OU=Vertica Users,DC=CompanyCorp,DC=com
cn: Jsmith
sAMAccountName: jsmith
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

  4. 创建客户端身份验证记录。cn 属性包含您想要的用户名 — jsmith。将您的搜索属性设置为 CN 字段，以便搜索找到相应帐户。

    => CREATE AUTHENTICATION v_ldap_bind_search METHOD 'ldap' HOST '10.10.10.10';
=> GRANT AUTHENTICATION v_ldap_bind_search TO public;
=> ALTER AUTHENTICATION v_ldap_bind_search SET
host='ldap://10.10.10.10',
basedn='OU=Vertica,DC=CompanyCorp,DC=com',
binddn='CN=jsmith,OU=Vertica Users,DC=CompanyCorp,DC=com',
bind_password='password',
search_attribute='CN';

有关详细信息，请参阅 LDAP 绑定和搜索参数

17 - OAuth 2.0 身份验证

用户无需使用用户名和密码即可向 Vertica 验证身份，具体操作为：首先通过身份提供程序验证其身份，然后接收 OAuth 令牌并将令牌传递给 Vertica。

Vertica 中的 OAuth 通过 Keycloak 和 Okta 进行测试，但如果其他提供程序支持 RFC 7662 令牌自省标准，也可以使用。

17.1 - 配置 OAuth 身份验证

有关 ODBC OAuth 连接属性的列表，请参阅 ODBC DSN 连接属性。

以下过程将：

  1. 配置 Keycloak 18.0。

  2. 创建 OAuth 身份验证记录。

  3. 使用 POST 请求检索访问令牌。

  4. 使用示例应用程序 sample application 向 Vertica 验证身份，并将访问令牌作为实参和令牌刷新参数（可选）传递。

配置 keycloak

以下过程将在 203.0.113.1 上配置 Keycloak 18.0.0 服务器。

使用 TLS（可选）

如果要使用 TLS，您必须获取由受信任的 CA 签名的 Keycloak 证书和密钥。为方便起见，此示例将使用自签名 CA。

  1. 生成 CA 证书：

    => CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;
CREATE KEY

=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/C N=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;
CREATE CERTIFICATE

  2. 生成由您的 CA 签名的服务器密钥和证书，将证书的 subjectAltName 设置为您的 Keycloak 服务器的 DNS 和/或 IP 地址：

    => CREATE KEY keycloak_key TYPE 'RSA' LENGTH 2048;
CREATE KEY

=> CREATE CERTIFICATE keycloak_cert
SUBJECT '/C=US/ST=Massachussets/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Server'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Keycloak CA', 'extendedKeyUsage' = 'serverAuth', 'subjectAltName' = 'DNS.1:dnsserver,IP:203.0.113.1'
KEY keycloak_key;
CREATE CERTIFICATE

  3. 使用生成的密钥的 key 列内容创建文件 keycloak_directory/conf/keyfile.pem：

    => SELECT key FROM cryptographic_keys WHERE name = 'keycloak_key';

  4. 使用生成的证书的 certificate_text 列内容创建文件 keycloak_directory/conf/certfile.pem：

    => SELECT certificate_text FROM certificates WHERE name = 'keycloak_cert';

  5. 将生成的 CA 证书的 certificate_text 列内容附加到系统的 CA 捆绑包中。默认 CA 捆绑包路径和格式因分发版而异；有关详细信息，请参阅 SystemCABundlePath：

    => SELECT certificate_text FROM certificates WHERE name = 'SSCA_cert';

  6. 设置 SystemCABundlePath 配置参数：

    => ALTER DATABASE DEFAULT SET SystemCABundlePath = 'path/to/ca_bundle';

启动 keycloak

  1. 输入以下命令获取最小配置，以创建 Keycloak 管理员并在 start-dev 模式下启动 Keycloak：

    $ KEYCLOAK_ADMIN=kcadmin
$ export KEYCLOAK_ADMIN
$ KEYCLOAK_ADMIN_PASSWORD=password
$ export KEYCLOAK_ADMIN_PASSWORD
$ cd keycloak_directory/bin/
$ ./kc.sh start-dev --hostname 203.0.113.1 --https-certificate-file ../conf/certfile.pem --https-certificate-key-file=../conf/keyfile.pem

  2. 使用浏览器打开 Keycloak 控制台（这些示例使用默认端口）：

    • 对于 HTTP：http://203.0.113.1:8080

    • 对于 HTTPS：http://203.0.113.1:8443

  3. 以管理员身份登录。

  4. （可选）为了更加方便地测试 OAuth，请导航到领域设置 (Realm Settings) > 令牌 (Tokens)，然后将访问令牌生命期 (Access Token Lifespan) 增加到更大的值（默认值为 5 分钟）。

创建 Vertica 客户端

  1. 导航到客户端 (Clients) 并单击创建 (Create)。此时会显示添加客户端 (Add Client) 页面。

  2. 在客户端 ID (Client ID) 中，输入 vertica。

  3. 单击保存 (Save)。此时会显示客户端配置页面。

  4. 在设置 (Settings) 选项卡中，使用访问类型 (Access Type) 下拉菜单选择机密 (confidential)。

  5. 在凭据 (Credentials) 选项卡中，记下密码 (Secret)。这是用于在令牌过期时刷新令牌的客户端密码。

创建 Keycloak 用户

Keycloak 用户可映射到同名的 Vertica 用户。此示例创建了一个 Keycloak 用户 oauth_user。

  1. 在用户 (Users) 选项卡中，单击添加用户 (Add user)。此时会显示添加用户 (Add user) 页面。

  2. 在用户名 (Username) 中，输入 oauth_user。

  3. 在凭据 (Credentials) 选项卡中，输入密码。

配置 Vertica

创建身份验证记录

为 OAuth 创建身份验证记录。

以下 身份验证记录v_oauth 使用 OAuth 令牌（而不是用户名和密码）对来自任何 IP 地址的用户进行身份验证，并且使用以下参数。身份提供者是 Keycloak 18.0.0：

  • client_id：机密客户端 vertica 在 Keycloak 中注册。

  • client_secret：客户端密钥，由 Keycloak 生成。

  • discovery_url：也称为 OpenID 提供者配置文档，这是包含有关身份提供者的配置和端点的信息的端点。

=> CREATE AUTHENTICATION v_oauth METHOD 'oauth' HOST '0.0.0.0/0'
=> ALTER AUTHENTICATION v_oauth SET client_id = 'vertica';
=> ALTER AUTHENTICATION v_oauth SET client_secret = 'client_secret';
=> ALTER AUTHENTICATION v_oauth SET discovery_url = 'https://203.0.113.1:8443/realms/myrealm/.well-known/openid-configuration';
=> ALTER AUTHENTICATION v_oauth SET introspect_url = 'https://203.0.113.1:8443/realms/myrealm/protocol/openid-connect/token/introspect';

创建 Vertica 用户

Vertica 用户可映射到用户名相同的 Keycloak 用户。

  1. 要映射到 Keycloak 用户 oauth_user，请创建一个同名的 Vertica 用户。无需指定密码，因为身份验证由身份提供程序执行：

    => CREATE USER oauth_user;

  2. 将 OAuth 身份验证记录授予用户（或其角色）：

    => GRANT AUTHENTICATION v_oauth TO oauth_user;
=> GRANT ALL ON SCHEMA PUBLIC TO oauth_user;

检索访问令牌

获取 OAuth 访问令牌的一种简单方法是将 POST 请求发送到令牌端点，同时提供 Keycloak 用户的凭据。例如，oauth_user：

$ curl --location --request POST 'http://203.0.113.1:8080/realms/master/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'username=oauth_user' \
--data-urlencode 'password=oauth_user_password' \
--data-urlencode 'client_id=vertica' \
--data-urlencode 'client_secret=client_secret' \
--data-urlencode 'grant_type=password'

如果身份验证正确，Keycloak 会以 JSON 的格式作出响应。然后，您可以将返回的访问令牌、刷新令牌和范围与相应的连接属性一起使用。

{
   "access_token":"access_token",
   "expires_in":60,
   "refresh_expires_in":1800,
   "refresh_token":"refresh_token",
   "token_type":"Bearer",
   "not-before-policy":0,
   "session_state":"6745892a-aa74-452f-b6b9-c45637193859",
   "scope":"profile email"
}

运行示例应用程序

在令牌过期之前，OAuth 示例应用程序至少会将访问令牌作为实参来对数据库进行身份验证。如果您希望示例应用程序在令牌过期后刷新令牌，您必须指定以下内容。示例应用程序会将这些内容放入 JSON 字符串：OAuthJsonConfig 或 (ODBC) oauthjsonconfig (JDBC)。

  • 刷新令牌

  • 客户端 ID

  • 客户端密码

  • 令牌 URL

ODBC

  1. 遵循 README 中的说明。

  2. 运行示例应用程序，同时将 OAuth 参数作为实参传递：

    • 在令牌过期之前进行身份验证：

      $ ./a.out --access-token OAuthAccessToken

    • 在访问令牌过期后进行身份验证并静默刷新访问令牌：

      $ ./a.out --access-token OAuthAccessToken
    --refresh-token OAuthRefreshToken
    --client-id OAuthClientID
    --client-secret OAuthClientSecret
    --token-url OAuthTokenURL

JDBC

  1. 遵循 README 中的说明。

  2. 运行示例应用程序，同时将 OAuth 参数作为实参传递：

    • 在令牌过期之前进行身份验证：

      $ mvn compile exec:java -Dexec.mainClass=OAuthSampleApp -Dexec.args="vertica_host database_name --access-token oauthaccesstoken"

    • 在访问令牌过期后进行身份验证并静默刷新访问令牌：

      $ mvn compile exec:java -Dexec.mainClass=OAuthSampleApp -Dexec.args="vertica_host database_name --access-token oauthaccesstoken
    --refresh_token oauthrefreshtoken
    --client-id oauthclientid
    --client-secret oauthclientsecret
    --token-url oauthtokenurl"

故障排除

要获取 TLS 的调试信息，请使用 -Djavax.net.debug=ssl 标记。

将 CA 证书导入 Java 信任库

如果您通过 TLS 配置身份提供程序（即，如果您对令牌或刷新 URL 使用 HTTPS 端点），且其证书不是由熟知的 CA 颁发的，则必须使用 keytool 导入颁发机构的 CA 证书。

例如，将证书 keycloak/cert.crt 添加到 Java 信任库：

$ keytool -trustcacerts -keystore /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.261-2.6.22.2.el7_8.x86_64/jre/lib/security/cacerts -storepass changeit -importcert -alias keycloak -file /keycloak/cert.crt

18 - TLS 身份验证

tls 身份验证方法使用在常用名 (CN) 字段中指定有效数据库用户名的证书，对可以建立相互模式客户端-服务器 TLS 连接的用户进行身份验证。

在创建和使用 tls 身份验证方法之前，必须将 Vertica 配置为使用相互模式客户端-服务器 TLS（默认情况下禁用）。

18.1 - 使用 TLS 进行客户端身份验证

获授tls身份验证记录的数据库用户或角色可以使用 TLS 证书向 Vertica 验证身份。

先决条件

必须将 Vertica 配置为使用相互模式客户端-服务器 TLS。

在相互模式下，客户端和服务器在连接之前必须验证彼此的身份。在此模式下，Vertica 可验证客户端的身份，且可以通过其证书对客户端进行身份验证。

配置 TLS 身份验证

以下部分将为客户端生成一个私钥和证书。为简单起见，该示例使用以下自签名 CA 证书 SSCA_cert 对客户端证书进行签名（在该示例的上下文中，该自签名证书还对 Vertica 数据库的服务器证书进行签名）。

=> CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;
=> CREATE CA CERTIFICATE SSCA_cert
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Vertica Root CA'
VALID FOR 3650
EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
KEY SSCA_key;

而在生产环境中，则应该使用来自受信任证书颁发机构的 CA 证书。

以下示例将 Vertica 配置为使用包含方法 tls 的身份验证记录来对数据库用户 Bob 进行身份验证：

  1. 生成客户端的私钥：

    => CREATE KEY client_key_bob TYPE 'RSA' LENGTH 2048;

  2. 生成客户端的证书，同时为常用名 (CN) 字段指定数据库用户。此示例为数据库用户 Bob 创建了一个证书：

    => CREATE CERTIFICATE client_cert_bob
SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=Bob/emailAddress=bob@example.com'
SIGNED BY SSCA_cert
EXTENSIONS 'nsComment' = 'Vertica client cert', 'extendedKeyUsage' = 'clientAuth'
KEY client_key_bob;

  3. 导出客户端的私钥和证书：

    $ vsql -At -c "SELECT key FROM cryptographic_keys WHERE name = 'client_key_bob';" -o client_key_bob.key
$ vsql -At -c "SELECT certificate_text FROM certificates WHERE name = 'client_cert_bob';" -o client_cert_bob.crt

  4. 将证书复制或移动到客户端认可的位置。此示例适用于 vsql：

    $ mkdir -p ~/.vsql
$ cp client_cert_bob.crt ~/.vsql/client.crt
$ cp client_key_bob.key ~/.vsql/client.key
$ chmod 600 ~/.vsql/client.key ~/.vsql/client.crt
$ chown -R bob ~/.vsql ~/.vsql/client.key ~/.vsql/client.crt

  5. 创建 tls 身份验证记录：

    => CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0';

  6. 将身份验证记录授予 Bob 或其默认角色之一：

    => GRANT AUTHENTICATION v_tls_auth TO Bob;

拒绝明文连接

您可以创建拒绝来自指定 IP 范围的远程连接的身份验证记录。

例如，要拒绝所有纯文本的客户端连接，按如下所示指定 reject 身份验证方法和 HOST NO TLS 访问方法：

=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '0.0.0.0/0';  --IPv4
=> CREATE AUTHENTICATION RejectNoSSL METHOD 'reject' HOST NO TLS '::/0';       --IPv6