ibm tivoli

TDS代理服务器是一种特殊类型的目录服务器，它位于分布式目录的前面，并提供有效的请求路由。 它配置有后端服务器的连接信息，并为客户端提供统一的目录视图（TAM / WebSEAL）。 TAM提供了一套统一的安全服务，其中包括身份验证，授权，审核和日志记录。 TAM WebSEAL是一种多线程Web服务器，它将细粒度的安全策略应用于受TAM保护的Web资源。
本文将介绍与TAM环境中的TDS代理服务器有关的以下领域：

• 了解在TAM环境中使用TDS代理服务器的好处
• 了解全球行政小组
• 配置TDS代理服务器以进行故障转移和负载平衡
• TDS代理服务器在网络体系结构中的位置
• 在Access Manager环境中验证TDS代理服务器
• 管理TDS代理服务器
• 一些已知问题，代理的APAR修复和技术说明
• 对TDS代理服务器进行故障排除
• TDS代理6.1中添加的新功能
• 结论

了解在TAM环境中使用TDS代理服务器的好处

在TAM环境中，TDS代理服务器位于后端服务器和客户端之间，例如WebSEAL Policy Server，如图1所示。

图1

TDS代理服务器提供请求路由，负载平衡，故障转移和分布式身份验证。 以下是好处：

• 可以轻松分发和管理大量数据

在某些情况下，TAM有大量的用户数据要存储，在这种情况下，数据的分发和管理是最重要的。 使用TDS的代理功能，大量数据可以分布在多个后端服务器上，并且可以轻松地进行管理。

• TDS Proxy Server的请求路由功能提高了性能

在分布式环境中执行客户端请求的有效路由。 它将基于其拥有的分区信息将请求分发到分布式后端服务器。 代理知道数据的分发方法，并且知道这些方法后，代理就可以从后端服务器获取请求的数据并将其中继到WebSEAL客户端。 代理服务器与后端目录服务器之间的交互对于WebSEAL完全透明。

• 使用代理服务器可以实现可伸缩性

关于目录服务器，客户要求随时间而变化。 现在，预期可以存储数千个条目的目录服务器可以在五年后存储数百万个条目。 在单个目录服务器中存储数百万个条目非常困难，并且可能会降低性能。 同时，它引入了硬件可伸缩性问题。 在这种情况下，Proxy Server可以解决这些性能和可伸缩性问题。

• 故障转移和负载平衡

代理服务器还可以充当负载平衡器或故障转移管理器。 尽管，TAM使用可用的LDAP后端服务器具有自己的故障转移功能，但使用TDS代理服务器故障转移而不是TAM故障转移，可以提高性能和健壮性。 请记住，代理对读取请求执行负载平衡，并为更新请求进行故障转移

• 高可用性

通过在代理服务器之间使用故障转移，可以消除任何单点故障，并可以确保高可用性

了解全球管理小组

用户面临的最常见问题是，使用管理员DN（cn = root）连接到TDS代理服务器时，他们无法修改目录数据。 尽管cn = root是代理和后端服务器的管理DN（在配置代理和后端时将cn = root设置为管理DN），但是当用户使用cn = root连接到TDS代理时，该用户是该服务器的管理员仅代理服务器-不适用于后端服务器。 此时，用户对后端服务器是匿名的。 如果用户以cn = root身份绑定到代理服务器并尝试修改后端服务器条目，则该用户在修改条目时会遇到“访问权限不足”错误。 换句话说，cn = root只能更改代理服务器配置，并且只能访问具有匿名访问权限的那些后端目录条目。

全局管理组的目的是确保要通过代理修改后端服务器条目时，您具有访问后端服务器的正确管理员权限。 这里要注意的一点是，在这种情况下，即使您将代理绑定为全局管理组，也是如此。 您没有以下特权或：

• 对后端服务器的配置设置的访问权限。
• 对任何模式数据的访问权限。
• 访问审核日志。 因此，出于安全目的，本地管理员cn = root可以使用审核日志来监视全局管理组成员活动。

在代理环境中，全局管理组在后端服务器上定义，以向用户提供管理员权限。 TAM WebSEAL不知道全局管理组。

将用户添加到全局管理组的步骤

# idsldapadd -h hostname -p port_no -D cn=root -w root -f LDIF1
# idsldapadd -h hostname -p port_no -D cn=root -w root -f LDIF2where LDIF1 contains:       and where LDIF2 contains:
dn: cn=manager,cn=ibmpolicies     dn: globalGroupName=GlobalAdminGroup,cn=ibmpolicies
objectclass: person         changetype: modify
sn: manager             add: member
cn: manager             member: cn=manager,cn=ibmpolicies
userpassword: secret

故障转移，负载平衡和高可用性的代理

如前所述，TDS代理服务器可以充当故障转移代理，还可以对客户端请求进行负载平衡。 代理知道给定分区的所有主服务器，并且必须使用其中一个作为主服务器。 在分区信息中找到的第一个母版被选作主要母版。 如果主主服务器已关闭，则代理能够故障转移到备用服务器（对等服务器之一）。

如果代理在启动时无法与一个或多个后端服务器连接，则代理仅在配置模式下启动。 在设置服务器组之前，这是正确的。 服务器组在代理服务器上定义，用于从多台对等服务器中至少获取一台联机后端服务器，以便即使该组中的一台或多台后端服务器宕机也可以继续运行。 在图2中，您可以轻松地预测服务器组1由前两个目录服务器组成，服务器组2由其他两个目录服务器组成。 在每个服务器组中，您有一台主服务器和一台对等服务器。 因此，如果服务器组1中的主服务器已关闭或不可用，则代理可以故障转移到同一服务器组中的其他对等服务器。 如果当前联机的服务器无法执行请求的操作，则代理服务器将返回操作错误。

图2

当TDS代理联机时，它将查询每个后端服务器的复制拓扑。 作为给定分区的子树的主服务器的任何后端服务器都将添加到代理的“可写”列表中。 其他的将添加到“可读”列表中。 现在，为了避免冲突解决，代理将使用第一个“可写”服务器并将所有更新请求发送到该服务器。 这一直持续到该服务器脱机。 届时，代理将自动故障转移到下一个可用的“可写”服务器，并继续使用它直到失败。

代理还知道给定分区的所有副本，并且它可以负载平衡在线副本之间的读取请求。 代理为读取请求执行负载平衡，并为更新请求执行故障转移。 代理发送更新请求并读取到适当的读/写和只读服务器。

TDS代理还可以处理对未分发目录的请求，但是这些目录必须是TDS V6.0目录，并且您必须向代理提供有关子树的拆分点信息。 诀窍是设置分割点，但是分割点只有一个分区。 可能存在这样的情况：客户已经拥有TDS后端服务器和副本服务器设置的现有环境，并且要求仅提供负载平衡而不提供数据分发。 在这种情况下，引入代理服务器可以对请求进行负载平衡，并在一定程度上提高性能。

代理的高可用性：如果需要，可以使用负载平衡器将TDS代理服务器设置为进行故障转移，以实现高可用性，并且它将充当消除的单点故障。 负载平衡器（例如IBMWebSphere®Edge Server）可用于平衡代理服务器之间的LDAP读/写请求。 负载平衡器配置为仅将这些请求发送到一个代理服务器。 如果该代理服务器由于网络故障而关闭或不可用，则负载平衡器会将请求发送到下一个可用的代理服务器，直到第一个代理服务器可用为止。 同样，TDS代理服务器不能被级联，即一个代理不能坐在另一个代理后面，也不能将请求传递给它后面的另一个代理（在另一个网络区域中），第二个代理然后将请求传递给后端服务器。

TDS代理服务器在网络体系结构中的位置

在本节中，我们讨论TDS代理服务器在网络体系结构中的位置。 由于WebSEAL仅了解代理，并且没有后端服务器的信息，因此WebSEAL将与TDS代理服务器（而不是TDS后端服务器）进行交互以执行LDAP操作。 这意味着WebSEAL必须可以访问TDS代理服务器。 但是，不应从Internet访问它。 如图3所示，Internet位于不受控制的区域下。 Internet DMZ和Intranet位于控制区域下，生产网络位于限制区域下，而管理网络位于安全区域下。

图3

以下是代理服务器的可能放置位置：

• 代理服务器不应放置在Internet不受控制的区域中。
• 永远不要将Proxy Server放置在Internet DMZ控制区域中。
• 如果不存在生产或管理网络，则可以将代理服务器部署在Intranet受控区域中。
• 如果存在生产网络区域，则这是代理服务器的第一个放置点。
• 管理区域是主后端服务器的逻辑放置点； 但是代理服务器也可以放在这里。

TDS代理服务器可用于跨中间网络区域进行请求。 例如，绑定TDS客户端（在这种情况下为WebSEAL）位于DMZ中，而TDS后端服务器和数据库位于管理区域或生产区域中，并且它们之间具有多个中间网络区域。

在Access Manager环境中验证代理

在TAM环境中设置代理后，建议您验证TDS代理和策略服务器。 在Access Manager环境中验证代理和策略服务器的基本步骤包括：

1）验证TDS代理

a）验证代理是否已启动并正在运行

# ibmdirctl -D <admin-dn> -w <admin-pwd> status

b）在代理上运行ldapsearch，以查找后端服务器上的现有条目

#ldapsearch -D <Global_AdminGroup_member> -w <password> -p <port> -s sub -b "" \
objectclass=*

c）通过代理添加条目，并验证是否在后端添加了该条目

# ldapadd -h <hostname> -D <Global_AdminGroup_member> -w <password> -p <port> -i \
<add.ldif>where ldif file contains :dn: cn=sunil,o=ibm,c=us
objectclass: person
cn: Sunil
sn: Verma
userpassword: password
-
dn: cn=sunil,cn=Users,secAuthority=default
objectclass: person
cn: Sunil
sn: Verma
userpassword: password

d）检查并确保在代理，后端服务器和副本上使用ldapsearch在后端正确添加了条目

Run below ldapsearch on proxy, master and replica server as well :# ldapsearch -h <hostname> -D <Global_AdminGroup_member> -w <password> -p <port> -s sub \
-b "cn=sunil,o=ibm,c=us" objectclass=*# ldapsearch -h <hostname> -D <Global_AdminGroup_member> -w <password> -p <port> -s sub \
-b "cn=sunil,cn=Users,secAuthority=default" objectclass=*

如果使用两个带有副本的主后端服务器使用基于子树的分区来设置代理，则可以通过在代理的子树下添加一个测试条目来对其进行验证。 例如，在一个后端服务器上定义了o = ibm，c = us，在另一台后端服务器上定义了secAuthority = default。 接下来，应该在两个后端服务器上对添加的条目执行ldapsearch，以检查是否正确添加了条目。 在主服务器上搜索条目之后，应在副本服务器上执行相同的搜索，以检查条目是否正在复制。

如果是RDN和基于散列的分区设置，则可以在任何服务器上添加条目，这取决于散列算法，因此应在后端和副本服务器上都执行搜索以验证代理。

2）验证策略服务器

a）Policy Server是否已启动并正在运行

# pd_start status

b）检查ldap.conf文件中的代理详细信息

--ldap.conf--
[ldap]
ldap-server = proxy IP Address
-------------

注意：ldap.conf文件应指向代理，而不是后端服务器或副本服务器。

c）登录到pdadmin

# pdadmin -a sec_master -p password

这是验证的第一步。 之后，您可以执行一些命令来验证您的环境，例如，使用user list命令列出用户。

d）使用pdadmin添加用户

# pdadmin> user create varsha cn=varsha,o=ibm,c=us Varsha Sogani password

e）在代理和后端副本上检查是否添加了条目

# ldapsearch -h <hostname> -D <Global_AdminGroup_member> -w <password> -p <port> -s sub \
-b "cn=varsha,o=ibm,c=us" objectclass=*# ldapsearch -h <hostname> -D <Global_AdminGroup_member> -w <password> -p <port> -s sub \
-b "cn=varsha,cn=Users,secAuthority=default" objectclass=*

管理TDS代理

将TDS代理放置在TAM环境中并不意味着不需要调整后端服务器。 Tivoli Directory Server是LDAP目录，它在DB2®之上提供了一层，允许用户有效地组织，操纵和检索DB2数据库中存储的数据。 调优以获得最佳性能主要是根据工作量的性质调整LDAP服务器与DB2之间的关系的问题。

以下指南提供了IBM Tivoli Directory Server和相关IBM数据库的调整信息。

调优指南： 性能调优指南

IBMRedbooks®： IBM Tivoli Directory Server的性能调优

1）代理的架构管理

配置代理后，它将使用自己的架构进行配置。 代理服务器应与作为其代理服务器的后端服务器具有相同的架构定义。为了使代理服务器的架构与后端服务器的架构同步，修改后的架构文件（例如，V3.modifiedschema）应从后端服务器复制到代理服务器。

注意：所有后端服务器的架构文件也应该同步。

2）备份配置和架构文件

如果存在数据库或任何其他文件的备份过程，则建议您备份ibmslapd.conf和模式文件。 除了数据库备份外，还应按时备份配置文件和架构文件，以便万一发生故障，可以再次正确配置LDAP服务器。

其他一些已知问题，代理的APAR修复和技术说明

使用TDS代理服务器配置WebSEAL时，您可能会遇到几个问题。 要在TAM环境中使用TDS代理服务器，我们建议TDS代理应位于最低修订包级别2（FP02）上。 以下是已知问题：

1）当配置为使用Tivoli Directory Server代理服务器6.0时，WebSEAL无法认证用户。

使用TDS代理服务器配置WebSEAL时，可能会遇到认证问题。 常见问题之一是WebSEAL在配置为使用Tivoli Directory Server Proxy Server 6.0时无法认证用户。 用户可以成功绑定TDS代理服务器和主LDAP服务器。 例如，用户“ sunil”可以将“ idsldapmodify -D cn = sunil，O = IBM，C = US -w密码”绑定到TDS代理服务器和主后端服务器。 要检查某些身份验证问题，请首先收集IRA跟踪。 IRA跟踪是在WebSEAL机器上收集的LDAP客户端跟踪，用于查找可能有助于查找问题原因的所有ldap返回代码。 在这种情况下，ldap_compare按预期成功，但是ira_cache_user_get_groups返回“ d2”，表示该用户不属于任何组。

爱尔兰共和军的痕迹

2006-01-11-14:02:53.683+11:00I----- thread(3) trace.pd.ivc.ira:8 /project/am600 \
/build/am600/src/ivrgy/ira_cache.c:2092: CII EXIT
ira_cache_user_get_groups() with status:  0x000000d2

运行以下搜索以针对主后端服务器和代理获取用户的组成员身份。 结果非常不同，如下所示：

# idsldapsearch -D cn=root -w password -h hostname -p port_no -b "cn=sunil,O=IBM,C=US" \
"objectclass=*" ibm-allgroupsLDAP Master Returned:
cn=sunil,O=IBM,C=USLDAP Proxy Returned:
Did not return anything!

将WebSEAL配置为使用LDAP代理时，用户身份验证可能会失败，因为它无法成功完成LDAP搜索以确定用户的组成员身份。 将用户添加到组时，WebSEAL认证将成功。 此外，通过将用户添加到组并再次运行搜索，LDAP搜索也会成功执行，依此类推。 进行WebSEAL认证。 这是ADS IO03861中修复的TDS 6.0中的缺陷。

APAR IO03861：如果请求了ibm-allGroups，则代理不返回DN。 测试成功完成。 我们可以验证没有组成员身份的用户现在可以通过指向ldap代理的WebSEAL登录。 当客户机需要ibm-allGroups属性时，代理不返回任何数据。 不属于任何组的用户都是如此。 对于属于组成员的用户，代理将返回正确的DN。 但是，如果用户不是任何组的成员，则不会返回DN。 代理必须返回该用户的DN。

2）当TDS后端服务器计算机关闭时，TDS代理服务器不会故障转移到其他可用的TDS后端服务器。

当TDS后端服务器计算机关闭时，WebSEAL不会从代理服务器获得响应，因为代理不会故障转移到其他可用的TDS后端服务器。 在这种情况下，WebSEAL用户无法进行认证。 此外，在代理执行故障转移到可用的后端服务器之前，使用Policy Server的用户配置将被保留。

6.0中的TDS故障转移旨在处理后端服务器关闭或未运行时的异常情况，但是，如果网络关闭，则TDS故障转移将不起作用。 如果TDS后端服务器出现故障，则代理上的任何打开套接字都会从TCP层获取FIN数据包，因此代理可以得出后端服务器进程已关闭的结论。

如果后端计算机断开网络连接或发生故障，则代理上的TCP堆栈不会从事件的后端服务器获取信息，因此它会等待（因此代理进程会等待）。 TCP堆栈具有适当的方法来处理此类较低级别的问题。 TCP被设计为Internet上的可靠协议，因此它解决了网络层的问题，例如不良主机或路由器（它希望OSPF等问题可以通过找到备用路由来解决），因此默认超时为7200。秒或两个小时。

要验证TCP超时后是否会发生TDS故障转移： TDS代理服务器的确会响应并在keepalive超时后打印一条错误消息，并且应该在TCP超时后进行故障转移。 这是如何更改tcp_keepalive_ *设置（对于Linux®）。

# cd /proc/sys/net/ipv4
# ls -la tcp_keepalive_*-rw-r--r--  1 root root 0 Nov 24 22:57 tcp_keepalive_intvl
-rw-r--r--  1 root root 0 Nov 24 22:57 tcp_keepalive_probes
-rw-r--r--  1 root root 0 Nov 24 22:57 tcp_keepalive_time# echo 5 > tcp_keepalive_intvl
# echo 2 > tcp_keepalive_probes
# echo 15 > tcp_keepalive_time

3）在使用Webadmin GUI来管理密码策略的代理时，对于不同的环境可以看到不同的行为。

a）连接到代理服务器时，如果在代理的ibmslapd.conf文件中仅定义了cn = pwdPolicy拆分，则webadmin不会隐藏pwdpolicy条目，如下所示：

dn: cn=pwdpolicy split, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, cn=Schemas, \
cn=Configuration
cn: pwdpolicy split
ibm-slapdProxyNumPartitions: 1
ibm-slapdProxyPartitionBase: cn=pwdpolicy
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdProxyBackendSplitContainerdn: cn=split1, cn=pwdpolicy split, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory,\
cn=Schemas, cn=Configuration
cn: split1
ibm-slapdProxyBackendServerDN: cn=Server1,cn=ProxyDB,cn=Proxy Backends, cn=IBM \
Directory, cn=Schemas,cn=Configuration
ibm-slapdProxyPartitionIndex: 1
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdProxyBackendSplit

b）当您使用cn = root或任何其他用户通过Webadmin GUI连接到代理服务器并尝试进行更改时，服务器发出的访问错误不足，这是正确的。 为了进行更改，您应该使用全局管理员组成员登录。

4）如果使用“ idsslapd”命令启动了代理服务器实例，它将不会加载正确的代码或执行环境，并且将无法正常运行。 确切的结果是无法预测的。

可以使用“ ibmslapd”命令或“ idsslapd”别名启动TDS 6.0服务器实例。 这两个命令都在/opt/IBM/ldap/V6.0/sbin中执行“包装器脚本”，该脚本会初始化环境并为服务器实例加载适当的代码，具体取决于它是常规的“ RDBM”服务器还是“ PROXY”服务器。 命令应相同。 但是，“ idsslapd”包装脚本中存在一个错误，该错误无法为PROXY服务器实例加载正确的代码。

此问题的解决方法是用V6.0 / sbin / ibmslapd脚本的副本或符号链接替换V6.0 / sbin / idsslapd脚本。 或仅使用“ ibmslapd”命令。

此问题已在APAR IO06919中修复。

5）固定为代理的APAR

• IO07536：来自openldap客户端的[仅AIX®]匿名DIGEST-MD5绑定可能会使AIX上的TDS 6.0代理服务器崩溃
• IO07309：[仅Linux]错误GLPCOM027E在特权端口上启动代理
• IO06919：启动代理服务器实例时，[仅AIX] GLPWRP002E错误
• IO06918：如果使用“ idsslapd”命令启动，则PROXY服务器不稳定
• IO06323：代理服务器可能挂起（死锁）
• IO05509：后端服务器关闭时，代理服务器核心（ABEND）
• IO05748：如果启用了跟踪，则代理将在比较操作中终止
• IO05579：代理服务器每次操作泄漏48个字节
• IO05508：更正了代理支持的控件和ibm支持的功能
• IO05269：审核操作ID以将代理请求映射到后端操作
• IO05276：代理服务器泄漏内存处理修改操作
• IO05287：代理服务器可能会放弃执行绑定操作
• IO05261：如果后端服务器关闭，则Windows®上的代理服务器将使用较高的CPU
• IO05092：“ ldap_delete：操作错误”正在删除代理服务器上的条目
• IO05040：通过代理删除或修改可能返回LDAP_INSUFFICIENT_ACCESS
• IO04808：代理服务器可能会在压力下崩溃（ABEND）
• IO04765：为了增强代理服务器的可维护性，请为每个成功打开的TCP连接记录一条消息
• IO03861：如果请求了ibm-allGroups，则代理不会返回DN
• IO03862：代理程序崩溃，而操作员未采取任何特殊措施。
• IO04277：6.0代理不应将更新发送到“转发器”服务器
• IO04208：代理在监视器搜索中返回错误的opscompleted值
• IO03886：需要有关代理服务器功能的更多信息
• IO03885：当成员被删除时，代理不会更新全局管理组
• IO03334：代理面板中的默认连接池大小应增加
• IO02387：代理服务器无法正确处理仅属性搜索。
• IO02385：处理摘要MD5身份验证时，代理服务器异常终止。
• IO02378：代理服务器异常终止处理ibm-allgroups搜索。
• IO02369：增强代理服务器，以允许只有1个分区时修改拆分容器条目。
• IO02374：使用组的Acl解析无法通过代理服务器正确运行。
• IO02377：如果由非管理用户调用，则比较，删除和modrdn操作无法通过代理正确操作。

6）代理技术说明

Linux：代理无法在端口389上启动； 出现errno 13失败（权限被拒绝） ...

通过代理进行引用跟踪：ITDS 6.0代理服务器不跟踪引用...

ITDS v6.0代理和后端ldap服务器-支持的扩展，控件和功能...

代理服务器不支持对ibm-allgroups进行基于子树的搜索...

IBM Tivoli Directory Server 6.0代理服务器与早期版本的IBM Tivoli Directory Server不兼容...

对TDS代理进行故障排除

1）如果操作失败，您需要检查的基本日志文件

在后端服务器上使用代理时，通过查看日志文件中的错误消息可以解决许多问题和故障。 您可以使用日志文件来验证正确的行为。 日志文件是查看遇到的任何错误的第一个选项。 日志文件将使您对已发生的事情有基本的了解。 仅管理员或管理组成员可以查看或访问代理日志信息。

代理日志的默认日志路径为：

UNIX®路径：instance-base-directory / idsslapd- <instance-name> / logs

Windows路径：drive \ idsslapd- <实例名称> \ logs

WebSEAL的缺省消息日志路径是：

UNIX路径：/var/pdweb/logs/msg__webseald-<instance-name>.log

Windows路径：<安装驱动器> \ Tivoli \ logs \

注：通常使用ibmslapd.log文件和audit.log文件，其中审计日志记录用于提高目录服务器的安全性，而ibmslapd.log用于查看与服务器相关的状态和错误消息。

在TDS 6.0管理员指南中可以找到有关日志和日志管理的更多说明。

消息指南可用于对日志中的错误采取适当的措施。

2）如果日志未发现问题，则收集调试数据的更多详细信息

如果您无法使用日志解决问题，则在发生故障时收集基本信息总是有帮助的。 这些详细信息可帮助支持团队分析问题：

a）在代理服务器和后端服务器上也启用ASCII /二进制跟踪。 可以从下面的技术说明链接中遵循收集服务器跟踪的步骤：

如何在启动时收集ascii服务器跟踪

如何收集动态ascii服务器跟踪。

如何在ITDS上收集并发动态二进制和ASCII服务器跟踪

b）LDAP版本和修订包级别详细信息：＃ldapsearch -e输出
我们建议您始终处于最新的修订包级别： 升级到最新的修订包级别

c）目录下的所有日志文件：

• / home- <实例名称> / idsslapd- <实例名称> / logs
• 和/ home / <实例名称> /sqllib/db2dump/db2diag.log

d）代理配置文件-ibmslapd.conf：

/ home / <实例名称> / idsslapd- <实例名称> / etc

e）其他一些有用的信息：

• 操作系统详细信息
• DB2 Fixpack详细信息：db2level
• 复制详细信息？ （如对等，主副本）
• SSL详细信息（无论是否启用）

f）为WebSEAL收集的其他数据

• webseald- <实例名称> .conf
• msg__webseald- <instance-log> .log

3）检查身份验证错误（拒绝登录）

使用TDS代理服务器配置WebSEAL时，可能会遇到认证问题。 要检查是否存在某些登录拒绝，请首先检查并验证用户是否可以成功绑定TDS代理和主LDAP服务器。 如果用户能够绑定到TDS代理服务器和主后端服务器，则在WebSEAL消息日志中查找任何登录错误消息。 若要进一步调查问题，请收集IRA跟踪。 IRA跟踪是在WebSEAL机器上收集的LDAP客户机跟踪，以查找任何ldap返回码，这可以帮助找到问题的根本原因。

例如：在WebSEAL服务器消息日志（/var/pdweb/log/msg__webseald-default.log）中捕获的失败登录：

---------------------------------------
2007-09-20-07:55:29.772+00:00I----- 0x132120DD webseald WARNING ias authsvc pdauthn.cpp
1435 0x00002728
HPDIA0221W   Authentication for user testuser failed. You have used an invalid user name,
password or client certificate.
---------------------------------------

收集IRA跟踪记录：
使用以下命令启用pd.ivc.ira跟踪：
pdadmin>服务器任务webseald-instance-name跟踪集pd.ivc.ira 9文件路径= / tmp / pdweb.ira.out

使用以下命令禁用pd.ivc.ira跟踪：
pdadmin>服务器任务webseald-instance-name跟踪集pd.ivc.ira 0

pd.ivc.ira跟踪输出的一部分，该部分显示登录钉和LDAP服务器的返回码：

-------------------------------------
2007-07-20-07:55:29.757+00:00I----- thread(4) trace.pd.ivc.ira:8 /project/am510/build/
am510/src/ivrgy/ira_auth.c:1417: CII ENTRY: ira_auth_passwd_compare() dn: cn=testuser,
o=ibm,c=us2007-07-20-07:55:29.757+00:00I----- thread(4) trace.pd.ivc.ira:7 /project/am510/build/
am510/src/ivrgy/ira_entry.c:3053: ira_ldap_compare_s() DN: cn=testuser,o=ibm,c=us Attr
: userPassword2007-07-20-07:55:29.758+00:00I----- thread(4) trace.pd.ivc.ira:7 /project/am510/build/
am510/src/ivrgy/ira_ldap.c:757: ira_ldap_compare_s(): No timeout - calling ldap_compare_s2007-07-20-07:55:29.759+00:00I----- thread(4) trace.pd.ivc.ira:7 /project/am510/build/
am510/src/ivrgy/ira_ldap.c:767: ira_ldap_compare_s: Returning LDAP rc x52007-07-20-07:55:29.759+00:00I----- thread(4) trace.pd.ivc.ira:7 /project/am510/build/
am510/src/ivrgy/ira_entry.c:3060: LDAP rc: x52007-07-20-07:55:29.759+00:00I----- thread(4) trace.pd.ivc.ira:8 /project/am510/build/
am510/src/ivrgy/ira_auth.c:1427: CII EXIT ira_auth_passwd_compare() with rc:
0x00000031 LDAP_ERROR x5 "A compare operation returned false.".
--------------------------------------

IRA跟踪显示登录失败的LDAP返回码。 x31“无效的凭据”或x5“比较操作返回false”。 使用绑定或比较的身份验证由webseald-default.conf文件中的“ auth-using-compare”参数控制。

4）使用代理配置TAM Policy Server / WebSEAL时检查访问控制

Tivoli Access Manager必须具有适当的访问控制，才能在维护用户和组定义的后缀中管理用户和组。 换句话说，TDS后端服务器必须具有对Policy Server和WebSEAL的适当访问控制，才能执行LDAP操作。 无法从TDS代理服务器修改和管理TDS代理服务器的访问控制列表（ACL）。 使用代理服务器时，是后端服务器强制执行访问控制。 如果分区拆分点的顶级对象上存在ACL，请确保在每个后端服务器上都创建并附加了正确的ACL。 要在后端服务器上设置必要的ACL以允许Tivoli Access Manager管理分区后缀，请使用带有add-acls参数的Tivoli Access Manager ivrgy_tool实用程序。

# ivrgy_tool -h 9.182.194.116 -p 3389 -D cn=root -w root -d add-acls default
ivrgy_tool: Attempting to add Access Control Lists (ACLs) to each suffix for domain \
"default".O=IBM,C=USSECAUTHORITY=DEFAULT
ivrgy_tool: IRA interface reports result (x'0'):
Request was successful.

TDS代理6.1中添加的新功能

1. 监视： TDS 6.1代理支持其他监视搜索，这有助于更好地监视配置有代理的分区基础以及针对每个后端服务器请求的操作的单独操作计数。 您还可以监视在代理后端执行的操作总数。
2. 运行状况检查： TDS 6.1代理服务器在后端服务器上提供运行状况检查并快速进行故障转移，以减少故障转移条件下失败操作的数量。
3. 3.代理服务器快速故障转移和后端服务器的分层优先级：在TDS 6.1中，可以为每个分区配置主要的后端服务器，这可以通过将后端服务器分组为优先级来实现。
4. 哪里是条目： TDS 6.1代理服务器允许管理员使用代理服务器分区算法来定位将存储给定条目的后端服务器。
5. 支持LDAP事务：代理服务器提供有限的事务支持。 当事务中的所有操作都针对单个后端服务器时，允许事务。
6. 密码策略支持：代理服务器现在提供对全局密码策略的完全支持，并且只要不对数据进行分区，在代理环境中还支持多个密码策略。
7. 代理服务器配置：代理服务器可以配置为作为全局管理组成员绑定到后端服务器。 在以前的版本中，他们必须绑定为本地管理组成员或root管理员。
8. 对代理服务器组的Web Admin支持：在TDS 6.1中，可以使用Web管理工具配置服务器组。
9. 定制的DN分区算法： IN TDS 6.1分区功能正作为插件实现，ITDS代理服务器分区算法很容易替换。 结果，ITDS代理服务器可以更灵活，更具适应性。
10. 多线程分布式目录设置工具：可以在ITDSv6.1中创建多线程ddsetup工具，以使用代理服务器的配置文件和该工具的性能改进。

结论

本文介绍了TDS代理的管理，放置和故障排除，以更好地了解和管理TDS代理服务器。 它涵盖了在TAM环境中使用TDS代理服务器的好处以及对全球管理小组的了解。 它还涵盖了代理服务器报告的一些已知问题。

致谢

我们要感谢Darshan R Donni在本文中对TDS代理概念的宝贵贡献。

翻译自: https://www.ibm.com/developerworks/tivoli/library/t-tdsproxytam/index.html

ibm tivoli