I'm using an external LDAP provider with the ldap-plugin. I can authenticate against the LDAP service and I'm using a group based security matrix.

I've never had any trouble logging in with LDAP credentials, but when I try to add jobs through the web api I get some very strange behavior.

The first ten or so posts will return 201s (Created) and add jobs.

Then, one of the following jobs will throw a 401 (Unauthorized) and the rest of the jobs in that run won't get created.

LDAP keeps working. I can login and logout. I can run the job again and get the same/similar behavior.

The only things I've been able to find in the logs look like this:

<entry><title>SecurityContextHolder now cleared, as request processing completed</title><link type="text/html" href="https://extraction.bigstaging.rainforest.urjanet.net/log" rel="alternate"/><id>1310460365</id><published>2017-01-26T19:24:41Z</published><updated>2017-01-26T19:24:41Z</updated><content>Jan 26, 2017 2:24:41 PM org.acegisecurity.context.HttpSessionContextIntegrationFilter doFilter
FINE: SecurityContextHolder now cleared, as request processing completed
</content></entry><entry><title>The HttpSession is currently null, and the HttpSessionContextIntegrationFilter is prohibited from creating an HttpSession (because the allowSessionCreation property is false) - SecurityContext thus not stored for next request</title><link type="text/html" href="https://extraction.bigstaging.rainforest.urjanet.net/log" rel="alternate"/><id>1310460364</id><published>2017-01-26T19:24:41Z</published><updated>2017-01-26T19:24:41Z</updated><content>Jan 26, 2017 2:24:41 PM org.acegisecurity.context.HttpSessionContextIntegrationFilter storeSecurityContextInSession
FINE: The HttpSession is currently null, and the HttpSessionContextIntegrationFilter is prohibited from creating an HttpSession (because the allowSessionCreation property is false) - SecurityContext thus not stored for next request
</content></entry><entry><title>Authentication of BASIC header failed</title><link type="text/html" href="https://extraction.bigstaging.rainforest.urjanet.net/log" rel="alternate"/><id>1310460363</id><published>2017-01-26T19:24:41Z</published><updated>2017-01-26T19:24:41Z</updated><content>Jan 26, 2017 2:24:41 PM jenkins.security.BasicHeaderProcessor
FINE: Authentication of BASIC header failed
</content></entry><entry><title>Authentication request for user:

{0} failed: {1}</title><link type="text/html" href="https://extraction.bigstaging.rainforest.urjanet.net/log" rel="alternate"/><id>1310460362</id><published>2017-01-26T19:24:41Z</published><updated>2017-01-26T19:24:41Z</updated><content>Jan 26, 2017 2:24:41 PM jenkins.security.BasicHeaderRealPasswordAuthenticator
FINER: Authentication request for user: build.manager failed: org.acegisecurity.AuthenticationServiceException: Unable to connect to LDAP server; nested exception is javax.naming.CommunicationException: ldap.jumpcloud.com:636 [Root exception is java.net.SocketException: Connection reset]; nested exception is org.acegisecurity.ldap.LdapDataAccessException: Unable to connect to LDAP server; nested exception is javax.naming.CommunicationException: ldap.jumpcloud.com:636 [Root exception is java.net.SocketException: Connection reset]
</content></entry><entry><title>Creating InitialDirContext with environment {java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.referral=follow, java.naming.security.principal=uid=ldap.binding,ou=Users,o=112211221122112211221122,dc=jumpcloud,dc=com, com.sun.jndi.ldap.connect.timeout=25000, com.sun.jndi.ldap.connect.pool=true, com.sun.jndi.ldap.read.timeout=60000, java.naming.provider.url=ldaps://ldap.jumpcloud.com/, java.naming.security.authentication=simple, java.naming.security.credentials=******}</title><link type="text/html" href="https://extraction.bigstaging.rainforest.urjanet.net/log" rel="alternate"/><id>1310460361</id><published>2017-01-26T19:24:41Z</published><updated>2017-01-26T19:24:41Z</updated><content>Jan 26, 2017 2:24:41 PM org.acegisecurity.ldap.DefaultInitialDirContextFactory connect
FINE: Creating InitialDirContext with environment {java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.referral=follow, java.naming.security.principal=uid=ldap.binding,ou=Users,o=112211221122112211221122,dc=jumpcloud,dc=com, com.sun.jndi.ldap.connect.timeout=25000, com.sun.jndi.ldap.connect.pool=true, com.sun.jndi.ldap.read.timeout=60000, java.naming.provider.url=ldaps://ldap.jumpcloud.com/, java.naming.security.authentication=simple, java.naming.security.credentials=******}
</content></entry><entry><title>Searching for user 'build.manager', with user search [ searchFilter: 'uid={0}

', searchBase: 'ou=Users,o=112211221122112211221122,dc=jumpcloud,dc=com', scope: subtreesearchTimeLimit: 0derefLinkFlag: false ]</title><link type="text/html" href="https://extraction.bigstaging.rainforest.urjanet.net/log" rel="alternate"/><id>1310460360</id><published>2017-01-26T19:24:41Z</published><updated>2017-01-26T19:24:41Z</updated><content>Jan 26, 2017 2:24:41 PM org.acegisecurity.ldap.search.FilterBasedLdapUserSearch searchForUser
FINE: Searching for user 'build.manager', with user search [ searchFilter: 'uid=

{0}

', searchBase: 'ou=Users,o=112211221122112211221122,dc=jumpcloud,dc=com', scope: subtreesearchTimeLimit: 0derefLinkFlag: false ]

The problem goes away when I use ldap instead of ldaps. Unfortunately, that's not an acceptable solution.