JSS LDAP login failing

The good folks in support pointed me to the "Use recursive group searches" option in the User Group Membership Mappings tab. The option was unchecked, but after checking the box we are now able to log in with our LDAP accounts.

Hi Kevin,
I tried that but no luck. Any other ideas?

Update: It also looks like I can't setup a new LDAP connection. It fails at the "Enter Credentials" stage, it says that it "could not find user".
I can do test lookups using the existing LDAP connection no problem.

I'm having the exact same problem with 9.01. Were u able to get yours fixed?

Hi Shaidar,

No, the problem is that Casper 9 has issues with LDAP that uses digest-md5 authentication. I rolled back to 8.71. It is noted in the release notes now, I'm not sure if it was at release.
You can use local accounts if you'd like, the LDAP queries for location information still worked for us.

Cheers

Hi Shaidar,

No, the problem is that Casper 9 has issues with LDAP that uses digest-md5 authentication. I rolled back to 8.71. It is noted in the release notes now, I'm not sure if it was at release.
You can use local accounts if you'd like, the LDAP queries for location information still worked for us.

Cheers

I wanted to revive this to see if anyone else had any solutions. I am not an LDAP expert so I am lost. Moving fro 9.2 -> 9.21 broke LDAP.

Hi Matt,

I can confirm that LDAP logins are working for me in 9.21. Perhaps log a support job? I didn't see anything in the 9.21 release notes about issues with LDAP so it might be an isolated issue.

Hi Matt,

When upgrading 9.2 -> 9.21, our LDAP logins broke here too.

Are your groups & users in different OUs? If so, set your search base to encompass both of the OUs.

You can also try to change your User Group Membership Mappings to use Group Object instead of User Object.

Either one of these for works us, and in our environment with a very large AD, we went with the latter, however, JAMF recommends the former.

All of what I said assumes that the problem your seeing is similar to what we're seeing, and it has nothing to do with MD5-Digest (we're not using MD5-Digest, just simple authentication). You could be seeing something completely different, and if the above don't help, I'd recommend contacting JAMF Support.

Me and Tim Hartzel got it going yesterday. All we had to do was back out one on our group Search Base. There is a bug report open so JAMF is working on it. Thanks everyone!!!

Our JSS (9.11) has never had an LDAP associated, so it's not a matter of having to back one out first. Can't get the first one set up; fails every time with the "could not find user" error, just like curullij's 8/24 post. No luck so far finding a fix.

I'm also having an issue with v9.21 and logging in to JSS from an app or web. I configured similarly to my v8.71 JSS. I can lookup users and assign rights to user groups that are discovered in AD. But unless I define an AD user specifically, I can't logon. Here's my current AD connection info. I've tried changing the Membership Location Group Object to group and user, toggled the "use DN" setting, and have even added classes like top and group but no love.

Hitting an urgent deadline so any thoughts would be greatly appreciated. Thanks.

ID 1 Name: Company users Connection used for users Hostname: our_AD_DC.company.com [[ DNS alias ]] Port: 389 SSL: false Open Timeout: 30 Connection Timeout: 480 Wildcard Searches: true ---------------------------------------------------------------------------------- Authentication: simple Distingushed Name: CN=MyServiceAccount,OU=Special Accounts,OU=US,DC=company,DC=com ---------------------------------------------------------------------------------- User Object Class Limitation: all User Object Class(es): user, organizationalPerson, person, top User Search Base: DC=company,DC=com User Search Scope: All Subtrees Map User ID to: employeeNumber Map Username to: sAMAccountName Map Real Name to: displayName Map Email Address to: userPrincipalName Map Department to: department Map Building to: streetAddress Map Room to: physicalDeliveryOfficeName Map Phone to: telephoneNumber Map Position to: title Map User UUID to: objectGUID ---------------------------------------------------------------------------------- User Group Object Class Limitation: all User Group Object Class(es): member, top, group User Group Search Base: DC=company,DC=com User Group Search Scope: All Subtrees Map Group ID to: sAMAccountName Map Group Name to: name Map Group UUID to: objectGUID ---------------------------------------------------------------------------------- Membership Location: Group Object Member User Mapping: member Use distinguished name: false

(wiping egg from face) I found my own stupid mistake. The next to last entry above should have mapped to "memberof" instead of "member". Crisis averted. Good thing I didn't do something stupid like post my problem publicly so that I'd…

oh wait. Darn, I hate when I do that.