OD Master and Replica on Public IPs

[OD Master]

I want to use Open Directory Binding and Kerberos outside the LAN as well and the best way to manage that seems to do away with a separate router and finally use the built-in stuff of Tiger Server.

(Side note: Till now it was not easy to get an Internet hookup with fixed IP and Reverse DNS for a reasonable price from one of the big players here in Germany. Finally this has changed – German Telekom now offers this for a total of less than 50 EUR/month with speeds of 6000/576.)

Kerberos will always use the primary interface when promoting a server to an OD Master. So as the Ethernet Interface connected to your DSL or cable modem has to be the topmost in the list anyhow, your OD Master will pick up the (fixed) public IP and the associated machine name – if you have the public DNS set up to provide correct Forward and Reverse DNS records.

You can do the same with an OD Replica at a second site and so you will have both reachable from inside their LANs and all over the Internet as well. Something possible now with Tiger as Trusted Binding allows you to secure your OD servers and expose them to the world outside your VPN.

I just wonder if Tiger Server might run into troubles with the still just pseudo-static IP assignment on the PPPoE interface. So if one of you has some experience in this field I’ll be happy to hear.

Norbert

[OD Master]

A little update from myself:

I have one of the two servers running on a public IP via PPPoE now. Last weekend the PPPoE connection did drop and the server got offline and was unable to reconnect until we did reboot it.
Otherwise the installation is stable so I’m going to add the replica server as soon as we get the fixed IP plus Reverse DNS for that office from the provider.

I still wonder if there’s really nobody out there running at least an OD Master on a public IP – everybody keeping them inside their LANs on private IPs?

If you want to secure VPN dial-in via Kerberos – and that a real big gain in security – you need to make the KDC etc. accessible from the Internet. I think that should be the standard way of doing it today, but I feel this does not seem to be the case at all… 😎

Norbert

[OD Master]

MacTroll wrote:

I am not a huge fan of exposing your KDC just for the VPN functionality.

For this to be of any benefit your remote users have to log into their systems first, and get a krb ticket from your OD setup, and then go into the VPN.

Well, without being logged into their mobile Macs there will be no way to VPN into the company net 🙂

Now for dialing in via VPN using the classic way they have to use their SSO password, so this has to go across the net first. And it will likely be on the user’s keychain. This makes it more difficult to force them to change it at regular intervals and creates two other security holes.

And regarding the Kerberos ticket: As soon as the have the VPN connection up they will have to get a Kerberos ticket anyhow to access any file server. So there is no extra step in creating the ticket before the dial-in.

MacTroll wrote:

This forces you to expose a large amount of data to the outside world since it has to be there before the VPN can come up.

I would always suggest you put your OD infrastructure behind a firewall and port forward the few ports you may need to expose to the outside world.

Sure, the KDC will be one of the few ports to expose. But this makes no difference either, the L2TP server will have to be open for accepting the password as well using the traditional way.

I think what we have here is just the point that the “unavoidable” holes we have today are simply accepted and any new way which plugs those and might possbily open other creates some kind of mixed feelings…

Just a side-note: I see it everywhere that massive limitations are put in place to prevent outside access to company LANs and servers. The result: people carry gigabytes of confidential data around on their laptops – now judge for yourself :-))

Norbert

[OD Master]

Yes, all the users have mobile accounts, so they are in sync with Open Directory. Network Accounts won’t work anyhow as you can only VPN from a single Mac after you have already logged into an account…

For the branch offices I have the site-to-site VPNs in place as you suggested. Currently via stand-alone routers, in the future from Mac OS X Server to Server so they use the same standard as the single-user VPN connections.

I’m still in favor of Kerberos as there are more uses coming besides just VPN dial-in authentication and Mail access. I can’t give more details here as part of this is still confidential. But those additional services make a single place to hold the password and manage the authentication even more interesting.

I know that password transmission is encrypted with traditional MSCHAP authentication and that the Keychain is a secure place to store them.
But still, when a user is forced to change the password in Open Directory from time to time the VPN, Mail, Web password will change as well so they need to update all those afterwards so the Keychain holds the new one.

Personally I have no problem to handle that, but believe me, I know how many support calls I willl get because people don’t understand why services fail when they use them next time, weeks after the password change…

Kerberos avoids all these problems, it makes it easier to force secure passwords and reduces risks in many other places. Apple designed Mac OS X Server to run on public IP and serve mobile clients, and the guys at MIT had exactly that in mind when they invented Kerberos. So I think it’s worth a try 🙂

Norbert

[OD Master]

To answer my own question from the initial posting under this topic:

“Will Mac OS X Server work with a PPPoE Interface as the primary – assuming you have a fixed IP from your provider plus a working forward and reverse DNS in their servers?”

I’ve done some tests the last two weeks and have come up with the following results:

1. Apple does not support the use of a ppp interface in the NAT settings of Server Admin. It will only list en0, en1, etc. in the popup for the primary interface. You can work around this by editing the plist by hand, so I could get this to work.
But Apple seems to have imposed this restriction with good reason:

2. When the PPPoE connection goes down because of some Internet problem, Tiger Server will see this interface as inactive and move the primary connection over to the next interface in the list which will usually be your internal LAN.
Unfortunately this also means that this becomes the default route for firewall and NAT so the server will get into big problems from this point on. So the setup does not work reliably when the Server does the PPPoE dial-up.

3. The solution is to get a DSL modem which supports so-called “DHCP-spoofing” or “half-bridge mode”. Such a modem does the PPPoE dial-up, gets the addresses for your connection, router and name servers and forwards them via DHCP to the internal port. But it does not do any NAT, port forwarding etc. which will make the connected device use a private IP, not the public IP we need for the setup I’m suggesting.

As the internal port of the modem never goes down (it’s just plain Ethernet so the link is up as long as the modem has power) the server will always keep it as its primary interface.

With the above solution you can use any (really cheap) PPPoE line with a static IP for hooking up Tiger Server. The server will assume the public IP of your DSL line a so be usable as an OD Master or Replica for your clients inside AND outside your LAN.

A modem which fully supports DHCP spoofing right out of the box is the Netgear DG632. I’ve installed one of those today and in case I find some problem with this model I will post here. But so far it looks like this is the best possible solution here. I have not found any other modem where the manufacturer does advertise this feature as the standard mode of operation.

Norbert

[Author]

Posts