I would like to start by saying we have completely deployed 802.1x across all our computers, exception being a few critical administrator workstations and servers. The actual mechanisms for 802.1x works very well, the issues really come into the integrations with anything but Microsoft networks. As I have said before and I will say it again Novell really needs to address this weakness, 802.1x is the defacto standard for layer 2 authentication and Novell has just not stepped up to the plate in embracing it. We currently use Cisco Radius Server(ACS) and Cisco’s supplicant(CSSC). This document is not designed to describe the complete implementation of 802.1x but rather getting workstations to login prior to login.
So the problem at hand is that with the version of CSSC version 4.1 and above the CSSC supplicant( supplicant just means the 802.1x client) stopped communicating on the network unless a user was logged in. Prior to this when it was knocked onto the guest vlan or failed authentication vlan it could talk on the network but with the 4.1 and above client it does get placed in these vlans, the supplicant itself will just not allow any communication on that vlan. I have reported this to Cisco and jumped through their dog and pony show and basically came back with nothing. So we have lived with the fact that we could not control stations on the network until they logged in, which made it very difficult to manage such programs as Deepfreeze and windows updates.
So one day an idea struck me, I thought of trying to use the ZENworks 7 workstation objects as the authentication object for the workstation, allowing the workstation to login to the 802.1x port. This would add a benefit; with the old way of the machine popping on the guest or failed vlans those machines are on an unprotected network, add to this that in order to manage those machines you have to open up holes to that network for the support protocols. With the new way of having the workstation object logging in you are able to place the workstation in a more secure vlan that is not such a high risk for virus infections or for “Guests” trying to hack the support services protocols you had to open up.
I have run packet traces between our Radius servers and our LDAP server, when LDAP is run in clear text mode, and it appears the authentication mechanism used is not a simple password. In fact I could not figure out how the workstation actually authenticates other then a small part in a packet that mentioned certificate, which makes me assume the workstations use certificates to authenticate.
So lets get down to the nitty gritty.
First we will create a group in the ACS server. When integrating with LDAP you have two groups, the LDAP group and the ACS group. The ACS group holds all the parameters for Radius(802.1x) and LDAP group holds the users. So later we will see the association between the two groups.
Here I am just creating a group, you can rename it if you wish, and I usually do.
The only thing to see here is that in the properties of the group you set the service Type to Authentication Only
Further down the Group properties page you will see Tunnel Type, Tunnel-Medium-Type and Tunnel-Private-Group-ID. So you set these to VLAN, 802 and the name of the Vlan you want users of this group to go on. NOTE.. This is not the VLAN number but the vlan Name you assign the vlan when you create it.
These two slides are just showing where to go to create an external LDAP source.
So in this instance I already have workstation Ldap setup, so I press the configure button.
This is the meat of the configuration. Here I am changing what class types the ACS is looking for with Workstations. You will also notice Domain filter has some stuff like “host/”, this was just testing stuff, what you really need is the “Process all usernames after stripping domain name and delimiter” then check the “Strip starting characters through the last / character”. So the reason for this is when the CSSC supplicant sends the machine info it pre-pends “host/”. You can remove this from the client but seeing as it is the default I left it and just changed it here.
So this is a little further down the page above and it is basically just configure your LDAP servers.
Next you need to click on the Database Group Mappings to get to this page. What you see here is LDAP groups mapped to ACS groups. As you see I have renamed the groups I use to make it easier. These groups are Workstation groups, as were defined in the schema mapping in the ACS LDAP config.
So now we have where you actually map these groups, it is very easy to do, and once the LDAP is setup correctly you will see groups populated in the LDAP groups. Because this ACS has two different LDAP server configs you are seeing the user groups and the workstation groups. Simply select a LDAP group and click add mapping and then below select the CiscoSecure group you configured earlier.
So at this point your ACS server is setup to receive workstation logins from the CSSC clients. Some notes in this, one thing I did was create a filtered replica on a server that just has workstation objects on it. The ACS server is also authenticating users so I did not want hammer our user LDAP server more by adding the workstations to the same LDAP. Lastly, you need to create a workstation group with workstations in it; otherwise the ACS server will not know what settings to apply to a workstation.
The next portion I will just briefly show the creation of a vlan.
Once this is done it is a matter for configuring a route interface for the vlan.
Lastly you will have to configure DHCP for the vlan and on the vlan interface configure a helper address.
The next part is configuring the CSSC client. Now this can be done manually at each client or from the CSSC Management Utility. The Management Utility is basically a configuration editor that you can save and import into an .msi file so when you install you do not have to manually configure it.
The next set of slides will be to use the Management Utility; you can extract the manual config from that pretty easily.
So this portion is however you want to set it up. Preset client just means people can’t edit the config once it is installed.
Here you want to make sure Wired is checked. I have not tested this with wireless.
We use Eap-Fast with Generic Token inner method; so far it is the only way you can integrate directly with a LDAP server using Cisco ACS without having to deploy certificates.
For a new config you will want to add a network, this is already created so I would modify this network.
This is where you enable machine authentication.
This is the portion where you can remove the “host/” portion but seeing as with every new config you do, this is going to be in there, it may be easier to just add the / in the ACS config above.
This of course causes the client to automatically attempt a connection to the network.
This last part is used for Single Sign On. The CSSC 4.22 client and below automatically detect the Novell Client and will configure SSO for it. Moving up to the 5.X client Cisco no longer supports Novell Client.:(
So lastly there is the port config on the switch itself that needs to be configured. I will just show the config from a single interface.
interface FastEthernet0/2 switchport mode access dot1x mac-auth-bypass eap dot1x pae authenticator dot1x port-control auto dot1x timeout quiet-period 3 dot1x timeout tx-period 3 dot1x reauthentication dot1x guest-vlan 441 dot1x auth-fail vlan 441 dot1x auth-fail max-attempts 1 spanning-tree portfast end
So this basically allows 802.1X on a Cisco switch interface. I am not going include the other Cisco config stuff seeing as it is beyond the scope of this document. You can tweak some of the timeout periods, I have and they do not seem to make too much of a difference. Most of the stuff is for networks that for some reason or another may have lag between the servers and switches. You may notice the auth-fail and guest are the same vlan, I considered making these different but in reality they would both be the same security equivalent seeing as a guest with a 802.1x client would get popped onto the auth fail vlan not making it different then a guest vlan, especially with 802.1x being turned on my default in windows now.
In case you did not notice, this config will not work with ZENworks CM. It requires NDS workstation objects that can be queried via LDAP which leads me to my opinion on Novell and 802.1x.
Novell offers one solution for 802.1x integration for Novell clients, which is the MS supplicant with a FreeRadius back end. I am a big fan of free and open source software but FreeRadius is extremely hard to configure and does not offer a lot of the reporting features as other Radius servers do. For instance, with the ACS server I allow my techs to view the passed and failed log and they can figure out login issues with that, this is a basic web view that is easy to get to and view. I am sure FreeRadius has a log and such but from what I know about it there is no easy to use web interface for techs, or people in general, to view that does not require a bit of Linux knowledge and direct access to the server. My experience at configuring FreeRadius consisted of Novell on the line doing some crazy tweaks that were not in any of the docs, it is not a good solution for anyone but the most hard core freeware Linux gurus.
There are several things Novell should do, because no other vendor is willing to do it for them. They need to create software and configurations to work with all the major vendors of 802.1x solutions, which is Cisco and Juniper. They need to offer secure 802.1x integration with their client that does not require manually administered certificates and works with the ACS and Steel-belted Radius back-ends. The current course they are taking is actually pushing people to Windows and Active directory, that is the only way to get the integration of 802.1x as it exists today in the Novell client is to use the MS supplicant. This means that unless you use FreeRadius on the backend that will decrypt the MSChapV2 inner method supported by the MS supplicant it has to go to an Active Directory tree for authentication.
Another option is to develop an intuitive and easy to use web interface for FreeRadius.
You can make the argument that this is a limitation from ACS and Steel-belted Radius and I would agree. The problem lies in the fact that those companies are not willing to add features for Novell products anymore so where does that leave Novell? Either Novell says to heck with you and does it themselves or they lose customers because they need this higher level of security. I have been a Novell customer for darn near 14 years now, and I find everyday I am thinking of moving to Active Directory just so I don’t have to deal with these head aches, granted they would be replaced by others..
At this moment we are trying figure out if we should move to Zen CM or stick with Zen 7 because with Zen CM this workstation login issue will no longer work. If Novell could integrate more supplicant protocols in its client that could use Zen CM as the workstation repository we would be there in a minute.
Probably the most frustrating thing is that right when I find a solution to one problem I am finding a road block with another. For instance, getting CSSC 4.22 to work well with the Novell client and then finding out that Novell will not be supported in the CSSC 5 client meaning we have no option to upgrade to Vista or 7. Or getting the workstation issue figured out but moving the Zen CM 10 breaks it again.
Sorry for the Rant, I just had to get that out…