Good afternoon, ladies and gentlemen. I'd like to welcome you to session 511, iPhone configuration-- iPhone Management with Configuration Profiles. My name is Stan. I'm one of the guys who wrote this piece of code and I'm going to go first through a few slides. What are you going to learn in this session? We're going to be talking about what configuration profiles are and how to use them.

We're going to look at what we can configure with configuration profiles. We're going to look at the profile format. We're going to be talking and actually showing you in a demo how to create configuration profiles. And eventually, we're going to also talk about how to deploy a profile.

So what are configuration profiles? Well, there are very small XML files that contain information about how to configure an iPhone or an iPod Touch. They configure common, yet potentially complex settings, such as VPN networking, which would be really hard to do on the device itself. They can also enforce a specific degree in security on the iPhone by imposing certain restrictions and behavioral patterns on the user. They can install credentials on the iPhone, such as certificates. They are not to be confused with provisioning profiles. If you're here hoping to get information about provisioning profiles, you're in the wrong session. This is purely about configuration profiles.

So what do configuration profiles do for you? They can configure a series of aspects of the phone. First of all, they can configure Microsoft Exchange ActiveSync account settings, passcode policies, credentials, certificates, VPN configuration and Wi-Fi configuration, application access restrictions, mail settings and APN settings. So let's go through all of those one by one in detail and let's talk a little about how or what you can do with them. So first let's look at EAS.

An EAS account is a Microsoft ActiveSync push server that pushes email, calendars, and address book to the user, or any subset of those three. It can also enforce a certain level of security on the device. It can maintain a certain degree of passcode strength. It can maintain a certain iPhone lock that the phone will lock automatically after one minute of idle time, et cetera. And it can also issue a remote wipe command to the phone. So if the phone is lost, you can remotely wipe it from the server. Next, we have passcode restrictions.

Passcode restrictions allow you to configure a similar set of restrictions, passcode requirements, without actually using an EAS server. So it's the same passcode quality, passcode expiration, et cetera. They are applied in conjunction with your EAS settings. And therefore the policies will be merged because it's possible that multiple profiles will have different passcode policies specified or they might potentially conflict with an EAS server specified policy. So let's have a look at how this merging works. Let's look at, for instance, example policy A requires at least six characters passcode and the passcode to expire in 30 days.

The policy B, say, comes from a different profile, requires four characters PIN but at least two special characters. So you can see that the policy B requires four characters PIN but at least two special characters PIN. So you can see that the policy B requires four characters PIN but at least two special characters PIN but at least two special characters PIN but at least two special characters characters. So the synthesized policy for all of this together is six characters, minimum two of them are complex, and the whole passcode will expire in 30 days. And this can be basically extended to infinity.

Next, credentials or certificates. So what are certificates used for? Well, first, what are they? You can either install them onto the phone as a raw PKCS file or packaged in one of those configuration profiles. There are some advantages to both. We'll be talking about that later. Organizations can install their own signing certificates, root certificates on the device and then in turn use those root certificates to sign their own configuration profiles.

Like in the graph here, we see that the The first package to be installed on the phone would be a PKCS1 certificate and then all the other profiles would be signed with that certificate. Also, a VPN profile can be using an identity certificate for Cisco VPN, for instance.

And we'll be talking about that a little bit later in greater detail. The next thing to be configured with a configuration profile is VPN. VPN is a fairly simple thing. We support a number of protocols. And now and new on iPhone 2.0, we also support IPsecs for Cisco, which uses certificates.

Wi-Fi settings are a somewhat more complicated example. I mean, when you look at the list, you know what those things are. We can configure visible or hidden networks, the good old standard web, WPA networks, or the new 802.1x, WPA2 enterprise Wi-Fi networks. This is actually an example of something that can be configured only via profile. There is no user interface to do this on the phone itself, because the user interface would be way too clumsy, and we don't expect normal people to be actually able to understand and enter those values. So you deliver that only via profile.

Next thing are application access restrictions, also known as parental controls. Probably not necessarily used for your teenagers in the enterprise environment, but still it can be interesting for an IT department to disallow the use of certain applications such as YouTube, Safari, iTunes Music Store, or very interesting, the installation of third-party applications. You can also--this allowed access to explicit media on the iPod application. Again, probably not very interesting in an IT environment.

Next, mail settings is one of the most common things that you might want to configure on a phone. You can create a complete configuration or just a subset of those very common settings like protocol, host, account name, authentication scheme, whether to use SSL or not. What's interesting for you as IT people, you can create a template of a given subset, basically not the account name.

And then you can distribute it to your whole organization, to a thousand people. And the people, when they're installing that profile, will be prompted for username, password, etc., for the missing pieces. So you can have one very generic profile that will serve a large number of people and is very easy to use.

Now finally, APN settings. What is APN? You either know what APN is or you will never need to know. It's like basically Wi-Fi except it goes via cell phone cellular technology, typically used by very large corporations who want to route their edge data via their own stations. And so we have a means to incorporate that, to configure that. That's also one of those examples that can only be done by configuration profiles, not on the phone directly.

The content of the profiles is quite flexible. You can configure in a profile either any single of those components that I was talking about before or virtually any combination of those settings. This is very convenient, but it also can be used for what I call the carrot and stick approach. I give you access to, say, my VPN, to my Wi-Fi network, but I will also make you abide by my rules, by my passcode policies, by my device lock policies.

So let's look at an example of carrot and stick. So the carrot is you give the user access to a certificate-based VPN, which is very user-friendly, very modern. You can also give them access to your WPA2 enterprise network. On the other hand, you enforce passcode quality, you enforce locking, that the phone will lock itself after one minute of idle time. You disallow installation of third-party applications, which might potentially interfere with what you want your company-owned phone not to be doing.

There are some restrictions about content of profiles. Each profile can contain only one of passcode policy, application access and EAS. EAS actually, on an iPhone 2.0, we can have only one EAS account globally. So if you set up an EAS account manually, you cannot also install a profile that will also specify an EAS account and vice versa.

The passcode policy and application access kind of make sense that in one profile, you cannot have two different ones because that would be kind of not really making sense. But you can have two different profiles that will both specify a passcode policy and an application access policy and we will merge them as in the previous example that I've already shown.

Really important to know is that profiles are all or nothing. You cannot cherry pick what you want. Either all settings will get installed or none of them will get installed. Removal is equally atomic. Either everything gets removed or nothing gets removed. So when the user goes through the install process--and we will see that later in the demo-- Sometimes there is no questions to be asked and we expect the installation to succeed and everything gets nicely installed.

Other times the user first needs to go through, answer a few questions because you omitted the user name or the password in the profile and maybe you need to comply with a new password policy. If the user just stops and doesn't want to have any of that, well then the profile as a whole did not get installed.

So what about signing? What about verification? There's three types of profiles that you will see during the installation process. And again, we're going to see that in the demo later on. It is not required that profiles be signed. So you can have totally unsigned profiles installed on the phone. And that's in the last example, the unsigned. The user knows, hey, this could be anything. This could be coming from a not well known source.

Or you can have a profile that is signed, but then is it signed and traceable to a well known root authority? That's the difference between verified and not verified. So if we can trace-- Assigning to a well-known root authority, we're going to say it's verified. If not, we're going to say it is signed, but I cannot verify that it really comes from whoever claims it to be.

And for it to be verified, it has to be traceable to one of the roughly 600 pre-installed certificates on the device. It's the same certificates as on OS X. We keep updating them in software updates. And there's a way for an organization to install their own signing certificate on the device, as I mentioned earlier. PKC is one or packaged in a profile. And then all of the subsequent profiles that the user will be installing will be shown as verified.

What about the security? This time profiles are not encrypted. So if somebody intercepts a profile, they're going to see a nice XML file. You can sign them to avoid tampering. If you sign a profile, even if you sign it with a self-signed certificate and it's not traceable, it's not verified, it cannot be tampered with. Nobody can change any fields in it. We will always refuse to install a profile that has been tampered with.

Some properties are obfuscated. They're not encrypted, they're obfuscated. This will--the average snooper who intercepts one of those profiles in email cannot really do much with it, but it is definitely not something to deter the hacker. Therefore, you should never fill in sensitive data like passwords or maybe even usernames if you don't want to hand out Steve Jobs' email address.

What are some of the caveats? Currently, there is no dependency analysis when removing a profile. So, what that means is that removing one profile can render another one potentially useless. Imagine that you have installed one profile that contains a certificate, an identity certificate, which is then used by a Wi-Fi configuration that's installed in a different profile. If you remove the first profile that has installed that identity and you remove it, that identity is gone and the Wi-Fi profile is now kind of worthless.

Also, we have no conflict resolution. What that means is that if you install, say, a Wi-Fi configuration that calls your network "my network" and another profile would try to install another Wi-Fi configuration that also calls "my network," this will fail. And the whole payload, the whole profile will fail to install.

Passcode policies and application access policies are the only exceptions, as I already talked before. We expect those to be potentially conflicting and we have a resolution engine there. The other restriction is there's no expiration date. That's both a feature and a caveat, I guess. They live forever until the user deletes them. You have no way of revoking them. And so keep that in mind.

Profile format itself is a straightforward XML. It uses the same DTD as all pay lists on OS X. It is a very simple file format with lots of repeating or consistent properties that we'll see that later in the demo. The specification for the XML profile will be available by the time this product ships. As a matter of fact, I think I saw it today going through the intranet's tubing at Apple, the final document, so I think we're getting really, really close. And again, you're going to see soon a short demo of the format. So how do we create profiles?

You have basically two ways of creating a profile. We have, on one hand, the iPhone configuration utility. It runs on Mac OS X Leopard and, you know, features the full experience of OS X. And there's the alternative, the iPhone configuration utility for the web, which is browser-based and can be run basically on any machine.

First, OS X, iPhone Configuration Utility, serves as a curator for Configuration Provisioning Profiles. It manages all the profiles that you might have for different departments, say, also for Provisioning Profiles, but we're not gonna be talking about those here. It can create Configuration Profiles and also sign them, obviously. And it also allows you to view console logs for iPhones and iPod Touches. So if some user has some problems with it, you can plug it in there, see the console log, and potentially file a bug or do some troubleshooting of your own.

The iPhone configuration utility for the web is totally browser-based. It requires Ruby, SQLite to be installed on the machine running it, and also .NET if it's running on XP. It does not perform any kind of device management. There's no provisioning profile stuff in it. There's no way to look at the console logs, et cetera. However, it is command line driven as an option, so you can actually issue commands to it and have it create things for you.

So after all this talk, I would like to invite on stage Ron and followed by Hernán, and they're going to give you a demo of iPhone configuration utility. Actually, you're cooking on the demo. Thanks, Dan. I still like this. Okay. Up on the demo machine here, we can see we have iPhone Configuration Utility, or IPCU, as we normally call it.

And as Stan mentioned, there's a lot of stuff that iPhone Configuration Utility can do. We keep track of all the devices that you've plugged into this computer. We can also install applications and provisioning profiles. But as Stan also mentioned, this session isn't about any of that. So we'll jump over to configuration profiles here. Okay.

So we have this iTunes-style UI where we have the general restrictions, passcode, Wi-Fi, tabs for VPN, email, exchange, credentials advanced, all these tabs. I'll just go through these one by one to show you some of the things in them and how they relate to the configuration profiles that Stan just described.

So the first thing we have here, if we create a new configuration profile, We can name it. So, "Profile from Ron." This is the name that you'll see--that your users will see when they install this configuration profile on their iPhones so that they can see that this is a profile from Ron and--oops--and know a little bit about who this came from.

Here in the identifier field, you can see we have this little red circle with the arrow in it that indicates this is a required field. This is what you need--this needs to be filled in in order for this configuration profile to be installed. And the identifier is really just that. It's just a unique identifier for just this configuration profile.

And it's used to prevent overwriting other settings from another configuration profile with the same name. So you could name them whatever you want, but you should really use these identifiers to keep configuration profiles unique. You can also use this instead of preventing overwriting of settings, you can use this to intentionally overwrite old settings from older configuration profiles. So just something to keep in mind that this identifier is really important.

If we look down here, we also have an organization and a description field. And these are optional fields that also-- the text of these also show up on the iPhone when this configuration profile is installed. So your user gets a little bit more information about what this profile will give them and which organization this comes from. So maybe like the East Coast Sales Org. and from Ron. There you go. So from the General tab here-- oop, we should fill that in.

From the General tab here, I'm going to jump over to the Restrictions tab. Here we can see we're presented with this little badged icon that shows we haven't set up any restrictions yet. So we can go ahead and configure them by pressing the Configure button. And we get this UI for setting application restrictions, just like what Stan had described earlier.

So all of the same settings are available here in IPCU. Explicit content--or rather, disallowing access to explicit content. You can disable access to YouTube, surfing the web, installing other apps, all of these things. So all of that is available here in IPCU. And the same thing is true for the passcode policies. Here we can add passcode policies to this configuration profile by hitting Configure.

And by pressing this, we've set in this configuration profile that when it's installed on a user's iPhone, the user will be prompted for a passcode so that you'll require a passcode on their device. We can even set things like the quality of the passcode by specifying allow sample value, requiring the number of characters, alphanumeric values, all of these settings, passcode age and days, the amount of minutes before it locks. We can even set the number of failed attempts. And check this out, it even goes to 11. Sweet.

So if you're familiar with Exchange ActiveSync-- I did pronounce that right, right? If you're familiar with Exchange ActiveSync settings, these probably look familiar to you. And actually, now that I speak about Exchange, let's jump over to that tab. So here we can configure an Exchange ActiveSync account. Neat. I guess I have to fill in this host name.

And I could set the username here, but I probably don't want to set up one username for all of the people installing this configuration profile. And I'm not going to configure a single profile for every user that I'm going to send this to, a separate, you know, configuration profile. So I can leave this blank. I can leave the user field here blank. And on the iPhone, when this configuration profile is installed, the user will be prompted for the username for his Exchange ActiveSync account name.

And besides Exchange, we can also set up regular old email accounts, as you can see here. Go ahead and hit Configure. We can configure both IMAP and POP accounts, set the email address and account name. And again, we can leave these blank and leave it up to the user to fill these in at install time. We can set up the mail server, another required field here, even set up using SSL for incoming and outgoing mail. And while we're on the topic of SSL and security, let's jump over to the Credentials tab.

So Stan mentioned credentials as dealing with certificates on the iPhone. And here you can -- let me back up a second. You can install certificates certainly directly onto the iPhone via Web delivery or as e-mail. But you can also embed them inside of configuration profiles. And here is how you can embed them using IPCU into this configuration profile. We just hit the configure button and we get this dialogue, and we can choose any certificates we want to embed. So for this one, let's add first our root certificate for our company.

Cool. Actually, you see here we have these little plus and minus buttons. Go and add another certificate. Let's see, we have Johnny Appleseed P12. This is actually an identity certificate, so we can add that as well. We have both kinds. We have both kinds. So now we have these certificates in here, but what good are they? What can we do with them? Well, we'll jump over to the Wi-Fi tab and I'll show you.

Here we'll configure Wi-Fi settings for this configuration profile so that all of our users can get access to our Wi-Fi networks. So we can configure the SSID for, you know, all of our access points. We can configure multiple Wi-Fi settings in a single configuration profile here. We'll just go ahead and do the one for this--for right now, though. And we can also set the security type.

Here you're probably familiar with the existing WEP, WPA. And of course, with iPhone 2, we get WEP Enterprise and WPA Enterprise. If we choose one, we see all of the geeky settings that we could set that we really wouldn't want our end users to ever set on the iPhone. I mean, TLS, Leap, TTLS, EAP. Sweet. EAP Fast. That's the best one. It's fast. And then for authentication, though, this is what I really wanted to show you.

Check it out. We can do identity-based certificates--identity-based authentication here by choosing the certificate name that we set up in the Credentials tab. So this makes it really easy to set up really easy Wi-Fi access for our end users by embedding the certificates and then configuring our Wi-Fi to use that certificate for authentication. And we can do the same thing for our trust settings, where we have our root CA cert here available as one of the trusted certificates for this Wi-Fi setup.

And we can do something similar here for the VPN tab. We'll configure a VPN setting. Again, we have the plus and minus buttons that show we can add multiple VPN settings. And we see the familiar L2TP and PPTP. And now we have the IPSec, Cisco flavor IPSec settings. Again, the optional account name, the required server name.

You see here we have the shared secret that we could fill in. Something you should know, I think Stan actually mentioned this. We'll put in--we can put in shared secret information into this configuration profile. And it's encoded to prevent casual snooping, but it's not encrypted. So if you're worried at all about sharing your shared secret, then you can leave this out. And it'd probably be better to switch over to certificate-based authentication anyway, where you can, again, choose the identity that you want for authentication.

So let's see, we've gone over restrictions, passcode, Wi-Fi. Have I missed any of these? Have I missed any of these? Let's see what's under the Advanced tab. Let's see. APN. I actually don't know what that is, so let's get rid of that. So here, of course, is where you would set up the APN settings for your configuration profile if you're sure you want to do that. Be careful.

That's very dangerous, I've been told. So if we go back, we've set up all these things for our configuration profile so that we can enforce our security policies for our users using the stick and also provide them with the carrot of access to our Wi-Fi and VPN networks and setting up their email and exchange accounts. Now we want to go... Oh, wait. We should actually sign this first.

I want to make sure that our users can trust that this configuration profile actually comes from our company. So, IPCU allows you to sign configuration profiles. We could leave it as unsigned, but here I'll show you what it looks like to sign one. In our UI here, we can choose one or more certificates to sign with. We'll just choose this one, the Profiles Signing Certificate.

And we also need a private key file to sign with. So we'll go ahead and choose our signingkey.pem file. Open that up and hit the Sign button. And here you can see all of the text fields, all of the input fields for all of these payloads have gone to non-editable. And we have the cool little signed badge here to let us know that this is a signed configuration profile and we can't accidentally go off and edit it and invalidate it and make it invalid to install on an iPhone.

Of course, if we want to actually go back and make changes, we can easily remove the signature. We're warned that this will mean you'll have to re-sign it again if you really want to install a signed configuration profile. Go ahead and remove the signature, make any of the changes we want, go back and sign it again.

Once we have the configuration profile set up, we can export it. and export it either to our in-house web server or export it and send it over to mail and share directly via mail. So that's a quick tour of some of the things that you can do with IPCU and configuring configuration profiles. And I'd like to ask Hernán to come up and introduce you to iPhone Configuration Utility for the Web. Thank you very much, Ron.

Good afternoon, everybody. Ron did such a great job that actually what I have to do is very little to show you that the iPhone Configuration Utility, IPCU for the web, was designed based on the one for Mac OS X in order to simplify the transition between the two. So whenever you have to use the web tool, you will feel right at home. You can start by creating a profile from scratch or you can just import one that you already have. In this case, I have already done that, as you can see.

So I have all the information for the demo. When you import a profile, you would do this because either you want to change it so that you can redeploy it by updating it, and in that case, as Ron has mentioned, make sure that the identifier in the general tab remains the same.

So then the phone, when the user is installing the profile, will find the one that's already installed, remove it, and replace it with this one. If you want to create a new one but you don't want to start from scratch, make sure that you change this. So very similar to what we have on Mac OS X, you can specify restrictions. In this case, I'm disallowing explicit content and YouTube.

You can see the password policy for the device. I have created, in this case, two Wi-Fi networks. One is hidden and it will be much-- it's using WEP enterprise security, so fewer people will be able to access it. But... You can also create, in this case, a second Wi-Fi. Let me remove this one. Sorry. That is not hidden and everybody in your organization can access.

VPN. I have created three, one for each type that is supported. We have the first one is IPC, SEC, Cisco, followed by a PPTP VPN and an L2TP VPN. They all have specifying--they are all specifying different authorization mechanisms and even encryption levels. As you will notice, I also left some information out, like the account name, and the phone will prompt the user during installation for this information. As we mentioned before, this is so that you can distribute the same profile to multiple people.

Two email accounts, IMAP and POP. Again, leaving some information. and an exchange account, your corporate exchange account. I haven't specified the user or the email. And again, the phone will prompt for this information during installation. I will show you later in the second demo. Finally, we have credentials. In this case, it's a PKCS12 package.

It's not being used by Wi-Fi or VPN, but maybe some other applications use it or some other profile, and you can install it. So let's say that I'm happy with the configuration profile as it is. You can go back to general and sign it. In this case, I already have the signing certificate and the private key used for signing.

Once the profile is signed, the only thing that is left is to deliver it to your users. You can either export it, and in this case it will be automatically saved to your downloads folder, so that then you can move it over to a web server where it's going to be available for distribution, or from there you can use your back-end system to send it by email.

And again, similar to IPCU or Mac OS X, you can email it from the tool to one or multiple users. So as you can see, the tool feels very much the same as the desktop application. It behaves in the same way, so we hope that you will be able to move between them based on your needs and it will work. Before I return the presentation to Stan, let me quickly show you The configuration profile, how it looks like. In this case, it's a profile that is setting up an exchange account. First, here.

A passcode policy, second. And at the bottom we have what maps to the general tab, which is a description for the profile itself. As Stan mentioned, the description for each one of these sections can be split into two parts. One that is common, that you need to specify for all of them, and another one that is specific to each one of the payloads. So in this case, I've used black to highlight the parts that are shared between all of them.

So for example, if we look here at the root level, we have a description, we have a display name, the payload identifier, etc. I have an ID, a version. We go back up to the description for the passcode policy. And again, description, display name, etc. Finally, we have the same for the exchange account.

Using different colors, I have also highlighted the parts that are specific to the profiles--I'm sorry, to the payloads. For the exchange account, we need to specify the host. We need to specify whether it uses SSL or not, and in this case also the username. In the case of the passcode policy, we'll say what is the minimum length for the passcode that is going to be installed, then the user needs to set how long it's going to last, whether it needs to--the user needs to use alphanumeric characters in the passcode.

Some of these key value pairs are obligatory. You need to set them. Otherwise, the profile will be considered invalid and we will tell you that--we'll tell that to the user during installation. And the other ones are optional. Now, some of them you can leave out so that the phone will ask for information during installation. The other ones, if you leave them out, we will assume that they are not needed. For example, in the case here of the passcode policy, if you leave out required alphanumeric, we will assume that it's not required, as if you had set it to false.

All the information about which ones are required and which ones are not, which ones the user--sorry, the phone will prompt the user for will be available in this documentation that Stan mentioned before. So as you can see, this is pretty simple. Anybody that is familiar with Microsoft S10 with PLIS will feel right at home editing this, creating tools for this. And if you're not familiar, if you're familiar with XML, you will find the documentation for PLIS in developer.apple.com, and you will basically learn this in five minutes. So with that, let me return the presentation to Stan. All right.

So we have now seen how to create the profiles, both via the OS X Leopard and the web-based utility. What I would like to repeat, which we have not shown in the demo, is that the IPCU web is actually also command line driven or command driven. So you can have it sitting somewhere on a server and issue commands to it.

And it can spit out configuration profiles for you, so that if you want to have more individualized ones than just generic templates. And the documentation will be also talking about how to do that. Now, profile deployment. Now you have created the profile. Now you want to get it to the people.

We basically offer two ways of-- No, I don't have a phone. We offer basically two ways of distributing profiles. One is via the web, and one is via email. The first one is via the web. Let's say your organization has created a nice web user interface. The user can go and click on that little button, and the whole install process that we'll get into in greater detail later will begin.

This is useful for when you're distributing to a large pool of people, potentially unknown people. Say you're in a university or organization, and you want to just tell everybody, hey, go and install those profiles. Remember, profiles are not encrypted. They're somewhat obfuscated. Do not put really, really sensitive data into those profiles. Have the users enter them on the phone and deliver that out of line in a different way. Potentially use password-protected website for download. Use throwaway passwords, whatever you want.

You can also distribute the URL via SMS so that typically entering a URL is not a very fun thing to do anywhere, and people make several mistakes. You can send them the SMS. You just click on it, and you get directed to that website. Also remember that if you want to distribute profiles via the web, you need to set a special MIME type. That looks like that. Again, the documentation will be talking about that.

The alternative to that is delivery via email. This is especially intended for more personalized profiles when you not want to send it to 10,000 people in your organization. It's a more active way of distributing it. The user does not have to go and enter a URL. He just can attach .mobileconfig or multiple of those into a file and send it off into an email and send it off to the user.

The advantage of that is The user's mailbox is cached on the phone, and so if the user for whichever reason needs to reinstall the profile, he just can go back to the mailbox and click on the attachment and start from scratch. On the other hand, remember it is not real push.

So even though it will get pushed into the user's email account, he still needs to go and click on it and go through the installation so it's not forced on them. Um, Also, this might cause a chicken and egg problem because what if the user doesn't have an email account, you don't want to send it to their whatever third party email address, so this might not be so suitable. But it's an alternative.

So what I expected here. So next thing, profile backup and migration. Weren't the--? Excuse us. No, this is--okay. Somehow this slide moved. So further topic that doesn't really fit in here is profile backup and migration. Profiles are backed up for you. Each time when you connect your iPhone to iTunes, it will do its syncing, it will upload new music and it backs up the settings of the phone.

The same applies for all the managed configuration settings. So whatever you have installed, whichever profiles you have installed, certificates and all that, that will get backed up. If you need to wipe your phone for whichever reason, you know, there's the reset all settings and whatnot, and you sync it back with your Mac, it will be preserved.

However, there's no migration. So if you drop your phone in the river, you buy a new one, plug it in, your music and other media content will get migrated. Your managed configuration settings or certificates, your keychain, et cetera, will not get transferred. You have to go back to the web server, receive that email again, reinstall it.

That's a security feature because we don't want, in the open cubicle landscape where anybody can go and just plug into your co-workers' computer and simply get their stuff. So now with that, we're going to have a small guided tour of the installation experience. I'll give back to Hernán.

We have talked a lot about configuration profiles, the format, how to create them. So we thought it would be interesting to show you how the user would interface with them, how on the phone they would be able to receive them, look at them, what are the contents, install them and remove them, what would happen when these things take place. Also at the end, we have a little clip of how we prevent configuration that has been signed but has been altered afterwards from being installed on the phone.

We thought of coming up with a presentation that you would see with the simulator. Unfortunately, our code doesn't work on the same, so we have recorded some videos and I will talk to them. The idea is that I'm going to first install a root certificate that is going to be used later on by the second profile to verify its signature. For demo purposes, the certificate is just raw data because we want to show you what happens when a user receives such a certificate.

But ideally what you would do is put it in the profile, sign it, and even if you sign it with a certificate that we cannot trace back to a known authority, at least you will know that what the user is installing is what you sent him. It has not been tampered with. Much better would be if you actually sign it with a certificate that can be traced back to one of those 600 certificates that Stan mentioned.

And therefore we are going to tell the user, and you will see how prominent we say whether a profile has been signed or not. This will give the user peace of mind and they would install without any problems. So let's go ahead. Let me show you. For this demo, I've chosen mail as a delivery mechanism. And this is an email that one of your users could receive where you explain what's in the contents and what are the steps that they need to follow to configure their phone. The first one is to install the root certificate. The first attachment.

You tell them they will be taken back here and they need to look for the second certificate. I'm sorry, the second profile, which is at the bottom of the email. In this case, I've also included information about the passwords that would be asked during installation. You may want to use other means for that. So let's go ahead and tap on the first attachment, the root certificate, and the user would immediately be taken to settings.

As you can see, we've taken a root certificate and created a profile on the fly. The idea for this is that the user can later on find this on the phone in settings. They can look at the contents and they can actually remove it too. This is the only interface that we currently have on iPhone 2.0 for removing certificates.

What does all this information mean? At the top, we have the name of the profile followed by the name of the organization that sent it. Very big in red letters, we say, this has not been verified. So the user knows so. In the middle of the screen, we have a description.

As Ron mentioned, you could have here, you could be repeating some information you have in your website or on the email to give context to user while he's installing or about to install a profile. The data was received, which becomes the data has been installed and is useful, and what it contains. In this case, just a root certificate. If the user decides he can actually get more information on the profile by going into more details.

Again, just the root certificate as we expected. We have name, when it was issued, when it's going to be expired and who issued it. Furthermore, mostly probably for you, the creators of profiles or some more technical users, you can tap on this button and we are going to show you all the gory details of the certificate, whether it's a PKCS1 or a PKCS12 package. And basically, this is the information that is available to users on Mac OS X Desktop on the Keychain Access application. So, let's go back out to the install screen. I can show you what happens during installation of a simple profile.

The user would tap the Install button, the only one there, and we will ask for a confirmation. This is the only time that we ask for confirmation for installation. So given that we were not able to verify the signature in the profile, we ask--I'm sorry, we tell the user so with a big message, and we suggest that the profiles should not be installed.

You would have told the user that it's okay to install this. So the user would tap the Install Now button and installation would start. In this case, the installation is very short because it's just a PKCS1 certificate. There's no need for user input. So basically, it's done. The root cert is installed on the phone and it's active.

Okay, let's go back. The user from here, basically, tap the Done button and we'll take him back to Mail to continue installation. If it was the only profile, he can just continue reading email or do whatever he wants. Before installing the second profile, let me show you a springboard where we have Safari and YouTube in particular available. And I want you to pay attention to those because they're going to be removed using restrictions in a minute. So we go back to mail, look for the second attachment, profile. The user would tap on it, and once again, he will be taken to settings.

In this case, the profile was able to be verified thanks to the root certificate that just got installed. We know who signed it and we display that to the user. And as you can see from the contains section, this is a much more elaborate and much more interesting profile. We have restrictions, CBP and service and exchange account, and an identity certificate. Let's look a little bit more into the details of those.

In actuality, we call it an identity certificate. It's actually a PKCS 12 package, which is password encrypted. So we cannot yet display the information for it. Once it's installed on the phone, we will. We have the exchange account, we have a server and an email address, in this case it's available.

We have the three VPN settings for Cupertino. We have Los Angeles and Oakland. And at the bottom, the user can see what are the restrictions that are going to be enforced on the device. In this case, removing, as I mentioned, Safari and YouTube. Again, as Stan mentioned, the carrot and stick.

Let's go ahead and install the profile. Once again, we tap the Install button. And in this case, given that we were able to verify the signature used for the profile, we can suggest to the user that the default action has to be installed. It's okay to install, so go ahead.

The user will tap there, the installation starts, and in this case, the phone detects there is some information that is missing in order to fully install and activate this profile. The first thing that it found is that we need the password for the Exchange account. We use this in order to go out to the network and validate all the account information.

and later on to validate password policies from Exchange. So the user will type in the password for his Exchange account. We will go out to the network and verify that it's correct. If it is not, we give the user a chance of retyping it or in the case of being offline, just move it on.

The second question is the password that we need in order to decrypt the PKCS12 package. Again, and you will see it's the same password. The user will type it, will verify that it's correct by decrypting the memory but not installing it yet. And the same is true for the Exchange account. Nothing has been installed yet.

The final question is after talking to the Exchange server, we get a request for enforcing a passcode policy on the device. Without this, Exchange will not give us any data, emails, calendar information. It needs to be seven or more characters and numbers with one special character. So the user needs to type this in twice to verify it, like any passcode.

And we won't let the installation finish until we get a suitable passcode. As you can see, there's also always the ability to cancel installation and nothing will be installed on the phone. So we're done. It's installing. It's laying out all the accounts, VPN services, et cetera. And it's also immediately activating them so that the user can take advantage of them.

Before verifying this, let me show you that you are able to now see the contents of the PKCS12 package. Again, at the high level. And if you want all the gory details, they are there for you to see, too. Okay, now the user will again tap done and we take him back to mail. The user had to come originally from Safari, we'll take him there too.

Given that we're here, let's first verify email information. Let's see what came down from the Exchange server. First thing that we see is that now we have multiple accounts. We didn't have that before. There's an exchange account. All the mailboxes have been downloaded. And for the inbox, I already have--or the user already has--emails for it.

Go to Springboard for a second and please take notice that both YouTube and Safari are gone. There's no way to use them anymore because of the restriction coming from the profile. We go into Calendar. All the events have come down from the server and of course all the calendars too.

The final piece of the Exchange equation is contact information. We go to the phone, see that we have all the contacts coming from Exchange. In this case, the user didn't have any groups, but otherwise they would be there, and you can also--he would be able to search the Exchange directory from here.

Let's go back into settings so we can see the rest of the things that got installed. First, in Mail Contacts and Calendars, we're going to find the Exchange account, which we know that it's there already. But what I want to highlight is that the account can no longer be removed.

It cannot longer be deleted because it has been installed by a profile and it's under its control. We do let the user change the amount of information that gets synced at any given time because given that it's a mobile device, he could be in different places with different connection speeds and availability. So he may want to change this.

But on the other hand, once we get into account information, You'll see that most of it has been disabled. We don't want the user tampering with this by mistake or on purpose. Again, because it's coming from a profile. We do let the user change the password because it could change on the server. And we do let the user change the description because maybe, you know, he doesn't like Office Exchange as the name of the account.

Okay, let's now go into general and first stop in networking. Here we have a VPN. Now it's not connected, but they are configured. Once again, the user will not be able to remove these VPNs unless the profile is removed and can select whichever one he needs to use at a given time and enable it.

As you can see, the passcode lock is enabled and it cannot be removed. Again, because in this case, for the profile, the Exchange account requested this. The user can change it and we are going to enforce the quality of the passcode. In this case, just based on Exchange, but it could also include any other profiles that specify passcode policy.

You can also see restrictions are on. Safari and YouTube have been disabled. And in this case, the restrictions are completely under the control of profiles. The user cannot change anything here at all. Finally, at the bottom of the section, we now have profiles where the user can tap and see what profiles have been installed on his phone.

In this case, we just have two. The root certificate was first and then the configuration. The user can go in here to see details about them. And more importantly, the user can come here to remove them. And this is actually the only place where they can come to remove a profile.

Let's see what happens when we remove a profile. First, again, there's only one button the user will tap there. We will prompt for a confirmation. And in this case, given that there's a passcode already set on the device, we're going to ask for it because we want to make sure that only the phone's owner will be able to remove a profile. The same would have been true for the installation, but there was no passcode set on the phone at the time.

That's okay, and we are removing--at this point, we are removing all the data and all the accounts, all the restrictions and the profile itself. There's no such concept of a profile that is sort of disabled but still on the device. It's either installed and effective or not. The restrictions, as you can see, have been removed and now they're under user control. The passcode we leave on. We leave the passcode there for security reasons, but it can be turned off and it can be changed. And in this case, given there are no longer any restrictions on it, do anything, basically.

Last, VPN is no longer configured. We've got rid of all of them. As you can expect, the Exchange account is gone, so I'm not going to go in there. Let's just verify in the different applications that the data is also gone. First, contacts, no more--no longer there, no groups. Calendars, all my events--all the user events are gone.

And finally, if we go into mail, We can see that there's only just the Gmail account. The Exchange account is no longer there. So basically, after a profile is installed, everything in it will be enabled and active. After it's removed, the profile itself and all of its contents will be removed from the device.

To finish this tool demo of the UI, let me show you what happens when the user receives an email with a profile. The profile has been signed, but the contents have been altered after signing, maybe by a man-in-the-middle attack. So the user goes on and taps on this without knowing what had happened. We immediately check the signature, compare that with the content, and we detect that it's invalid. And we don't let the user move on and try to install or anything. We just don't give them the option. With that, I finish my presentation. Back to Stan.

So now that we have seen how profiles can be deployed, let's talk about some best practices. Please remember that you can have multiple profiles, and that you should actually be using this capability for the good of your security and of the user. So a profile can incorporate identity credentials.

Another profile can then leverage those credentials and use them. And the iPhone will prompt for any information that was potentially omitted in it. What Hernan has shown in his walkthrough, you saw that the first thing that he installed was a raw PKCS1 file. That was the root certificate.

And that itself showed as not signed. What you could do instead is package that PKCS1 file in a profile using IPCU. Sign that with something that is traceable to one of those 600 root authorities. And therefore, have the entire workflow for the user be always verified so that it is possible to have a workflow or user experience that is totally certified and every single thing that they receive on the phone is totally trusted as coming from you.

So an example of that would be: First, deploy corporate root certificate, be it via PKCS1 file, which then again in itself is not trusted, or packaged in and signed with something that you got from VeriSign, for example. Distribute a second profile, which has a generic email or EIS account template.

Without the username, without any passwords, and the user will be prompted to enter these. Certificate-based VPN, Wi-Fi configuration, stuff that we have seen, and security policies, caret and stick. It's all or nothing. Then the third profile, give it something to your sales organization or to your VPs or whatever, some really high-profile server, and now you have even more draconian access restrictions, passcode policies.

For web distribution, place it potentially on a password-protected website. Use throwaway passwords. Remember, the contents are not encrypted, they're just obfuscated. Signed profiles are tamper-proof. The user or the man in the middle can still see what's in the profile, therefore don't put secrets in them. However, it will not be installed, no matter what. So you can really trust that when you sign something, it's that or nothing.

Ron and Hernan have stressed before the importance of the identifier. The root identifier, each individual payload within the profile has its own identifier. But we're talking about a root identifier. The profile identifier determines whether when a new profile is installed, whether it will be added to the list of profiles installed on the phone or whether it will replace a profile that is already installed on the phone. So be really careful how you choose those profile identifiers.

Currently, there is no way to push the profiles to the user. The user always has to go either to a website and click on it and then go install and all that or not. You cannot really force a user to install a profile. You do it, again, via the carrot and stick approach. You want the phone to be really useful to you, you have to install it.

In summary, the profiles are intended to simplify iPhone and iPod touch configuration. Remember, there are certain aspects of the phone that can be only configured by profiles. APN is an example that can be only configured that way. Also, a lot of VPN and Wi-Fi, like the whole 802.1X Wi-Fi network can be only configured by profiles because you saw the UI on a desktop, it's pretty complicated. We did not want to incorporate that into the phone.

You have utilities available for creating the profiles. You have an OS X native application, you have a web-based tool that can also be driven via commands. So, you also have an XML description, format description, or will have. You can then distribute the profiles via web or email. And remember to consider security when creating templates. Put in as much information as needed, but only as much as necessary. Also, by omitting some information, you can make a profile much more generically usable throughout your company.

Related sessions, if you have Time Machine, you can go back to earlier today and attend those two sessions. More importantly, tomorrow morning at 10:30, we have a lab. We don't have a slide for it because we forgot about it. Tomorrow morning at 10:30, one of the labs is our lab about profiles. Mark, do you by any chance know which lab? In the IT lab, obviously. So 10:30 you can come and bug us with questions for an hour. You can also bug Mark Malone. That's his email address.