现在，在WebLogic Server（WLS）上轻量级目录访问协议（LDAP）连接存在一些困难。可能您的认证提供者不能连接到LDAP。可能用户不能认证或者能认证但是没有需要的密码。可能是组成员关系失败或者是您在定义多个认证提供者时遇到麻烦。或许客户端的认证恰好缓慢。无论您碰到什么问题，当LDAP连接失败时，我们都有一些有用的故障分析技巧。



　　认证是一个认证提供者证明和检查用户或系统进程的身份的过程。WebLogic Server提供几种认证提供者，包括访问外部LDAP存储器的LDAP认证提供者。WebLogic Server 提供了能访问Open LDAP、Netscape iPlanet、LDAP Microsoft Active Directory、Novell NDS stores 以及其他LDAP存储器的LDAP认证提供者。

　　当您定义一个LDAP认证提供者时，可能会经历一次或多次普通的认证失败。让我们来做一些故障分析，看是否我们能解决一些这样的问题。

　　连接问题。如果WebLogic Server 不能连接到LDAP服务器上，您需要检查：

• LDAP服务器正在运行。如果是的话，您可以尝试用一个像www.iit.edu/~gawojar/ldap的LDAP浏览器去连接它。
• 在运行WLS的机器上已正确地定义和识别LDAP服务器的主机名。
• 端口号是正确的（默认的是389，对于SSL是636）。
• 负责人是一个在LDAP中的用户，不仅仅他的用户ID，而且完整的DN要配置为负责人，负责人配置如下：
  
  Principal="uid=admin,
  　　　　ou=Administrators,
  　　　　ou=TopologyManagement,
  　　　　o=NetscapeRoot"
  
• 密码是负责人的密码。

　　您可能收到一些常见的连接错误，如下：
　　LDAP error (49)—incorrect password (credentials)
　　LDAP error (32)—incorrect principal (user)

　　要获得LDAP结果代码的完整列表，请访问：
　　http://docs.sun.com/source/816-5608-10/log.htm#15324.

　　Debug标志。您可以通过用WebLogic.Admin命令行工具控制标志DebugSecurityAdjudicator、 DebugSecurityAtn、DebugSecurityAtz 和DebugSecurityRoleMap，以便动态打开或关闭调试选项。例如，在ServerDebug Mbean的所有管理实例中（比如管理服务器或者所有被管理的服务器），为了打开DebugSecurityAtz，用这样的代码：
　 java weblogic.Admin -url t3://host:port
　　　　　　　-username adminuser -password adminpwd SET
　　　　　　　-type ServerDebug -property DebugSecurityAtz
　　　　　　　true

　　注意，虽然在ServerDebugMBean状态下改变调试属性的值将会被反射，但是直到管理服务器重新启动才会产生输出。

　　对于每个您想调试的服务器，您也可以编辑文件config.xml 和<ServerDebug/>中Mbean元素，把它设置为“true”表示启用，设置为“false”表示禁用：
　　<ServerDebug
　　DebugSecurityAdjudicator="true"
　　　　　　// for security adjucator debug
　　DebugSecurityAtn="true"
　　　　　　// for security authentication debug
　　DebugSecurityAtz="true"
　　　　　　// for security authorization debug
　　DebugSecurityRoleMap="true"
　　　　　　// for security role mapping debug
　　Name="MyServer"/>

　　然后，您必须重新启动管理服务器。
确保StdoutDebugEnabled设置成“true”。您可以在config.xml中检查这一点。通过控制台或者使用命令行，可以启用 Debug to stdout。

　　-Dweblogic.StdoutDebugEnabled=true
调试信息将会被记录在服务器日志和标准输出中。服务器的日志文件在启动时通过消息BEA-170019指定：

　　BEA-170019 Notice: The server log file fileName
　　　　　　is opened. All server side log events will be
　　　　　　written to this file.

　　用户认证失败。WLS首先连接到LDAP，然后根据认证提供者定义的“User Base DN” 和 “User Filter”搜索用户，一旦发现了用户，WLS试着使用提供的密码去认证。

　　如果认证失败，在启用调试标志后，在日志文件中搜索getDNForUser模式，看为什么会失败。很可能要么用户不在LDAP中（javax.security.auth.login.FailedLoginException），或者密码不正确（认证失败错误49）。

　　搜索类似如下：

　　<SecurityDebug><getDNForUser search
　　　　　　("ou=people,dc=beasys,dc=com",
　　　　　　"(&(uid=fred)(objectclass=person))",
　　　　　　base DN & below)

　　如果用户不存在，我们会看到这样的信息：
　　<SecurityDebug><returnConnection
　　　　　　conn:netscape.ldap.LDAPConnection@e4bb3c>
　　javax.security.auth.login.FailedLoginException:
　　　　　　[Security:090302]Authentication Failed:
　　　　　　User fred denied

　　如果用户的密码不正确，我们会看到LDAP中整个DN被检索，但是认证失败：

　　<SecurityDebug> <DN for user fred:
　　　　　　uid=fred,ou=People,dc=beasys,dc=com>
　　<SecurityDebug> <authenticate user:fred with
　　　　　　DN:uid=fred,ou=People,dc=beasys,dc=com>
　　<Debug> <SecurityDebug>
　　<authentication failed 49>

　　组成员关系失败。在用户经过认证后，WLS搜索得到用户属于那些组的列表，这样能够在组和角色之间映射。这种搜索是通过用认证提供者定义的“Static Group DNs from Member DN Filter”来完成的。例如，对于iPlanet，这种搜索类似如下：

　　(&(uniquemember=%M)
　　(objectclass=groupofuniquenames))

　　%M可以用我们查找的组用户的完整DN代替。搜索可以根据您的LDAP层次而改变，如果用户不属于任何组，或者查询判别式不成立，我们可以看到相似的调试信息：

　　<SecurityDebug>
　　<getDNForUser search("ou=people,dc=
　　　　　　beasys,dc=com", "(&(uid=fred)
　　　　　　(objectclass=person))", base DN & below)>
　　<SecurityDebug>
　　<DN for user fred: uid=fred,ou=People,
　　　　　　dc=beasys,dc=com>
　　<SecurityDebug>
　　<search("ou=groups, dc=beasys,dc=com",
　　　　　　"(&(uniquemember=uid=fred,ou=People,
　　　　　　dc=beasys,dc=com) (objectclass=
　　　　　　groupofuniquenames))", base DN & below)>
　　<SecurityDebug>
　　<Result has more elements: false>

　　注意%M如何被用户的完整DN代替的。

　　角色映像失败。在用户经过认证后，WLS把一连串的组和用户当作允许访问资源的负责人。它要么授权访问或者拒绝访问。因此调用角色映像程序来决定用户和组的角色。然后，WLS访问授权者，决定授权或者拒绝访问要求的资源。清单1给出了一个被拒绝访问的用户的例子，因为他的角色不允许做他正在尽力做的事情——重新启动服务器。

　　清单1. 一个用户，weblogic，它是管理组的成员但是没有管理角色，所以没有启动服务器的权限。

　　<SecurityDebug>
　　<Default RoleMapper getRoles(): input arguments:
　　　　　　Subject: 2
　　　　　　Principal = class weblogic.security.principal.
　　　　　　WLSUserImpl("weblogic")
　　　　　　Principal = class weblogic.security.principal.
　　　　　　WLSGroupImpl("Admin")
　　　　　　Resource: type=<svr>, application=,
　　　　　　server=cgServer, action=boot>
　　<SecurityDebug>
　　<Default RoleMapper getRoles(): returning roles:
　　　　　　Anonymous>
　　<SecurityDebug>
　　<RoleManager.getRoles Subject: Subject: 2
　　　　　　Principal = class weblogic.security.principal.
　　　　　　WLSUserImpl("weblogic")
　　　　　　Principal = class weblogic.security.principal.
　　　　　　WLSGroupImpl("Admin")
　　　　　　Resource: <svr> type=<svr>, application=,
　　　　　　server=cgServer, action=boot Anonymous roles.>
　　<SecurityDebug>
　　<Default Authorization isAccessAllowed():
　　　　　　input arguments:>
　　<SecurityDebug>
　　<Subject: 2
　　　　　　Principal = class weblogic.security.principal.
　　　　　　WLSUserImpl("weblogic")
　　　　　　Principal = class weblogic.security.principal.
　　　　　　WLSGroupImpl("Admin")
　　<SecurityDebug> <Roles:Anonymous>
　　<SecurityDebug> <Resource: type=<svr>,
　　　　　　application=, server=cgServer, action=boot>
　　<SecurityDebug> <Direction: ONCE>
　　<SecurityDebug> <Context Handler: >
　　<SecurityDebug> <null>
　　<SecurityDebug> <Default Authorization
　　　　　　isAccessAllowed(): returning DENY>

　　如果存在多重认证提供者，就由协调者根据授权访问规则去决定是授权还是拒绝访问所请求的资源。
性能问题。把用户属于的那些组编成一个列表。然后对于其中每一个组，WLS寻找所有它属于的组。递归地执行这个过程直到一个组不属于其他的所有组。

　　因此，例如，如果用户U1属于组G1和G2，组G1属于组G3，于是用户U1属于G1、G2、G3。组成员关系取决于U1（导出G1和G2），然后是G1（导出G3），再是G2（没有导出），再是G3（没有导出）。这个递归搜索可能导致性能问题，特别是如果LDAP中有许多组。为了避免这样的性能问题和限制递归调用的次数，我们可以配置两个参数：GroupMembershipSearching 和MaxGroupMembershipSearchLevel。

　　GroupMembershipSearching属性控制是否组搜索限制深度，缺省的是无限搜索。如果配置一个限制搜索，　　MaxGroupMembershipSearchLevel属性具体指定限度。如果配置一个无限制搜索，则忽略axGroupMembershipSearchLevel属性。

　　如果GroupMembershipSearching属性设置为限定的，则MaxGroupMembershipSearchLevel属性控制组成员关系的搜索深度，否则，它被忽略，缺省值为0。

　　注意这些参数在WLS 8.1 SP3中是可以获得的。已经为 WLS 8.1 SP1 和 WLS 8.1 SP2 提供了一个补丁。
多重认证提供者。我们可以配置多重认证提供者。我们应该设置JAAS Control Flag attribute on the Authenticator-->General tab来控制认证提供者如何在登录序列中使用。控制标记可以是下面这些值中的一个：

• REQUIRED——认证提供者总是被调用，用户必须总是通过它的认证测试。
• SUFFICIENT——如果用户通过认证提供者的测试，就不执行其他的认证提供者（除非JASS控制标记设置为REQUIRENCED的认证提供者），因为用户已经经过充分认证了。
• REQUISITE——如果用户通过了这个认证提供者的测试。则执行其他的认证提供者，但是可能失败（除了JASS控制标记设置为REQUIRENCED的认证提供者）
• OPTIONAL——用户允许通过认证提供者的认证测试，然而，如果所有在安全域配置的认证提供者的JASS控制标记设置为OPTIONAL，则用户必须通过一个提供者的认证考察。

　　当一个安全提供者创建时，WebLogic Server 管理控制台设置JASS控制标记为OPTIONAL。安全提供者的Mbeans缺省为REQUIRED。

　　这些故障分析和调试技巧将会帮助您解决LDAP连接问题。如果这些提示都不能解决问题，为了进一步诊断故障，请联系BEA客户支持。您可以登录到http://support.bea.com/login.jsp，利用有效的支持合同创建一个实例。

原文出处：
　　http://www.fawcette.com/weblogicpro/2004_09/magazine/columns/troubleshootersdiary/