如何配置ldaptive以使用连接池(JAAS) [英] How to configure ldaptive to use connection pooling (jaas)

查看：315
本文介绍了如何配置ldaptive以使用连接池(JAAS)的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我们有一个使用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";
};

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

  1. ldaptive中没有SimpleBindAuthenticationHandler类.它 似乎最可能的课程应该是 BindAuthenticationHandler.
  2. 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活动停止后会保留这么长时间? 池/修剪配置是否应该做更多的工作以减少连接数?我猜想它会带来更多帮助.

解决方案

请注意，ldaptive文档正在针对版本2进行过渡. 这就是文档似乎不同步的原因. 可以在 http://www.ldaptive.org/v1/ <中找到版本1文档/p>

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

目前的解决方案是使用UnboundID提供程序.更新您的JAAS配置并添加

We have an application that uses ldap to authenticate users. We are using https://www.ldaptive.org/ as our ldap client and we are configuring it via a jaas login configuration file.

Here is an example our our jaas login configuration file:

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";
};

This works well enough. Over time we have started getting errors, similar to what is described here:

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

In case that link goes bad, the complaint is from a confluence user that users are sometimes unable to be authenticated via the ldap server. Errors like this are reported:

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)
...

We are getting similar communication and bind errors.

The link above suggests running the 

netstat -na

command on our application server to see if there are a lot of open connections to the ldap server. When I do that I see hundreds of lines that look like this:

TCP    129.135.249.138:65525  129.135.28.18:10389    ESTABLISHED

Where the left address is our server:port and the right is the ldap server:port. Ultimately, the port on the left goes to 65535, which is probably what is causing the inability to authenticate: all ports occupied, so cannot communicate.

The atlassian link above points to the ldaptive jaas configuration page for an example of how to configure connection pooling for ldaptive:

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

Here is the example ldaptive gives for configuring ldaptive to use connection pooling via jaas configuration:

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";
};

I have been unable to get this to work. First, I found a couple of errors in the example:

  1. There is no SimpleBindAuthenticationHandler class in ldaptive. It seems like the most likely class should be BindAuthenticationHandler.
  2. PooledConnectionFactory's fully qualified class name should be: org.ldaptive.pool.PooledConnectionFactory

After making those changes, my jaas config file looks like this:

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";
};

Now, when I run our application and try to authenticate, I see this error in our log file:

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

So, it seems like ldaptive is unable to use the pooling configuration that I have defined, mostly per their example.

Does anyone use ldaptive like this (configure via jaas and use pooling)? Does anyone know enough about ldaptive to make a guess as to what is going wrong here and how to configure it correctly?

I guess I should also ask, should pooling in ldaptive solve the apparent exhaustion of ports that I am seeing via netstat -na?

UPDATE:

I was able to get pooling configuration working in my jaas config file:

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";
};

That does seem to have made some difference, but I am still seeing what (seems to me) to be too many connections remaining open between our application server and the ldap server. Here is an example of netstat -na output:

  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

When I first started investigating this, virtually all of the ports in use on the application server side were consecutive. Now it seems that, at most, every other port is in use and there are even gaps of 2, 3, 4, and more ports. Note that this example was taken almost two hours after the last ldap activity.

Why are these connections remaining so long after ldap activity has stopped? Should the pooling/pruning configuration have done more to reduce the number of connections? I would have guess that it would have helped more than it has.

解决方案

Note that the ldaptive docs are transitioning for version 2. That's why the documentation seems out of sync. The version 1 docs can be found at http://www.ldaptive.org/v1/

The cause of your problem is this bug: https://bugs.openjdk.java.net/browse/JDK-8217606

The solution for now is to use the UnboundID provider. Update your JAAS config and add the ldaptive-unboundid and unboundid jars to your classpath.

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)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
Java开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆