Changing a SBS 2011 Server to TLS
Having fits with a SonicWall. It integrates to the AD via LDAP on port 389 and the SonicWall technicians want to try LDAP over TLS on port 636. I wouldn't have any idea how to do that. Is it complicated and would I run a risk of harming the server?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That is where I have been getting a little pissed at them. Every time I call in the first ting they want to do is verify the configuration. Then they determine it is a LDAP connection problem. Then the tech wants to packet capture the next time it happens. So the next time it happens we go through the same thing except since it is a different tech they want do do something different then the previous tech. So 10 calls in two months and we haven't gotten anywhere.
I keep going back to the fact that the thing that needs to be done is always to the SonicWall. I never have to reboot or restart any services on the server. That to me points a finger at the SonicWall. Everything has ran great for years and for the last three monts I have to jump start the SonicWall.
I would think that if the LDAP on the server was messed up that it would manifest itself in other ways. Is there a utility in Windows to test LDAP connectivity?
I keep going back to the fact that the thing that needs to be done is always to the SonicWall. I never have to reboot or restart any services on the server. That to me points a finger at the SonicWall. Everything has ran great for years and for the last three monts I have to jump start the SonicWall.
I would think that if the LDAP on the server was messed up that it would manifest itself in other ways. Is there a utility in Windows to test LDAP connectivity?
Usually the LDP tool will help test a connection, however this won't test connection from the SonicWall.
There are alternates such as in this EE article (Tool still exists)
I have used JoeWare's LDAP tool as well in the past. (CMD Line based)
With SonicWall I would escalate the call, demand a manager. Sometimes I have to be the "Annoying grumpy customer" to get the service required. If they say there is no manager say you will wait till he comes in, or ask for the managers manager. I don't let them go or talk me away. I will keep them on the phone till someone with authority listens to me. Usually get excuses like "Manager does not answer phone, He's on lunch, he's in a call" You kind of know its an excuse for them to get rid of you (I mean most of us been in similar jobs with similar instructions not to pass managers on as managers don't generally want to deal with client end) But I'm all good with the waiting. I will wait on the line for hours if must be. Its going to save me time in the long run, and will help them improve their services. So everyone wins.
As for the issue itself again. What I would suggest is to setup a monitor on your back end monitoring system such as Labtech, Kaseya, Nagios, SCCM, or similar, and if it has an LDAP error, report it, plus if the backend software allows for it, kick off a 30 second sniffing session to capture whats going on.
There are alternates such as in this EE article (Tool still exists)
I have used JoeWare's LDAP tool as well in the past. (CMD Line based)
With SonicWall I would escalate the call, demand a manager. Sometimes I have to be the "Annoying grumpy customer" to get the service required. If they say there is no manager say you will wait till he comes in, or ask for the managers manager. I don't let them go or talk me away. I will keep them on the phone till someone with authority listens to me. Usually get excuses like "Manager does not answer phone, He's on lunch, he's in a call" You kind of know its an excuse for them to get rid of you (I mean most of us been in similar jobs with similar instructions not to pass managers on as managers don't generally want to deal with client end) But I'm all good with the waiting. I will wait on the line for hours if must be. Its going to save me time in the long run, and will help them improve their services. So everyone wins.
As for the issue itself again. What I would suggest is to setup a monitor on your back end monitoring system such as Labtech, Kaseya, Nagios, SCCM, or similar, and if it has an LDAP error, report it, plus if the backend software allows for it, kick off a 30 second sniffing session to capture whats going on.
ASKER
This to me points the finger at the SonicWall but their support is so horrible. An hour on hold. They they want to check the configuration. Then they determine it is in LDAP integration and want to do a packet capture the next time it happens. So... the next time it happens you get a different tech who wants to start all over from ground zero and tells me to ignore what the previous tech wanted to do.
It has been happening once a week for two months. At 3 hours per call that amounts to 24 hours on the phone and every time I call in we start all over. I think this request to change to LDAP over TLS is simply because they can't think of anything else to try. What do you guys think?