Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LDAPS + NAT + Certificate

Hi there,

I want to publish our internal LDAP server (it's a novel one residing on let's say ldap.internal, corectly speaking ldaps) to the rest of the world. So I did a NAT-Forwording as described elsewhere and everything works fine except for the certificate, because with NAT the internal certificate (for ldap.internal) is presented, which a) is not trusted by the public and b) does not match the hostname.

I know the possibility for Web-Server forwarding (Webserver Protection -> Web Application Firewall), but I guess, this will not work for LDAPS.

Is there another possibility to provide a different Certificate to the "outer world" for NATing LDAPS through UTM9?

 

Best regards and thanks for your help in advance...

 

Willi



This thread was automatically locked due to age.
  • Hi Willi,

    The best way is a UCC (SAN) SSL certificate (https://www.digicert.com/subject-alternative-name.htm ) wich can be used with internal (private) and external names and ip-adresses simultaneously.

    Maybe:

    ldap.internal

    ldap.external.com

    ldap

    192.168.2.22

    127.0.0.1

     

    You have to install this on your internal ldap server.

     

    Sophos Certified Architect (UTM + XG)

  • Hi CS,

     

    thanks for your response. That was what i was thinking about too, but i was asking our certificate-partner (icertificate) whether i can (or not) include SAN entries such as ldap.internal in our wildcard certificate. Maybe that was the error, because he told me, nobody would sign such a certificate.

    I'll check this and give some feedback here...

     

    Regards,

    Willi

  • So here my promised feedback...

    Unfortunately this option seems to be out for allmost 2 years now, see:

    https://www.digicert.com/internal-names.htm

    So maybe we have to use public names internally :(

    Any other ideas? 

  • Upps. That was new to me. I don't see any other option with the utm.

    Have a look at Kemp ( https://freeloadbalancer.com/ ). There should be the ldaps offloading feature.

    With public names internally you should use split dns (UTM configured as forwarder for your internal DNS, internal LDAP as static DNS entry) to avoid connections from internal via NAT over the public ip to the internal server.

    Good luck!

    CS

     

    Sophos Certified Architect (UTM + XG)

  • CS said:

    Have a look at Kemp ( https://freeloadbalancer.com/ ). There should be the ldaps offloading feature

    Well, this seems to be a bit too big for our case...

    CS said:

    With public names internally you should use split dns (UTM configured as forwarder for your internal DNS, internal LDAP as static DNS entry) to avoid connections from internal via NAT over the public ip to the internal server.

    I do not quite understand. The idea was to use external DNS to point to internal ldap, for example ldap-i.example.com -> 192.168.209.48. Then give the LDAP our wildcard-certificate. Make ldap.example.com a CNAME to sophos external address and use NAT as before (World <-> ldap.example.com <-> ldap-i.example.com).

    Since the wild card certificate now matches both (ldap and ldap-i) it should be valid for both.

    So I just have to access ldap-i from inside, which should not use NAT then.

    Well anyhow, the problem now is to convince the novell groupwise LDAP to use our wildcard certificate, which we have not succeeded yet.

    Thanks a lot for your help

     

    Willi

  • The real problem is that LDAP is not HTTP(s), so it will not flow through a WAF server.  Your usable options would be (1) configure SSL VPN logins for designated users, or (2) create a web page that converts the LDAP information into a web page, and publish the web page with WAF to some or all users.

    Assume that any information that you publish unsecured, or publish without 2-factor authentication, will be for sale on the dark web very quickly.   So be very careful what you make available.