Question

我们有一个使用ldap对用户进行身份验证的应用程序。我们将https://www.ldaptive.org/用作ldap客户端，并通过jaas登录配置文件对其进行配置。

以下是我们的jaas登录配置文件的示例：

ourApplication {
  org.ldaptive.jaas.LdapLoginModule required
    storePass="true"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=People,dc=example,dc=com"
    useStartTLS="false"
    bindDn="uid=admin,ou=People,dc=example,dc=com"
    bindCredential="password"
    userFilter="(uid={user})";
  org.ldaptive.jaas.LdapRoleAuthorizationModule required
    useFirstPass="true"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=Roles,dc=example,dc=com"
    roleFilter="(member={dn})"
    roleAttribute="cn";
};

这很好用。随着时间的流逝，我们开始出现错误，类似于此处所述：

https://confluence.atlassian.com/confkb/ldap-queries-fail-with-address-already-in-use-error-222201829.html

如果链接出现问题，则来自汇合用户的投诉是，有时无法通过ldap服务器对用户进行身份验证。报告这样的错误：

2010-08-10 13:04:18,277 ERROR [http-80-8] [user.impl.ldap.LDAPUserManagerReadOnly] getUser Error retrieving user: 'Husein.Alatas' from LDAP.
 -- url: /display/Test | userName: Husein.Alatas | referer: http://confluence/display/dashboard/Home | action: notpermitted
com.atlassian.user.impl.ldap.repository.LdapConnectionFailedException: javax.naming.CommunicationException: ldap.atlassian.com:389 [Root exception is java.net.BindException: Address already in use: connect]
    at com.atlassian.user.impl.ldap.repository.DefaultLdapContextFactory.getLDAPContext(DefaultLdapContextFactory.java:93)
    at com.atlassian.user.impl.ldap.search.DefaultLDAPUserAdaptor.search(DefaultLDAPUserAdaptor.java:70)
    at com.atlassian.user.impl.ldap.search.DefaultLDAPUserAdaptor.search(DefaultLDAPUserAdaptor.java:54)
    at com.atlassian.user.impl.ldap.LDAPUserManagerReadOnly.getUser(LDAPUserManagerReadOnly.java:70)
    at com.atlassian.user.impl.delegation.DelegatingUserManager.getUser(DelegatingUserManager.java:68)
    at bucket.user.DefaultUserAccessor.getUser(DefaultUserAccessor.java:146)
...
Caused by: javax.naming.CommunicationException: ldap.atlassian.com:389 [Root exception is java.net.BindException: Address already in use: connect]
    at com.sun.jndi.ldap.Connection.<init>(Connection.java:200)
    at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:118)
    at com.sun.jndi.ldap.LdapClientFactory.createPooledConnection(LdapClientFactory.java:46)
    at com.sun.jndi.ldap.pool.Connections.getOrCreateConnection(Connections.java:185)
...
Caused by: java.net.BindException: Address already in use: connect
    at java.net.PlainSocketImpl.socketConnect(Native Method)
...

我们正在获得类似的通信并绑定错误。

上面的链接建议运行

netstat -na

在我们的应用程序服务器上使用

命令查看与ldap服务器的打开连接是否很多。当我这样做时，我看到数百行如下所示：

TCP    129.135.249.138:65525  129.135.28.18:10389    ESTABLISHED

左边的地址是我们的server：port，右边的地址是ldap server：port。最终，左侧的端口转到65535，这可能是导致无法进行身份验证的原因：所有端口都已占用，因此无法通信。

上面的atlassian链接指向ldaptive jaas配置页面，以获取有关如何为ldaptive配置连接池的示例：

https://www.ldaptive.org/docs/guide/jaas.html

这是ldaptive给出的示例，用于通过jaas配置将ldaptive配置为使用连接池：

ldaptive {
  org.ldaptive.jaas.LdapLoginModule required
    ldapUrl="ldap://directory.ldaptive.org:389"
    baseDn="ou=people,dc=ldaptive,dc=org"
    bindDn="cn=priviledged_user,ou=services,dc=vt,dc=edu"
    bindCredential="notarealpassword"
    useStartTLS="true"
    userFilter="(uid={user})"
    userRoleAttribute="eduPersonAffiliation"
    dnResolver="org.ldaptive.auth.SearchDnResolver"
    authenticationHandler="org.ldaptive.auth.SimpleBindAuthenticationHandler"
    connectionFactory="org.ldaptive.PooledConnectionFactory"
    cacheId="ldaptive-pooled";
};

我无法使它正常工作。首先，我在示例中发现了几个错误：

ldaptive中没有SimpleBindAuthenticationHandler类。它似乎最可能的课程应该是 BindAuthenticationHandler。
PooledConnectionFactory的完全限定的类名应为： org.ldaptive.pool.PooledConnectionFactory

进行了这些更改之后，我的jaas配置文件如下所示：

ourApplication {
  org.ldaptive.jaas.LdapLoginModule required
    storePass="true"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=People,dc=example,dc=com"
    useStartTLS="false"
    bindDn="uid=admin,ou=People,dc=example,dc=com"
    bindCredential="password"
    userFilter="(uid={user})"
    dnResolver="org.ldaptive.auth.SearchDnResolver"
    authenticationHandler="org.ldaptive.auth.BindAuthenticationHandler"
    connectionFactory="org.ldaptive.pool.PooledConnectionFactory"
    cacheId="ldaptive-pooled";
  org.ldaptive.jaas.LdapRoleAuthorizationModule required
    useFirstPass="true"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=Roles,dc=example,dc=com"
    roleFilter="(member={dn})"
    roleAttribute="cn";
};

现在，当我运行我们的应用程序并尝试进行身份验证时，我在日志文件中看到此错误：

2019-09-12 14:45:10,229 ERROR (ajp-nio-8009-exec-3)[org.ldaptive.props.AbstractPropertyInvoker] Error invoking public void org.ldaptive.auth.SearchDnResolver.setConnectionFactory(org.ldaptive.ConnectionFactory), on [org.ldaptive.auth.SearchDnResolver@1036972035::factory=null, baseDn=, userFilter=null, userFilterParameters=null, allowMultipleDns=false, subtreeSearch=false, derefAliases=null, referralHandler=null], with params org.ldaptive.pool.PooledConnectionFactory

因此，似乎ldaptive无法使用我定义的池配置，主要是根据他们的示例。

有人会这样使用ldaptive吗（通过jaas配置并使用池化）？是否有人对ldaptive足够了解，可以猜测这里出了什么问题以及如何正确配置它？

我想我也应该问一下，在ldaptive中进行池化是否可以解决通过netstat -na看到的端口的明显耗尽？

更新：

我能够在jaas配置文件中使用池配置：

ourApplication {
  org.ldaptive.jaas.LdapLoginModule required
    storePass="true"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=People,dc=example,dc=com"
    useStartTLS="false"
    bindDn="uid=admin,ou=People,dc=example,dc=com"
    bindCredential="password"
    userFilter="(uid={user})"
    dnResolver="org.ldaptive.auth.PooledSearchDnResolver"
    authenticationHandler="org.ldaptive.auth.PooledBindAuthenticationHandler"
    pruneStrategy="org.ldaptive.pool.IdlePruneStrategy{{prunePeriod=PT3M}{idleTime=PT6M}}"
    cacheId="ldaptive-users-pooled";
  org.ldaptive.jaas.LdapRoleAuthorizationModule required
    useFirstPass="true"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=Roles,dc=example,dc=com"
    roleFilter="(member={dn})"
    roleAttribute="cn"
    dnResolver="org.ldaptive.auth.PooledSearchDnResolver"
    authenticationHandler="org.ldaptive.auth.PooledBindAuthenticationHandler"
    pruneStrategy="org.ldaptive.pool.IdlePruneStrategy{{prunePeriod=PT3M}{idleTime=PT6M}}"
    cacheId="ldaptive-roles-pooled";
};

这似乎确实有所不同，但是我仍然看到（似乎对我而言）在我们的应用程序服务器和ldap服务器之间仍然有太多连接保持打开状态。这是netstat -na输出的示例：

  TCP    129.135.28.210:61285   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61288   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61290   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61292   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61294   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61299   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61301   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61303   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61309   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61311   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61313   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61317   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61319   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61323   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61336   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61338   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61340   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61342   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61344   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61346   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61348   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61350   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61353   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61355   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61359   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61374   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61376   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61378   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61380   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61383   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61385   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61389   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61396   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61398   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61400   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61402   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61404   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61408   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61416   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61419   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61421   129.135.28.18:10389    ESTABLISHED
  TCP    129.135.28.210:61423   129.135.28.18:10389    ESTABLISHED

当我第一次开始对此进行调查时，实际上在应用程序服务器端使用的所有端口都是连续的。现在看来，最多每个其他端口都在使用中，甚至还有2、3、4和更多端口之间的间隔。请注意，此示例是在上一次ldap活动结束后将近两个小时拍摄的。

为什么这些连接在ldap活动停止后会保留这么长时间？池/修剪配置是否应该做更多以减少连接数？我猜想它会带来更多帮助。

Answer 1

请注意，ldaptive文档正在过渡到版本2。这就是文档似乎不同步的原因。可以在http://www.ldaptive.org/v1/

中找到版本1文档。

问题的原因是此错误： https://bugs.openjdk.java.net/browse/JDK-8217606

目前的解决方案是使用UnboundID提供程序。更新您的JAAS配置，并将ldaptive-unboundid和unboundid jars添加到您的类路径中。

ourApplication {
  org.ldaptive.jaas.LdapLoginModule required
    storePass="true"
    provider="org.ldaptive.provider.unboundid.UnboundIDProvider"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=People,dc=example,dc=com"
    useStartTLS="false"
    bindDn="uid=admin,ou=People,dc=example,dc=com"
    bindCredential="password"
    userFilter="(uid={user})";
  org.ldaptive.jaas.LdapRoleAuthorizationModule required
    useFirstPass="true"
    provider="org.ldaptive.provider.unboundid.UnboundIDProvider"
    ldapUrl="ldap://ldapserver:10389"
    baseDn="ou=Roles,dc=example,dc=com"
    roleFilter="(member={dn})"
    roleAttribute="cn";
};

如何配置ldaptive以使用连接池（JAAS）

1 个答案: