3037 Views 6 Replies Latest reply: Nov 5, 2009 7:14 AM by Peter Scordamaglia
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!
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!
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.
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.
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.