Java Error

[imagswadmin]

We've got LDAP setup authenticating fine but this error comes up when querying accounts

No matches
0.01 seconds
Error: javax.naming.directory.InvalidSearchFilterException: invalid attribute description; remaining name ''
Suggestion: No suggestion available

Does anyone know what this is referring to and how to fix it ?.

Above is for manual config if we use the normal AD setup config pages non manual this log entry appears and we are stuck at invalid username or username not found ":

2014-05-07 13:20:04,593 [ERROR] [Tomcat-31 ] [lientCommunicationServlet] - Communication device is null
2014-05-07 13:23:35,938 [ERROR] [Tomcat-30 ] [LDAPLookupHelper ] - Exception: javax.naming.CommunicationException: 10.100.0.63:636 [Root exception is java.net.SocketException: Connection reset]

[thedanielmatt]

Having the same issue - did you ever get this figured out?
I have a feeling it is on the AD/Networking end, but curious what you found.

[were_wulff]

@imagswadmin @thedanielmatt

The first place I’d start looking here would be at network connectivity with the LDAP server.

Based on this bit of the error, “Root exception is java.net.SocketException: Connection reset” it looks as though it’s not able to make and maintain a connection to your LDAP environment.

There are a lot of things that can cause that, ranging from incorrect credentials, trying to use the wrong domain when setting it up, a search base that is too narrow or restrictive being set in the JSS, trying to have the JSS use SSL to connect when the LDAP environment isn't set up for SSL, trying to have the JSS authenticate without SSL when the LDAP environment requires it, network connectivity issues, firewall issues (usually port 389 being blocked), etc...

In this case, based on the "Connection reset" portion of the error, my thought is leaning toward either network connectivity issues or a port being blocked, as that's typically when we see connection reset errors.

One of the easiest ways to test that out is to put Apache Directory Studio on the JSS computer and try to connect to the LDAP server using the same credentials you’re trying to query from the JSS; if it works, then we can narrow down the issue to something the JSS is doing. If it doesn’t work, we’ve ruled the JSS out as part of the issue and can then focus on the network or the LDAP environment.

If your server is running an OS that can’t use Apache Directory Studio, we should be able to test the same thing from a computer that can run it, I just prefer to test it directly from the JSS machine if possible to keep the scope of troubleshooting as narrow as we can.

If everything appears okay on the LDAP side of things, sometimes we have luck cloning the existing LDAP connection in the JSS and using that one or deleting and re-adding the LDAP server to the JSS.

If none of that does it, we’re sure the LDAP environment is up and reachable by the JSS, and we’ve done testing with Apache Directory Studio and it seems okay, I’d recommend opening up a case with your Technical Account Manager so they can dig into it a bit further than we might be able to on the forums here.

Thanks!

Amanda Wulff
JAMF Software Support

[thedanielmatt]

Thanks Amanda, I figured it was a connectivity issue - but as this JSS is on a headless Linux box I was curious for some insight from anyone who had seen this, before I installed Directory Studio (the LDAP connection is whitelisted to a specific IP). Although, I agree - that is probably the next step. What makes it a little more interesting is I can establish a connection via telnet over 636 (which is the open port).

I'll see if I can read the directory with Directory Studio; hopefully it will provide some more clues.

I appreciate the response!

[were_wulff]

@thedanielmatt

Not a problem!

Since we’re using port 636, I’m guessing the LDAP environment is set up to use SSL instead of TLS (which would be on 389)?

Are we using Active Directory, Open Directory, eDirectory, or something different, like OpenLDAP?

I do know that sometimes LDAP search services view port 636 as an ‘unsecured’ port and will occasionally reject messages, but that’s not super common.

This is a fairly old mailing list post, but it does have some information in it to look into: http://www.openldap.org/lists/openldap-software/200201/msg00625.html

The most relevant part of that e-mail thread:

“For some reason, when ldap search attempts to connect, it is pretty dumb. Even though you have specified the secure port (636), it thinks that port 636 is a plain ldap port. So, your ldap server receives the connection on port 636, expecting some 'secure' talk. It doesn't recognize what it sees because the packet that it gets is requesting a search. Get it? ldap search thinks that port 636 is an insecure port.”

Thanks!
Amanda Wulff
JAMF Software Support

[thedanielmatt]

For anyone who comes across this in the future:

Ended up being an SSL issue - the AD is using a self-signed cert/internal CA, basically.
So while I could establish a connection without trusting the cert, I couldn't authenticate.

I was able to pull the cert down using Apache Directory Studio and import it into Java's keystore. https://jamfnation.jamfsoftware.com/article.html?id=121
The comment regarding the path to the Linux keystore saved me some time. https://jamfnation.jamfsoftware.com/article.html?id=121#responseChild514

Cheers!

[oocl]

@thedanielmatt Hi
I got the same problem.
May i know how to pull the cert down using apache directory studio?? I can connect to LDAP via Apache Directory Studio but casper can't
Thanks thanks

[thedanielmatt]

If I remember correctly, it is during the initial connection to the LDAP server. It will ask you what to do about the untrusted certificate, at which point it offers to show you the certificate and you can export it locally.

You can also view your LDAP connection properties, click on the "Certificate Validation" link in the middle of the window the pops up, and then export you certificate there.

[sburt]

(Updating an old thread since I was running into this and it was the first result on Google)

I was running into this and was able to resolve by correctly populating the "Mappings" section of the LDAP configuration page. The correct settings will be based on your own LDAP server setup, but I would recommend checking there.