[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

How to activate SSL/TSL LDAP signing on SonicWALL SSL-VPN?

Posted on 2011-10-31
20
Medium Priority
?
8,076 Views
Last Modified: 2012-05-12
Hi there,
This year we upgraded our domain to Windows 2008 R2 and it has completed with success. We have two DC having the roles of ADS, DNS and DHCP. They have been working fine for months. One little issue that we left aside for a while was the fact that LDAP signing hasn't been enforced so last week we set to correct that.

In following MS articles and suggestions we first turned the level of logging higher to detect which clients were requesting LDAP binding without signing. Over a period of one week we detected only three clients were doing such requests: an OpenFiler box, and our two SonicWALL routers. We have a configuration of two SonicWALL appliances, the 2040 Pro and the SSL-VPN 2000 with latest firmware (both updated last Saturday).

We proceeded to turn SSL/TSL signing on the 2040 Pro and it works fine though the DC logs the 36886 event from the Schannel source about "No suitable default server credential exists on this system".
We also turned the SSL/TSL signing on the OpenFiler but the DC stills logs the event 2889 reporting that this box performed a  LDAP bind without requesting signing. We will try to deal with this box later but if someone have any ideas they are also welcome.

The one that really worries us is the SonicWALL SSL-VPN 2000 box which prevented users from signing in after we turned this on (see screen shot) SSL-VPN SSL/TSL signing
We went into the SonicWALL box and it won't even let us configure domains groups or edit them as long as SSL/TSL signing is checked; the box returns an error saying that the LDAP server could not be contacted. A soon as this check box is unchecked we can edit all the groups and the users can sign in again through SSL VPN. Users signing in through the SonicWALL 2040 Pro with L2TP tunnels have no problem, so this is an SSL-VPN box issue.

I have the feeling that this might have to do with the fact that the connections coming from the SSL-VPN box are in another network segment different from the internal LAN where the DC sits.

The internal LAN where the DC and clients sit is 192.168.1.0 the SSL-VPN box sits on the 192.168.200.0. The address of the SSL-VPN port connected to the firewall (2040 Pro) is the one reported on the 2889 LDAP errors on the DC.

As I mentioned before both DC are W2008 R2 with latest patches and updates. We are planning to add a RADIUS server on both DC to allow L2TP connections for domain users.

One more thing, the setting "Domain Controller:LDAP server signing requirements" is set to "None" under Policies>Windows Settings>Security Settings>Local Policies>Security Options on the Default Domain Controller Policy. I want to set it to "Require Signing" when there are no clients left that do unsigned bindings.

If you require more info please let me know.
Thanks,
0
Comment
Question by:ricardocoto
  • 13
  • 7
20 Comments
 
LVL 33

Assisted Solution

by:digitap
digitap earned 400 total points
ID: 37060170
I need to know how things are connected together. I think that might have some determination of how we move forward. Here are some links and questions.

First, let's make sure you have this setup correctly for the Pro appliance.

https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=7813

How do you have the ssl-vpn appliance connecting to the Pro?

https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=6122

Here is a link for using certs with the ssl-vpn and the pro working in conjunction.

https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=5883
0
 

Author Comment

by:ricardocoto
ID: 37060253
digitap,
Hmm, I think I got this wrong in the first place. Question:
Doesn't a certificate needs to be installed in the LDAP server at the moment when I tell it to only allow SSL/TSL signed LDAP binds? Since the DC (the LDAP server) is telling me that only these three (the two SonicWALLs and the OF box) particular clients are requesting the unsigned binds I thought that initially I could force them (the clients) to use signed binds and then set the LDAP server to allow signed ones.

This brings me to another more interesting question, if a Certificate is required for LDAP signing how come the LDAP server only flags these three clients and not the other dozens of Windows machines, servers, printers, etc I have in my LAN? Since they don't get flagged I assumed them all using LDAP signing and hence no certificate needed.

To answer your questions I have not installed any certificate on my LDAP server.

I will give a full read to the three articles linked and get back to you in the morning (I'm PST here) but I think my biggest problem is with understanding what LDAP binds signing is and why the issue is only with these three boxes.

Thanks,
0
 

Author Comment

by:ricardocoto
ID: 37060272
digitap,
Just to add the previous post.
The SSL-VPN appliance is connected to the Pro using the scenario A as described in the article on your second link i.e. SSL-VPN on a new DMZ.
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
LVL 33

Assisted Solution

by:digitap
digitap earned 400 total points
ID: 37060515
Back from trick or treating. The following link will help you integrate the sonicwall with an LDAP server. The second link helps you troubleshoot issues.

https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=5281
https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=5097

I think the same principle(s) is/are true for the ssl-vpn appliance. I'd get your Pro working first, then see if that fixes the ssl-vpn. If not, let me know. I have a couple of deployed ssl-vpn appliances I can test for you.
0
 

Author Comment

by:ricardocoto
ID: 37065870
digitap,
I haven't been able to progress any further after exporting the new signing request from the 2040 Pro appliance. The exported file is a .p10 format one and the MS CA server gives me an error related to the request not containing template information. I've spent a few hours trying to find info on how to import this specific signing request but all documents and articles I found talk about using the web services to do that. Do I really need to install IIS on my DC to just submit this signing request? Can it be done some other way?
Thanks,
0
 

Author Comment

by:ricardocoto
ID: 37067308
digitap,
After a whole day of looking for information and reading through countless articles and tutorials I decided to take the plunge and install IIS and other roles apparently necessary for step 5 (Requesting certificate for the new signing Request by the MS CA) on the first link of your first post. Here after many attempts to reach the web service and not finding the Web Server template in the drop down list as per guide, further reading pointed me to allow authenticated users for certificate enrolling which added this template to the drop down list. (Curiously on the web interface I don't see any buttons to browse for the request file neither I see one for reading this file, so I used copy/paste after opening the signing request with notepad; maybe this is the cause of the certificate not being validated-read further)

After submitting the signing request and downloading the certificate using the "DER encoded" option I proceeded to step 6 "Validating the certificate on the SonicWALL appliance". Here I upload the file to the pending request and after clicking "Upload" the final certificate has the type LOCAL and the validated NO. The certificate does not get validated so I can't proceed any further.

Anyways there must be something I must be doing wrong but my head is really numb by now. Maybe in the meantime until tomorrow someone will weight in and offer some ideas.
Thanks,
0
 

Author Comment

by:ricardocoto
ID: 37071771
digitap,
I found a more updated article for W2008 (https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=8638&p=t) but no matter what I do the certificate does not get validated in the SW.
I tried to do everything from start (the certificates) and invariably the result is the same: when I upload the certificate in the SW to validate it doesn't get validated.
As a note aside I've noted that my interface for the web enrollment of the certificate does not looks exactly like in the linked article; I'm missing some features but all I need to follow up the guide is there.
Any clues why the certificate might not get validated?
Thanks,
0
 

Author Comment

by:ricardocoto
ID: 37077681
Well, still no dice. Now I perfectly understand what the famous definition of insanity is all about. I've signed so many certificates for the SW2040 Pro that I lost count; always with the same result: the certificate does not get validated.
I'm still looking for answers as to why this might be happening...
Thanks,
0
 

Author Comment

by:ricardocoto
ID: 37084091
Hmm... after a 2 hour support call with SW the agent discovered that ... wait for it... the hash algorithm installed and used by default on AD Certificate Services Role (at least on W2008 R2) which is SHA256 is NOT supported by the SW2040 Pro. Ha!  
Because I could not believe it I got on a support chat this morning with SW tech support and they confirmed that ALL UTM appliances are only compatible with MD5 hash algorithm. SSL VPN boxes do support SHA but UTM do not. This feature has been requested and it is on the list of suggested changes for upcoming versions of UTM.
What puzzles me is why there is no single mention of this crucial fact in any of the guides and articles related to security certificates on SW UTM; it took the agent on yesterday's call an hour and 50 minutes to realize this. What is worst, there are no errors from the UTM when you load the certificate about the used hash algorithm, so you could insanely upload signed certificates and find them not validated for no apparent reason; I have only one word - brilliant!

Now that I'm done with my rant let's get back to the issue at hand. I'll need to re-evaluate whether I'll implement LDAP SSL/TSL signing. SInce I also have an SSL-VPN appliance and I want to use LDAP signing and it supports SHA I need to decide what to do.
I'll get back to this post on Monday 7th to update.
Thanks,
0
 
LVL 33

Expert Comment

by:digitap
ID: 37086936
@Ricardocoto :: Yikes! I've been procrastinating on this because I've been running ragged, but also because I have no idea why it wasn't working. The steps are clear, as you VERY well aware, but yet nothing worked. Your discovery explains it all and I am so sorry there is any documentation.

Having said that, we don't employ ssl/tls with LDAP auth. When internal, we just don't see a security reason to go to the work of setting it up. The SW appliance is connecting to the AD server over the security LAN (secured by the SW appliance I might add).
0
 

Author Comment

by:ricardocoto
ID: 37103502
@digitap:
I've been swamped with stuff. Will post back by the end of tomorrow.
Thanks,
0
 
LVL 33

Expert Comment

by:digitap
ID: 37103766
no worries.
0
 

Assisted Solution

by:ricardocoto
ricardocoto earned 0 total points
ID: 37111274
@digitap,
OK. Initially this was a project to first allow some users with smart phones to connect to the internal LAN via VPN and access various shares. I got to test it by setting up a LOCAL user on the SW2040 Pro and setting up a L2TP tunnel between the appliance and an iPhone running iOS5. That worked fine and cleared any possible issues with the iOS part of the L2TP settings. We tested and app called NetPortal and another from the same vendor called FileBrowser and we could browse the internal shares on the file server after connecting.

Then of course we wanted to set up signing of the users using AD, to avoid maintenance of a separate list of users at the appliance level. So we looked at LDAP integration and we first got the messages about LDAP without SSL/TLS signing being highly insecure. There is also the fact that to use L2TP VPN connection you MUST use RADIUS as a server for authentication (L2TP does not support MS LDAP authentication because it does not support CHAP - so I was told).

Anyways we tried to clear first the issue with the LDAP signing to be compliant. As explained in my previous post this was not possible with the default algorithm chosen by the AD CS role installed on the server (SHA256) since all SW UTM are not compatible with it. So to get LDAP signing I'll have to "downgrade" my CA to use MD5 or not use it at all. Since we also have an SSL-VPN and it is compatible with SHA256 (or so I was told - I stopped believing at this point) we opted to ignore the warning and requirement about signing LDAP and left the server with the SHA256 and forgot about using SSL/TSL signing for LDAP on the UTM.

Next we tried to go to the second part: to set up RADIUS authentication for L2TP on the SW2040. I followed the SonicWALL KBID 6591:
 https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=6591&SearchType=advanced&referrer=&gpn=&CustID=&bUseEditor=&keyword=&rfield=&sortmethod=rel&usertype=&gpv=&catID2=579&formaction=search&catID1=143&IncludeHTML=&logsearch=True&catID3=458&TotalResults=17&submitbutton=Go&match=and
which is made for the Global VPN clients but is similar for any other VPN clients. We added the "Network Policies and Access Services" role to the DC and configured a RADIUS client as per the KBID for the SW appliance. We also configured a new network policy to grant access to the security group created for this purpose and for the IP of the SW. We chose to use MSCHAP v1 and v2 for authentication since those can be set also at the SW on the VPN>Advanced VPN Settings. After trying unsuccessfully to test the RADIUS connection from the test box inside the SW and getting "RADIUS client authentication failed" I called SW support. After a long call with remote access the tech support person informs me that the way we have it set up won't work because ...even though the settings in the SW VPN advanced settings page has MSCHAP and MSCHAP2 as options this does not works because the SW appliance stills sends the request using CHAP (the tech detected this analyzing a packet capture between the server and the SW with Wireshark). I said, no problem I can enable CHAP as well on the network policy but she said that would not work either because it needs the server to be set up for storing passwords using REVERSIBLE encryption. She said this (the MSCHAP problem) has been a long standing issue and won't be fixed on these appliances for now. Only Gen 5 appliances have resolved this.

Uff! So now I have to take a closer look at this "reversible encryption" for storing passwords with the "reversible" part of it making me feel very uncomfortable. It turns out that to secure access to my LAN using this SW appliance and having some better administration I have to downgrade the security on the inside part of the network since the SW appliance is not compatible with what we are using. It really bogs my mind; after all this is supposed to be the firewall, the first line of defense, right?

If someone has any ideas on where can I go from here please share them with me. I need to read some more info about this "reversible encryption" before I can proceed any further.

Thanks,
0
 

Accepted Solution

by:
ricardocoto earned 0 total points
ID: 37111651
From MS TechNet library:

"Store passwords using reversible encryption
Description

This security setting determines whether the operating system stores passwords using reversible encryption.

This policy provides support for applications that use protocols that require knowledge of the user's password for authentication purposes. Storing passwords using reversible encryption is essentially the same as storing plain text versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information."

Ouch! Sooo, this is a security risk that has been able to survive for years in so called "Security Appliances", SonicWALL UTM that is.

 That is great!
0
 

Author Closing Comment

by:ricardocoto
ID: 37158257
Following up on my comment is obvious that the suggested solutions didn't exactly resolved my problems. There were inaccuracies on the procedures regarding what my specific appliances support and the workarounds found are unacceptable based on security best practices.

I did decide to award some point based on effort and the fact that the proposed solutions appear to be the right ones as proposed by the vendor. In this case the fact that they didn't work with my specific set up was discovered after long troubleshooting calls with vendor's tech reps.

With that said I really appreciate the effort and help displayed by digitap on this post.
Thanks,
0
 
LVL 33

Expert Comment

by:digitap
ID: 37131012
It's unfortunate that the sonicwall wasn't able to support the hash that you needed to use. Documentation to that fact would have been helpful. Something to consider here is the fact that the credential interaction between the sonicwall and AD is on your private network. Someone would need to be on your private network sniffing packets in order to capture the password. I may be mistaken here. I will say though that the complexities of implementing certificate encrypted LDAP authentication between the sonicwall and AD has been a pain. So much so, that I've taken the view that I have and just not implemented it.

You've got a lot of great information here and I appreciate you weeding it out. Did support say that the NSA would support the hash algorithm that the Pro would not?

Thanks for the points!
0
 

Author Comment

by:ricardocoto
ID: 37132717
@digitap, you're very welcome!

I got to the same conclusions you did. My only worry on the internal LAN is that we have a 45% of the work force mobile with laptops that connect to other networks I don't trust. Besides despite our efforts educating users a lot of them still click "OK" to every pop up and they do browse and go to websites such as facebook, msn, Yahoo!, etc. I was trying to prevent the sniffing actions of a Trojan Horse being brought into the network, but as you, I already gave up for now on this project.

To answer your questions, the rep from SonicWALL said that none of the existing firewalls were compatible with SHA256 hash algorithm. On the other hand it was confirmed by another rep (on the second call regarding RADIUS authentication) that generation 5 NSA were capable of sending the authentication request using MSCHAP v2 without the need to use just CHAP and implement "reversible encryption" on the AD.

Since our appliances come to an end of support next year we are going to conduct a deep research regarding these issues on the SonicWALL line of products. I feel a little disappointed with the lack of information regarding these important details and the fact that SonicWALL has been slow in upgrading their products despite these issues being known (at least internally) and being requested to fix for quite a while (on the rep's own words).

Still I'm familiar enough with SW products that I would have to think this through before I consider any other vendor. On the other hand if you have any suggestion to what other products I might look at for comparison your advise will be more than welcome.

Regards,
0
 
LVL 33

Expert Comment

by:digitap
ID: 37132972
Hmm, interesting. From what you say, it seems that you can't use certs with LDAP auth without using reversable encryption which, as you've pointed out, is not secure. To that, I'd say that SW is missing something here moving forward. I might have someone look at your question that has a closer perspective than I do regarding this issue.

 Re other options, I'm certified on the sonicwall appliance and have been working with them for almost 7 years. I've used others (Cisco, Watchguard, etc.), but only because my clients used them. My full working knowledge on those appliances is not as strong as Sonicwall, so I couldn't give good direction there.

Hope that helps.
0
 

Author Comment

by:ricardocoto
ID: 37133526
@digitap,

To clarify for you and any other users coming to this post, there are two separate issues here:

1-LDAP signing can be used without the need to implement "reversible encryption". The problem with the LDAP signing is that SW UTM do not support certificates that has been signed with hash algorithms using SHA256 or SHA1 in fact they only support MD5 hash algorithms. So to make this work at the moment of installing your AD CS role on your server you will need to change the default hash algorithm used from SHA256 to MD5 which is weaker and subject to exploits.

2-For L2TP VPN tunnels (used by iOS - its the only way you can create a VPN tunnel today between iPhone/iPad and SW) you MUST (sort of-see below note) use RADIUS authentication because the L2TP server in the SW uses CHAP for authentication but LDAP does not support CHAP; this means that in order to create a L2TP VPN tunnel you have to use "RADIUS + Local" for authentication login to the firewall. You will think this will work no problem since in the VPN>Advanced Settings of the sw2040 Pro there is a check box that says "Use RADIUS in" with two options: MSCHAP and MSCHAPv2, but here is the rub: no matter which one you select the SW appliance will send the request using CHAP (confirmed by the rep after analyzing a packet capture in WireShark and consulting with the engineers). So somewhere along the design of the appliance and firmware there is a bug because, even though you have the option to select MSCHAPv1 and 2 it never happens! This is a big issue, because in order to make RADIUS work with CHAP you need to use "reversible encryption" for passwords with the known consequences of this being equal to store the passwords in plain text.

Note: BTW, you can still use LDAP for authentication for L2TP VPN tunnels but it MUST be TLS signed which bring us back to the first issue.

To sum it all, if I could get LDAP signing working then I would not have to install RADIUS on my DC and L2TP will work using "LDAP + Local Users" authentication at the SW level. But the issue with the hash algorithm is present in all UTM appliances so far with the fix being requested to the engineer's department at SW.

Let me know if you need more details. If you think they will not need to be posted here I can send them to you personally.

Regards,
0
 
LVL 33

Expert Comment

by:digitap
ID: 37133657
I'll read through this. By the way, when you post, you're selecting "Object" below. You can select "Submit" to post a new entry to your question. Objecting will alert the mods that there is an issue with the way you're question has been closed. I posted a screen shot.
Gmail---Objection-Posted-How-to-.jpg
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Here's a look at newsworthy articles and community happenings during the last month.
Let's recap what we learned from yesterday's Skyport Systems webinar.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…

872 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question