6. 强身份验证 ¶
本章内容包括:
6.1. 强身份验证简介 ¶
6.1.1. 关于强身份验证 ¶
当用户访问一个系统时,系统通常会要求用户提供一些信息来标志自己身份和使用系统的能力。系统验证这些信息来判断是否允许用户访问、用户可访问哪些功能。这便是用户认证的过程。 当系统的用户数量庞大时,对系统账号信息的管理和使用会是一个复杂问题。在系统内部处理这个问题可能偏离了系统本身应提供的功能,因此将其分离出来交给另一个服务来完成是一个比较好的解决方法。
身份认证是数据库服务器建立客户端身份的过程,并且服务器决定客户端应用是否被允许以请求的数据库用户名来连接。KingbaseES提供多种不同的身份认证方式。密码是最常见的身份验证方式,KingbaseES还通过支持多种第三方身份验证服务来启用强身份验证。
6.1.2. 强身份验证的工作原理 ¶
第三方身份验证服务器与数据库,客户端配合使用,基本的工作原理如下步骤:
-
客户端(或者运行客户端应用的用户)向身份验证服务器提供密码或者令牌等信息;
-
身份验证服务器验证用户身份并将凭证返回给客户端;
-
客户端将这些凭证和服务请求传递给数据库服务器;
-
数据库服务器将凭证发送给身份验证服务器请求验证;
-
身份验证服务器检查凭证并通知数据库服务器验证结果。如果身份验证服务器接受凭证,则身份验证成功。如果身份验证服务器拒绝了凭证,则客户端的请求将被拒绝。
6.1.3. 支持的强身份验证方法 ¶
KingbaseES数据库支持多种第三方服务认证的方法,如下表所示:
认证方式 | 说明 |
---|---|
scram-sha-256 | 执行SCRAM-SHA-256认证以验证用户的密码 |
md5 | 执行SCRAM-SHA-256或MD5认证以验证用户的密码 |
sm3 | 使用SM3算法加密用户口令来进行身份认证 |
scram-sm3 | 使用SCRAM-SM3算法加密用户口令来进行身份认证 |
sm4 | 使用SM4算法加密用户口令来进行身份认证 |
Kerberos | Kerberos是一个依赖于共享机密的可信第三方身份验证系统,支持使用keberos服务器进行集中身份鉴别 |
ldap | LDAP是一种通过IP协议提供访问控制和维护分布式信息的目录信息,支持使用LDAP服务器认证 |
radius | RADIUS是一种客户端/服务器的安全协议,支持使用LDAP服务器认证 |
cert | 使用 SSL 客户端证书认证 |
gss | 用GSSAPI 认证用户。只对TCP/IP连接可用。 |
sspi | 用 SSPI 来认证用户。只在Windows上可用。 |
ident | 允许客户端上的特定操作系统用户连接到数据库。Ident认证只能在TCIP/IP连接上使用。 |
peer | 从操作系统获得客户端的操作系统用户,并且检查它是否匹配被请求的数据库用户名。这只对本地连接可用。 |
pam | 使用操作系统提供的可插入认证模块服务(PAM)认证 |
bsd | 使用由操作系统提供的 BSD 认证服务进行认证 |
kcert | 用于指定证书登录,证书登录算法支持RSA,SM2 |
kcert_scram | 指定多重鉴别,在证书认证通过后,再进行scram-sha-256认证用户密码 |
kcert_sm3 | 指定多重鉴别,在证书认证通过后,再进行sm3认证用户密码 |
具体认证方式的配置和使用将在后续章节详细介绍。
6.2. 身份验证相关的配置文件 ¶
6.2.1. sys_hba.conf文件 ¶
客户端认证是由一个配置文件(通常名为 sys_hba.conf
并被存放在数据库集簇目录中)控制(HBA表示基于主机的认证)。在 initdb
初始化数据目录时,它会安装一个默认的 sys_hba.conf
文件。不过我们也可以把认证配置文件放在其它地方,可配置hba_file参数。
sys_hba.conf
文件的常用格式是一组记录,每行一条。空白行将被忽略, #
注释字符后面的任何文本也被忽略。记录不能跨行。一条记录由若干用空格和/或制表符分隔的域组成。如果域值用双引号包围,那么它可以包含空白。在数据库、用户或地址域中引用一个关键字(例如, all
或 replication
)将使该词失去其特殊含义,并且只是匹配一个有该名字的数据库、用户或主机。
每条记录指定一种连接类型、一个客户端 IP地址范围(如果和连接类型相关)、一个数据库名、一个用户名以及对匹配这些参数的连接使用的认证方法。第一条匹配连接类型、客户端地址、连接请求的数据库和用户名的记录将被用于执行认证。这个过程没有“落空”或者“后备”的说法:如果选择了一条记录而且认证失败,那么将不再考虑后面的记录。如果没有匹配的记录,那么访问将被拒绝。
记录可以是下面七种格式之一:
local database user auth-method [auth-options] host database user address auth-method [auth-options] hostssl database user address auth-method [auth-options] hostnossl database user address auth-method [auth-options] host database user IP-address IP-mask auth-method [auth-options] hostssl database user IP-address IP-mask auth-method [auth-options] hostnossl database user IP-address IP-mask auth-method [auth-options] hostgssenc database user IP-address IP-mask auth-method [auth-options] hostnogssenc database user IP-address IP-mask auth-method [auth-options]
各个域的含义如下:
local
这条记录匹配企图使用 Unix 域套接字的连接。如果没有这种类型的记录,就不允许 Unix 域套接字连接。
host
这条记录匹配企图使用 TCP/IP 建立的连接。
host
记录匹配SSL或者non-SSL连接企图,也匹配GSSAPI加密或non-GSSAPI加密的连接企图。注意
除非服务器带着合适的 listen_addresses 配置参数值启动,否则将不可能进行远程的 TCP/IP 连接,因为默认的行为是只监听在本地环回地址
localhost
上的 TCP/IP 连接。
hostssl
这条记录匹配企图使用 TCP/IP 建立的连接,但必须是使用SSL加密的连接。
要使用这个选项,编译服务器的时候必须打开SSL支持。此外,在服务器启动的时候必须通过设置 ssl 配置参数(详见 SSL客户端证书认证 )打开SSL。否则,
hostssl
记录会被忽略,并且会记录一个警告说它无法匹配任何连接。
hostnossl
这条记录的行为与
hostssl
相反;它只匹配那些在 TCP/IP上不使用SSL的连接企图。
hostgssenc
这条记录匹配企图使用 TCP/IP 建立的连接,但必须是使用GSSAPI加密的连接。
要使用这个选项,编译服务器的时候必须打开 GSSAPI 支持。 否则,
hostgssenc
记录会被忽略,并且会记录一个警告说它无法匹配任何连接。注意,只支持使用GSSAPI加密的认证方法是
gss
、reject
。
hostnogssenc
这条记录的行为与
hostgssenc
相反;它只匹配那些在 TCP/IP上不使用GSSAPI加密的连接企图。
database
指定记录所匹配的数据库名称。值
all
指定该记录匹配所有数据库。值sameuser
指定如果被请求的数据库和请求的用户同名,则匹配。值samerole
指定请求的用户必须是一个与数据库同名的角色中的成员(samegroup
是一个已经废弃了,但目前仍然被接受的samerole
同义词)。对于一个用于samerole
目的的角色,超级用户不会被考虑为其中的成员,除非它们是该角色的显式成员(直接或间接),而不是由于超级用户的原因。值replication
指定如果一个物理复制连接被请求则该记录匹配(注意复制连接不指定任何特定的数据库)。在其它情况里,这就是一个特定的KingbaseES数据库名字。可以通过用逗号分隔的方法指定多个数据库,也可以通过在文件名前面放@
来指定一个包含数据库名的文件。
user
指定这条记录匹配哪些数据库用户名。值
all
指定它匹配所有用户。否则,它要么是一个特定数据库用户的名字或者是一个有前导+
的组名称(回想一下,在KingbaseES里,用户和组没有真正的区别,+
实际表示“匹配这个角色的任何直接或间接成员角色”,而没有+
记号的名字只匹配指定的角色)。出于这个目的,如果超级用户显式的是一个角色的成员(直接或间接),那么超级用户将只被认为是该角色的一个成员而不是作为一个超级用户。多个用户名可以通过用逗号分隔的方法提供。一个包含用户名的文件可以通过在文件名前面加上@
来指定。
address
指定这个记录匹配的客户端机器地址。这个域可以包含一个主机名、一个 IP 地址范围或下文提到的特殊关键字之一。
一个 IP 地址范围以该范围的开始地址的标准数字记号指定,然后是一个斜线(
/
) 和一个CIDR掩码长度。掩码长度表示客户端 IP 地址必须匹配的高序二进制位位数。在给出的 IP 地址中,这个长度的右边的二进制位必须为零。 在 IP 地址、/
和 CIDR 掩码长度之间不能有空白。这种方法指定一个 IPv4 地址范围的典型例子是:
172.20.143.89/32
用于一个主机,172.20.143.0/24
用于一个小型网络,10.6.0.0/16
用于一个大型网络。 一个单主机的 IPv6 地址范围看起来像这样:::1/128
(IPv6 回环地址), 一个小型网络的 IPv6 地址范围则类似于:fe80::7a31:c1ff:0000:0000/96
。0.0.0.0/0
表示所有 IPv4 地址,并且::0/0
表示所有 IPv6 地址。要指定一个单一主机,IPv4 用一个长度为 32 的 CIDR 掩码或者 IPv6 用 长度为 128 的 CIDR 掩码。在一个网络地址中,不要省略结尾的零。一个以 IPv4 格式给出的项将只匹配 IPv4 连接并且一个以 IPv6 格式给出的项将只匹配 IPv6 连接,即使对应的地址在 IPv4-in-IPv6 范围内。请注意如果系统的 C 库不支持 IPv6 地址,那么 IPv6 格式中的项将被拒绝。
你也可以写
all
来匹配任何 IP 地址、写samehost
来匹配任何本服务器自身的 IP 地址或者写samenet
来匹配本服务器直接连接到的任意子网的任意地址。如果指定了一个主机名(任何除 IP 地址单位或特殊关键字之外的都被作为主机名处理), 该名称会与客户端的 IP 地址的反向名字解析(例如使用 DNS 时的反向 DNS 查找)结果进行比较。主机名比较是大小写敏感的。如果匹配上,那么将在主机名上执行一次正向名字解析(例如正向 DNS 查找)来检查它解析到的任何地址是否等于客户端的 IP 地址。如果两个方向都匹配,则该项被认为匹配(
sys_hba.conf
中使用的主机名应该是客户端 IP 地址的地址到名字解析返回的结果,否则该行将不会匹配。某些主机名数据库允许将一个 IP 地址关联多个主机名,但是当被要求解析一个 IP 地址时,操作系统将只返回一个主机名)。一个以点号(
.
)开始的主机名声明匹配实际主机名的后缀。因此.example.com
将匹配foo.example.com
(但不匹配example.com
)。当主机名在
sys_hba.conf
中被指定时,你应该保证名字解析很快。建立一个类似nscd
的本地名字解析缓存是一种不错的选择。另外,你可能希望启用配置参数log_hostname
来在日志中查看客户端的主机名而不是 IP 地址。这个域只适用于
host
、hostssl
和hostnossl
记录。注意
用户有时候会疑惑为什么这样处理的主机名看起来很复杂,因为需要两次名字解析(包括一次 客户端 IP 地址的反向查找)。在客户端的反向 DNS 项没有建立或者得到某些意料之外的主机名的情况下,这种方式会让该特性的使用变得复杂。这样做主要是为了效率:通过这种方式,一次连接尝试要求最多两次解析器查找,一次逆向以及一次正向。如果有一个解析器对于该地址有问题,这仅仅是客户端的问题。一种假想的替代实现是只做前向查找,这种方法不得不在每一次连接尝试期间解析
sys_hba.conf
中提到的每一个主机名。如果列出了很多名称,这就会很慢。并且如果主机名之一有解析器问题,它会变成所有人的问题。另外,一次反向查找也是实现后缀匹配特性所需的,因为需要知道实际的客户端主机名来与模式进行匹配。
注意这种行为与其他流行的基于主机名的访问控制实现相一致,例如 Apache HTTP Server 和 TCP Wrappers。
IP-address
IP-mask
这两个域可以被用作 ``IP-address``
/
``mask-length`` 记号法的替代方案。和指定掩码长度不同,实际的掩码被指定在一个单独的列中。例如,255.0.0.0
表示 IPv4 CIDR掩码长度 8,而255.255.255.255
表示 CIDR 掩码长度 32。这些域只适用于
host
、hostssl
和hostnossl
记录。
auth-method
指定当一个连接匹配这个记录时,要使用的认证方法。下面对可能的选择做了概述。
reject
无条件地拒绝连接。这有助于从一个组中“过滤出”特定主机,例如一个
reject
行可以阻塞一个特定的主机连接,而后面一行允许一个特定网络中的其余主机进行连接。
scram-sha-256
执行SCRAM-SHA-256认证来验证用户的口令。详见 口令加密认证 。
md5
执行SCRAM-SHA-256或MD5认证来验证用户的口令。详见 口令加密认证 。
sm3
使用SM3算法加密用户口令来进行身份认证。详见 口令加密认证 。
scram-sm3
使用SCRAM-SM3算法加密用户口令来进行身份认证。详见 口令加密认证 。
sm4
使用SM4算法加密用户口令来进行身份认证。详见 口令加密认证 。
password
要求客户端提供一个未加密的口令进行认证。因为口令是以明文形式在网络上发送的,所以我们不应该在不可信的网络上使用这种方式。详见 口令加密认证 。
gss
用 GSSAPI 认证用户。只对 TCP/IP 连接可用。详见 GSSAPI身份验证 。它可以与GSSAPI加密结合使用。
sspi
用 SSPI 来认证用户。只在 Windows上可用。详见 SSPI身份验证 。
ident
通过联系客户端的 ident 服务器获取客户端的操作系统名,并且检查它是否匹配被请求的数据库用户名。Ident 认证只能在 TCIP/IP连接上使用。当为本地连接指定这种认证方式时,将用 peer 认证来替代。详见 Ident身份验证 。
peer
从操作系统获得客户端的操作系统用户,并且检查它是否匹配被请求的数据库用户名。这只对本地连接可用。详见 Peer身份验证 。
ldap
使用LDAP服务器认证。详见 LDAP身份验证 。
radius
用 RADIUS 服务器认证。详见 RADIUS身份验证 。
cert
使用 SSL客户端证书认证 。详见 SSL客户端证书认证 。
pam
使用操作系统提供的可插入认证模块服务(PAM)认证。详见 PAM身份验证 。
bsd
使用由操作系统提供的 BSD 认证服务进行认证。详见 BSD身份验证 。
kcert
用于指定证书登录,证书登录算法支持RSA,SM2。详见 证书认证和多重鉴别 。
kcert_scram
指定多重鉴别,在证书认证通过后,再进行scram-sha-256认证用户密码。详见 证书认证和多重鉴别 。
kcert_sm3
指定多重鉴别,在证书认证通过后,再进行sm3认证用户密码。详见 证书认证和多重鉴别 。
auth-options
在
auth-method
域的后面,可以是形如name
=
value
的域,它们指定认证方法的选项。关于哪些认证方法可以用哪些选项的细节请见下文。除了下文列出的与方法相关的选项之外,还有一个与方法无关的认证选项
clientcert
,它可以在任何hostssl
记录中指定。这个选项能够设置verify-ca
或verify-full
。这两个选项都要求客户端提供一个有效的(受信任的)SSL证书,而verify-full
还要求证书中的cn
(Common Name)匹配用户名或适用的映射。 此行为类似于cert
身份验证方法(参见 SSL客户端证书认证 ),但允许将客户端证书的验证与支持hostssl
条目的身份验证方法配对。
用 @
结构包括的文件被读作一个名字列表,它们可以用空白或者逗号分隔。注释用 #
引入,就像在 sys_hba.conf
中那样,并且允许嵌套 @
结构。除非跟在 @
后面的文件名是一个绝对路径,文件名都被认为是相对于包含引用文件的目录。
因为每一次连接尝试都会顺序地检查 sys_hba.conf
记录,所以这些记录的顺序是非常关键的。通常,靠前的记录有比较严的连接匹配参数和比较弱的认证方法,而靠后的记录有比较松的匹配参数和比较强的认证方法。
在启动以及主服务器进程收到SIGHUP信号时, sys_hba.conf
文件会被读取。 如果你在活动的系统上编辑了该文件,您需要向邮件管理员发出信号(使用 sys_ctl reload
,调用SQL函数 sys_reload_conf()
,或使用 kill -HUP
)使其重新读取文件。
注意
前面的说明在Microsoft Windows上不为真:在Windows上, sys_hba.conf
文件中的任何更改会立即被应用到后续的新连接上。
系统视图 sys_hba_file_rules 有助于预先测试对 sys_hba.conf
文件的更改,该视图也可以在该文件的装载没有产生预期效果时用于诊断问题。该视图中带有非空 error
域的行就表示该文件对应行中存在问题。
提示
要连接到一个特定数据库,一个用户必须不仅要通过 sys_hba.conf
检查,还必须要有该数据库上的 CONNECT
权限。如果你希望限制哪些用户能够连接到哪些数据库,授予/撤销 CONNECT
权限通常比在 sys_hba.conf
项中设置规则简单。
下列示例中展示了 sys_hba.conf
项的一些例子。不同认证方法的详情请见下一节。
示例 sys_hba.conf 项
# 允许来自任意具有 IP 地址192.168.93.x 的主机上任意 # 用户以 ident 为该连接所报告的相同用户名连接到 # 数据库 "kingbase"(通常是操作系统用户名)。 # # TYPE DATABASE USER ADDRESS METHOD host kingbase all 192.168.93.0/24 ident # 如果用户的口令被正确提供, # 允许来自主机 192.168.12.10 # 的任意用户连接到数据库 "kingbase"。 # # TYPE DATABASE USER ADDRESS METHOD host kingbase all 192.168.12.10/32 scram-sha-256 # 如果前面没有“host”行, # 这三行将拒绝来自192.168.54.1的所有连接 # (因为那些项将首先被匹配), # 但是允许来自互联网其他任何地方GSSAPI加密连接。 # 零掩码导致主机IP 地址中的所有位都不会被考虑 # 因此它匹配任意主机。 # 允许不加密的GSSAPI连接(“fall through” # 到第三行,因为“hostgssenc”只匹配加密的GSSAPI连接), # 但是只能从192.168.12.10开始。 # # TYPE DATABASE USER ADDRESS METHOD host all all 192.168.54.1/32 reject hostgssenc all all 0.0.0.0/0 gss host all all 192.168.12.10/32 gss # 如果没有前面的 "host" 行,这两 # 行将拒绝所有来自 192.168.54.1 # 的连接(因为那些项将首先被匹配), # 但是允许来自互联网其他任何地方的 # GSSAPI 连接。零掩码导致主机 # IP 地址中的所有位都不会被考虑, # 因此它匹配任意主机。 # # TYPE DATABASE USER ADDRESS METHOD host all all 192.168.54.1/32 reject host all all 0.0.0.0/0 gss # 允许来自 192.168.x.x 主机的用户 # 连接到任意数据库,如果它们能够 # 通过 ident 检查。例如,假设 ident # 说用户是 "bryanh" 并且他要求以 # KingbaseES 用户 "guest1" 连接, # 如果在 sys_ident.conf 有一个映射 # "omicron" 的选项说 "bryanh" 被 # 允许以 "guest1" 连接,则该连接将被允许。 # # TYPE DATABASE USER ADDRESS METHOD host all all 192.168.0.0/16 ident map=omicron # 如果这些是本地连接的唯一三行, # 它们将允许本地用户只连接到它们 # 自己的数据库(与其数据库用户名 # 同名的数据库),不过管理员和角 # 色 "support" 的成员除外(它们可 # 以连接到所有数据库)。文件 # $KINGBASE_DATA/admins 包含一个管理员 # 名字的列表。在所有情况下都要求口令。 # # TYPE DATABASE USER ADDRESS METHOD local sameuser all md5 local all @admins md5 local all +support md5 # 上面的最后两行可以被整合为一行: local all @admins,+support md5 # 数据库列也可以用列表和文件名: local db1,db2,@demodbs all md5
6.2.2. 用户名映射 ¶
当使用像 Ident 或者 GSSAPI 之类的外部认证系统时,发起连接的操作系统用户名可能不同于要被使用的数据库用户(角色)。在这种情况下,一个用户名映射可被用来把操作系统用户名映射到数据库用户。要使用用户名映射,在 sys_hba.conf
的选项域指定 map=map-name
。此选项支持所有接收外部用户名的认证方法。由于不同的连接可能需要不同的映射,在 sys_hba.conf
中的 map-name
参数中指定要被使用的映射名,用以指示哪个映射用于每个个体连接。
用户名映射定义在 ident 映射文件中,默认情况下它被命名为 sys_ident.conf
并被存储在集簇的数据目录中(不过,可以把该映射文件放在其他地方,见 ident_file 配置参数)。ident 映射文件包含的行的一般格式:
map-name system-username database-username
以在 sys_hba.conf
中同样的方式处理注释和空白。 map-name
是一个任意名称,它将被用于在 sys_hba.conf
中引用该映射。其他两个域指定一个操作系统用户名和一个匹配的数据库用户名。相同的 map-name
可以被反复地用在同一个映射中指定多个用户映射。
对于一个给定操作系统用户可以对应多少个数据库用户没有限制,反之亦然。因此,一个映射中的项应该被看成意味着“这个操作系统用户被允许作为这个数据库用户连接”,而不是按时它们等价。如果有任何映射项把从外部认证系统获得的用户名和用户要求的数据库用户名配对,该连接将被允许。
如果 system-username
域以一个斜线( /
)开始,域的剩余部分被当做一个正则表达式(KingbaseES的正则表达式语法详见 正则表达式细节 )。正则表达式可以包括一个单一的捕获,或圆括号子表达式,然后它可以在 database-username
域中以 \1
(反斜线一)被引用。这允许在单个行中多个用户名的映射,这特别有助于简单的语法替换。例如,这些项:
mymap /^(.*)@mydomain\.com$ \1 mymap /^(.*)@otherdomain\.com$ guest
将为用户移除以 @mydomain.com
结束的系统用户名的域部分,以及允许系统名以 @otherdomain.com
结束的任意用户作为 guest
登入。
提示
记住在默认情况下,一个正则表达式可以只匹配字符串的一部分。如上例所示,使用 ^
和 $
来强制匹配整个系统用户名通常是明智的。
在启动以及主服务器进程收到SIGHUP信号时, sys_ident.conf
文件会被读取。如果你在活动的系统上编辑了该文件,您需要向邮件管理员发出信号(使用 sys_ctl reload
,调用SQL函数 sys_reload_conf()
,或使用 kill -HUP
))使其重新读取文件。
下列示例中展示了一个可以联合 sys_hba.conf
文件使用的 sys_ident.conf
文件。在这个例子中,对于任何登入到 192.168 网络上的一台机器的用户, 如果该用户没有操作系统用户名 bryanh
、 ann
或 robert
,则他不会被授予访问权限。只有当 Unix 用户 robert
尝试作为KingbaseES用户 bob
(而不是作为 robert
或其他人)连接时,他才被允许访问。 ann
只被允许作为 ann
连接。用户 bryanh
被允许以 bryanh
或者 guest1
连接。
示例 一个sys_ident.conf文件
# MAPNAME SYSTEM-USERNAME KDB-USERNAME omicron bryanh bryanh omicron ann ann # bob 在这些机器上有用户名 robert omicron robert bob # bryanh 也可以作为 guest1 连接 omicron bryanh guest1
6.3. Kerberos身份验证 ¶
6.3.1. 关于Kerberos身份验证 ¶
将KingbaseES数据库用户信息集中存储在第三方的Kerberos服务器中,用于用户请求Kingbase服务器时对其身份合法性进行集中管理,如对访问系统的用户权限进行认证、授权、用户信息维护更新等。第三方数据库是一种应用于分布式网络环境, 以加密为基础, 对用户及网络连接进行认证的增强网络安全的服务。
6.3.2. Kerberos协议原理 ¶
Kerberos 协议包括两种服务器: 一个认证服务器, 一个或多个门票分配服务器(TGS)。其认证协议基本结构如下图所示:
-
客户请求Kerberos 认证服务器发给接入Kerberos TGS (门票分配服务器) 的门票。请求以报文形式形成;
-
认证服务器在其数据库中查找客户实体,产生一个会话密钥, Kerberos 使用客户的秘密密钥对此会话密钥进行加密; 然后生成一TGT (门票分配许可证) , 该许可证包括客户实体名、地址、TGS 名、时间印记、时限、会话密钥等信息; 并用TGS 的秘密密钥(此密钥只有认证服务器和TGS 知道) 对TGT 进行加密,认证服务器把这两个加密报文发还给客户;
-
客户将第一个报文解密得到会话密钥, 然后生成一个认证单, 包括客户实体名、地址及时间印记, 并用会话密钥对认证单进行加密。然后, 向TGS 发出请求;
-
申请接入某一目标服务器的门票。此请求包括目标服务名称、收到Kerberos 发来的加过密的TGT 以及加密的认证单;
-
TGS 用其秘密密钥对TGT 进行解密, 使用TGT 中的会话密钥对认证单进行解密。然后将认证单中的信息与TGT 中的信息进行比较。此时, TGS 产生新的会话密钥供客户实体与目标服务器使用, 利用客户实体和TGS 用的会话密钥将新的会话密钥加密; 还将新的会话密钥加入客户向该服务器提交的有效门票;
-
之中, 门票中还包括客户实体名、网络地址、服务器名、时间印记、时限等, 并用目标服务器的秘密密钥将此门票加密; 然后将这两个报文发送给客户;
-
客户将接收到的报文解密后, 获得与目标服务器共用的会话密钥。这时, 客户制作一个新的认证单, 并用获得的会话密钥对该认证单进行加密。当请求进入访问目标服务器时, 将加密的认证单和从TGS 收到的门票一并发送给目标服务器。由于此认证单有会话密钥加密的明文信息, 从而证明发信人知道该密钥;
-
目标服务器对门票和认证单进行解密检查, 包括地址、时间印记、时限等。如果一切都核对无误, 服务器则知道了客户实体的身分, 并与之共享一个可用于他们之间秘密通信的加密密钥。
6.3.3. 配置Kerberos身份验证 ¶
6.3.3.1. 配置kerberos服务器 ¶
kerberos服务器的配置步骤如下:
-
修改/etc/hosts 文件;
-
配置/etc/krb5.conf 文件,如果没有该文件,则创建该文件;
-
生成kerberos的本地数据库 ;
-
kdb5_util create -r EXAMPLE.COM;
-
启动kdc服务 查看是否成功;
-
使用kadmin.local管理程序配置 ;
-
为管理员账号admin/admin指定权限;
-
启动kadmind服务程序,查看是否成功启动;
-
增加测试服务;
下面通过一个示例,来演示配置过程:
-
安装软件
krb5-libs krb5-server krb5-workstation
-
修改
/etc/hosts
文件(通过ifconifg命令查询服务器IP,例如:192.168.8.243)增加服务器ip信息:
192.168.8. 243 kerberos.example.com kerberos 192.168.8. 243 kdc.example.com kdc修改完成之后,保证下边两条命令能够ping通过:
Ping kerberos.example.com ping kdc.example.com
-
配置/etc/krb5.conf文件
查找: realms
确认在[realms]内kdc,admin_server,default_domain的值如下所示:
[realms] EXAMPLE.COM = { kdc = kdc.example.com:88 admin_server = kerberos.example.com:749 default_domain = example.com }以下为文件的样本:
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes [realms] EXAMPLE.COM = { kdc = kerberos.example.com:88 admin_server = kerberos.example.com:749 default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [kdc] profile = /usr/local/var/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
-
生成kerberos的本地数据库
kdb5_util create -r EXAMPLE.COM (注意:记住KDC master的口令)该命令将创建如下文件(缺省目录是:
/var/kerberos/krb5kdc/
)。这个命令用来生成kerberos的本地数据库principal,具体介绍如下:
principal:Kerberos database files 存放principal (数据和索引文件)
principal.ok:Kerberos database lock files
principal.kadm5:the Kerberos administrative database file
principal.kadm5.lock:the administrative database lock file
-
启动kdc服务,查看是否成功
service krb5kdc start查看启动是否成功:
ps -ef | grep krb5kdc
-
使用kadmin.local并回车,然后会出现如下提示信息:
Authenticating as principal root/admin@EXAMPLE.COM with password.kadmin.local:然后增加安全策略:
add_policy -maxlife 180days -minlife 2days -minlength 8 -minclasses 3 -history 10 default并增加管理员账号:
addprinc admin/admin输入管理员口令:
[admin12;](中括号内即为密码,包括分号)查看是否存在
admin/admin@EXAMPLE.COM
账号:listprincs创建一个包含密钥的keytab文件;
ktadd -k /usr/local/var/krb5kdc/kadm5.keytab kadmin/changepw退出程序:
quit
-
为管理员账号admin/admin指定权限
vim /var/kerberos/krb5kdc/kadm5.acl添加下面这一行:
admin/admin@EXAMPLE.COM *
-
启动kadmind服务程序
service kadmin start查看启动是否成功:
ps -ef | grep kadmind
-
增加测试服务
进入kadmin.local,将会出现如下提示:
kadmin.local Authenticating as principal root/admin@EXAMPLE.COM with password.kadmin.local:新增测试服务server_test:
addprinc server_test/kerberos.example.com 设置密码为[abcd110;](中括号内即为密码,包括分号)产生并导出服务server所使用的密钥:
ktadd -k /usr/local/var/krb5kdc/kadm5.keytab server_test/kerberos.example.com输入测试服务client_test:
addprinc client_test/kerberos.example.com 设置密码为[abcd110;](中括号内即为密码)退出程序:
quit
-
启动服务端测试程序
sserver -p 8899 -s server_test -S /usr/local/var/krb5kdc/kadm5.keytab;
6.3.3.2. 配置kerberos客户端 ¶
kerberos客户端的配置步骤如下:
-
修改
/etc/hosts
文件; -
获取client的TGT;
-
启动客户端测试程序;
-
获取
client/kerberos.example.com
的Kerberos TGT; -
启动客户端测试程序;
下面通过一个示例,来演示配置过程:
-
安装软件
krb5-libs krb5-server krb5-workstation
-
修改/etc/hosts文件(本地客户端IP为192.168.1.27):
192.168.8. 243 kerberos.example.com kerberos 192.168.8. 243 kdc.example.com kdc 192.168.1.27 test.example.com test保证
kerberos.example.com
,kdc.example.com
是否能够ping通:ping kerberos.example.com ping kdc.example.com ping test.example.com
-
修改/etc/krb5.conf,修改后的内容参考如下:
includedir /etc/krb5.conf.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt default_realm = EXAMPLE.COM default_ccache_name = KEYRING:persistent:%{uid} dns_lookup_kdc = false [realms] EXAMPLE.COM = { kdc = kdc.example.com:88 admin_server = kerberos.example.com:749 default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
-
测试机器能否正常连接kerberos服务器。获取
client/kerberos.example.com
的Kerberos TGT。客户端执行:
kinit client_test/kerberos.example.com 密码[test110;]
-
启动客户端测试程序
sclient kerberos.example.com 8899 server_test若测试成功,将会返回如下信息:
connected sendauth succeeded, reply is: reply len 53, contents: You are client_test/kerberos.example.com@EXAMPLE.COM
6.3.3.3. 配置KingbaseES服务器配置 ¶
KingbaseES服务器配置步骤如下:
-
启动服务器(kingbase在编译时加入—with-gssapi)创建jack用户,密码1234;
-
修改sys_hba.conf,修改认证方式;
-
修改kingbase配置文件kingbase.conf,确保能够连接到Kerberos服务器;
-
确保能够ping同Kerberos服务器;
-
远程登录Kerberos服务器,创建kingbase用户。
下面通过一个示例,来演示配置过程:
-
启动服务器(kingbase已经加入krb5编译选项kerberos)创建jack用户,密码1234:
CREATE USER jack WITH PASSWORD '1234';
-
修改sys_ident.conf,在最后一行新增用户名映射。若不添加用户名映射,kingbase服务器将无法匹配数据库中的用户名与kerberos服务器提供的用户名。
# MAPNAME SYSTEM-USERNAME KDB-USERNAME krbmap jack@EXAMPLE.COM jack
-
修改sys_hba.conf
1) 修改认证方式trust为gss: 2) 修改option: krb_realm=EXAMPLE.COM, map=krbmap. krb_realm限制仅EXAMPLE.COM域中的用户可以连接。map设置kerberos服务器和kingbase用户名之间的映射。
host all all 0.0.0.0/0 trust修改后如下:
host all all 192.168.0.0/16 gss krb_realm=EXAMPLE.COM map=krbmap
-
修改kingbase.conf
打开krb_server_keyfile,并赋值如下:
krb_server_keyfile = '/home2/bliu/p_install/etc/kadm5.keytab'注意
kadm5.keytab的默认位置是执行./configure时--prefix所指定目录下的etc目录,etc需要手动创建。
-
确保能够ping同Kerberos服务器
如果不能ping通服务器的话,则需要配置/etc/hosts。同Kerberos客户端。
-
远程登录Kerberos服务器,创建kingbase用户
切换到普通用户执行如下:
获取admin/admin的TGT,并根据提示输入密码
[admin12;]
kinit admin/amdin
输入kadmin回车,连接到Kerberos数据库管理服务进程kadmind:
/usr/kerberos/sbin/kadmin进入kadmin后会显示如下信息:
Couldn't open log file /var/log/kadmind.log: Permission denied Couldn't open log file /var/log/kadmind.log: Permission denied Authenticating as principal admin/admin@EXAMPLE.COM with password. Password for admin/admin@EXAMPLE.COM:<输入admin/admin的密码[admin12;]>注意
由于kerberos认证需要三台机器时间同步,相差不能超过五分钟,如果出现如下错误,请查看所用三台机器,确认时间是否同步。
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface
在Kerberos数据库中增加与数据用户同名的jack
kadmin: ank jack 根据提示输入密码 ``【admin12;】``
在kerberos数据库中增加kingbase的服务主记录
kadmin: ank -randkey kingbase/test.example.com
将kingbase的服务主记录导出到密钥表,确保导出的密钥表文件kadm5.keytab,kingbase拥有读权限,指令中的路径与上文中kingbase.conf内指定的路径相同。
kadmin: ktadd -k /home2/bliu/p_install/etc/kadm5.keytab kingbase/test.example.com kadmin: quit
重新启动kingbase服务器
./kingbase -D /data -h 192.168.1.27
6.3.4. 通过Kerberos身份验证连接KingbaseES ¶
完成Kerberos身份验证的配置后,就可以连接到KingbaseES数据库。步骤如下:
-
配置kingbase客户端/etc/hosts
-
获取用户TGT
-
判断是否登录成功。
下面通过一个示例,来演示配置过程:
-
安装软件
krb5-libs krb5-server krb5-workstation
-
配置kingbase客户端
/etc/hosts
,在(127.0.0.1 localhost.localdomain localhost
)下面增加:
192.168.8. 243 kerberos.example.com kerberos 192.168.8. 243 kdc.example.com kdc 192.168.1.27 test.example.com test
-
向kerberos服务器进行认证,获取用户TGT:
kinit jack 根据提示输入密码:[admin12;]检查是否获取TGT成功:
klist成功则会出现如下信息:
Default principal: jack@EXAMPLE.COM Valid starting Expires Service principal 2023-03-30T19:06:44 2023-03-31T19:06:44 krbtgt/EXAMPLE.COM@EXAMPLE.COM
-
用数据库用户jack登录kingbase数据库:
./ksql -U jack –d test -h test.example.com –p xxx如果登录成功,则说明Kerberos认证配置成功。可用klist检查获取服务主的ticket是否成功,如下:
klist 03/23/11 09:54:37 03/23/11 19:50:37 kingbase/test.example.com@EXAMPLE.COM
6.4. RADIUS身份验证 ¶
6.4.1. 关于RADIUS身份验证 ¶
这种认证方法的操作类似于 password
,不过它使用 RADIUS 作为密码验证方式。RADIUS 只被用于验证用户名/密码。因此,在 RADIUS 能被用于认证之前,用户必须已经存在于数据库中。其中,Freeradius是RADIUS(Remote Authentication Dial-In User Service)协议服务器的开源版本,可用来提供RADIUS协议的AAA(认证、授权、记账)服务。
6.4.2. RADIUS身份验证原理 ¶
RADIUS服务器和KingbaseES服务器通过网络连接。当数据库应用(ksql、jdbc等)访问数据库执行登录操作时,KingbaseES根据应用提供的登录信息向FreeRADIUS服务器发起认证请求。RADIUS依据提供的登录信息产生认证响应,KingbaseES根据认证响应决定是否允许登录到数据库。
当使用 RADIUS 认证时,一个访问请求消息将被发送到配置好的 RADIUS 服务器。这一请求将是 Authenticate Only
类型,并且包含参数 user name
、 password
(加密的)和 NAS Identifier
。该请求将使用一个与服务器共享的密钥加密。RADIUS 服务器将对这个服务器响应 Access Accept
或者 Access Reject
。不支持RADIUS accounting。
可以指定多个RADIUS服务器,这种情况下将会依次验证。如果从一台服务器接收到否定响应,则认证失败。如果没有接收到响应,则将会尝试列表中的下一台服务器。要指定多台服务器,可将服务器名放在引号内并且用逗号分隔开。如果指定了多台服务器,所有其他RADIUS选项也可以以逗号分隔的列表给出,用来为每台服务器应用个别的值。也可以把选项指定为一个单一值,这样该值将被应用到所有的服务器。
6.4.3. 配置RADIUS身份验证 ¶
6.4.3.1. 安装 ¶
-
KingbaseES数据库安装
无特殊要求,常用方式安装即可。安装完后initdb初始化数据目录。
-
FreeRADIUS安装
本文示例使用FreeRADIUS配置RADIUS身份验证,安装步骤如下:
-
下载freeradius-server-release_3_0_21.tar.gz源代码包。
-
解压源代码包:tar xvf freeradius-server-release_3_0_21.tar.gz 。
-
进入源代码目录执行:
$ ./configure $ make $ make install
FreeRADIUS 编译依赖额外的软件包,如系统缺失configure过程会报错,安装缺失软件包即可。如无指定安装后默认配置文件路径为:/usr/local/etc/raddb 服务器程序名为radiusd。
-
6.4.3.2. 配置 ¶
-
KingbaseES配置
使用RADIUS认证时,对数据库对象的权限管理部分还是要依赖数据库本身的管理方式。数据库和用户以及对象的访问权限请事先在数据库内创建好。跟RADIUS相关的配置只需要编辑数据目录的sys_hba.conf 文件即可。
下列被支持的配置选项用于 RADIUS:
radiusservers
连接到 RADIUS 服务器的名称或IP地址。此参数是必需的。
radiussecrets
和 RADIUS 服务器秘密交谈时会用到共享密钥。这在 KingbaseES 和 RADIUS 服务器之间必须有完全相同的值。推荐使用至少 16个字符的字符串。这个参数是必需的。
注意
如果KingbaseES编译为支持OpenSSL,所用的加密向量将只是强密码。在其他情况下,到 RADIUS 服务器的传输应该被视为应该被视为被混淆的、不安全的。如有必要,应采用外部安全措施。
radiusports
用于连接到 RADIUS 服务器的端口号。如果没有指定端口,则使用默认端口
1812
。
radiusidentifiers
在 RADIUS 请求中字符串被用作
NAS Identifier
。 这个参数可以被用作第二个参数标识。例如该用户试图以哪个数据库用户进行认证,它可以被用于 RADIUS 服务器上的策略匹配。如果没有指定标识符,默认使用kingbase
。如果需要在RADIUS参数值中使用逗号或空格,可以通过在值周围加上要两层双引号。例如,将空格放入RADIUS机密字符串的示例如下:
host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""secret two"""例如 配置下列信息的hba文件
据库实例名字为:radius
用户名为:radius
radius用户对radius库有所有权限。
FreeRADIUS服务器ip地址为:127.0.0.1(本地,不在本地时请替换为远程服务器的IP地址)
FreeRADIUS服务器监听端口为:1812 (默认端口)
通讯密钥为: testing123 通讯密钥是为了保护数据库与FreeRADIUS服务器通讯而存在,是预共享密钥的方式。必须与FreeRADIUS服务器的配置是一致的,可以为不同的认证路径提供不同的密钥。
sys_hba.conf文件内容如下:
host radius all 0.0.0.0/0 radius radiusservers="127.0.0.1” radiusports="1812" radiussecrets="""testing123"""相关sys_hba.conf文件各个参数字段意义如下表所示:
参数类型
参数值
说明
TYPE
host
连接类型
DATABASE
radius
连接的库名,对所有库应用认证方式时可指定为all
USER
all
连接的用户名,可指定具体的用户名。
ADDRESS
0.0.0.0/0
地址范围
METHOD
radius
指定使用radius认证方式
radiusservers="127.0.0.1”
radius服务器地址
radiusports="1812"
radius服务器监听端口
radiussecrets="""testing123"""
指定密钥,必须与radius服务器配置一致。
注意
为防止使用其他方式认证,hba文件中如配置有与radius认证冲突的其他项请删除。参数以逗号分割多个值的方式 。例如radiusservers="127.0.0.1,192.168.1.1”
-
FreeRADIUS服务配置
-
认证数据
radius服务器用来鉴别认证是否成功的数据。例如用户名和密码。
radius支持本地数据、LDAP、数据库等多种方式来获取鉴别数据,这是由内置的不同模块支持的。本文以本地数据为例来配置,本地数据保存在FreeRADIUS的配置文件中。 编辑配置文件目录的users文件(/usr/local/etc/raddb/users)增加用户及密码。
如下图所示:
# The canonical testing user which is in most of the # examples. # #bob Cleartext-Password := "hello" # Reply-Message := "Hello, %{User-Name}" # todd Cleartext-Password := "toddpass" Reply-Message := "Hello, %{User-Name}" radius Cleartext-Password := "radiuspass" Reply-Message := "Hello, %{User-Name}"
增加用户todd和radius,对应密码为toddpass和radiuspass
注意在这里添加的用户只是代表用该用户可以通过RADIUS认证,还要数据库内已有这个用户才能登录到数据库。
-
客户端配置
使用FreeRADIUS的认证服务的一方为客户端。本文中的KingbaseES数据库服务器为其客户端。 编辑客户端配置文件(/usr/local/etc/raddb/ clients.conf),当KingbaseES服务与FreeRADIUS服务在同一台机器时可直接修改原有的localhost项。也可修改或者增加一个新的客户端项。
client KingbaseES { ipaddr = 192.168.4.30 proto = * secret = testing123 require_message_authenticator = no nas_type = other # localhost isn't usually a NAS... limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } }
上示例中,KingbaseES为客户端指定的别名,可任意指定。主要关注ipaddr 和 secret两个参数,其他参数可不修改。 ipaddr为KingbaseES服务器所在ip地址。
Secret为预共享密钥要与 sys_hba.conf中的配置参数一致。
注意
FreeRADIUS会对其配置文件的所属用户及读写权限检查,请不要修改这些文件的权限,否则可能导致服务启动不了。
-
6.4.3.3. 启动服务 ¶
-
启动KingbaseES
-
启动FreeRADIUS
直接运行命令radiusd即可启动FreeRADIUS服务器,建议以调试模式启动,这样方便查看认证请求和响应的信息。调试模式启动命令为:
#radiusd –X
启动调试模式会一直占用终端。启动成功时会输出如下信息 :
Ignoring "ldap" (see raddb/mods-available/README.rst) # Loading preacct {...} # Loading accounting {...} # Loading post-proxy {...} # Loading post-auth {...} } # server default server inner-tunnel { # from file /usr/local/etc/raddb/sites-enabled/inner-tunnel # Loading authenticate {...} # Loading authorize {...} # Loading session {...} # Loading post-proxy {...} # Loading post-auth {...} # Skipping contents of 'if' as it is always 'false' -- /usr/local/etc/raddb/sites-enabled/inner-tunnel:336 } # server inner-tunnel radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { type = "acct" ipaddr = * port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { type = "auth" ipv6addr = :: port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { type = "acct" ipv6addr = :: port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address :: port 1812 bound to server default Listening on acct address :: port 1813 bound to server default Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on proxy address * port 43719 Listening on proxy address :: port 55298 Ready to process requests
6.4.4. 通过RADIUS身份验证连接KingbaseES ¶
RADIUS对数据库应用是透明的,正常方式连接数据库即可。
-
ksql客户端请使用符合sys_hba.conf中的radius认证方式的参数(ip、database、user)登录。例如:
ksql -U radius -d radius -W radiuspass -h 127.0.0.1
-
使用JDBC连接。示例代码如下:
private String url = "jdbc:postgresql://192.168.137.171:5432/todd"; private String username = "radiususer"; private String password = "radiuspass"; private Connection connection = null; public Connection getConn() { try { Class.forName("org.postgresql.Driver").newInstance(); connection = DriverManager.getConnection(url, username, password); } catch (InstantiationException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IllegalAccessException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (ClassNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); }catch (SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } return connection; }使用radius认证的登录方式,radiusd服务会有认证成功的输出信息,如果登录时没用RADIUS认证则不会有输出。
6.5. LDAP身份验证 ¶
6.5.1. 关于LDAP身份验证 ¶
Lightweight Directory Access Protocol (LDAP)是一个开放的,中立的,工业标准的应用协议,通过IP协议提供访问控制和维护分布式信息的目录信息。 LDAP服务可视为一种特殊的数据库服务,就像文件系统的目录一样以树形结构组织数据信息,通常存储的信息不会被频繁修改,侧重于快速检索,提供统一的访问方法。由于这种特性,LDAP常被用于用户认证的场景中。 这种认证方法操作起来类似于 password
,只不过它使用 LDAP作为密码验证方法。LDAP被用于验证用户名/口令。因此,在使用LDAP进行认证之前,用户必须已经存在于数据库中。
6.5.2. LDAP身份验证原理 ¶
LDAP 认证可以在两种模式下操作。在第一种模式中(我们将称之为简单绑定模式),服务器将绑定到构造成 prefix
username
suffix
的可区分名称。通常, prefix
参数被用于指定 cn=
或者一个活动目录环境中的 DOMAIN
\
。 suffix
被用来指定非活动目录环境中的DN的剩余部分。
在第二种模式中(我们将称之为搜索与绑定模式),服务器首先用一个固定的用户名和密码(用 ldapbinddn
和 ldapbindpasswd
指定)绑定到 LDAP 目录 ,并为试图登入该数据库的用户执行一次搜索。如果没有配置用户名和密码,将尝试一次匿名绑定到目录。搜索将在位于 ldapbasedn
的子树上被执行,并将尝试做一次 ldapsearchattribute
中指定属性的精确匹配。一旦在这次搜索中找到用户,服务器断开并且作为这个用户重新绑定到目录,使用由客户端指定的口令来验证登录是正确的。这种模式与在其他软件中的 LDAP 认证所使用的相同,例如 Apache mod_authnz_ldap
和 pam_ldap
。这种方法允许位于目录中用户对象的更大灵活性,但是会导致建立两个到 LDAP 服务器的独立连接。
下列配置选项被用于两种模式:
ldapserver
要连接的LDAP服务器的名称或IP地址。可以指定多个服务器,用空格分隔。
ldapport
要连接的LDAP服务器的端口号。如果没有指定端口,LDAP库的默认端口设置将被使用。
ldapscheme
设置为
ldaps
可以使用LDAPS。这是一种非标准的在SSL之上使用LDAP的方法,在有一些LDAP服务器实现上可以支持。其他选择还可以参考ldaptls
选项。
ldaptls
设置为1以使KingbaseES和LDAP服务器之间的连接使用TLS加密。这会按照RFC 4513使用
StartTLS
操作。其他选择还可以参考ldapscheme
选项。
注意使用 ldapscheme
或 ldaptls
仅会加密KingbaseES服务器和LDAP服务器之间的通信。KingbaseES服务器和KingbaseES客户端之间的连接仍是未加密的,除非也在其上使用SSL。
下列选项只被用于简单绑定模式:
ldapprefix
当做简单绑定认证时,前置到用户名形成要用于绑定的DN的字符串。
ldapsuffix
当做简单绑定认证时,前置到用户名形成要用于绑定的DN的字符串。
下列选项只被用于搜索与绑定模式:
ldapbasedn
当做搜索与绑定认证时,开始搜索用户的根DN。
ldapbinddn
当做搜索与绑定认证时,用户要绑定到目录开始执行搜索的DN。
ldapbindpasswd
当做搜索与绑定认证时,用户用于绑定到目录开始执行搜索的口令。
ldapsearchattribute
当做搜索与绑定认证时,在搜索中用来与用户名匹配的属性。如果没有指定属性,将会使用
uid
属性。
ldapsearchfilter
在做search+bind认证时使用的搜索过滤器。
$username
的出现将被替换为用户名。这允许比ldapsearchattribute
更加灵活的搜索过滤器。
ldapurl
一个RFC 4516 LDAP URL。这是一种用更紧凑和标准的形式书写某些其他LDAP选项的可选方法。格式是:
ldap[s]://host[:port]/basedn[?[attribute][?[scope][?[filter]]]]
scope
必须是base
、one
、sub
之一,通常是最后一个(默认是base
,但它在这个应用中通常没意义)。attribute
可以指定一个属性,在这种情况中它被用作ldapsearchattribute
的一个值。如果attribute
为空,那么filter
可以被用作ldapsearchfilter
的一个值。URL模式
ldaps
选择LDAPS方法来在SSL上建立LDAP连接,等效于使用ldapscheme=ldaps
。要使用StartTLS
操作加密LDAP连接,可以用普通的URL模式ldap
并且在ldapurl
之外指定ldaptls
选项。对于非匿名绑定,
ldapbinddn
和ldapbindpasswd
必须被指定为独立选项。LDAP URL 当前只支持 OpenLDAP,而不支持 Windows。
注意
不允许将简单绑定的选项中混合用于搜索与绑定的选项。
在使用search+bind模式时,可以用 ldapsearchattribute
指定的单个属性执行搜索,或者使用 ldapsearchfilter
指定的自定义搜索过滤器执行搜索。指定 ldapsearchattribute=foo
等效于指定 ldapsearchfilter="(foo=$username)"
。如果两个选项都没有被指定,则默认为 ldapsearchattribute=uid
。
如果KingbaseES是用OpenLDAP作为LDAP客户端库编译的,则 ldapserver
设置可以省略。在这种情况下,主机名和端口列表通过RFC 2782 DNS SRV记录查找。 _ldap._tcp.DOMAIN
的名称被查出,当 DOMAIN
被从 ldapbasedn
中提取出来时。
例如,一个简单绑定 LDAP 配置的例子:
host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
当请求一个作为数据库用户 someuser
到数据库服务器的连接时,KingbaseES 将尝试使用 cn=someuser, dc=example, dc=net
和客户端提供的口令来绑定到 LDAP 服务器。如果那个连接成功,将被授予数据库访问。
例如,一个搜索与绑定配置的例子:
host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid
当请求一个作为数据库用户 someuser
到数据库服务器的连接时,KingbaseES 将尝试匿名绑定(因为没有指定 ldapbinddn
)到 LDAP 服务器,在指定的基础 DN 下执行一次对于 (uid=someuser)
的搜索。如果找到一个项,则它将尝试使用找到的信息和客户端提供的口令进行绑定。如果第二个连接成功,将被授予数据库访问。
例如,一个 URL 的相同搜索与绑定配置:
host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
一些支持根据 LDAP 认证的其他软件使用相同的 URL 格式,因此很容易共享该配置。
例如,一个search+bind配置的例子,它使用 ldapsearchfilter
而不是 ldapsearchattribute
来允许用用户ID或电子邮件地址进行认证:
host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchfilter="(|(uid=$username)(mail=$username))"
例如,一个search+bind配置的例子,它使用DNS SRV程序来查找域名 example.net
的LDAP服务的主机名和端口:
host ... ldap ldapbasedn="dc=example,dc=net"
提示
如例子中所示,由于 LDAP 通常使用逗号和空格来分割一个 DN 的不同部分,在配置 LDAP选项时通常有必要使用双引号包围的参数值。
6.5.3. 配置LDAP身份验证 ¶
6.5.3.1. 安装 ¶
-
KingbaseES数据库安装
无特殊要求,常用方式安装即可。安装完后initdb初始化数据目录。
-
Openldap安装
本文示例使用openldap进行LDAP身份验证配置,项目官方只发布源代码,不对外发布安装包。
提示
项目官方网站为: https://www.openldap.org/ 。
可通过两种方式安装:
-
Yum 安装
直接通过yum 安装打包好的版本。安装需要root用户权限。
#yum -y install openldap openldap-clients openldap-servers
拷贝配置文件,并修改文件owner 为ldap ,ldap用户在安装时会自动创建。
# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG # chown -R ldap /var/lib/ldap/DB_CONFIG
启动服务和查看服务状态验证安装是否成功:
# systemctl start slapd # systemctl status slapd
如需配置ldap服务开机自动启动,可以执行:
# systemctl enable slapd
配置文件路径为: /etc/openldap 数据文件路径为: /var/lib/ldap
-
从源代码安装
如系统没有安装包,可选择从源码编译安装。
解压和编译源码包:
#tar xvf openldap-2.4.44.tgz #cd openldap-2.4.44 # ./configure # make depend # make
安装需要root用户:
# su root -c 'make install'
默认安装路径为:/usr/local
默认配置文件路径为: /usr/local/etc/openldap
默认可执行文件路径为: /usr/local/bin
默认数据库文件路径为: /usr/local/var/openldap-data
6.5.3.2. 配置LDAP服务器 ¶
通过yum安装和从源代码安装的openldap配置方式不一样。分开说明两种方式安装后的配置方法。
6.5.3.2.1. YUM安装后的配置方式 ¶
Yum安装后的配置文件默认路径为:/etc/openldap 下 ,请勿用编辑器直接编辑slapd.d目录下文件。使用ldapadd ldapdelete ldapmodify工具来编辑。
-
修改管理员密码
运行命令将明文密码“123456”转换成密文,修改密码是配置文件要用密文。
#slappasswd -s 123456 {SSHA}+lWgh5egDLskOg0dPAx5YWTFDExQ8lE6编辑配置文件changepwd.ldif,配置文件为导入数据使用,请勿将直接在/etc/openldap/slapd.d目录下编辑。文件内容如下:
dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: {SSHA}+lWgh5egDLskOg0dPAx5YWTFDExQ8lE6使用ldappad命令将修改的密码导入:
#ldapadd -Y EXTERNAL -H ldapi:/// -f changepwd.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={0}config,cn=config"
-
导入常用schema
常用schema文件位于/etc/openldap/schema/目录下,使用ldapadd命令导入:
# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=cosine,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=nis,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=inetorgperson,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/collective.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=collective,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/corba.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=corba,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/duaconf.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=duaconf,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/dyngroup.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=dyngroup,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/java.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=java,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/misc.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=misc,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/openldap.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=openldap,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/pmi.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=pmi,cn=schema,cn=config" # ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=ppolicy,cn=schema,cn=config"
-
自定义域名
域名(domain name)可视为ldap以树形组织数据信息时的一个分支或者类别。同一个domain name下的数据在以domain name为树根的树内。下文中域管理员密码延用之前生成的密码,如需修改请重新以slappasswd命令生成新的密码密文。
自定义域名为kingbase.com,管理员账号为domainadmin,域名和管理员账号可根据需要修改内容红色部分,域名仅是组织数据的一个形式,不一定与所在主机域名一样。 编辑域名配置文件changedomain.ldif,内容如下:
dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=domainadmin,dc=kingbase,dc=com" read by * none dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=kingbase,dc=com dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=domainadmin,dc=kingbase,dc=com dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}+lWgh5egDLskOg0dPAx5YWTFDExQ8lE6 dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=domainadmin,dc=kingbase,dc=com" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=domainadmin,dc=kingbase,dc=com" write by * read将配置文件数据导入:
# ldapmodify -Y EXTERNAL -H ldapi:/// -f changedomain.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}monitor,cn=config" modifying entry "olcDatabase={2}hdb,cn=config" modifying entry "olcDatabase={2}hdb,cn=config" modifying entry "olcDatabase={2}hdb,cn=config" modifying entry "olcDatabase={2}hdb,cn=config"
-
创建组织
创建名为KingbaseES的组织,并且根据数据库的角色分类,创建4类组织单元,DBA、SSO、SAO、USER。
编辑配置文件base.ldif,内容如下:
dn: dc=kingbase,dc=com objectClass: top objectClass: dcObject objectClass: organization o: kingbaseES dc: kingbase dn: cn=orgadmin,dc=kingbase,dc=com objectClass: organizationalRole cn: orgadmin description: Directory Manager dn: ou=DBA,dc=kingbase,dc=com objectClass: organizationalRole ou: DBA导入数据,导入数据时需要输入domainadmin的密码,请参照1. 修改管理员密码处设置的密码。
# ldapadd -x -D cn=domainadmin,dc=kingbase,dc=com -W -f base.ldif Enter LDAP Password: adding new entry "dc=kingbase,dc=com" adding new entry "cn=orgadmin,dc=kingbase,dc=com" adding new entry "ou=DBA,dc=kingbase,dc=com"
-
增加用户
LDAP内用户数据与KingbaseES数据库内的用户是独立的。LDAP只负责对用户名和密码的验证,因此数据库内必须有相同名字的用户才能登录。
生成新用户todd的登录密码todd123 密文:
# slappasswd -s todd123 {SSHA}vqCJ1KnL1xddvu5JXHaAH8h33f72Vgga编辑配置文件users.ldif ,内容如下:
dn: uid=todd,ou=DBA,dc=kingbase,dc=com objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: todd sn: database userPassword: {SSHA}vqCJ1KnL1xddvu5JXHaAH8h33f72Vgga loginShell: /bin/bash uidNumber: 503 gidNumber: 500 homeDirectory: /home/todd可在同一该文件内编辑多个用户,以空行分开多个用户的数据。
导入用户数据:
# ldapadd -x -D cn=domainadmin,dc=kingbase,dc=com -W -f user.ldif Enter LDAP Password: adding new entry "uid=todd,ou=DBA,dc=kingbase,dc=com"
6.5.3.2.2. 源码安装后的配置方式 ¶
-
slapd.conf 配置文件
# vim /usr/local/etc/openldap/ slapd.conf增加所有schema,并修改域名 内容如下:
# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/collective.schema include /usr/local/etc/openldap/schema/corba.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/duaconf.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/pmi.schema include /usr/local/etc/openldap/schema/ppolicy.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_mdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # MDB database definitions ####################################################################### database mdb maxsize 1073741824 suffix "dc=kingbase,dc=com" rootdn "cn=Manager,dc=kingbase,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq
-
启动服务器
以前端模式启动,输出调试信息:
# /usr/local/libexec/slapd -d 256 60a6bd0e @(#) $OpenLDAP: slapd 2.4.44 (May 18 2021 09:47:03) $ todd@localhost.localdomain:/home/todd/LDAP/openldap-2.4.44/servers/slapd 60a6bd0e mdb_monitor_db_open: monitoring disabled; configure monitor database to enable 60a6bd0e slapd starting可通过以下命令检查服务器是否正常启动:
# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=kingbase,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
-
创建组织
编辑配置文件base.ldif,内容如下:
dn: dc=kingbase,dc=com objectClass: top objectClass: dcObject objectClass: organization o: kingbaseES dc: kingbase dn: cn=orgadmin,dc=kingbase,dc=com objectClass: organizationalRole cn: orgadmin description: Directory Manager dn: ou=DBA,dc=kingbase,dc=com objectClass: organizationalRole cn: DBA ou: DBA导入数据,LDAP 密码为字符串 secret:
# /usr/local/bin/ldapadd -x -D "cn=Manager,dc=kingbase,dc=com" -W -f base.ldif Enter LDAP Password: adding new entry "dc=kingbase,dc=com" adding new entry "cn=orgadmin,dc=kingbase,dc=com" adding new entry "ou=DBA,dc=kingbase,dc=com"
-
创建用户
LDAP内用户数据与KingbaseES数据库内的用户是独立的。LDAP只负责对用户名和密码的验证,因此数据库内必须有相同名字的用户才能登录。
生成新用户todd的登录密码todd123 密文:
# slappasswd -s todd123 {SSHA}OoPRlB2dPrJIzTygJgWJrkLnqFgg6Ibu编辑配置文件users.ldif ,内容如下:
dn: uid=todd,ou=DBA,dc=kingbase,dc=com objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: todd sn: database userPassword: {SSHA}OoPRlB2dPrJIzTygJgWJrkLnqFgg6Ibu loginShell: /bin/bash uidNumber: 503 gidNumber: 500 homeDirectory: /home/todd可在同一该文件内编辑多个用户,以空行分开多个用户的数据。
导入用户数据:
# ldapadd -x -D cn=Manager,dc=kingbase,dc=com -W -f user.ldif Enter LDAP Password: adding new entry "uid=todd,ou=DBA,dc=kingbase,dc=com"
-
可验证导入kingbase.com域的数据
# ldapsearch -x -b 'dc=kingbase,dc=com' '(objectClass=*)' # extended LDIF # # LDAPv3 # base <dc=kingbase,dc=com> with scope subtree # filter: (objectClass=*) # requesting: ALL # # kingbase.com dn: dc=kingbase,dc=com objectClass: top objectClass: dcObject objectClass: organization o: kingbaseES dc: kingbase # orgadmin, kingbase.com dn: cn=orgadmin,dc=kingbase,dc=com objectClass: organizationalRole cn: orgadmin description: Directory Manager # DBA, kingbase.com dn: ou=DBA,dc=kingbase,dc=com objectClass: organizationalRole cn: DBA ou: DBA # todd, DBA, kingbase.com dn: uid=todd,ou=DBA,dc=kingbase,dc=com objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: todd sn: database userPassword:: e1NTSEF9T29QUmxCMmRQckpJelR5Z0pnV0pya0xucUZnZzZJYnU= loginShell: /bin/bash uidNumber: 503 gidNumber: 500 homeDirectory: /home/todd uid: todd # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4
6.5.3.3. 配置KingbaseES ¶
6.5.3.3.1. 配置参数 ¶
安装的KingbaseES数据库版本需选择打开—with-ldap编译选项,否则无法支持LDAP认证方式。
6.5.3.3.2. 配置LDAP认证方式 ¶
编辑数据目录下的sys_hba.conf配置文件增加使用ldap认证的项。
例如,要从本地登录的todd用户使用位于192.168.45.157上的LDAP服务器认证。则增加一条认证项:
# TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all todd ldap ldapserver=192.168.45.157 ldapprefix="uid=" ldapsuffix=",ou=DBA,dc=kingbase,dc=com" local all all trust # IPv4 local connections: host all all 127.0.0.1/32 scram-sha-256 host all all 0.0.0.0/0 scram-sha-256 # IPv6 local connections: host all all ::1/128 scram-sha-256 host all all ::0/0 scram-sha-256 # Allow replication connections from localhost, by a user with the # replication privilege. local replication all trust host replication all 127.0.0.1/32 scram-sha-256 host replication all ::1/128 scram-sha-256
6.5.3.3.3. 创建数据库用户 ¶
如数据库内已存在用户忽略此步骤。
haoqinghe=# create user todd with password '123456'; CREATE ROLE
注意
上述示例中,数据库内用户todd使用密码123456,而LDAP内的todd用户使用密码todd123。当使用LDAP认证时使用密码todd123来登录而不是123456。
6.5.4. 通过LOAP身份验证连接KingbaseES ¶
使用ksql本地登录数据库,会匹配sys_hba.conf中使用LDAP认证的项,触发LDAP认证过程。
输入正确口令时,登录成功。例如,输入LDAP内的todd用户的正确口令todd123:
$ ksql -U todd -p 7777 用户 todd 的口令: 输入 "help" 来获取帮助信息. WARNING:License file will expire in 23 days. todd=>
输入其他口令时登录失败,并提示LDAP authentication failed:
$ ksql -U todd -p 7777 用户 todd 的口令: ksql: 错误: 无法连接到服务器:FATAL: LDAP authentication failed for user "todd"
6.5.5. 配置LOAP身份验证的常见问题 ¶
-
服务器拒绝连接
LDAP服务器监听在tcp的 389端口,如服务正常无法访问服务的情况,请检查防火墙设置。设置防火墙允许访问:
# firewall-cmd --add-service=ldap –permanent # firewall-cmd --reload或者关闭防火墙
# systemctl stop firewalld关闭SELinux
# setenforce 0
-
导入数据时报错
报错如下:
ldap_modify: Insufficient access (50)可能是执行命令的用户权限不足,请尝试以root执行。
-
ldif配置文件错误
报错如下:
ldapmodify: wrong attributeType at line xxx可能对应的空行只有空格字符,删掉空格。属性名和值之间以空格分开,每行头部和尾部无多余空格。
-
数据库版本不支持ldap
数据库无法启动,并且log日志有:
invalid authentication method "ldap": not supported by this build
信息时,表示当前版本的数据库不支持LDAP认证方式,请重新安装支持的版本。
-
objectClass问题
导入用户数据时提示:
additional info: objectClass: value #0 invalid per syntax可能是因为导入的schema不全引起的,请按照导入schema的步骤全部导入。
6.6. SSL客户端证书认证 ¶
6.6.1. 关于SSL客户端证书认证 ¶
传输层安全ssl协议可以KingbaseES数据库的强身份验证相结合。这种认证方法使用证书验证方法, 即SSL客户端证书执行认证。因此,它只适用于 SSL 连接。
6.6.2. SSL客户端证书认证的工作原理 ¶
当使用SSL客户端证书认证方式时,服务器将要求客户端提供一个有效的、可信的证书。不会有密码提示将被发送到客户端。证书的 cn
(通用名)属性将与被请求的数据库用户名进行比较,并且如果匹配将允许登录。用户名映射可以被用来允许 cn
与数据库用户名不同。
下列被支持的配置选项用于 SSL 客户端证书认证 :
map
允许在系统和数据库用户名之间的映射。详见 用户名映射 。
在一条指定SSL客户端证书认证 的 sys_hba.conf
记录中,认证选项 clientcert
被假定为 verify-ca
或 verify-full
,并且它不能被关掉, 因为这种方法中一个客户端证书是必需的。 cert
方法对基本 clientcert
证书验证测试所增加的东西是检查 cn
属性是否匹配数据库用户名。
6.6.3. 配置SSL客户端证书身份验证 ¶
6.6.3.1. 证书制作 ¶
-
查看openssl 版本
假设以及安装完成openssl环境:
#/pkg/8.0.0025/db/bin/ca$ openssl version openssl: /home/test/pkg/8.0.0025/db/lib/libssl.so.1.0.0: version `OPENSSL_1.0.2' not found (required by openssl) openssl: /home/test/pkg/8.0.0025/db/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.2' not found (required by openssl) openssl: /home/test/pkg/8.0.0025/db/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.2g' not found (required by openssl) 出现上述缺少链接库问题,是因为LD_LIBRARY_PATH用的是数据库的lib,置空后正常, #/pkg/8.0.0025/db/bin/ca$ export LD_LIBRARY_PATH= #/pkg/8.0.0025/db/bin/ca$ openssl version OpenSSL 1.0.2g 1 Mar 2016
-
Root证书制作
#/pkg/8.0.0025/db/bin/ca$ openssl req -newkey rsa:2048 -keyout root.key -keyform PEM -out root.csr -outform PEM Generating a 2048 bit RSA private key ..................+++ ............+++ writing new private key to 'root.key' Enter PEM pass phrase:123456 Verifying - Enter PEM pass phrase:123456 ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CN State or Province Name (full name) [Some-State]:BJ Locality Name (eg, city) []:BJ Organization Name (eg, company) [Internet Widgits Pty Ltd]:KB Organizational Unit Name (eg, section) []:KB Common Name (e.g. server FQDN or YOUR name) []:ROOT Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: #/pkg/8.0.0025/db/bin/ca$ openssl x509 -req -in root.csr -out root.crt -signkey root.key -days 3650 Signature ok subject=/C=CN/ST=BJ/L=BJ/O=KB/OU=KB/CN=ROOT Getting Private key Enter pass phrase for root.key:123456
-
生成服务器证书
#/pkg/8.0.0025/db/bin/ca$ openssl genrsa -des3 -out server.key 1024 Generating RSA private key, 1024 bit long modulus ...........................................++++++ .++++++ e is 65537 (0x10001) Enter pass phrase for server.key:123456 Verifying - Enter pass phrase for server.key:123456 #/pkg/8.0.0025/db/bin/ca$ openssl req -new -key server.key -out server.csr Enter pass phrase for server.key:123456 You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CN State or Province Name (full name) [Some-State]:BJ Locality Name (eg, city) []:BJ Organization Name (eg, company) [Internet Widgits Pty Ltd]:KB Organizational Unit Name (eg, section) []:KB Common Name (e.g. server FQDN or YOUR name) []:SERVER Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
-
生成kingbase证书
#/pkg/8.0.0025/db/bin/ca$ openssl genrsa -des3 -out kingbase.key 1024 Generating RSA private key, 1024 bit long modulus ......................................................................++++++ ...++++++ e is 65537 (0x10001) Enter pass phrase for kingbase.key:123456 Verifying - Enter pass phrase for kingbase.key: 123456 #/pkg/8.0.0025/db/bin/ca$ openssl req -new -key kingbase.key -out kingbase.csr Enter pass phrase for kingbase.key:123456 You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CN State or Province Name (full name) [Some-State]:BJ Locality Name (eg, city) []:BJ Organization Name (eg, company) [Internet Widgits Pty Ltd]:KB Organizational Unit Name (eg, section) []:KB Common Name (e.g. server FQDN or YOUR name) []:KINGBASE Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: #/pkg/8.0.0025/db/bin/ca$ openssl x509 -sha1 -req -in kingbase.csr -CA root.crt -CAkey root.key -CAcreateserial -out kingbase.crt -outform PEM -days 3650 -passin pass:123456 -extfile ./openssl.cnf -extensions v3_req Signature ok subject=/C=CN/ST=BJ/L=BJ/O=KB/OU=KB/CN=KINGBASE Getting CA Private Key
6.6.3.2. 配置KingbaseES服务器 ¶
-
环境准备
a). 在kingbase.conf中增加 ssl=on;
b). 在sys_hba.conf中,host修改为 hostssl,MD5修改为cert ;
c). 把 所有的 crt和key 文件权限改为 600;
d). 把 root.crt、server.crt、server.key 放到数据库目录下。已生成好的ssl证书相关证书默认放在安装目录share下;
e). 把 root.crt、kingbase.crt、kingbase.key 放到用户根目录的.kingbase目录下;
-
启动数据库
# ./kingbase -D ca_data/ 启动日志打印如下: LOG: 转存许可证信息... LOG: 许可证版本:2.0 LOG: 产品线:ES LOG: 产品版本:8.0.0 LOG: 版本类型:ME LOG: 操作系统:LNX LOG: 体系结构:X64 LOG: 浮动日期模式:是 LOG: 基准日期:2021-09-26 LOG: 许可证有效时间:180天 LOG: 最大连接数:无限制 LOG: 用户信息:V8 LOG: 试用模式:否 LOG: 网卡物理地址检查模式:否 LOG: 网卡物理地址: LOG: IPV4地址检查模式:否 LOG: IPV4地址: LOG: 序列号:1e763e91-cb914c9a-dfe158e5-f462527b sh: /home/test/pkg/8.0.0025/db/lib/libtinfo.so.5: no version information available (required by sh) please enter the server key password:123456 LOG: SSL 的证书吊销列表文件"/home/test/pkg/8.0.0025/db/bin/ca_data/root.crl"未找到,忽略:没有那个文件或目录 DETAIL: 证书将不予核对吊销列表 LOG: the encrypt device is opened LOG: 数据库系统已关闭在 2021-09-27 16:39:46 CST LOG: checkpoint record is at 1/1DB9050 LOG: redo record is at 1/1DB9050; undo record is at 0/0; shutdown TRUE LOG: 下一个事务ID: 0/269; 下一个OID: 31827 LOG: 下一个 MultiXactId: 1; 下一个 MultiXactOffset: 0 LOG: 数据库系统准备接受连接注意
上面缺失root.crl警告信息不影响功能正常使用。
6.6.4. 通过SSL客户端证书身份验证连接KingbaseES ¶
通过ksql连接数据库。例如,下面这个例子:
#./ksql -p19940 -USYSTEM -d TEST -p19970 用户密码 SYSTEM:123456 本次登录信息: 用户名: SYSTEM 主机: [local] 登录时间: 2021-09-27 16:42:57.052739+08 这是你第一次登录. 本次登录和最后一次登录之间的失败次数: 0 密码的过期时间没有设置. TEST=#
6.7. 证书认证和多重鉴别 ¶
6.7.1. 关于证书认证和多重鉴别 ¶
多重鉴别机制认证登录(证书登录)对证书进行核验,以实现用户身份的鉴别。 在证书验证的基础上,功能融合了sm3和scram-sha-256密码验证逻辑,以实现多重鉴别,增加用户身份认证的安全性。 对于数据库所支持的证书和密钥文件的类型,目前支持rsa和sm2两种类型,并可以在数据库服务器上选择任一类型进行证书登录的功能实现。其中,rsa还支持带pin码的证书认证方式。
6.7.2. 证书认证和多重鉴别的工作原理和配置方法 ¶
基本加密算法(RSA、SM2)的证书认证功能,只需使用证书认证就可以登录数据库。但多重鉴别功能,在证书认证通过后,还需再进行口令认证。
假设已经指定了ca证书路径,证书登录算法cert_type取值rsa,服务端服务已启动:
-
生成证书和密钥,并放置到证书路径指定位置;
使用openssl指令生成CA证书、客户端证书、客户端密钥。生成密钥时候,对于除根证书以外的文件,要在文件名后添加用户名,以做区分,例如uclient_xx.key,xx代表用户名;
在服务端,将生成的ca.crt文件放到data目录下,在客户端,将客户端密钥和客户端证书(uclient_xx.key, uclient_xx.crt)放置某一指定目录。如下图所示:
图 6.7.7 认证部署 ¶
-
在连接时,在指令上指定客户端证书路径和客户端私钥路径;
-
之后如果需要客户端输入PIN码,则会弹出相应提示进行输入,如果密码文件内识别到正确的PIN码,则跳过本步骤;
-
服务端对收到的内容进行验签;
以上为证书认证阶段,如指定的是多重鉴别认证方式,则会继续执行以下步骤:
-
服务端证书验证成功后,返回结果给客户端,同时返回的还有用户密码加密认证方式(例如sm3或者sha256);
-
客户端收到证书认证成功结果后,输入用户登录密码,并发给服务端认证密码;
-
服务端收到密码,进行对应的sm3、sha256等方式的认证,认证成功,返回结果给客户端;
-
客户端收到最终认证结果,连接成功。
6.7.2.1. 示例 ¶
示例1 rsa证书认证(带pin码)
对于rsa证书,首先要把根证书(例如名为ca.crt)拷贝到data目录下,然后在kingbase.conf文件内添加字段cert_type = rsa 和 ca_cert_file = 'ca.crt',cert_type是指定认证证书类型为rsa,根证书为ca.crt。
1) kcert认证方式
将sys_hba.conf内对应的场景下的认证方式改为kcert:
host all testuser 0.0.0.0/0 kcert
重启服务后,使用ksql连接数据库并在指令中指定-C和-k分别指定客户端证书路径和客户端密钥路径,并指定-h,示例如下指令:
release/bin/ksql -d test -p 22223 -U testuser -C /home/testuser/certfile/rsa_with_pin/uclient.crt -k /home/testuser/certfile/rsa_with_pin/uclient.key -h 10.12.1.30
在尝试连接时,需要输入打开client.key的PIN码,正确输入后,可以直接登录成功。
2) kcert_scram认证方式
将sys_hba.conf内对应的场景下的认证方式改为kcert_scram:
host all testuser 0.0.0.0/0 kcert_scram
重启服务后,使用ksql连接数据库并在指令中指定-C和-k分别指定客户端证书路径和客户端密钥路径,并指定-h,示例如下指令:
release/bin/ksql -d test -p 22223 -U testuser -W -C /home/testuser/certfile/rsa_with_pin/uclient.crt -k /home/testuser/certfile/rsa_with_pin/uclient.key -h 10.12.1.30
注意,此处连接指令加了-W,因为数据库连接开始会有一个空连接,如果不指定-W,则会在两次尝试连接时都提示要求输入对应PIN码,如果指定-W,则只需要输入一次PIN码。
之后应用会要求输入用户密码,然后要求输入client.key的PIN码,输入正确后,可以顺利登录数据库。
3) kcert_scram认证方式
将sys_hba.conf内对应的场景下的认证方式改为kcert_scram:
host all testuser 0.0.0.0/0 kcert_sm3
重启服务后,使用ksql连接数据库并在指令中指定-C和-k分别指定客户端证书路径和客户端密钥路径,并指定-h,示例如下指令:
release/bin/ksql -d test -p 22223 -U testuser -W -C /home/testuser/certfile/rsa_with_pin/uclient.crt -k /home/testuser/certfile/rsa_with_pin/uclient.key -h 10.12.1.30
注意,此处指令加-W的原因和2)中描述一致。
之后应用会要求输入用户密码,然后要求输入client.key的PIN码,输入正确后,可以顺利登录数据库。
示例2 rsa证书认证(带pin码)使用passfile自动解码
为了适应集群服务器之间涉及到证书登录的问题,需要支持PIN码自动输入功能,可以在ksql连接指令里指定存储PIN码的文件,实现PIN码自动填入,不必手输。以下以认证模式为kcert_scram为例(kcert_sm3一致,kcert不会要求输入用户密码,其余一致)。
-
在任意目录新建PIN码存储文件,文件名为passfile;
-
将PIN码进行base64加密,123456cl为打开client.key的PIN码,指令如下
echo -n 123456cl |base64
-
将加密后的字符拷贝至passfile文件内并保存。然后执行如下指令:
release/bin/ksql -d test -p 22223 -U testuser -W -C /home/testuser/certfile/rsa_with_pin/uclient.crt -k /home/testuser/certfile/rsa_with_pin/uclient.key -K /home/testuser/certfile/rsa_with_pin/passfile -h 10.12.1.30
此处增加了-K选项,以指定PIN码存储文件位置。
最后在输入正确的用户密码情况下,系统不会提示要求输入PIN码,验证成功。
6.7.2.2. 注意事项 ¶
-
对于rsa和sm2证书,生成证书需要在系统内预先安装openssl,版本要求1.1.1以上(rsa对openssl版本没有要求,sm2依赖openssl版本需要在1.1.1以上)。
-
集群环境下,主备机普通用户(非集群用户)的证书认证配置一致,配置过程与单机相同。
-
集群用户和物理备份认证不使用证书。示例hba.conf配置如下:
local all all scram-sha-256 host esrep esrep 0.0.0.0/0 scram-sha-256 host replication all 0.0.0.0/0 scram-sha-256 host esrep esrep ::0/0 scram-sha-256 host replication all ::0/0 scram-sha-256需要注意的是,配置上述内容需放置hba.conf 配置文件的最前端。
6.8. GSSAPI身份验证 ¶
6.8.1. 关于GSSAPI身份验证 ¶
GSSAPI是用于 RFC 2743 中定义的安全认证的一个工业标准协议。 KingbaseES支持GSSAPI用户加密、认证层或者仅用于认证。
身份验证本身是安全的,但通过数据库连接发送的数据将不被加密,除非使用SSL。KingbaseES支持带Kerberos认证的GSSAPI,GSSAPI为支持它提供自动身份验证(单点登录)功能。如果使用GSSAPI加密或SSL加密,数据库连接发送的数据将被加密,否则将不加密。 当编译KingbaseES时,GSSAPI 支持必须被启用。
6.8.2. GSSAPI身份验证的工作原理 ¶
当GSSAPI使用Kerberos时, 它会使用格式为 servicename / hostname @ realm
的标准 principal。 KingbaseES服务器将接受该服务器所使用的 keytab 中包括的任何 principal,但是在从使用 krbsrvname
连接参数的客户端建立连接时要注意指定正确的 principal 细节。安装的默认值 kingbase
可以在编译时使用 ./configure --with-krb-srvnam=
其他值
修改。 在大部分的环境中,这个参数从不需要被更改。某些 Kerberos 实现可能要求一个不同的服务名, 例如 Microsoft Active Directory 要求服务名是大写形式( KINGBASE
)。
hostname
是服务器机器的被完全限定的主机名。服务 principal 的 realm 是该服务器机器的首选 realm。
客户端 principal 可以被通过 sys_ident.conf
映射到不同的 KingbaseES数据库用户名。例如, kbusername@realm
可能会被映射到 kbusername
。或者,可以使用完整的 username@realm
当事人作为 KingbaseES中的角色而无需任何映射。
KingbaseES也支持一个参数把 realm 从 principal 中剥离。这种方法是为了向后兼容性,并且我们强烈反对使用它,因为这样就无法区分具有相同用户名却来自不同 realm 的不同用户了。要启用这种方法,可将 include_realm
设置为 0。对于简单的单 realm安装,这样做并且设置 krb_realm
参数(这会检查 principal 的 realm 是否正好匹配 krb_realm
中的参数)仍然是安全的。但比起在 sys_ident.conf
中指定一个显式映射来说,这种方法的能力较低。
确认服务器的 keytab 文件可以被KingbaseES服务器帐户读取(最好为只读)。密钥文件的位置由配置参数 krb_server_keyfile 指定。默认是 /opt/Kingbase/ES/V8/etc/krb5.keytab
(或者任何在编译的时候作为 sysconfdir
的目录)。出于安全原因,推荐对KingbaseES服务器使用一个独立的 keytab而不是开放系统 keytab 文件的权限。
keytab 文件由 Kerberos 软件生成,详见 Kerberos 文档。下面是 MIT 兼容的 Kerberos 5 实现的例子:
kadmin% ank -randkey kingbase/server.my.domain.org kadmin% ktadd -k krb5.keytab kingbase/server.my.domain.org
当连接到数据库时,确保你有一个匹配被请求数据库用户名的 principal 的票据。例如,对于数据库用户名 fred
,principal fred@EXAMPLE.COM
将能够连接。要也允许 principal fred/users.example.com@EXAMPLE.COM
,可使用一个用户名映射,如 用户名映射 中所述。
下列被支持的配置选项用于GSSAPI:
include_realm
如果设置为 0,在通过用户名映射之前( 用户名映射 ),来自已认证用户 principal 的 realm 名称会被剥离掉。我们不鼓励这样做,这种方法主要是为了向后兼容性而存在的,因为它在多 realm 环境中是不安全的(除非也使用
krb_realm
)。推荐用户让include_realm
设置为默认值(1)并且在sys_ident.conf
中提供一条显式的映射来把 principal 名称转换成KingbaseES用户名。
map
允许在系统和数据库用户名之间的映射。详见 用户名映射 。 对于一个 GSSAPI/Kerberos 原则,例如
username@EXAMPLE.COM
(或者更不常见的username/hostbased@EXAMPLE.COM
),用于映射的用户名会是username@EXAMPLE.COM
(或者username/hostbased@EXAMPLE.COM
,相应地),除非include_realm
已经被设置为 0,在那种情况下username
(或者username/hostbased
)是映射时被视作系统用户名的东西。
krb_realm
设置 realm 为对用户 principal 名进行匹配的范围。如果这个参数被设置,只有那个 realm 的用户将被接受。如果它没有被设置,任何 realm 的用户都能连接,服从任何已完成的用户名映射。
6.9. SSPI身份验证 ¶
6.9.1. 关于SSPI身份验证 ¶
SSPI是一种用于带单点登录的安全认证的Windows技术。 KingbaseES在 negotiate
模式中将使用 SSPI,它在可能的情况下使用Kerberos并在其他情况下自动降回到NTLM。只有在服务器和客户端都运行在Windows时,SSPI才能工作。或者在非 Windows 平台上GSSAPI可用时,SSPI也能工作。
6.9.2. SSPI身份验证的工作原理 ¶
当使用Kerberos认证时,SSPI和GSSAPI的工作方式相同,详见 GSSAPI认证 。
下列被支持的配置选项用于SSPI:
include_realm
如果设置为 0,在通过用户名映射之前( 用户名映射 ),来自已认证用户 principal 的 realm 名称会被剥离掉。我们不鼓励这样做,这种方法主要是为了向后兼容性而存在的,因为它在多 realm 环境中是不安全的(除非也使用
krb_realm
)。推荐用户让 include_realm 设置为默认值(1)并且在sys_ident.conf
中提供一条显式的映射来把 principal 名称转换成KingbaseES用户名。
compat_realm
如果被设置为 1,该域的 SAM 兼容名称(也被称为 NetBIOS 名称)被用于
include_realm
选项。这是默认值。如果被设置为 0,会使用来自 Kerberos 用户主名的真实 realm 名称。不要禁用这个选项,除非你的服务器运行在一个域账号(这包括一个域成员系统上的虚拟服务账号)下并且所有通过 SSPI 认证的所有客户端也在使用域账号,否则认证将会失败。
upn_username
如果这个选项和
compat_realm
一起被启用,来自 Kerberos UPN 的用户名会被用于认证。如果它被禁用(默认),会使用 SAM 兼容的用户名。默认情况下,对于新用户账号这两种名称是一样的。注意
如果没有显式指定用户名,libkci会使用 SAM 兼容的名称。如果你使用的是libkci或者基于它的驱动,你应该让这个选项保持禁用或者在连接字符串中显式指定用户名。
map
允许在系统和数据库用户名之间的映射。详见 用户名映射 。 对于一个 GSSAPI/Kerberos 原则,例如
username@EXAMPLE.COM
(或者更不常见的username/hostbased@EXAMPLE.COM
), 用于映射的用户名会是username@EXAMPLE.COM
(或者username/hostbased@EXAMPLE.COM
,相应地),除非include_realm
已经被设置为 0,在那种情况下username
(或者username/hostbased
)是 映射时被视作系统用户名的东西。
krb_realm
设置领域为对用户 principal 名进行匹配的范围。如果这个参数被设置,只有那个领域的用户将被接受。如果它没有被设置,任何领域的用户都能连接,服从任何已完成的用户名映射。
6.10. Ident身份验证 ¶
6.10.1. 关于Ident身份验证 ¶
ident 认证方法通过从一个 ident 服务器获得客户端的操作系统用户名并且用它作为被允许的数据库用户名(和可选的用户名映射)来工作。它只在 TCP/IP 连接上支持。
注意
当为一个本地(非 TCP/IP)连接指定 ident 时,将实际使用 peer 认证(见 Peer身份验证 )。
6.10.2. Ident身份验证的工作原理 ¶
下列被支持的配置选项用于ident:
map
允许系统和数据库用户名之间的映射。详见 用户名映射 。
“Identification Protocol(标识协议)”在 RFC 1413中描述。实际上每个类 Unix 操作系统都带着一个默认监听 TCP 113 端口的 ident 服务器。ident 服务器的基本功能是回答类似这样的问题: “ 哪个用户从你的端口 X
发起了连接并且连到了我的端口 Y
?” 。因为当一个物理连接被建立后,KingbaseES既知道 X
也知道 Y
,所以它可以询问尝试连接的客户端主机上的 ident 服务器并且在理论上可以判断任意给定连接的操作系统用户。
这个过程的缺点是它依赖于客户端的完整性:如果客户端机器不可信或者被攻破,攻击者可能在 113 端口上运行任何程序并且返回他们选择的任何用户。因此这种认证方法只适用于封闭的网络, 这样的网络中的每台客户端机器都处于严密的控制下并且数据库和操作系统管理员操作时可以方便地联系。换句话说,你必须信任运行 ident 服务器的机器。注意这样的警告:
标识协议的本意不是作为一种认证或访问控制协议。 --RFC 1413
有些 ident 服务器有一个非标准的选项,它导致返回的用户名是被加密的,使用的是只有原机器管理员知道的一个密钥。当与KingbaseES配合使用 ident 服务器时,一定不要使用这个选项,因为KingbaseES没有任何方法对返回的字符串进行解密以获取实际的用户名。
6.11. Peer身份验证 ¶
Peer 认证方法通过从内核获得客户端的操作系统用户名并把它用作被允许的数据库用户名(和可选的用户名映射)来工作。这种方法只在本地连接上支持。
下列被支持的配置选项用于peer:
map
允许在系统和数据库用户名之间的映射。详见 用户名映射 。
Peer 认证只在提供 getpeereid()
函数、 SO_PEERCRED
套接字参数或相似机制的操作系统上可用。这些 OS 当前包括Linux、大部分的BSD包括OS X以及Solaris。
6.12. PAM身份验证 ¶
这种认证方法操作起来类似 password
, 只不过它使用 PAM(插入式验证模块)作为认证机制。默认的 PAM 服务名是 kingbase
。PAM 只被用于验证用户名/口令对并且可以有选择地验证已连接的远程主机名或 IP 地址。因此,在使用 PAM 进行认证之前,用户必须已经存在于数据库中。 有关 PAM 的更多信息,请阅读 Linux-PAM页面 。
下列被支持的配置选项用于 PAM:
pamservice
PAM服务名称。
pam_use_hostname
判断是否通过
PAM_RHOST
项把远程 IP 地址或者主机名提供给 PAM 模块。默认情况下会使用 IP 地址。把这个选项设置为 1 可以使用解析过的主机名。主机名解析可能导致登录延迟(大部分的 PAM 配置不使用这些信息,因此只有使用为利用这种信息而特别创建的 PAM 配置时才需要考虑这个设置)。
注意
如果 PAM 被设置为读取 /etc/shadow
,认证将会失败,因为KingbaseES 服务器是由一个非 root 用户启动 。然而,当 PAM 被配置为使用 LDAP 或其他认证验证方法时这就不是一个问题。
6.13. BSD身份验证 ¶
这种认证方法操作起来类似于 password
,不过它使用 BSD认证来验证口令。BSD 认证只被用来验证用户名/口令对。因此,在 BSD认证可以被用于认证之前,用户的角色必须已经存在于数据库中。BSD认证框架当前只在 OpenBSD 上可用。
KingbaseES中的 BSD 认证使用 auth-kingbase
登录类型,如果 login.conf
中定义了 kingbase
登录分类,就会用它来认证。默认情况下这种登录分类不存在,KingbaseES将使用默认的登录分类。
注意
要使用 BSD 认证,KingbaseES 用户账号(也就是运行服务器的操作系统用户)必须首先被加入到 auth
组中。在 OpenBSD 系统上默认存在 auth
组。
6.14. 关于身份验证的常见问题 ¶
认证失败以及相关的问题通常有类似下面的错误消息显示:
-
服务器连接失败
FATAL: no sys_hba.conf entry for host "123.123.123.123", user "andym", database "testdb"
这条消息最可能出现的情况是你成功地联系了服务器,但它不愿意和你说话。就像消息本身所建议的,服务器拒绝了连接请求,因为它没有在其
sys_hba.conf
配置文件里找到匹配项。 -
口令错误
FATAL: password authentication failed for user "andym"
这样的消息表示你联系了服务器,并且它也愿意和你交谈,但是你必须通过
sys_hba.conf
文件中指定的认证方法。检查你提供的口令,或者如果错误消息提到了 Kerberos 或 ident 认证类型,检查那些软件。 -
用户名错误
FATAL: user "andym" does not exist
指示的数据库用户没有被找到。
-
数据库名错误
FATAL: database "testdb" does not exist
你试图连接的数据库不存在。请注意如果你没有声明数据库名,默认会用数据库用户名作为数据库名,这可能正确也可能不正确。
提示
服务器日志可能包含比报告给客户端的更多的有关认证失败的信息。如果你为失败的原因而困惑,那么请检查服务器日志。