Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have been working all evening on this issue and have hit a roadblock. We have a firewall that recently was restored to a November backup, and after reconfiguration LDAP auth is toast. I researched potential sources for the problem including Nate's excellent answer here on Server Fault.

Here is the rundown of the problem: Server 2012 environment, one DC running all services, just a simple CIFS box, shared printers and ADDS. Firewall is TZ205W with VPN licensing.

With the following settings:

LDAP Name : Server.MYCOMPANY.local
Port: 636
Give bind distinguished name: svc_account@MYCOMPANY.local
Protocol: LDAP v3
Use TLS: Y
Send LDAP Start TLS: Y

I get LDAP communication error. I've played around with port settings and TLS, and I can get as close as "User is not authorized on LDAP server" but never anything else. The ports and routes between the firewall and the server are clean.

This DC is the only server in the environment and nothing has changed on its end. We have seen some minor DNS errors but nothing that would totally break standard LDAP on 636 or 389. I have gone so far as to go against best practice and install AD LDS on the domain controller to see if I can force a connection but so far no dice either.

The most unusual part about this is that if I go to the Schema or Directory tabs, I get errors returned of either unrecognized schema despite AD being selected or when trying to pull the group OUs an error returned no user groups were found on the LDAP server. Check the LDAP directory configuration.

I am at a loss. We've tried every combination of IP, FQDN, UPN and the like to get this thing to work and it is refusing.

Has anyone see problems like this before?

share|improve this question
add comment

1 Answer 1

up vote 0 down vote accepted

So we went through several hours of troubleshooting this with Dell-Sonicwall and the issue seems to be some hidden corruption in the SAMaccountname or some other attribute of our test account; we simply created a new AD user for testing purposes, turned off TLS and ran the connection over port 389, and the issue was resolved.

This appears to be a bug in the way the Sonicwall processes LDAP connections to AD. There are known issues with using display names that have capitals or spaces in them, so this is likely another quirk of the TZ205 that should be added to the general knowledge base.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.