Error adding AD Server (Could not find user)

[danhutchings]

Hello,

When adding my LDAP server I am getting a "could not find user" error message.

I also inspected the JSS log called "JAMFSoftwareServer.log" that lives on the JSS. Here is the error that gets written to that log when I get the "could not find user" in the JSS GUI.

2014-01-16 13:09:00,782 [ERROR] [Tomcat-9 ] [LDAPLookupHelper ] - Exception: javax.naming.CommunicationException: <mydomainname>:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

[bapettit]

I am having similar problems, any conclusion?

Thanks,

Brad

[tkimpton]

same problem but on linux server. Any solutions?

[were_wulff]

@danhutchings][/url @bapettit][/url @tkimpton][/url

There are a couple of things I can think of off the top of my head:

1) Are we trying to use LDAP over SSL? If yes, double check the steps we have in this KB and make sure everything is set up the way it needs to be.

2) The reference in the error to port 636 reminded me of a thread from back in May/June that may be useful.

This, specifically, was the quote from a linked e-mail list that pointed us toward the possibility of it not having all the certificates it needed in place to work properly:

“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.”

In that case, it turned out the issue was with their internally signed SSL certificate. It ended up being necessary for them to pull that cert down and import it into Java’s keystore to be able to authenticate.
Prior, they’d been able to establish a connection (and get the LDAP server set up in the JSS), but not actually authenticate or perform searches on users, as they all came up as 'not found'.

That may be worth looking into as well.

In this case, I see a reference to port 636 in the error, followed by "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]", which makes me immediately think that we're missing a certificate somewhere in the chain and need to get that imported, especially if the AD environment is using an internal CA for its certificates.

3) Of course, double check the basics. If we download and fire up Apache Directory Studio, are we able to connect to the LDAP server using the same address, domain, username, and password that we're trying to use in the JSS?
If no, there's the problem. Finding the correct information, at that point, should take care of it.
If yes, then we need to dig in a bit further (or go over 1 & 2 if that hasn't already been done).

If that doesn't do the trick, or if you need help getting to that point, please get in touch with your Technical Account Manager either by giving them a call, sending an e-mail to support@jamfsoftware.com (it routes directly to their case queue), or by using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support

[tkimpton]

Thanks Amanda I'm having problems importing certificates into Java’s keystore to be able to authenticate.

[were_wulff]

@tkimpton

I see that you’ve got a case open with your TAM already, and I added a link to this discussion in the case notes so he can keep up to date on that as well.

Looking through our own case archives, I found this set of instructions on a case for a customer who was having the same issue on a RHEL server that is going on here and figured it might be helpful to post the instructions here:

Import the root certificate of the CA into the Java truststore. dq7lU88VL2og0MwTk6qY /etc/ssl/ exists on the CentOS 6.4 and RHEL VMs we have here, so if this doesn't exist in the same place there may be something customized about that location in RHEL.

If we’re already doing that and running into an error in the process, that would be something to send over to your TAM as part of the open case if you haven’t done so already.

Thanks!
Amanda Wulff
JAMF Software Support

[danhutchings]

The resolution to my problem was to just add the LDAP server manually.

[csanback]

Yeah we also had to add the LDAP server manually. (Windows Sever 2016 and AD)

[Taylor_Armstron]

Any walk-throughs for adding manually? (On 2016 AD here as well, just tells me "could not find user" no matter what I've done so far)

[ammonsc]

I just had the exact same issue. My JSS is on RedHat both AD and OpenLDAP was causing issues.

The only fix was the Search Base had to be set correctly and all of the Attribute settings needed to be manually mapped. Once that was set correctly everything is working just fine.

[Taylor_Armstron]

My problem is that I can't get that far. Tells me "could not find user" and won't let me get to the mapping section. I don't remember having any issue at all on my old server, but that was a few years ago so I can't be held responsible for my memory that far back.

[ammonsc]

@Taylor.Armstrong Sorry, I guess I left out a crucial part... I could not get it to work with the Automatic Settings and had to use Manual. That will give you the options.

[Taylor_Armstron]

At the risk of sounding stupid...

Where do I go for manual settings? All I have right now is the Settings>System Settings >LDAP Servers asking for domain/username/password, and then rejecting my inputs. I don't see anywhere to configure manually.

[ammonsc]

System Settings/LDAP Servers/New/Configure Manually

[Taylor_Armstron]

Awesome. I feel stupid, but I've never let that get in the way of getting something done!

LDAP now working as it should - very much appreciated.