Welcome to our session on Deploying Mobile Access Server. My name is Steve Cervera. I am the Solutions Architect Manager for Apple Education Sales I am joined by my colleagues Al Begley, John Murata and Greg Vaughan, Software Engineers and Principal Architects of Mobile Access Server. So what we are going to talk about today is what Mobile Access Server is, what problems it solves and we are going to get under the hood a bit and look at how it works.

We will talk about some deployment scenarios and then we are going to give you a brief demo on how simple it is to configure Mobile Access Server. I will then take your questions. So Apple built Mobile Access Server as a way to provide iPhone users with secure on-the-go access to company information or, in the case of education, school information. Now Mac OS X server has excellent services for Mobile users.

The challenge up to now has been how to provide secure access to those services across a firewall without the need to configure a VPN on each client. So we built Mobile Access Server with this in mind. We wanted to provide secure access to web services, iCal server, Address Book Server, and mail services without the need to touch any of the clients to configure a VPN on them. And all communication is secure and securely encrypted over SSL, and only access to specified servers and services is granted to authorized users.

So one of the design goals for Mobile Access Server was to make it simple to configure and administer and we have done that and you will see that in a bit. We also wanted to make it easy to connect through. We didn't want you to have to configure anything on your device in order to access resources through Mobile Access Server.

We have implemented a system that allows us to maintain a common name space, say for a web URL, whether accessing it from the internal network or from the external network, and you will see why that is important in just a bit. And while we have designed Mobile Access Server principally for the iPhone, certainly any mobile computer or the iPod touch can utilize Mobile Access Server as well. Now Mobile Access Server is built on the idea of a reverse proxy, a reverse web proxy.

To kind of understand that, let's review what a forward proxy is. With a forward proxy, we have our internal network and our external network and typically we have a host that receives queries from our internal clients and then forwards those on to servers out on the internet and typically we will use this to either optimize performance by caching web pages on that proxy server or to use it to control access to the internet.

Now with the reverse proxy, typically this is used today, if you have a rack say of web servers on the back end and you want to provide load balancing to those servers, you place a host in the front end to receive the request from the clients and then distribute them among the backend servers. If you will recall, we introduced the configuration of reverse proxies in the GUI in Leopard Server and this was principally done to provide load balancing for Ruby on Rails and Mongrel applications.

Now we have taken it a step further in Snow Leopard to provide secure access through the Mobile Access Server. Now there are three common implementation schemes for implementing reverse proxies. The next couple of slides I am going to go over some of those and it will help you understand why we chose the scheme that we did. Now let's just define some terminology.

Obviously, we know what a client is and I will be referring to the client as an iPhone or iPod touch or a laptop computer. We have discussed the proxy server and I want to introduce the term origin server. The origin server is the server that the clients connect to and that is the origination source of the services, whether it is mail, iCalendar server, or web services. So with that in mind, let's take a look at some common schemes for implementing reverse proxy.

In this diagram, we have got our internal network and our external network. We have got an origin server named wiki.example.com. We have our Wiki proxy; this is our reverse proxy that spans the internal and the external network. Our client is going to address the Wiki proxy, the reverse proxy in this case, wikiproxy.example.com.

That reverse proxy then forwards the request onto the origin server. And one of the challenges here is when we are accessing that Wiki server from the internal network we are addressing it directly using wiki.example.com, but when we move to the external network, we now need to address it with wikiproxy.example.com.

So the problem that exists is, we have disparate name spaces, so any links that we create from the internal network no longer work when we are on the outside network. Now what if we want to use this reverse proxy to proxy not just one server, but many servers, well there is another way to implement reverse proxy that allows us to do that and we do that by modifying the path to the, in the URL.

So here in this case, we are going to be addressing wikiproxy.example.com/ and then the name of the host, the origin server that we want to access. In this case, it is Wiki and of course if we had an iCalendar server named foo it would be /foo. So this method gives us or presents the same challenge in that we have a disparate name space, so again any links created on the internal network no longer work from the external network.

So we have chosen to implement a reverse proxy that depends on split DNS to accomplish a constant host name and constant path, so in this example, we have again our Wiki server on the internal network. We now have a Mobile Access Server, this is our reverse proxy server, again spanning the network, and here our internal DNS, I'm sorry, our ISP's DNS is configured to resolve wiki.example.com to the IP address of our Mobile Access Server. The Mobile Access Server then passes that request onto the internal origin server.

Now the benefit here is when we are on the internal network, we are going to be querying our internal DNS server. The internal DNS server resolves wiki.example.com to the IP address of the origin server; we are completely bypassing Mobile Access Server at this point. We don't need Mobile Access Server.

We have direct access to the origin server and so we make bookmarks here and then we go home or out of the network. Now our client is going to query our ISP's DNS server, which resolves wiki.example.com to the Mobile Access Server, which grants access to the origin server. Now here the bookmarks we created on the internal network work just fine from the internet and our web apps work just fine too. So to review, split DNS is a key to deploying Mobile Access Server.

Here we have the Mobile Access Server multi-homed in the DMZ, the demilitarized zone or the border zone, and the, our internal DNS server is configured to resolve the host name of the origin server to the IP address of the origin server, but our external DNS server, our ISP's DNS server is configured to resolve the host name of the origin server to the IP address of the Mobile Access Server, which then goes on and passes that request onto the origin server. So to give you an idea, from the external network, external DNS is configured to resolve wiki.example.com to say 63.x.y.z. But our internal DNS is configured to resolve the origin server to the interface of the origin server, so bypassing Mobile Access entirely.

As with any server placed in the DMZ, it is important to protect that server with tight firewall rules and the use of certificates. So with regard to certificates, it is important to use CA-issued certificates. Why? You can use self-signed certificates, they will work, they will function, but your users will receive this warning indicating that the certificate presented by the server is invalid and if, as a matter of business practice you are using self-signed certificates and you are training your users to accept this warning, then you are training them to ignore a very important warning that could protect them from a rogue server, so it is important to use CA- issued certificates. Now in the event that you really need to use a self-signed certificate, you can make this error go away simply by copying the root certificate to each of the devices that will be accessing Mobile Access Server.

Of course, now you have to touch each device and that kind of defeats the point of Mobile Access Server in the first place. So we think it is a good investment to purchase the CA- issued certificate for this application. Now it is also important to tighten up your firewall rules to make sure that any host access in the Mobile Access Server from the external network is only able to get to the server through the ports necessary to access the services from the origin server. And similarly on the inside interface, it is important to create rules that allow that Mobile Access Server to only access the directory services and the origin servers that it is serving proxy for.

Security is obviously very important for this server and so, in this role, so all data is encrypted over SSL from the client to the proxy and only access, access is only granted to the Mobile Access Server for authenticated users. Users must be authenticated either against Open Directory or active directory and we have a mechanism built in called Auth throttle back that will incur a decreasing delay on repeated failed attempts to authenticate and so that helps to thwart brute force attacks. Now once a user is authenticated, the user must also be authorized. So we have a whitelist authorization system and you see a screenshot here that shows the default setting is that all authenticated users are allowed to access web mail, iCal and Address Book Servers.

But obviously, you are probably going to want to tighten that up a bit and grant access only to the users, individual users, or groups of users for the specific servers that they require. So you see in this example here, the students group has access only to web services. Whereas our remote workers group has access to all of the services available in Mobile Access Server and obviously, we can provide John and Al with the services they require as well.

Now access through the Mobile Access Server varies a bit depending on the service and the protocol being used, so let's start off with the way, talking about the access through Mobile Access Server for web and Wiki services. Here we have created a customization and a patchy plugin called mod_auth_session_apple that provides access only to the web server.

What it does is provide a login user interface to allow the user after making a request for an internal server, to log in with their credentials? Now upon a failed authentication, the user will be redirected to an access denied URL and then there is a Try Again button that will allow them to try and authenticate again, so maybe they fat-fingered their password.

And if they are trying to hack the system, they will run into this brick wall here with Auth throttle back and, upon repeated failed attempts, will create an increasing delay between the time that the login user interface is presented to them again. And so once we authenticate, then the user is automatically redirected to the URL they they've requested.

Now we don't want to have to make the user log into Mobile Access User for every server they want to access and so there is an option here to keep me logged in, in which case a session cookie is created that has a 14-day expiration. So in that time period, they will no longer have to authenticate against the Mobile Access Server.

Let's take a look at how this works with web services. Here we have on our internal network, our origin server, wiki.example.com serving up some Snow Leopard Wiki pages and spanning the internal and external network is our Mobile Access Server. Our external DNS, the ISP's DNS is resolving that host name to the IP address of the Mobile Access Server. Now our client here is making a request over HTTP. The Mobile Access Server will immediately redirect this to HTTPS an encrypted communication over SSL.

So the request comes in now with SSL and the Mobile Access Server will then authenticate the server and check the user against the whitelist, assuming the user is both authenticated and authorized through the whitelist, the request is passed on to the Wiki server and the information is passed back to the client. Now let's take a look at a case where the user is authenticated, but not on the whitelist. Well that is a red condition.

Also if the user is not authenticated obviously and not on the whitelist, access through the Mobile Access Server will be denied and the user will not get any further, so that is an important feature. Now let's take a look at the user experience from an iPhone. Now here we are entering the URL for the server we are trying to access wiki.example.com. Notice we are accessing this through HTTP that will then get redirected automatically to HTTPS.

But this is an important concept here, because remember we want our users to be able to access this server regardless of whether they are on the internal network or on the external network. And this is why split DNS is so important in implementing Mobile Access Server to enable us to maintain that single name space.

So when we click Go, we are then brought automatically to this login user interface. This is a construct of Mobile Access Server. Mobile Access Server is saying okay, to go any further, you need to be authenticated, so you enter your credentials and we also, you see the option to keep me logged in. Again, that will create a session cookie that will last for 14 days and we click the Log In button.

Uh oh, this user is not authenticated, this is the access denied URL that they receive. So we fat-fingered that, we got it right this time. We are then brought to this URL, which indicates that the user has been authenticated, has been authorized and we will automatically be redirected to the URL that we requested.

In this case, it is a Snow Leopard Wiki, so remember I said that we have this option to keep me logged in for 14 days. Well what happens if for some reason in that 14-day period, we need to take access away from that particular user. So what do we do? Well quite simply, we can remove that user from the whitelist, either their account or the group that they are a member of or take them out of the group membership.

In any case, if they are not on the whitelist, at any point, we are constantly examining the HTTP authorization headers to extract the username and compare to this whitelist. If they are not on the whitelist, they will receive this URL so access will be denied at the Mobile Access Server.

So most applications should work just fine through the web proxy and Mobile Access Server. There are a couple things to keep in mind. Some applications will require the IP address of the requesting client. And because we are proxying here and we need the address of the original requesting client, you need to get that information from the X-Forwarded-For header. Also, you should try to make your links relative wherever possible.

Consider the fact then when we are on the internal network, we are going to be in most cases accessing our web servers over HTTP, but when we access those same web servers from the external network, what is going to happen? It is going to automatically be redirected to HTTPS. So if you make your links absolute, then you are going to have a broken link.

Also, remember that you can only access other servers that are proxied as well and so any links that you make in an application or a website need to link to other proxied applications or other proxied web servers rather or to public hosts, obviously then we are bypassing our own network entirely. Now if your application is or your website is using some kind of authentication, you need to use basic digest or session cookie authentication. Remember we are examining those authorization headers and as a result, we can't use Kerberos in that type of an implementation.

Now in server admin for web services, in an effort to keep the user interface simple, we use name based virtual hosts. As a result, that requires all virtual hosts, in this case proxy virtual hosts to listen in on all IP addresses, but because we are using SSL, we run into the host header versus SSL certificate issue.

You see the host header provides the information about which virtual host should respond to the request, but we can't examine the host header to determine who the virtual host is until we use the correct certificate to do that and if each virtual host is using a different certificate, Apache has no idea which virtual host should respond. So there are a couple of ways around that, the first one is to use a wild card certificate.

Now we are using one certificate for all the web, the virtual hosts in your domain and so Apache then needs to take the request, apply the single wild card certificate to decrypt and then to determine who the host header is, I'm sorry or the virtual host is that needs to respond.

Another solution is just to make your proxy virtual host be port specific to help identify which virtual host should respond and finally it is possible to manually configure the virtual host config file, we don't recommend this, because it is possible that any changes made here in the config file would be overwritten by any changes made to the GUI. So let's take a look now at iCal server and address book server and take a look at the access mechanisms employed there.

They are similar because they are also utilizing the HTTP protocol and but here we don't have an option to present a log in interface to the user as we do with access through a web browser, so we have a different plug-in that we have created called mod_auth_user_host_apple. This does authorization only.

Here we are relying on the iCal Server and the Address Book Server to do the authentication and here again we are extracting the username from the HTTP authorization headers to compare that to the whitelist and so here again basic and digest authentication should be configured and not Kerberos. So once we extract that username, we check it against the whitelist and then determine whether this user has access for the requested service. Let's take a look at how this list works.

Here now our origin server is an iCal Server, our Mobile Access Server again spans the external and internal network and our client is going to connect with CalDAV over HTTPS, unlike with web services, the Mobile Access Server doesn't redirect an HTTP request back over to HTTPS. So it is important to know that your users on their device need to configure their iCal client to use SSL.

So once the connection is made, the request is passed on to the iCal Server, the user is authenticated and the reply is sent again through the Mobile Access Server and the whitelist checked, the user is on the whitelist, the information is passed on to the client and of course if the user is authenticated, but not on the whitelist, then access is denied and the information never gets back out through the Mobile Access Server.

Alright let's take a look now at mail services, we are using IMAP and SMTP protocols here and the Mobile Access Server acts as a mail proxy in this situation proxying IMAP commands and SMTP commands. Now we have only tested this with Apple's mail server, but there is nothing that we are doing to prevent anybody's IMAP or SMTP server from working, it is just not a test case for us.

So in this particular implementation, the Mobile Access Server both authenticates and authorizes the users at the proxy before they can access the mail server. Let's take a look at how that works. So with a mail proxy, the Mobile Access Server is acting both as a mail client, a proxy mail client to the origin server on the internal network and as a proxy mail server to our physical client on the external network.

And the way this works out is we have our origin server, in this case our mail server. We have got our Mobile Access Server. Notice here the origin server is mail.example.com for mail services we have mail.proxy.example.com so we are not using the same name space in this particular case and I will talk more about that in a moment.

So our client makes a request for an IMAP connection, again over SSL, no redirection here, just needs to use SSL or it won't work. The Mobile Access Server then authenticates the user, if the user authentication fails, obviously they are denied access and if the user is authenticated, but not on the whitelist, they will be denied access as well Of course, if the user is both authenticated and on the whitelist, the client, the request is passed on to the origin server and the mail is retrieved to the requesting client.

We spoke about the importance of split DNS to maintain this common name space, where when our client is on the internal network, they will be querying the internal DNS server and will be accessing directly the origin server, the internal DNS server resolves the IP address directly to the origin server and when we move to the external network, the ISP's DNS server is going to resolve that origin server host name to the Mobile Access Server, well with mail we can't do that.

The mail protocol does not support this type of redirection and so here, you are going to point your mobile clients to the Mobile Access Server as their mail server. Okay, so clients then whether they are on the internal network or the external network will be pointing to in this case, it is mailproxy.example.com and the Mobile Access Server will of course forward that request on to the origin server as the mail proxy. Now we have given you a look under the hood and maybe you are saying geez, this doesn't look so simple, Steve said it was simple.

It really is simple and I am going to have John Murata come up and demonstrate to you how simple it is to configure and administer Mobile Access Server.

So, I want to show you how easy it is to configure a Mobile Access Server. I am going to launch my Mac OS X Server admin app.

It is going to come up and it is going to show a Mac OS Server that I have running on a private LAN, the server is fully qualified domain name inside my LAN is myserver.example.com and as you can see I have an open directory service, my Address Book, iCal, mail and web services all running on this server here.

Now I want to make the Wiki web service that I have on my LAN available to my iPhone, so let me show you how in Snow Leopard, we have made it easy to add secure Mobile Access to a private network. So first, I am going to add an OS X Server to my network and this is going to run my Mobile Access proxy and I can do this right here in my server admin app, using its ability to configure multiple OS X servers.

So here is my proxy server and my proxy server is available through my ISP's DNS as myserver.example.com and this is of course the same name as what I am using internally and my server, because it is on the internet is running a firewall and my firewall is configured to allow access to those services that I am going to be using. So let's go ahead and add my Mobile Access Service to this proxy machine, there it is.

Mobile Access uses SSL, so that means I need my CA-issued certificates. I have already imported into server admin the certificates that I will be using, so now I am ready to add Web Access, and I'll do that here in my Mobile Access Settings. I type in the name of my internal server.

And that's it.

Thank you. All right, that leads me to the next dialog, the Edit Dialog. So, as you can see here, if I want to check my incoming connections, I can do that here in the Edit Dialog and fix my host name.

And all of my URLs are going to be redirected to my incoming port, 443, and it's going to do it over HTTPS using SSL. And so, this is going to happen automatically, whether I'm inside or outside of my LAN, on the private LAN or on the public internet.

And that's it. If I need to add another server, I can do that right here. Also, only these servers that I add in the interface you see here are going to be accessible from the public internet through the Mobile Access proxy. Now, I'd like to also have access to my private mail server from my iPhone, so I'm going to add my mail server on this particular internal server.

And, in this case, I want to have my DNS name be something unique, mail.example.com, something so that I can access it through my ISP's DNS and since I'm changing the DNS name, I'm going to need a certificate that matches. If I happen to have a wild card certificate, then I can go ahead and use that for all my domain names.

There, I've secured mail and web access to my internal network, and let's go ahead now, and authorize some users to access this server I'm going to click on my Access Panel. Right now, it's allowing all authenticated users access to the two services that I've set up. I can restrict my access to just those users I'm going to specify. I have an open-directory server running, so I should have access to all of my users. And I'm going to ad Al and myself.

Not quite that smart. So there are a lot of other users who want access, so since this is an open directory, I can just go ahead and add a couple of groups to handle the rest of the users who need access. Then you save, start Mobile Access, the light is green, and that is configuring the new Mobile Access Server on OS X Server.

I just want to summarize here, the ability for Mobile Access Server just to provide secure and simple access to your web mail, iCal and Address Book Servers, without the need to configure any clients. Also, the administration is simple. A key message here is the correct implementation of split DNS is the key to success here, with implementing Mobile Access Server. Here's where you can go for some more information.