6 Replies Latest reply: Nov 5, 2009 7:14 AM by Peter Scordamaglia
Some Dude Level 1 (55 points)
So, I'm setting up a 10.6.1 server in the DMZ to be a Mobile Access Server to reverse proxy mail, calendaring, and web. Couple issues I have:

1. I want to manage this DMZ server from a different internal 10.6.1 Server inside my network. I have turned on Remote Management on the DMZ server, but cannot connect from Server Admin on the internal server to the DMZ server. I need to be able to manage both servers from one Server Admin console. I also need to be able to screen share the DMZ server for access ONLY from the internal server. How do I accomplish this?

2. My internal 10.6.1 server is my Open Directory Master already, and working nicely. But to use Mobile Access Server and reverse proxy services back to the internal server, I need the DMZ server to be aware of my existing directory inside. Would I want to make the DMZ server an Open Directory Replica, or should I use the middle option for Open Directory types called "Connect to another directory"? Obviously, I know that it should NOT be another master.

3. I have purchased and implemented a wildcard cert on my internal 10.6.1 server to use for TLS, HTTPS, etc. I have also told the Open Directory Master to use ssl for the LDAP piece of it (there's a GUI option for that). Figured I might as well secure everything I can a bit more since I purchased the cert. What effect will this have on Question 2 above? Will I need to open a different port for instance on the firewall for LDAP over SSL? Or any issues with creating a Replica or "connect to another OD server" on the OD server in the DMZ to get it to connect to the internal OD Master?

Thanks for all the help here.

MacPro 2008 3.2GHz 8-core,32GB RAM,4x1TB in a hardware RAID5, Dual 8800GT's, Mac OS X (10.6.1), Snow Leopard Server
  • Some Dude Level 1 (55 points)
    Bump...guys, can I get some help here? The most important thing I need to know right now is whether I need to run Open Directory on the server that is running Mobile Access Server? If so, do I use a replica config, or what? I would love to not have to run Open Directory at all on the Mobile Server, and just bind it to my internal Open Directory master server (which is also the origin server for things), but am not sure if that's doable. There is so little information out there on Mobile Server its ridiculous. I have figured many things out on this myself, but still need to know about OD. Thanks much for the help, someone? Anyone? Bueller? Cheers!
  • AJXserveAdmin Level 1 (5 points)
    You can bind the MAS server to the origin server using the LDAY binding in the System Preferenaces- > Users Panel.

    This works! I have been able to get it upto the login page form the internet on an iphone, but stuck after that...anyway the trials continue.Cheers!
  • Some Dude Level 1 (55 points)
    Hmmm, thanks for the response, I really really appreciate some interest in this topic, so thank you! Now, I ended up deciding that the MAS server must have to be an OD replica, because part of its job is to authenticate every user that hits the login page and based on the "Access" tab in the Mobile Access server settings, that's where you would enforce that user "jane" gets address book and calendar, user "joe" gets mail and Address book, ,and user group Finance gets everything. If you are not an OD replica, how can you enforce the level of granular access control that clearly MAS was invented for, and marketed to.

    Set me straight here. I totally hear ya on the binding your way, but then how the heck would access decisions, clearly a part of the MAS, be made?

    Thanks so much for the interest in this, someday this will work, but right now its all hit and miss. Cheers!
  • Peter Scordamaglia Level 2 (380 points)
    To your #1: When you use a firewall to place a device in a DMZ, that device is not part of the internal network. It 'technically' sits on the outside of the firewall at nearly the same place as your external connection.

    Some discussions about a firewall use colors to designate the 'data protection' level or 'threat' vector.

    (Below was 'borrowed' from http://riskless.com/firewall_configuration.aspx)

    * RED Network Interface
    This network is the Internet or other untrusted network. IPCop’s primary purpose is to protect the GREEN, BLUE and ORANGE networks and their computers from traffic originating on the RED network. Your current connection method and hardware are used to connect to this network.
    * GREEN Network Interface
    This interface only connects to the computer(s) that IPCop is protecting. It is presumed to be local. Traffic to it is routed though an Ethernet NIC on the IPCop computer firewall.
    * BLUE Network Interface
    This optional network allows you to place wireless devices on a separate network. Computers on this network cannot get to the GREEN network except tightly controlled “pinholes”, or via a VPN. Traffic to this network is routed through an Ethernet NIC.
    * ORANGE Network Interface
    This optional network allows you to place publicly accessible servers on a separate network. Computers on this network cannot get to the GREEN or BLUE networks, except through tightly controlled “DMZ pinholes”. Traffic to this network is routed through an Ethernet NIC.

    * The GREEN and RED networks are required
    * The ORANGE and BLUE networks are optional

    The interface requirements for your RED network will vary depending on your connection to the Internet. The RED network may require an additional Ethernet card and cable.

    you can also read up all this from a more neutral article here: http://www.ocmodshop.com/ocmodshop.aspx?a=1526

    The point of all this is that, depending on 'where' the dat is comgin from , it either is denied access ,or must be 'punched through' to allow access. Her is a diagram of that process (from a linux firewall called ipcop)

    Soaccess from inside (your network) to your DMZ device should work without any trouble but from DMZ to inside should require ports to be opened up. On most Firewalls, they call this port access 'Pin Holes' as the DMZ is itself protected by only allowing the ip address of that network into through the firewall. Possibly Your firewall is not doing any kind of Statefull Packet Inspection so all conversations must have a pinhole to come 'back' out of the dmz? Tell us your firewall brand and that might help.

    #2: I would use "Connect to another directory". YOu want to limit the amount of data that can be compromised in the DMZ. As I mentioned the DMZ is outside your network, technically naked to the world. I believe that any port that does NOT get routed (forwarded) into your green, will automatically be forwarded to your DMZ, so it will be hammered with all manner of hack and virus vectors.

  • Some Dude Level 1 (55 points)
    Peter, thanks for the thoughtful response. I should have updated this request earlier. Thru trial and error, i have things set from an infrastructure standpoint now...now my issues are just around application server usage ie Mobile access with mail, cal, use of Open Directory, etc. I should mention that I am VERY familiar with network security and the use of DMZs vs. internal networks, etc.

    To be perfectly clear for the record, my 10.6.1 MobileAccessServer/OD replica is on an external IP, between my DSL router and my firewall. I have it heavily locked down with the IP firewall that is included in 10.6 Server. I have opened up the necessary ports both on the host-based firewall on Server and on my actual firewall device (currently just a Airport Extreme), for the DMZ server to talk back to the internal 10.6.1 Server (origin servers) on the required ports. So, all connectivity that is required is in place, and nothing else. I am keeping a close eye on the Firewall logs on all 3 devices (2 servers and the Airport extreme) to ensure that I am not blocking anything valuable to the equation here. So, all is well there.

    My issues are all now at the "application layer", where I am less sure of myself. Part of me wants to wait for 10.6.2 to land, as I have a gut feeling that MUCH of what I'm seeing will be improved in that release. However, I continue to dabble here, the problem is lack of experience in the Mac community with Mobile Access Server in general, and Apple's pathetic attempt at documentation for these services. I won't go ranting about that again, but I truly believe that better resources will become available at some point here, hopefully soon. They have to, because I can't spend 14 hours a day managing basic setup tasks.

    My issues are that LDAP over SSL is broken badly in 10.6.1, and the rest is just needing more time to troubleshoot, beyond what I've accomplished thus far. It's frustrating, but I'm a sucker for pain I guess.

  • Peter Scordamaglia Level 2 (380 points)
    Gotcha. I am willing to put myself through some serious (and normally not necessary) pain as well .

    Maybe it is a good idea to wait the shakedown until 10.6.2, like you said. While waiting, I found an article about SSL and LDAP on here http://discussions.apple.com/message.jspa?messageID=10490678#10490678, no idea if that helps.

    I am stuck @ 10.5 for now, this economy is precluding any chance at replacing this G5, although the only reason to replace/upgrade it is for the ability to say I own an intel mac (read as: for 'vanity's' sake), the G5 we have now runs perfectly and consistently.

    Good Luck!