You Don't Need A VPN Part II - LDAP Integrations, User Data Imports, & the Internet solution

[BillB]

Last week we discussed why you don't need to use a VPN when running a user data import, and can instead use the MID server. But what if you don't want to use a MID server to sync data?

You still don't need a VPN tunnel!

VPN tunnels leave a leg in both networks unencrypted. So, a better method would be to use LDAPS-over-the-Internet.

I know, I know…"But it's our Domain Controller," you say, "sensitive data. We can't have that open to the Internet!" Right?

Well, SSL encrypts the traffic over the Internet using the same encryption methods as IPSec tunnels. If the data is intercepted, then either method, SSL or VPN, would present the same challenges to an attacker. In fact, VPN tunnels use pre-shared keys, which are basically like passwords. Most of the ones I have seen are pretty weak and fairly short—the equivalent of one word.

Using LDAPS-over-the-Internet

By contrast, the SSL key is several lines long, always gibberish, extremely hard to guess, and can be changed at-will by you, our customer, according to whatever policy you decide to implement, and all without even needing to involve anyone at ServiceNow. Change the key once a year or once a month—it's completely up to you. Simply upload the new key over an encrypted channel to your instance and you have a new set of encryption parameters. Changing VPN pre-shared keys, on the other hand, require a tunnel outage. I have never seen anyone change a tunnel key except when completely changing out their peers. SSL certificates are updated on a more frequent basis in most cases.

When using LDAPS-over-the-Internet without a VPN tunnel, is the server exposed to the Internet? Microsoft introduced the concept of a Read Only Domain Controller (RODC) in Windows 2008, which can be configured to not store any passwords. Since ServiceNow never asks for a password and makes a read-only Bind query to validate a token instead, this technology is perfect for our use case. Simply install an RODC in a DMZ, lock down access to allow connections from only the specific source addresses from ServiceNow and the port number of your choosing (since you can configure this in the Instance), and an attacker would be hard-pressed to obtain that information. Top that off with the fact that an attacker would need the key that you export and upload to your Instance (again over an encrypted channel), along with the username, password, and starting directory that you configure, and you have a very secure connection point.

All this to say, LDAPS-over-the-Internet will give you the flexibility to make changes to your environment quickly and efficiently without the need to engage ServiceNow to modify a tunnel. Your LDAPS-over-the-Internet solution would look something like this:

1. You have a domain controller in your network. You install an RODC in a DMZ with a public IP address.
2. On your firewall, you allow connections to that public IP address from only the specific source addresses that ServiceNow will be using from the two (paired) data centers where your instances are located.
3. You further lock down access to a port of your choosing and do a port translation (PAT) on your firewall to redirect the non-standard port to port 636 (LDAPS).
4. You then configure the non-standard port in your instance and upload the SSL cert over an encrypted channel.
5. If you want to get really creative, you could also implement stateful inspection to ensure that only LDAP traffic is passing through, thereby preventing other TCP connections to your RODC.

Of course, using the MID server is much easier. But the MID server can't be used for authentication. For that we need something that is on-demand when we log in.

Check out Part III for why you still don't need VPN and the benefits of using Single Sign-On (SSO).