My name is Tommy Hann. I'm a Consulting Engineer and had been focusing for the past few years primarily on 802.1X and Wireless. Before we get started, I kind of like to get an idea of who's in the audience. How many people here have already implemented 802.1X? OK, good. How many people are working towards implementing 802.1X? Excellent. So one more question, how many people have implemented 802.1X over a wired network? There we go [laughs] successfully. Very good, OK good.

This will be a good grade for the session. So why 802.1X? Why do we care about 802.1X? Well first of all, 802.1X is port based network acces controller think of it as authenticating to get on to your network. But why is so popular? Well as it turns out, the Wi-Fi alliance requires 802.1X for enterprise wireless security.

And as a result, 802.1X is very, very common place or becoming very common place in the market But then the question always comes up, well why 802.1X? Can't we use WPA or WPA2, PSK or WPA personal? You know isn't that secure? Well yes, WPA and WPA2 are very secure.

However, with any PSK technology, you have a single password that protects your network. So that password is compromised n some way, you then have to change it, you know, when all your machines, all your access points, or your switches, et cetera. So the point is that 802.1X actually provides individual authentication to the network.

Now that by individual, that could be user credentials, it could be machine credentials but it offers the ability for each individual entity to have their own credentials to the networks. So that, if that-- if those credentials are compromised, well then it's really easy to change it just for that one user. Now I'm saying kind of implied with the question, 802.1X is not just a wireless-- are used on for wireless security. It can also be used on ethernet as well.

So what were-- what Apple has done is we've implemented a Supplicant, an 802.1X supplement-- Supplicant in Mac OS X and in the iPhone OS. In addition, the back-- the back end component server for 802.1X is typically RADIUS. So Apple has also implemented RADIUS in our Mac OS X server offering.

So here's what we're going to cover today. We'll start out with a quick introduction to 802.1X, just to make sure everybody is kind of on the same level playing field. We'll talk briefly about the RADIUS of service built-in to Mac OS X server. Then we'll talk about configuring of-- configuring 802.1X both for Mac OS X and for the iPhone OS. We'll talk about deployment strategies. If you've got thousands of machines or thousands of iPod Touch devices, for example, how would you go about deploying those with 802.1X.

And then finally, we'll talk a little bit about trouble shooting, some troubleshooting techniques for 802.1X connections. There will be a couple of demos scattered through out. And then of course we'll have a time for Q&A at the end. Now before we get started, I kind of wanted to throw up architectural slide.

Now understand, this is more conceptual than anything else. The point I wanted to make with this slide though is that 802.1X kind of sits in between TCP/IP Connectivity in your physical interfaces, whether that be ethernet or wireless. Now in reality, again this side is technically correct in reality.

Once you've authenticated, that layer kind of comes out and the connectivity is there. But the point is before you can do anything on the network, you've gotta authenticate via 802.1X. So let's get started with an overview then. So as I said 802.1X is port-based network access control. And by that what I mean is at the point of network attachment. Until you authenticate to the network, the port is not open. You can't do anything on the network. We'll talk a little bit more about that in a few minutes.

Now, the actual authentication is handled via what we call EAP types, Extensible Authentication Protocol. We'll talk in a little bit more depth about that as well. And 802.1X commonly utilizes PKI. So use certificates for both client and server authentication. Again, we'll get into a little bit more detail about that as well. Now when you talk about 802.1X, there are actually three components that are involved.

The client side is called a "Supplicant." So if somebody asks you, does your Supplicant support PEAP or something like that? What they're asking is, does the software, when your client that does 802.1X does it support PEAP? Now on the other end is the authentication server, the authentication server is where the client actually authenticates too. And as I said, the server authenticates to the client in some cases as well, we'll talk about that in just a few minutes. But more commonly, the authentication server is handled with radius.

So radius is the authentication server. And then in the middle is this-- middle-- kind of middle man if you will, called an "Authenticator." And this might be an access point or it might be an ethernet switch and it passes the messages back and forth between the Supplicant and the Authentication Server.

So here's kind of a diagram of how 802.1X would fit in with a wireless connection. So here's a client that wants to attach to an access point to gain access to resources on the network. Initially, the port for access to the network is close. So there's nothing the client can do initially until after it authenticates.

Now during the initial process of associating to the access point, there's a security negotiation that goes on between the supplicant and the access point. And from that negotiation, it's determined that 802.1X will be needed to authenticate to this network. So at that point, an 802.1X authentication session is started. And again, understand that the authentication happens between the client and the authentication server, the authenticator just passes-- passes the messages back and forth.

Now, after a successful authentication, what's called the "Pairwise Master Keys" are determined both at the client side and at the authentication server side. But the authenticator, the access point in this case needs to know what that PMK is. So upon a successful 802.1X authentication, the server passes that PMK to the-- to the access point.

And then during the 4-Way Handshake between the client and the access point, the actual keys to use for inscription are determined. And then at that point, the port is open so now the client has access to the network. You can access other network resources et cetera. So that's kind of how 802.1X plays in a wireless situation.

So we talked about EAP types, I briefly mentioned EAP types. EAP types are what actually perform the actual authentication. There's four kind of really common EAP types. EAP-- starting with EAP-TLS. The idea behind EAP-TLS is that both the client and the server uses a certificate to authenticate to the other. So the client instead of typing any username and password, instead it uses a certificate to authenticate to the server. And then the upset happens as well. The server uses a certificate to authenticate to the client, thus preventing a man in the middle attack.

Now, it's-- it can be difficult to manage lots of certificates if you've got, you know, thousands or even tenths of thousands of clients. So PEAP and TTLS, very similar technologies, instead of using certificates on the client side, they allow for username and password. So from the server side, we still use a certificate but the clients use username and password. That's the idea behind TTLS and PEAP.

And then finally, EAP-MD5, now EAP-MD5 is very common on ethernet. However, MD5 will not work over wireless because it doesn't have the ability to pass that PMK back to the access point. So typically MD5 is what we'll see on an ethernet connection. Now there are others you might run into the next two LEAP and EAP-FAST are both Cisco Technologies.

LEAP actually was around in early days when WEP was the only wireless security protocol we have. And it kind of introduces the concept of individual logins or authentication sessions to the network as supposed to a shared key. Now LEAP is, since then replaced with newer technologies such as TTLS and PEAP or EAP-FAST to get another EAP type developed by Cisco.

And then finally EAP-SIM, EAP-SIM utilizes existing GSM technology, you know, similar to the SIMs in your iPhone's. So these are the EAP types, the things that actually perform the authentication via 802.1X. Now we talked a little bit about PKI, this is actually a pretty big subject. But I just wanted to give you the top level, what's important to understand about PKI in 802.1X.

So as we talk about-- if you use TLS as EAP type, you would use a client side certificate fore the authentication.

So optionally, you know, a client's side certificate can be used. Most of the EAP types also define a server side certificate, so that's another area where PKI is used.

But let's talk about the server side for just a second. If you compare this to a web server for example, a secure web server, the way it's used in 802.1X is slightly different. So in the case of a web server, I type in let's say, you know https.www.example.com and I'm given a certificate form that server, well if within that certificate, I see www.example.com, well I know that because of domain name look ups that I just got to that server and it told me who it was. And I'm pretty sure that that is the server that I thought it was. However, with 802.1X, when I'm authenticating, I'm authenticating to get on the networks.

So I'm on the network yet. I can't do a DNS look up. I can't verify the server that I'm authenticating against is www.example.com or whatever it might be. In addition, there is no way to tie or there's no correlation between the SSID, the wireless network name, and the server that I'm authenticating again.

So really there's no way that the machine by itself can validate the certificate. So as a result, a human has to at some point validate the certificate at least one time. Now that can happen the first time you try to authenticate against this network. Or you might-- if your network administrator supporting, you know, thousands of machines, you might want to pre-trust that certificate upfront.

So whenever you're using PKI from a server certificate perspective with 802.1X, a human has to get involved upfront to trust that certificate. Now, let's talk a little bit more about this explicit trust of certificates. So if you look at a certificate chain, maybe a root, any number of intermediate CAs and then a Leaf Cert, you can trust at any level within that chain. So for example, you might trust the actual RADIUS server.

OK so, whether it be part of a chain that comes directly from the root CA or from an intermediate CA, it doesn't matter. You're trusting the specific server itself. Now if you're in a very large organization and maybe you have multiple RADIUS servers, you know, lots of RADIUS servers, it maybe difficult to trust every one of those, a pre-trust to everyone of those servers.

So another strategy might be to set the trust at the intermediate CA level. And basically what you're saying by doing that is any certificate that's issued by the CA will be trusted for EAP. So when you set trust for EAP on that intermediate, you're saying any certificates issued by that CA-- intermediate CA would then be trusted.

So that's a good strategy maybe for a large organization. Now you could also trust at the root CA level, however, I would warn against this, be very careful with this at least. If for example you were to trust for EAP something like VeriSign or some other well known certificate authority.

Basically, what you've just said is any certificate issued from that certificate authority is going to be trusted, which means anybody can go out and buy a certificate and perform a man in the middle attack. So be careful with that. But I think trusting at the intermediate CA level is probably a good strategy. And of course, we can't trust-- you can't trust a self signed certificate.

So let's kind of look at Wired 802.1X. The idea behind Wired 802.1X is you're protecting an ethernet jack, maybe in a public location. So what you're protecting against is somebody walking into your organization, a business school, whatever, plugging in an ethernet cable and they're on your network. So before they can actually get on your network if it's protected with 802.1X, they have to authenticate to get on to the network. Now this is somewhat challenging when compared to wireless.

If we look back at where 802.1X fit in to the wireless scenario, there is that security negotiation that happened upfront. And through that security negotiation, it was determined that 802.1X was required to get on to this network, to authenticate to the network. With ethernet, you don't have that security negotiation. So there's no way the computer knows that it needs to authenticate to get on to the networks.

So therefore you must basically pre-configure ethernet to know about 802.1X. Now this is actually very similar to another wireless scenario, and that's when you use 802.1X WEP. So you're using 802.1X to authenticate to the wireless network, but then you're using WEP for inscription. And the thing is during that security negotiation that happens up front, the computer can't tell the difference between plain old WEP and 802.1X WEP. So the computer again doesn't know that it needs to perform that 802.1X authentication, so it kind of a similar situation in wireless. Now what we see quite often in conjunction with 802.1X, and this is over wired or wireless, we see Dynamic VLAN switching.

And the idea behind that is when you authenticate to get on the network, depending on what credentials you use to authenticate, you maybe put into one VLAN or a different VLAN. So for example in a school environment, if a student were to authenticate via 802.1X, that machine maybe put into a student VLAN that has access to their work, you know, their student server et cetera. But if a teacher or an administrator were to authenticate based on those credentials, the machine would be put in to a different VLAN that might have access to different resources. So we think quite often Dynamic VLAN switching used in conjunction with 802.1X.

OK, so let's talk about Apple's implementation of 802.1X. That's kind of an overview now let's talk about how Apple's implemented it, and starting out with Mac OS X server. As I talked about previously, the back end, the authentication servers typically implemented with RADIUS. And as part of Mac OS X server, specifically in this case, Snow Leopard, we've implemented a FreeRADIUS version 2.1.3.

A very, very powerful open source RADIUS implementation, full featured, really a nice implementation of RADIUS. However, with our GUI that we've put on top of this, you can literally implement the server in five minutes. It's pretty incredible how easy it is to set up such a powerful server.

In addition, we've integrated directory services to a-- to the RADIUS process. What I mean by that is the RADIUS server understands how to look up in directory services whatever user or a computer might be trying to authenticate. So you don't have to retype all of your users that are already in Open Directory or active directory.

You don't have to retype all those users and put them in the RADIUS server instead it just knows how to look that up through the Open Directory APIs. Now in addition to the GUI, we've also created a command line utility called "radiusconfig." And this allows you to access maybe some of the settings that the GUI does not allow you to get to. Now, so basically what we've done, we've taken a very, very powerful open source RADIUS server and put a really nice interface on top of it, very easy to implement.

So now let's look at the client side starting out with Mac OS X. Let's take a look at the Snow Leopards Supplicant. The way we've chosen to implement 802.1X in Snow Leopard is via three modes what we call modes, a user mode, a system mode and a login window mode. And something new in Snow Leopard, you can actually use multiple modes at the same time.

So we'll talk a little bit about that [laughs].

OK, so let's talk about these modes in a little bit more detail starting with the user mode. The idea behind user mode is that the authentication session is initiated via the logged-in user. OK, so think about that for a second. It requires that the user be logged-in to the machine before the session kicks off and it's kicked off using preferences or keychain items out of that user's preferences or keychains. So again, it's initiated by the logged-in user.

Now in contrast with that is something we call the "system mode." The system mode is actually initiated by the system itself regardless of what user is logged-in. And in fact, it can take off even before users logged-in. So at boot for example, a system mode may initiate that authentication, maybe using a machine certificate for the credential to authenticate to the network before user even logs-in. So you're setting it login window and the machine is already authenticated to the network. So that's the idea behind user mode and system mode.

I forgot to mention, system mode uses system preferences and keychain items out of the system keychain. Now think about this for a second. Think about machines that are bound to an external directory, say Open Directory or Active Directory. Well if you're using user mode, there's kind of a problem here, let me kind of describe that for just a second.

I like to think of this as the chicken and the egg scenario. So to authenticate to a-- to login to my computer, if I'm bound to an external directory, I've got to authenticate against that directory before I can even login to my machine, 'cause my user, the user I'm logging in as is stored on that external directory. But to reach the directory server, the computer must be on the network which means it must have already authenticated via 802.1X. Well until authenticate via 802.1X, I've got to be logged-in to my computer.

So you kind of see the problem here that a user profile or user mode does not really work in the case of an external directory. Now system mode would but system mode doesn't allow for the individual logins. So as a result, we've created something called login window mode. The idea behind login window mode is that login window is responsible for the 802.1X authentication session. So whatever username and password is typed in at login window, that username and password is used to authenticate the computer to the-- via 802.1X to the network.

And then one set authentication is successful, we're now on the network. That same username and password is used to authenticate against the external directory. Now the current credentials again, are typed in at the username and password prompt, any resources does the preferences and keychain items come form the system preferences and the system keychain.

So does that make sense, the idea behind login window mode? OK good. So then I also mentioned that we can kind of mixed modes now, this is new is Snow Leopard. So real common example of this might be, first of all we create a system-- we create a system profile, to implement a system mode and maybe we configure it with TLS.

So we're going to use the client side certificate and maybe that certificate is a machine certificate. So at boot, the machine will automatically authenticate to the network so that when I'm at login window, the machines already on the network. And it's authenticated as the machine itself, not the user.

So at that point, I might use Apple Remote Desktop to mange that machine, I may even be able to see the directory if it's configured, if the directory is configured to be on that network. But then when a user walks up to that machine, we don't know what user at this point but when a user walks up to that machine and types in a username and password. Well that username and password is then used to start a new 802.1X authentication session and it's kicked off by login window. And then when that user logs back out, we go back to the system profile.

So that's a very common way that we'll use mixed modes within Snow Leopard, again a new feature in Snow Leopard. So let's look how this-- look at how this translates to the interface, the GUI that we've created around this. So we, you configure-- what we call 802.1X profiles in system preferences. So you would go to system preferences, you'd select the interface you want, in this case it's AirPort, and then you click the Advance button.

And when you click the Advance button, it brings up another panel that has several tabs and you notice one of those tabs is 802.1X. This is where you would add the various profile types. The system profile, the login window profile and the user profile. So this is where you would configure it via system preferences. Now as far as certificate trust goes, we talked a little bit about at some point somebody needs to trust the server side certificate.

Certificates in Mac OS X are stored in the keychains, in which keychain depends on which profile type your configuring. Again, we've talked about system and login window using the system keychain and the user profile uses, the user's keychain. And we can explicitly trust at any level. Now there's a new GUI in Snow Leopard, I think you really appreciate this.

And if you look down at the bottom, there's this Configure Trust button. And what does, that pops up a new dialogue and at this dialogue, you can actually drag a certificate in. So if you've got the file, the certificate file, you can drag that certificate in and that sets a trust for this profile.

And then also there's another tab called "servers." So we can now actually create a list of servers that are only valid for this SSID. So one of the problems that we've seen in the past is if a dialogue pops up and there's user sitting at the machine, that user may not have any idea if the certificate presented in that dialogue as valid or not. So as an administrator, what you can do is create a list of the servers and only the servers that are valid for this particular profile. And if one of those servers is not-- certificate is not presented during the connection, it just fails.

So the user does not have to be involved anymore. So that's a little bit on certificate trust. In addition to doing this in the GUI, there are some additions to the security tool, the security command line tool that allows you to import certificates and set the trust as well. So for example, if you type security dump-trust-settings, you will see all the trust settings for the certificates installed in your keychains.

Now if you put the -d switch at the end, you're going to see those in the admin domain, those that might be used by any user or process within the computer. Or if you leave off the -d, you'll see all the trust settings within the user domain, so the trust specifically for that user, so again, a new GUI that we've implemented in Snow Leopard. So at this point, I think what I'm going to do is perform a demo using Mac OS X.

OK, so what I've got set up here is a small 802.1X network. I've actually got a server hidden back here on a laptop. I've got AirPort Extreme Base Station which is going to be my authenticator and it requires 802.1X authentication to get on to the network. So here from my client, I'm going to start out with something very simple. I'm just going to click on the AirPort menu. Here's my network. I'm just going to select it.

Type in my credentials. I'm going to trust this certificate.

And now I'm connected to the network. I didn't really have to setup a profile but let me just insure that I really am connected to the network. I'm going to bring up Safari.

And I've got a web server set up here in my private network. So we'd see the page loaded, we're on the network. Now what happened under the hood here? If we go back to system preferences, we're going to click on Network, where we're using the AirPort interface, and notice first of all that we have a Disconnect button, that we are connected to an 802.1X protected network.

If we click on Advance, we'll see that, first of all, the wireless network was added to our AirPort preferred networks list and a user profile was created that will now be used for the future to connect to this network. So all this happened under the hood. I didn't actually have to come here to set that up. Now, if I wanted to remove this profile at this point, what I would do is click Disconnect, go back click Advance. I'd remove the preferred network.

I'm sorry. I would remove the preferred network [laughs], apply that. I did click Advance again, this time click on the 802.1X tab. I'll remove that profile, click OK and apply. So that's how you-- and so what happened under the hood? We have a template built-in that understands kind of the most common 802.1X configurations. So that automatic template was used and I as a user did not have to explicitly set all the settings for that 802.1X connection.

Now on the other hand, what I might want to do is set up a system profile. So I'm going to go back to network, back to AirPort, advanced. And this time I'm going to click on the 802.1X tab and I'm going to specify that I want to create a system profile. Now with the system profile, you have to save some sort of credentials.

This could be a certificate or an identity actually which is the certificate and the private key. If I were using TLS I'd have to use a client side certificate. In this case, I'm just going to use a username and password and I've got a generic one set up.

I'm going to select my wireless network. And in this case, I'm just going to allow both TTLS and PEAP.

Now if I wanted to configure this further, I could click on configure, and this is where I could set the in or off type in the outer identity. In my case, I don't need that. Now, here's the GUI I was talking about, here's the configured trust dialog and so what I've done, I've already obtain my certificates from the server that I'm authenticating against.

So I'm going to drag this RADIUS server certificate here, I'll click OK, click OK again, and I'll apply that. And we're now connected with the system profile. And I can verify that again by going to my web server and I'll just refresh that and sure enough there we are, we're connected.

Now what's nice about this, I can log out at this point. But I'm going to stay connected or authenticated against, with 802.1X to this wireless network. So at this point, the machine is still on the network, and by the way we can see that at the login window because we have an IP address. So at this point, I'm authenticated to the network using that 802.1X system profile.

So I'm going to log back in. And now what I'm going to do is I'm also going to create a login window profile. So we go to network, again, we'll click on AirPort, advanced, 802.1X, and this time I'm going to create a login window profile. Now with the login window profile, we don't know who's going to be login in.

So we're not going to type in any credentials at this point. We're just going to leave that blank. But for the wireless network, certainly we have to select that. And then again, I'm going to configure the trust on the server side certificate. So I'll grab my certificate here. I'll drag that in.

Oh, and I should mention by the way this Plus button allows me to select a certificate file which is what I'm really doing by dragging it in. You could also select a certificate from the keychain. So if the certificate or certificates you're interested in are already installed in your keychains, you can simply select them from the keychain. In this case I drag the certificate in. I'm going to click OK, click OK again, and apply that.

So now what I've done is I've created both the system profile and a login window profile. And previously, I ban this machine to Open Directory, so I'm going to log out at this point. And again when we log out, we should still be connected to the network. And we can verify that again with the IP address. Now this time I'm going to attempt to login with a network user.

So I'm going to use the user Kevin.

Now if you watched this what happened was we just disassociated from the wireless network. We re-associated to the wireless network and authenticated via 802.1X using the user name Kevin. OK, so we disconnected, if you will, the system mode and reconnected using a login window mode.

Now if all went well, we should be able to see our server and sure enough we do, we see our server and also just to show you that really was the network user, there's Kevin and you see network user there. So that's an example of how you might implement both a system profile and a login window profile.

OK, so that's the Mac-- that's how we implemented the supplicant in Mac OS X. Now, let's switch gears a little bit and look at the iPhone OS. How did we implement a supplicant 802.1X supplicant for the iPhone and the iPod Touch? Well it's-- first of all, you have to understand the concept that an iPod or an iPhone is not at multi-user device like a Macintosh is. With the Macintosh, you login, right? And who are you login as? I don't know, some user, whatever user credentials you typed in. With the iPhone it's really a single-user device.

So you real only have what's analogous to the user mode on Mac OS, OK. So there's no login window mode, no system mode. And actually in reality it's almost like a system mode. I don't know, it's kind of confusing but to understand that it's just a single mode, OK. So the connection is very similar to Mac OS X, I simply select the wireless network via negotiation, security negotiation happens.

It's determined that I need to use 802.1X and then the supplement-- supplicant kicks in and authenticates me to the network. And it's implemented via in automatic profile template very similar to the way Mac OS was and it will work as I said, you know, from most configurations of 802.1X.

And of course, certificate trust still the same in Mac OS X, I'm sorry, in the iPhone OS. And once you've created this automatic profile, it auto-joins very similar to the way the Macintosh would auto-join a network. And if you want to get rid of that profile, you simply forget the wireless network. And I'll actually go through a demo of that as well.

So here's an example-oops, let's do this again. Here's an example, here's the iPhone and I'm going to tap on the 802.1X test network. Once I do that, the security negotiation happens. It's determined that I need to use 802.1X to authenticate. So I type in a username and password, I prompt, I type that in, and then presented with a certificate. Again, very similar to Mac OS X, I could look at-- look deeper at that certificate, get a little bit more information about that certificate. And then once I trust that certificate, then I'm on the network.

So the connection by selecting a wireless network is very similar to Mac OS X. However, maybe as an administrator whose deploying lots of the iPhones or iPod Touch devices, you might want to pre-configure a profile for your users. So there's a toll that you can get off the internet called the "iPhone Configuration Utility." How many people have used this so far? OK, great.

So you can use this to create an 802.1X profile. You can explicitly trust certificates just like you would with Mac OS X. This is where you would set up things like what EAP type you're using, PEAP, TTLS, TLS, etcetera. For using TLS, you need a client side identity, this is the application you would use to configure that and apply that to your 802.1X profile.

And what's really nice, you can actually sign or trust this profile and then email it out to your users or maybe post it on a secure website or something so that the user might have to type in a username and password to get on to the website. And once they get this profile, you simply install it, installs on the iPhone or the iPod Touch and at that point, you're set and ready to go.

So it's a really easy way for you as an administrator to set up a profile for your users. So we have the Authentication tab, this is where you set up your authentication types, your EAP types. If you want you can pre-determine the username that's going to be used or you can live that blank. And then finally, here's where you set up the trust for the certificates. So let's do a demo really quick of using the iPhone to connect to a wireless network.

And to do that--

-- OK, so here I am. I would like to join my iPhone to the same protected network that we were connecting to earlier. So what I'm going to do is click on settings or tap on settings. And then I'm going to tap on Wi-Fi to connect to the wireless network. Now that same network shows up here. So I'll tap on that.

Now it understands that I need to type in a username and password.

I got you. And I simply click on Join. It's asking me do I want to accept the certificate from the server. And sure enough there we are. We are now connected to the wireless-- well, no we're not quite connected. There we are, now we are connected to the wireless network.

I'll tap on Safari-- oops, I'll tap on Safari and reload that webpage and sure enough we're actually connected to the wireless network and authenticate it via 802.1X. Now if I wanted to remove this automatic profile that I just created I would click on settings, go back to Wi-Fi, and what I'm going to do for that wireless network is I'm going to forget the network. And so what that just did, it removed the profile and the certificate associated with that profile.

So that's how you would just simply join a wireless network and authenticate via 802.1X. But what if somebody has created a profile for me so that it would automatically configure the iPhone to connect to that network?

Well, it just so happens that somebody did that for me.

Actually, I did that for me. And so, if I go to my email, as you see, we're not connected top a network here, if I go to my email and look in this demo folder, there's an email that I sent to myself that includes a profile. So all I have to do to install this profile on the iPhone, is select it, oops, select it. Now it's starting the installation process. I'm going to install that. Yes, I do want to install that now. Now, I did not say the username and password, so I have to type that in.

And it's installing the profile. I simply tap Done. And I can watch here on my server that the authentication is occurring and I am now connected to that network. So there you go [applause] that's how you use a profile, configure via iPhone Configuration Utility.

So let's get back over to the slides. So now that we've looked at how you configure both Mac OS X and the iPhone OS for 802.1 X. Let's talk a little bit about deployment. How do you deploy this for lots and lots of devices, hundreds or thousands of devices? So a new feature in Snow Leopard is the ability to import and export X profiles, all three types.

So you basically set up your machine with whatever profile or profiles you want, make sure they work properly, and then you simply click this new Export button or Export pop-up menu, and it exports the profile. You can have a single profile, like for example, a single system profile or you might have all three profile types in a single file. And then you can then import that profile, again, using the GUI within system preferences. In addition to the new GUI, networksetup, the command line tool now offers the ability to import and export profiles.

So the same functionality could be accomplished in a script. [Applause] Thank you. So, the idea here is you set up a machine, create the profile, export it, and then you can use something like Apple Remote Desktop to send that profile out to the machine and networksetup to import it into your machine.

So you don't physically have to touch all of your machines anymore to configure them for 802.1X. Now there's one additional step that may be needed, depending on the profile type. If you're configuring TLS, so you have an individual identity, and again an identity is a certificate and a private key, whenever you configure a user profile or a system profile, you need to associate that identity to the profile. So there's an additional switch for networksetup, one is settlsidentityonuserprofile, I have to read that but I can never remember it, or settlsidentityonsystemprofile. So again, just to kind of an additional step you may need to do if you're configuring TLS.

So let's look at an example. How of you attended the scripting session where they went to a CA and downloaded an identity? OK. So imagine if you've got a web server setup, it's your certificate authority and yo could login to that web server and request a certificate et cetera.

Well, you can do that with the script as well, so with the script, you may go up, grab your identity, user or machine, download it, save it to your machine, and then using these commands, you would import a profile and set the identity. So starting with import, I'm sorry, starting with security, the command line tool security, you would import that identity.

And by the way, that -x option is new in Snow Leopard and what that is, is when you import that identity, it is secure. You are not allowed to export it back out. So you import your identity, and again, that could be a user identity or a machine identity.

You then use security to add the trusted search. So this is the server certificate, alright? So we're doing the entire configuration. We take the server sides certificate, import that, and we trust it for EAP. We then import the profile. In this case, we're importing, I believe a system profile.

Or actually, in this case, we're importing all profiles. So it depends on what was actually exported. And then finally, that extra step that I was talking about, you need to associate the identity to the profile that you just imported. So here's an example of how you could completely script exporting and importing profiles.

Now, another way that people deploy lots of devices, lots of machines, is via imaging. So the basic idea is you set up your machine, create an image of that machine, and send that image out to all your other machines. So let's look at how 802.1X profiles translate in the imaging process. So first of all, user profile. Actually, a user profile does not really image properly because there's a binding between the interface and the profile, and that binding stored in the ByHost preferences.

And as you know, ByHost preferences are specific for each machine. So a better way to handle setting up a user profile during the imaging process would be to create a post image script that's automatically launched and would create the profile for you. As far as the system profile goes, the system profile images just fine. However, understand that you're taking in an exact copy of your master machine and putting that on all your other machines.

So that means whatever saved credentials were on your master machine, would also be copied down to all your other machines. So all your machines would authenticate via the system profile with the same credentials, either a certificate or a username and password credentials. Now, that maybe what you want. That may be fine. However, if you want individual credentials per machine, again, you would use networksetup and associate that identity, machine or user, to the system profile.

And then finally, a login window profile, that just works. That does exactly what you would expect. The profile is copied from one machine to another, and since you don't know what user is logging in, it just works, whatever credentials are typed at the login window, they just work. So this is how 802.1X profiles translate in the imaging process.

So now, let's look at deployment on the iPhone. Well, or iPod Touch. We've really already talked about this. Because there's, you know, it's really a single mode, there's you don't login to your iPhone, the way you would implement or deploy 802.1X on lots of iPhones or iPod Touch devices is with the IPCU, the iPhone Configuration Utility. So you'd create your profiles the way you want them, and then figure out how to get those on to the iPhone.

You could do it through the iPhone Configuration Utility, you could do it on a web server, you could do it via email. So whatever works for you. OK, so that's deployment. Let's now look at trouble shooting. We've added a couple things here as well. So in terms of troubleshooting, one thing I've learned in several years of troubleshooting 802.1X, is don't immediately think that the problem is 802.1X.

To get on to a network using 802.1X, there's a lot of things that come in play here. For example, DHCP is very important. You may actually authenticate to the network via 802.1X and never get an IP address or something like that. So usually, where I start are the client log files. And again, don't look just for 802.1X information.

Look for any kind of network operations. Look for EAP, that's the actual authentication process, see if you can find out what's going there. If that doesn't work for you, maybe the next step is go to the authenticator log. So for example an access point, I can see that the client has associated to the access point, and then what I should see is that the access point is trying to authenticate the user to the RADIUS server.

If I never see the authentication, well that's where it's breaking. It's never-- it would be a wireless issue in that case and it's never authenticating to the access point. And then of course you can look at the RADIUS log files, the authentication server log files, so, to see if the authentication was successful. And of course, if the RADIUS server is pointed to a back end directory, you might want to look at the directory server files, log files to see what's going on there. Again, as I mentioned, DHCP is very important.

So if everything else looks like it worked properly and you're still not able to access the internet or your network resources, check the DHCP server log files to see if you ever issued an IP address or renewed your lease. And of course, if none of that works, you can always resort to packet traces, and you can do that via TCP dump and WireShark. Actually, I really like WireShark for analyzing our connections.

Now something that you can do if all of that doesn't tell you what you need, doesn't help you solve the problem, you can actually turn on Debug Logging. So for the Mac OS X supplicant, you can turn on debug logging with the defaults write command. And basically, what you're doing is creating this file called com.apple.eapolclient, and it sits in /Library/Preferences/SystemConfiguration/, and it's a plist. And within that plist is this flag called LogFlags, and it has a value of -1.

If that file exists with the LogFlags switch set to -1, EAPol will spit out a bunch of log files and they're stored in /var/log/eapolclient/. So that's how you turn on debug logging for EAPol in Mac OS X. Also, you can turn on DHCP debug logging with the ipconfig setverbose to 1. So this is how you can get a little bit more information on Mac OS X.

Now, in terms of iPhone OS, how do you get more information from the iPhone? Well first of all, you use iPhone configuration utility to download the logs from the iPhone and then view them on your computer. But before you can do that, you've actually gotta turn on debug logging on the iPhone. And before you can do that, you've actually got-- you actually have to expose the GUI within the iPhone configuration utility.

So to expose that GUI, use defaults write again, and this time, you're writing to com.apple.iPhoneConfigurationUtility. And you're basically turning on EnableDebugLoggingInterface by using Yes. Once you do that, a new tab will show up in IPCU called "Logging." And under the logging tab, you can then turn on 802.1X logging.

So this is how you turn on debug logging from the iPhone Configuration Utility and then use that same utility to download the logs. So that's it for a little bit more information, here are some contacts. Let's summarize. So Apple has built-in what I think are very robust supplicants both in Mac OS X and in the iPhone OS. We support an external directory in which-- we support that in three different ways.

We support that with system profile and the login window profile and then we also support standard user authentication with the user profile. You can deploy as we talked about via imaging or with the new commands networksetup when iPhone use IPCU for deployment. And so that's it. That's our supplicants for Mac OS X and iPhone.