The first step in setting up the EX Switch with the UAC (Unified Access Control) solution is to determine what authentication method to use. EX Switches support three 802.1x methods: EAP-MD5, EAP-PEAP, and EAP-TTLS. Likewise the Infranet Controller (IC) and its counterpart the Odyssey Access Client can be configured to support any of these EAP methods. If you are not using the Infranet Controller or you are not using Odyssey Access Client and replacing them with a different Radius server or 802.1x supplicant (respectively). You will need to check into what that server or client supports If you intend to attach unmanaged devices to your switch, such as IP phones, most of these devices only support EAP-MD5, Which is a simple CHAP authentication to the RADIUS server. Newer devices and most all modern PCs can support PEAP and/or TTLS. Both PEAP and TTLS are tunnel protocols, meaning that a second EAP method will be tunneled through a tunnel created by these protocols.
PEAP is the more restrictive of the two protocols but it is also more commonly implemented, For example the Microsoft supplicant (also called Windows Zero Config) uses PEAP as its primary authentication. PEAP is restricted to two inner methods: EAP-GTC, which is equivalent to doing a PAP authentication inside of the encrypted tunnel, and EAP-MS-CHAP-V2 which itself is a way of tunneling a NTLMv2 transaction. TTLS is less restrictive in that it will tunnel another EAP packet in its entirety without using proprietary “hacks” to the protocol. So essentially any other EAP protocol can be used within an EAP-TTLS tunnel without modification. The disadvantage is that this method is not as widely implemented, for example Microsoft’s Windows Zero Configuration does not support EAP-TTLS. However the Odyssey Access Client which is part of the UAC solution does support this method (and uses it by default).
First set up the EX Switch to use the Infranet Controller (IC) as its radius server:
On the EX switch enter into config mode.
Configure the radius server parameters with the command below (remember the password and the source interface address as it will be used while setting up the IC):
Juniper# set access radius-server X.X.X.X secret <password> Juniper# set access radius-server X.X.X.X source interface X.X.X.X
Next create a radius profile to bind to dot1X.
Juniper# set access profile <name> authentication-order radius Juniper# set access profile <name> radius authentication-server X.X.X.X
Configure 802.1X for a port on the switch. Note that the interface configuration used throughout this section (802.1X) is IFL – it has unit 0. There are 3 Options as to which mode to put the port into.
Sign into the Infranet Controller’s admin console: On the menu, on the left side, look under Authentication > Auth.Servers. If needed create an authentication server that will authenticate to the desired server. For simplicity a username is added to the System Local authentication server.
Go to Endpoint Security > Host Checker. Create a new Host Checker Policy; in this example it is called notepad. Create the Host Checker policy so that it checks what is needed. For simplicity, the example is checking for the Notepad.exe process. If notepad is running this check will pass. Under Users > User Roles and create a new role. (The example role is called “Host Checker (Compliant)” ). Don’t worry about any others settings at this point as this role is only a Place holder right now, but will later allow to Dynamically assign a VLAN. Repeat Step 5 but this time the role will be called “Host Checker (Remediation)”. Again this will be used to assign a radiation VLAN later. Next, go to Users > User Realms. If needed create a new Realm. This example will be using the Users realm which is already provided. Set the Authentication server to the appropriate server (in this case “System Local”). Save changes and select the role mapping tab. Create a new Rule; selectcustom expression from the drop down and click Update. Click Add Expressions to create a new Expression which requires the Host Checker to have passed: After the expression is added it becomes available on the role mapping page. Configure this similar to the screenshot below. In the example, we specified if compliant only assign this role; this is for simplicity and is usually not a requirement. Next, create a second role mapping rule that is a catch all. In other words if a user’s username and password are valid they will receive this role. Since in the example there is only two rules anyone who is not caught by the above rule does not meet the Host Checker’s requirements. From the left navigation, select Authentication > Signing In > Authentication Protocol Sets. Assuming no modifications have been made to this section, the methods the EX support are already configured. For the inner authentications, PEAP and TTLS have been pre-configured to the default Windows ZeroConfig Supplicant as well as the Odyssey Access Client. The default configuration is shown below: Go to Authentication > Signing In > Sign-in Policies. Associate the realm with a sign in policy. Specify what protocol set to use. The example is set to use the default sign-in policy though you may find that creating a new sign-in policy may suit your needs better. Create a location group. This will be used shortly to direct a radius client to the proper sign-in policy. Select UAC > Network Access > Location Groups and create a new Location group. Specify a name and which sign-in policy to use. Finally select UAC > Network Access > RADIUS Client and create a new Radius client. For the IP Address enter the source interface specified in the first section. For the shared secret enter the password used on the EX during the same step. Make Model should be set to Juniper Networks Inc (JUNOS), and last the location group should be set to the location group just used. Settingup VLAN’s on the EX switch Before instructing the Infranet Controller to assign VLAN’s to users define them on the switch. First create the Guest VLAN that will be assigned to the user if they either do not perform 802.1x or if they fail 802.1x authentication. Copy the following commands and paste them into the switch terminal window to create the guest VLAN: set vlans guest-vlan vlan-id 300 Next tell the EX switch to assign unauthenticated users to this VLAN set protocols dot1x authenticator interface all guest-vlan Now that the Guest VLAN has been set up create two VLAN’s which the Infranet Controller will dynamically assign. Setting up the Infranet Controller to Assign VLAN’s In the case that a user’s username and password are authenticated, assign a VLAN based on whether they pass the Host Checker. To accommodate this, for the example we created two roles, one that is assigned if the Host Checker policy is passed and one that is assigned if it is not passed. Now createand associate a RADIUS Attribute policy with these roles and assign either an access VLAN or a Remediation VLAN accordingly. Go to UAC > Network Access > RADIUS Attributes. Create a new radius attribute policy. Set up the following three items. First give the policy a name (i.e. “Access VLAN”). Second under the RADIUS Attributes section on this page specify the VLAN ID (in this case “1”). Lastly specify this policy should be applied only to selected roles and specify the compliant role: Repeat this process but with the information for your remediation VLAN. Share this: Related