10

I'm trying to configure my SonicWALL to allow LDAP authentication for VPN users. I've done this before with another device, and I remember it being pretty simple. But I can't get it to work this time for the life of me.

When I enable "LDAP + Local Users" mode, enter the LDAP server information and AD group names, I constantly get either "LDAP authentication failed" or "Credentials not valid at LDAP server" errors. I've tried all different permutations of settings that make sense to me, with the same results. SonicWALL support is absolutely no help so far. I've followed their manual's instructions to a T, with no solution.

Has anyone here had this same situation? I feel like I'm missing a setting somewhere...

colemanm
  • 659
  • 5
  • 10
  • 25

1 Answers1

15

It may be small comfort, but it’s working for us. The server is Windows Server 2003 R2 and the SonicWALL has SonicOS Enhanced 4.2.0.1-12e.

Here are the settings:

  • Authentication method for login: LDAP + Local Users
  • LDAP Server tab:
    • Chose “Give bind distinguished name”
    • Bind distinguished name: sonicwall_ldap@OURDOMAIN.local (a user we created to allow the SonicWALL to read LDAP)
    • Use TLS (SSL) checked
      • Send LDAP ‘Start TLS’ request: checked
      • Require valid certificate from server: unchecked (we use a self-signed cert)
      • Local certificate for TLS: None
  • Did not configure RADIUS as a fallback.

Now, before your logins will work you have to go to the Directory tab and click “Auto-configure.” If auto-configure fails, make sure the SonicWALL’s LDAP username and password (e.g. sonicwall_ldap@OURDOMAIN.local) is correct.

After doing auto-configure make sure “Trees containing user groups:” includes the section of your AD tree that has the users who will be logging in. Once you do that, on the “Test” tab you should be able to test with:

  • User: username (Note:**AD domain name should **not be included in the username because the SonicWALL will search the user contexts that were specified on the Directory tab).
  • Password: (their password)
Nate
  • 2,316
  • 4
  • 21
  • 24
  • Did you give any special rights/groups to the sonicwall_ldap user? – Kara Marfia Sep 03 '09 at 19:07
  • No. It is a regular member of Domain Users. (Yeah, I should probably remove that membership and replace it with something more restrictive, that only allows LDAP to work.) – Nate Sep 03 '09 at 19:11
  • Well described! Great answer! – geoffc Sep 03 '09 at 19:11
  • Hmm... when I enter the settings you've got, I still get "LDAP authentication failed" when I run a test login. Everything looks correct. When I go to the Directory tab and auto-configure, the trees all populate correctly, it's just the test that keeps failing. – colemanm Sep 03 '09 at 20:39
  • I also created a service account specifically for the LDAP read, sonicwall@domain.local (like you did above). When I leave all the settings like yours and try an actual connection with VPN, only the "sonicwall" service account can establish a connection... – colemanm Sep 03 '09 at 20:43
  • So if the service account login wasn’t working you’d get “Credentials not valid at LDAP server.” Instead, the problem really seems to be with the user account(s). Just to clarify: the “Test” tab in the SonicWALL is failing, not just the VPN logins, right? – Nate Sep 03 '09 at 20:57
  • Yes, test tab and VPN login is ONLY working for the "sonicwall" service account I created, even though the "trees containing users" area shows each OU in Active Directory with user accounts. With each regular user account, I can neither successfully run a test or connect to VPN. Does that make sense? – colemanm Sep 03 '09 at 21:01
  • One observation and one suggestion. Observation: I tried using my service account (hadn’t tried that before on the test tab) and it didn't work because the password was too long and the SonicWALL test tab truncated it. You aren’t using really long passwords are you? Suggestion: Have you tried creating a test user in the same OU where you created the service account? – Nate Sep 03 '09 at 21:13
  • I just created a new user called "testuser" (with the same password as my regular user account) in the same location as all of my regular user accounts. Running the test with testuser SUCCEEDS. No other real, original user account passes the test, though. It seems that my old existing accounts won't authenticate... I'm now officially confused. – colemanm Sep 03 '09 at 22:29
  • Strange! I’d be interested to hear how this turns out. You might try using Active Directory Users and Computers to change your own password to something else and then change it back. Possibly it’s stored in some format that isn’t accessible to LDAP. Short of that, it sounds like you’re going to have to stare-and-compare all of the possible settings for your own user vs. testuser. Regards, Nate. – Nate Sep 03 '09 at 23:19
  • I've tried restarting everything, SonicWALL,server, etc, to no avail. I've made a post on the SonicWALL forums to see if I get any response there, along with my still-as-yet-unresponded-to support case with SonicWALL. I'll update this post with my findings soon, hopefully. Thanks, guys. – colemanm Sep 04 '09 at 00:51
  • 3
    I figured out the problem, and consequently feel like an idiot. You know that checkbox in the main User Settings area that says "Case sensitive usernames"? Well that was checked. I unchecked and things work now. The issue is that when someone initially set up the AD, the user accounts were written in "John.Doe" format, I was testing with "john.doe". The newer accounts I created I made all lowercase, which is why they worked. Case-sensitivity never matters when using AD/Windows authentication, but it certainly does with raw LDAP. Thanks everyone. – colemanm Sep 04 '09 at 23:02
  • Thanks for the case sensitive username comment, that was driving me absolutely insane. – cjones26 Nov 21 '11 at 20:00