Informix Dynamic Server 上使用单点登录身份验证

最新推荐文章于 2022-08-02 10:46:05 发布

congao1735

最新推荐文章于 2022-08-02 10:46:05 发布

阅读量390

点赞数

简介

单点登录（Single Sign-On，SSO）是一个针对 IBM Informix Dynamic Server (IDS) 11.50 的新身份验证机制。有了 SSO 支持之后，用户只需要输入密码一次，就可以登录到操作系统，然后访问多个软件系统，而不需重新输入用户名和密码。其他 IDS 服务器身份验证机制包括传统的 OS 用户名和密码身份验证以及 Pluggable Authentication Module（PAM），在这两种机制下，用户每次连接到数据库时都需要提供用户名和密码。

IDS 服务器通过 Kerberos 5 和 Generic Security Services Application Programming Interface（GSS API）开放标准提供 SSO 支持。IDS 的 SSO 支持是一种称为 GSSCSM 的通信支持模块。

Kerberos 概述

Kerberos 是一种身份验证协议，它使用 ‘票据’ 验证未受保护的网络中的用户的身份。Kerberos 使用了一个可靠的第三方，称为密匙发放中心（key distribution center，KDC）。网络中所有客户机和服务器都信任 KDC，并且使用 KDC 验证用户身份。KDC 在逻辑上由一个身份验证服务器（Authentication Server，AS）和一个票据授与服务器（Ticket Granting Server，TGS）组成。KDC 还拥有一个密匙数据库；每个实体（用户、主机或应用服务器）与 KDC 共享一个密匙。

下面是一个概览图，展示了客户机、应用服务器和 KDC 在身份验证期间的通信。第一个步骤是用户从 KDC 获取 Ticket Granting Ticket（TGT）。如果该步骤是 kerberos 式的，它就可以作为登录过程的一部分完成。此外，TGT 也可以在登录过程之后再获取。用户获得 TGT 之后，不同的 kerberos 式服务的身份验证对于用户是不可见的。用户在为初始的 TGT 输入密码之后就不需要做任何事情了。参考 Kerberos 标准获得 Kerberos protocol [RFC4120] 的详细说明（参见参考资料）。

图 1. Kerberos 概览

AS_REQ

- AS_REQ 是初始用户身份验证请求。这个消息指向称为身份验证服务器（Authentication Server，AS）的 KDC 组件。

AS_REP

- AS_REP 是 AS 对前面的请求的回复。它主要包括 TGT（使用 TGS 密匙加密）和会话密匙（使用请求用户的密匙加密）。

TGS_REQ
- TGS_REQ 是客户机向票据授与服务器（Ticket Granting Server，TGS）发出的请求，它请求获得服务票据。这个包包含从前面的消息获取的 TGT 和一个由客户机生成的用会话密匙加密的身份验证程序。
TGS_REP
- TGS_REP 是 TGS 对前面的请求的回复。它包含被请求的服务票据（使用该服务的私有密匙加密）和由 TGS 生成的服务会话密匙（使用前面由 AS 生成的会话密匙加密）。
AP_REQ
- AP_REQ 是客户机向应用服务器发送的要求访问服务的请求。这些组件包括通过前面的回复从 TGS 获得的服务票据和另一个由客户机生成的身份验证程序，但这一次使用服务会话密匙加密（由 TGS 生成）。
AP_REP
- AP_REP 是应用服务器对客户机的回复，用于证明它就是客户机所期待的服务器。通常不会需要这个包。只有在需要进行相互身份验证时，客户机才向服务器请求这个包。

KDC 持有某个域中所有主体的密码。因此 KDC 数据库绝对不能泄漏，否则它就会成为一个单点故障，这一点非常重要。运行 KDC 的主机原则上不应该再运行其他服务，以最小化泄漏的风险。Kerberos 并不能解决密码猜测和拒绝服务等攻击。Kerberos 使用一个主体的密码（加密密匙）作为它的身份的主要证明。如果一个用户的 Kerberos 密码被攻击者窃取，攻击者就能够模拟该用户。因此，需要了解如何配置 KDC 和如何防止它的泄漏，这非常重要。

配置 IDS 以使用 SSO

为 IDS 提供的 SSO 解决方案要求在 IDS 服务器和客户机上正确安装和配置 Kerberos。KDC 应该安装在另一台机器上，与 IDS 服务器和客户机分开。按照以下的步骤配置 SSO：

配置 KDC 服务器
在 KDC 中配置 IDS 服务器（服务）主体
在 KDC 中配置客户机（用户）主体
配置 IDS 以使用 SSO 身份验证
配置客户机以使用 SSO 身份验证

下面详细解释这些步骤。

1. 配置 KDC 服务器

下面的示例 KDC 设置展示了设置 MIT Kerberos 身份验证系统所需的步骤。其他 Kerberos 实现的 Kerberos 设置与此非常相似。

注意：仅在机器尚未配置 Kerberos 身份验证时才需要该步骤。Kerberos 配置文件和 Kerberos 实用程序的位置取决于 Kerberos 的安装位置。

如果 Kerberos 尚未可用，请安装 Kerberos 和必要的包。编辑 krb5.conf 和 kdc.conf 配置文件，使它能够反映您的域名和 domain-to-realm 之间的映射。

清单 1. 示例 krb5.conf 的内容

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.LENEXA.IBM.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true

[realms]
  EXAMPLE.LENEXA.IBM.COM = {
  kdc = toru.lenexa.ibm.com:88
  admin_server = toru.lenexa.ibm.com:749
  default_domain = lenexa.ibm.com
 }

[domain_realm]
 .lenexa.ibm..com = EXAMPLE.LENEXA.IBM.COM
 lenexa.ibm.com = EXAMPLE.LENEXA.IBM.COM

[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf

清单 2. 示例 kdc.conf 文件的内容

[kdcdefaults]
 acl_file = /var/kerberos/krb5kdc/kadm5.acl
 dict_file = /usr/share/dict/words
 admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
 v4_mode = nopreauth

[realms]
 EXAMPLE.LENEXA.IBM.COM = {
  master_key_type = des-cbc-crc
  supported_enctypes = des3-hmac-sha1:normal des-hmac-sha1:normal 
    des-cbc- md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3
 }

kadm5.acl（访问控制列表）文件位于 KDC 主机，它控制对 Kerberos 数据库的访问。kadm5.acl 的位置在 kdc.conf 中指定。它包含主体的名称和访问权限，然后是一个可选的用于 ACL 的主体。

使用 kdb5_util 实用程序创建 KDC 数据库。

清单 3. 使用 kdb5_util 创建 KDC 数据库

				
$kdb5_util create –s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm
'EXAMPLE.LENEXA.IBM.COM'
master key name 'K/M@EXAMPLE.LENEXA.IBM.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify:

使用 kadmin 定义处理密码及其存活期的策略。

清单 4. 使用 kadmin 添加一个策略

				
Ex: /usr/kerberos/sbin/kadmin.local
------------------------------------
kadmin.local:  add_policy -maxlife 180days -minlife  2days 
	       -minlength 8 –minclasses 3 -history 10 default

使用 kadmin 添加管理员主体。

Kadmin 是 Kerberosis 数据库的管理接口。Kerberos 管理员可以使用 kadmin 实用程序添加主体、修改主体、删除主体、更改密码以及其他管理任务。kadmin 是通过网络从另一台机器运行的，它要求您验证拥有管理特权的主体。

kadmin.local 是 kadmin 的一个副本。它必须以根用户的身份在本地运行 KDC，它可以直接更改 KDC 数据库。管理员主体是处理管理任务的 KDC 服务主体。

kadmin 实用程序必须从命令行开始。

清单 5. 启动 kadmin.local 实用程序

				
kadmin.local
Authenticating as principal informix/admin@EXAMPLE.LENEXA.IBM.COM with
password.
kadmin.local:

在 kadmin.local 中，您可以执行 Kerberos 管理员任务。本文的代码清单假设您在执行管理员命令之前，已经登录到 kadmin.local 或 kadmin。

清单 6. 使用 kadmin.local 添加管理员主体

				
kadmin.local: addprinc informix/admin
Note: This will prompt for password for informix/admin@EXAMPLE.LENEXA.IBM.COM

Ex: kadmin.local:  add_principal informix/admin
Enter password for principal "informix/admin@EXAMPLE.LENEXA.IBM.COM": 
Re-enter password for principal "informix/admin@EXAMPLE.LENEXA.IBM.COM": 
Principal "informix/admin@EXAMPLE.LENEXA.IBM.COM" created.

kadmin.local:  list_principals
K/M@EXAMPLE.LENEXA.IBM.COM
informix/admin@EXAMPLE.LENEXA.IBM.COM
kadmin/admin@EXAMPLE.LENEXA.IBM.COM
kadmin/changepw@EXAMPLE.LENEXA.IBM.COM
kadmin/history@EXAMPLE.LENEXA.IBM.COM
krbtgt/EXAMPLE.LENEXA.IBM.COM@EXAMPLE.LENEXA.IBM.COM
Kadmin.local:quit

启动 KDC 守护进程。

Example: $/usr/local/sbin/krb5kdc

2. 在 KDC 中配置 IDS 服务器（服务）主体

在 Kerberos 安装中，每个实体（在服务器上运行的单个用户、计算机和服务）都拥有一个与之相关联的主体。对于每个启用 SSO 的 IDS 数据库服务器，KDC 管理员必须将一个服务器主体添加到 KDC 数据库。

服务主体的名称以服务的名称开头。Kerberos 5 服务主体包括安装服务的主机的完全限定域名（FQDN）。通用的服务主体格式是

service/fully-qualified-domain-name@REALM

在下面的例子中，将一个 Informix 服务器的服务主体（称为 ol_ids_1150）添加到 KDC。

清单 7. 将服务器服务主体添加到 KDC

Example: kadmin.local:  add_principal ol_ids_1150/toru.lenexa.ibm.com 
---------------------------------------------
Enter password for principal
"ol_ids_1150/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM": 
Re-enter password for principal
"ol_ids_1150/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM": 
Principal "ol_ids_1150/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM" created.

List the principals:
--------------------
kadmin.local:  list_principals
K/M@EXAMPLE.LENEXA.IBM.COM
informix/admin@EXAMPLE.LENEXA.IBM.COM
kadmin/admin@EXAMPLE.LENEXA.IBM.COM
kadmin/changepw@EXAMPLE.LENEXA.IBM.COM
kadmin/history@EXAMPLE.LENEXA.IBM.COM
krbtgt/EXAMPLE.LENEXA.IBM.COM@EXAMPLE.LENEXA.IBM.COM
ol_ids_1150/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM
kadmin.local:  quit

每个 IDS 服务器主体都与 KDC 共享它的私有密匙，并且这个密匙存储在服务器的 keytab 文件夹中。keytab 文件夹必须由进程访问权限进行保护。在 UNIX 上，所有者必须是用户 informix，组必须是 informix，而权限必须为 400。

清单 8. 将服务主体密匙添加到 keytab 文件

kadmin.local:  ktadd -k /etc/krb5.keytab -e "des-cbc-crc:normal"
 ol_ids_1150/toru.lenexa.ibm.com
Entry for principal ol_ids_1150 with kvno 2, 
encryption type DES cbc mode with CRC-32 added to keytab
WRFILE:/etc/krb5.keytab.

keytab 文件必须存放在 IDS 服务器所在的机器上。keytab 文件的位置在 krb5.conf 文件中指定。keytab 文件可以在 KDC 中生成，然后安全转移到 IDS 服务器机器，最后与现有的 keytab 文件合并，如下所示。

清单 9. 使用 ktutil 合并 keytab 文件

				
Example:/usr/kerberos/sbin/ktutil 
ktutil: rkt /etc/keytab.ol_ids_1150_fromkdc
ktutil: wkt /etc/krb5.keytab 
ktutil: quit

3. 在 KDC 中配置客户机（用户）主体

必须将每个客户机登录名添加到 Kerberos 数据库。通用的用户主体格式是 username[/instance]@REALM。

清单 10. 将一个 Informix 用户添加到 Kerberos 数据库

kadmin.local:  add_principal informix
Enter password for principal "informix@EXAMPLE.LENEXA.IBM.COM": 
Re-enter password for principal "informix@EXAMPLE.LENEXA.IBM.COM": 
Principal "informix@EXAMPLE.LENEXA.IBM.COM" created.
kadmin.local:  quit

4. 配置 IDS 以使用 SSO 身份验证

在 IDS 服务器和客户机中，SSO 身份验证通过使用 sqlhosts 和 concsm.cfg 条目来启用。

定义 SSO GSSCSM

concsm.cfg 文件定义 CSM 配置信息。在默认情况下，concsm.cfg 文件在 $INFORMIXDIR/etc/ 中。IDS 管理员（DBSA）可以配置 CSM 配置的位置，这通过在 IDS 启动时为其指定 INFORMIXCONCSMCFG 环境变量来实现。

concsm.cfg 中的条目的语法是

csmname("client=clientlib, server=serverlib, "global_opts", "conn_opts")

csmname 是通信支持模块的名称
clientlib 和 serverlib 值指定 GSSCSM 共享库的完整路径和名称
当前版本的 GSSCSM 模块中没有全局选项
连接选项指定是否使用保密性和完整性
保密性由连接选项 ‘c = [01]’ 来指定，值 1 表示使用了保密性（加密），0 则表示没有使用保密性。
完整性由连接选项 ‘i = [01]’ 来指定，值 1 表示使用了完整性（使用消息身份验证码确保接收和发送的消息是同一条消息），0 表示没有使用完整性。

示例 concsm.cfg 配置

GSSCSM("/work/informixdir/lib/csm/igsss11a.so", "", "c=1,i=1")

为 SSO 配置 SQLHOSTS 文件

将 SSO CSM 与 IDS 服务器的特定服务器别名关联起来。

为 SSO 身份验证配置的 sqlhosts 条目

ol_ids_1150onsoctcptoruol_ids_1150s=7,csm=(GSSCSM)

请参阅 IBM Informix Dynamic Server Administrators 指南和 IBM Informix Security 指南，获得详细的 SQLHOSTS 和 concsm.cfg 语法和用法（参见参考资料）。

配置 SSO 之后不要忘记重启 IDS，因为必须重启更改才生效。

5. 配置客户机以使用 SSO 身份验证

为 Client SDK 程序和客户机计算机准备 SQLHOSTS 信息和 Generic Security Services (GSS) CSM 配置文件的步骤，与对应的服务器端设置步骤是一样的。

ESQL/C 客户机

包含一个 SQLHOSTS 条目，它在 NETTYPE 字段中指定 onsoctcp（或 ontlitcp），在 OPTIONS 字段中指定 s=7,csm=(GSSCSM)，从而在服务器的 SQLHOSTS 信息中匹配 Kerberos 服务的相同信息。如果客户机运行的 INFORMIXDIR（或在相同的机器上）与服务器不一样，您就必须创建一个适当的 concsm.cfg 文件，很可能需要设置 INFORMIXCONCSMCFG 环境变量。

UNIX 和 Linux 上的 ODBC 客户机

对于 odbc.ini 文件中的已启用 SSO 的数据库服务器条目，将 ptions=s=7,csm=(GSSCSM) 添加到连接设置。

清单 11. 配置 ODBC 以使用 SSO

				
Example:
Driver=/ATM/STR100/sqldist/lib/cli/iclit01b.${SHLIBSUFFIX} 
Description=IBM INFORMIX ODBC DRIVER LogonID=informix Password=$INFORMIXPASSWORD
Pwd=$INFORMIXPASSWORD Database=common_db ServerName=ol_ids_1150 
ptions=s=7,csm=(GSSCSM).

JDBC 客户机

当 JDBC 驱动器为 SSO 的客户机时，使用 DriverManager.getConnection() 方法，它的 SSO 连接属性设置为 IDS 服务器服务主体。

修改连接 URL 使它包含服务主体。ENC=true 设置表示 Generic Security Services (GSS) 加密和完整性已经启用。

清单 12. 修改连接 URL

				
String url = 
"jdbc:informix-sqli://toru.lenexa.ibm.com:9019:informixserver=ol_ids_1150; 
 CSM=(SSO=ol_ids_1150/toru.lenexa.ibm.com@LENEXA.IBM.COM,ENC=true)";

用以下代码创建一个登录配置文件：

清单 13. 创建一个登录配置文件

				
Example: bcsLogin.conf file
com.sun.security.jgss.initiate {
        com.sun.security.auth.module.Krb5LoginModule required 
useTicketCache=true 
doNotPrompt=true;
}

通过 java.security.auth.login.config 属性运行应用程序，该属性设置为登录配置文件的完整路径名。

java -Djava.security.auth.login.config=bcsLogin.conf TestSso

IDS 服务器和客户机机器中的其他 Kerberos 配置

每个 IDS 客户机和服务器机器都应该启用 Kerberos 身份验证以使用 SSO。没有必要将 Kerberos 配置为用户的默认登录身份验证。用户通常可以通过在登录后在客户机机器上使用 kinit 来获得 Kerberos 凭证。IDS 服务器在启动时使用 keytab 文件自动获得服务器凭证。

使用 kinit 获得客户机身份验证凭证（TGT）

理想的情况下，配置客户机机器，这样登录过程要求用户在登录时提供 Kerberos 凭证。但是，如果客户机机器没有这样设置，则用户可以使用 kinit 命令获得凭证。如下所示。

清单 14. 使用 kinit 获得 Kerberos TGT 并使用 klist 实用程序检验 TGT

ex: /usr/local/bin/kinit  informix/admin@EXAMPLE.LENEXA.IBM.COM
Password for informix/admin@EXAMPLE.LENEXA.IBM.COM:

klist
-------
Ticket cache: FILE:/tmp/krb5cc_200
Default principal: informix/admin@EXAMPLE.LENEXA.IBM.COM

Valid starting     Expires            Service principal
07/16/08 06:53:46  07/17/08 06:53:40  krbtgt/EXAMPLE.LENEXA.IBM.COM@EXAMPLE.LENEXA.IBM.COM

Kerberos 4 ticket cache: /tmp/tkt200
klist: You have no tickets cached

添加 IDS 客户机和服务器机器的主机主体

在一个 Kerberos 域中，提供 Kerberos 服务的主机和服务器也有主体。因此，IDS 客户机和服务器的主机机器必须添加到 KDC 以实现成功的 Kerberos 身份验证。

一个示例 Kerberos 5 主机主体：host/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM

清单 15. 使用 kadmin 添加 Kerberos 5 主机主体

				
kadmin.local:  add_principal ol_ids_1150/toru.lenexa.ibm.com 
---------------------------------------------
Enter password for principal "ol_ids_1150/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM": 
Re-enter password for principal "ol_ids_1150/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM": 
Principal "ol_ids_1150/toru.lenexa.ibm.com@EXAMPLE.LENEXA.IBM.COM" created.

故障排除

在使用 Kerberos 协议的很多阶段都可能发生 Kerberos 身份验证故障。下面是一些最常见的导致故障的原因 —— 只要具备一些系统使用经验就可以避免所有这些故障。

客户机不能获得初始的 Ticket Granting Ticket (TGT)
- 如果客户机机器上的密码错误或 Kerberos 配置错误，客户机就不能获得 TGT。客户机主体名和客户机主机主体名必须在 KDC 数据库中。
客户机拥有有效的 TGT 但不能获取服务票据（TGS）
- 要诊断问题，请在 krb5kdc.log 文件中查找错误消息。在客户机机器上检查 Kerberos 配置。服务器服务主体应该在 KDC 数据库中。
客户机拥有 IDS 服务器的有效 TGT 和 TGS，但不能连接到 kerberos 式服务器
- 在 Kerberos 日志和 online.log 文件中查找错误消息。问题很可能发生在服务器端。检查 keytab 文件和密匙版本号。如果存在加密、时钟同步不匹配或其他配置错误，Kerberos 日志能够提供更多的信息。IDS 不支持跨域身份验证。

要测试 Kerberos 设置，我们推荐运行示例客户机和服务器程序，它们通常是 Kerberos 安装包的一部分。例如，MIT Kerberos 5 发行版就有称为 sclient 和 sserver 的示例程序。Heimdal 版本包括 gssapi_client 和 gssapi_server 程序。这些测试程序能够轻松捕捉任何可能导致身份验证失败的配置问题。

下面解释了一些特定的 SSO 错误消息和解决方案。

1. 5000: CSM error gss_init_sec_context() fails：时钟没有同步

服务器错误：

5000: CSM error: gss_init_sec_context: Unspecified GSS failure.  
Minor code may provide more information. Clock skew too great

krb5kdc.log 文件中的消息：

 Jul 10 13:02:52 lxvm-l141 krb5kdc[12925](info): TGS_REQ (5 etypes {17 16 23 3 1}) 
9.25.151.39: PROCESS_TGS: authtime 0,   
for ol_ids_1150/toru.lenexa.ibm.com@LENEXA.IBM.COM, Clock skew too great

解决方案：Kerberos 身份验证协议要求服务器和客户机之间的时钟差不大于 5 分钟。如果发生这种错误，请在 IDS 客户机、服务器和 KDC 机器上同步时钟。

2. 5000: CSM error：在 keytab 文件中没有服务器服务主体

服务器错误：

14:05:30  listener-thread: err = -5000: serr = 0: errstr = gss_acquire_cred:
 Unspecified GSS failure. Minor code may provide more information.
 No principal in keytab matches desired name

解决方案：IDS 服务器密匙存储在 Kerberos 配置文件指向的 keytab 文件中。如果没有为 Informix 服务器主体生成密匙，或服务器密匙存储在 IDS 服务器机器中的错误位置，就会导致 gss_acquire_cred() 失败。

如果 kerberos 式的 IDS 服务器能够读取客户机发出的用于身份验证的票据内容，存储在服务器的 keytab 文件中的加密密匙和密匙版本号，必须匹配存储在 Kerberos 数据库的加密密匙和密匙版本号。加密密匙或密匙版本号的不匹配会导致解密过程失败。

3. 25590：身份验证错误

Kerberos 日志文件中的消息：

Jul 24 05:07:27 sun280-6 krb5kdc[26612](info): TGS_REQ 9.25.148.203(0): 
UNKNOWN_SERVER: authtime 1216893965, 
informix@SUN_KDC for ol_vardhan/sun280-6.lenexa.ibm.com@SUN_KDC, 
Server not found in Kerberos database

解决方案：检查服务器服务主体名和客户机主体名是否存储在 KDC 数据库中。此外，还要在客户机上使用来自 klist 的输出检查有效的 Kerberos 凭证。只有拥有有效的、未过期的 TGT 的用户才能连接到 kerberos 式服务器。

4. 5000: CSM error: gss_acquire_cred：没有凭证错误

服务器错误：

5000: CSM error: gss_acquire_cred: No credentials were supplied, 
  or the credentials not found

在 online.log 中的消息：

14:14:46  listener-thread: err = -14565: serr = 0: errstr = : CSS: error reading data.
14:14:49  listener-thread: err = -25580: serr = 32: errstr =
 : System error occurred in network function.
 System error = 32.

如果试图连接的用户与其凭证保存在 Kerberos 缓存中的用户不一致，将发生身份验证错误。

5. 加密类型不匹配

krb5kdc.log 文件中的消息：

Jul 24 05:12:53 sun280-6 krb5kdc[26612](info): TGS_REQ 9.25.148.203(0): 
 BAD_ENCRYPTION_TYPE: authtime 1216893965, 
 informix@SUN_KDC for ol_ids_1150/toru.lenexa.ibm.com@SUN_KDC, 
 KDC has no support for encryption type

在客户机和服务器（和 KDC）上检查支持的 Kerberos 加密类型列表。当客户机和服务器机器用不同的 Kerberos 安装进行配置时，就更容易导致加密类型不匹配。

结束语

IDS 中的单点登录（Single-sign-on，SSO）支持可以简化用户身份验证和密码管理。本文概述了 IDS 用来提供 SSO 支持的 Kerberos 协议。您学习了设置 Kerberos 环境和在 IDS 中启用 SSO 所需的步骤。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15082138/viewspace-594512/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15082138/viewspace-594512/

congao1735

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Informix Dynamic Server 上使用单点登录身份验证

简介单点登录（Single Sign-On，SSO）是一个针对 IBM Informix Dynamic Server (IDS) 11.50 的新身份验证机制。有了 SSO 支持之后，用户只需要输入密码一次，就可以登录到操...
复制链接

扫一扫