我已成功安装了NDS eDirectory 8.8.5(linux版),我终端已连上了389端口但我用 JXplorer LDAP Browser工具连LDAP 却报错:Error opening connection:
[LDAP: error code 13 - Confidentiality Required]哪位大侠能告诉我什么原因么?能提供详细的解决方法么

解决方案 »

  1.   

     连接问题。如果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,利用有效的支持合同创建一个实例。