Skip to end of metadata
Go to start of metadata


The Manage your UW NetID Resources utility ( provides an interface for departmental types to configure Radius clients for the UW-IT Radius servers.  In order for the Radius servers to hear about a new client device or to hear about changes to an existing client device, the Radius server needs to be shut down and started back up again with a new client configuration file.  The Manage Utility does not communicate directly with the Radius servers, but it maintains snippets that get merged into the Radius servers' client lists.  One Radius server acts as a Sandbox that the Manage Utility can bounce up and down when it has new configuration files for it.  The changes will propagate to the other Radius servers at some later time in a less disruptive manner.  You should do your testing with the sandbox Radius server and then switch to the other production servers when things are ironed out.

Step 1: Choose a UW NetID

Your Radius client configuration will be assigned to a particular UW NetID.  This UW NetID should probably be a departmental Shared UW NetID.  See the Other Services tab on the Manage Utility for information on setting up Shared UW NetIDs.  All administrators of this UW NetID will have access to the Radius client configuration.  If we need to contact you about your Radius clients, e.g., when the Radius servers are getting upgraded, we'll send an email message to the email address associated with the shared UW NetID.  Make sure it forwards somewhere useful.  See Step 6 below as well.

Step 2: Establish a Shared Secret

The next step we need to do is to establish a shared secret.  The shared secret is a simple plaintext password that both your device and the Radius server know.  All packets sent between your device and the Radius server are signed with the shared secret.  If your device sends sensitive information to the Radius server, like user passwords, those fields will also be encrypted with the shared secret.  Send an email message to with RADIUS somewhere subject.  Indicate that you are setting up a Radius client device and want to establish a shared secret for your departmental UW NetID.  Note that with the shared secret and a network packet sniffer, a bad guy can decode passwords that your device sends to the Radius servers and/or impersonate the Radius server to gain access to your device.  If you have staff turnover you should get a new shared secret established and switch your device(s) to using the new shared secret to prevent misuse.

By default, UW Faculty, Staff and Students will be authorized to log in via your radius client.  If you want finer control on who gets access to your devices you will need to set up authorization groups.  If you will be needing these groups you can ask for them to be created when you request the shared secret.  See the G={xxx} method under the Authz Configuration Option below.

Step 3: Visit the Manage Utility

Retrieve the Shared Secret

Once you get conformation that your shared secret has been established, go to the Manage Utility and select your shared UW NetID.  You should see a new Radius Clients tab there (this tab will not be visible unless a shared secret has been established).  Clicking on this tab will give you the form for adding a new radius client device along with the list of your shared secrets.  When no one is looking over your shoulder, you can click on the Show link to toggle the display of the shared secret.  You can then copy-and-paste this string into your Radius device's configuration.

Add your Device

Enter the DNS name of your Radius device into the appropriate box and hit Save.  Note that your personal UW NetID or your shared UW NetID will need to be established as a Domain Contact for the indicated device.  If you wish to adjust the other fields from their defaults, you can click on any of the green fields to access a menu of options.  There is more information on what those options are below.  In particular, after you add your device with a server of All , add it again with just the sandbox server specified.  You should end up with two entries.

Push the Configuration to the Radius Servers

If all went well, you should now see your device listed twice, once with the sandbox Radius server and once with all the other Radius servers, both with a status of Pending along with a Push button.  This button will run the utility that updates the master Radius clients list.  It will also notify the sandbox Radius server that it's time to fetch the client list and restart itself.  Note that anyone with devices in a Pending state can click on their Push button.  Clicking on this button will cause all pending updates, for all users, to be applied to the master clients list.  Click the Push button.  You should now see the sandbox server with a status of Active and the rest with a status of Waiting.  The rest of the Radius servers will be restarted and load the new client list sometime within the next few hours to no more than a day.

Step 4: Configure your Device

The Radius servers all have names of the form  You will probably have to specify the IP address of the Radius server(s) in your device's configuration.  Use the host command somewhere to determine the Radius servers' IP addresses.  Configure your device to specify the sandbox Radius server's IP address now with a port of 1812 or 1645.  These are the default Radius ports.  If you have the option for accounting, you can specify the same server IP address with a port of 1813 or 1646.

Step 5: Switch to Production Servers

Once you get your device working with the sandbox Radius server, you can switch to the production servers.  Go back to the Manage Utility and refresh the radius clients list for your shared UW NetID.  Maybe come back tomorrow.  Eventually the status on the production servers will switch to Active.  At that point you can reconfigure your device to use one of the production servers as a primary server and another one as a fallback secondary server.  Of course you can continue using the sandbox server as well, but its stability might be questionable if there are other people out there repeatedly restarting it.  Who knows, though.  You might be the only client out there and it might actually be the fastest server to respond!!

Please note that there are production Radius servers in Seattle and across the state at Tierpoint in the Spokane area to provide so called "geographical resiliency."  While it may seem unnecessary to have your Radius client in Seattle fall back to the Spokane server – heck, if all the Seattle servers are down my client is probably down, too – we are mandated to perform disaster resiliency tests periodically wherein Seattle nodes of various services are shut down for a period of time to ensure that the Spokane nodes will respond to requests and handle the load.  For this reason, it is recommended that you select the Tierpoint radius server(s) as your tertiary fallback so that you can still authenticate to your device(s) during the disaster resiliency tests or during a true outage that may affect all the Seattle based Radius servers.  We will provide advance notice when the tests are scheduled in case you don't have the option to specify a tertiary server, but it's unlikely that you'll get advance notice in the case of a true outage.

Step 6: Sign up for Notifications

General announcements about Radius happenings, e.g., server updates and disaster resiliency tests, will be distributed via email to the members of the u_radius_announcements group.  You can join or leave this group as you see fit by visiting and clicking on the "Join..." or "Leave this group" link.  The UW NetID you specified in Steps 1/2 above will be included in the list distribution unless/until you remove it so you may not wish to add yourself again.

Configuration Options

By clicking on the colored fields to the left of the Save button, you can open the configuration option menus for a particular field.  Those options are described below.


You can specify any combination of the servers using this menu.  You can add the same Radius client with different Radius servers to have multiple configurations with different options or the same options.  It may be necessary/desirable to use one Radius server for administrative access and a second one for user access, for example.  You can only have one configuration for each Radius server, however.  Adding the same Radius client a second time will remove the selected server(s) from the list of servers associated with other entries for the same Radius client.

To remove a Radius client altogether specify None in the Server field.  To remove a Radius client from a single server specify the server you want removed and None in the Authz field.

If multiple people with different shared UW NetIDs add entries for the same Radius client it will cause a conflict.  Please don't do that. (sad)

Some Radius servers may be busier than others at particular times of the day.  Look for a monitor sometime soon that will provide stats on the various servers to help you decide which server(s) would be best for your client device.

DNS Name

Use the DNS Name field to specify the Radius client you want to act upon.  If your client name maps to multiple IP addresses all IP addresses will be affected.  You can also specify an IP address in this field to select just that IP address.  Your personal UW NetID or your shared UW NetID must be registered as a Domain Contact for the indicated device, subdomain or subnet in order to manipulate the Radius client list.


The configuration files that the Manage Utility maintains only contain keywords that refer to your shared secret.  The actual secret text gets substituted in for the keyword on the Radius servers themselves.  You can have multiple shared secrets established, but only one secret can be configured with a particular Radius server for your client device at a time.  If you need to change your secret, because of staff turnover for example, you can request an additional one by sending another email message to  To change your device to use the new secret follow these steps:

  1. Configure the sandbox Radius server to use the new shared secret.
  2. Push that configuration to the sandbox server to make it Active.
  3. Switch your client device's configuration to use the sandbox server.
  4. Configure the rest of the Radius servers to use the new secret.
  5. Wait until they show Active.
  6. Switch your device back to the production servers with the new secret.
  7. Let us know that you no longer need the old secret.


The Radius protocol sends packets back and forth with various Attribute-Value Pairs (AVPs).  There are a number of generic AVPs that apply to all device types.  These include such attributes as User-Name, User-Password,  Service-Type, Message-Authenticator, etc.  There are also Vendor Specific Attributes (VSAs) that only apply to certain devices made by particular vendors or manufacturers.  The VSAs are usually used to indicate the authorization levels.  Our Radius servers here in UW-IT support three levels of users, Normal, Superuser and Semi-Privileged which falls somewhere in between normal and superuser and VSAs are used to indicate which type of user is logging in.  To wit:




























If you have another vendor that absolutely needs a special VSA assertion, send some email to  Chances are you'll be happy with a vendor of Generic and the simple "Yes" or "No" response you get to the "Did this clown authenticate properly and is he authorized to log in here?" query.


The Authz field specifies the authorization method to use to determine whether the user attempting to log in is authorized to do that.


The Campus authorization method allows most current UW Faculty, Staff and Students to log in.  This is controlled by the "Eduroam Radius Access" subscription that appears under the Computing Services tab on the Manage Utility.  The user could shoot themselves in the foot by unsubscribing from this basic service or there may have been issues that caused the CISO to disable their access.

G={UW NetID}

The UW NetID groups authorization method uses up to four GWS groups ( to control who has access to your devices.  Effective members of the following groups get the indicated access:

u_radius_authz_{netid}Normal user access
u_radius_authz_{netid}-l0Superuser access
u_radius_authz_{netid}-l1Semi-privileged access
u_radius_authz_{netid}-lxNo access (overrides membership in above groups)

Distinction between the different authorization levels either requires vendor specific AVPs or the ADMIN flag below.  Only the first group is required, the other groups can be empty or non-existent.  You can send an email message to with RADIUS in the subject asking that these authorization groups get created.  We'll create all four groups; you can utilize the ones you need and ignore the others.  NB: It can take a few minutes before updates to these groups are reflected in the actual authorization settings for the users involved.

GP, K20, ONS, UW, UWL2, UWSecurity

These other authorization methods use a slightly different, older, set of GWS groups that have similar functionality (but weren't extensible).


By specifying None for the authorization method, the Radius client will be removed from the indicated server(s).  To remove a Radius client from all Radius servers you can specify a server of None or use an authorization method of None with All servers.


The flags field sets various options that affect the authorization and authentication performed for the Radius client.  To wit:


The KRB/NOKRB option controls whether plaintext Kerberos passwords are supported.  Some older devices allow unsecured plaintext access.  Such devices should disable Kerberos passwords.  Even though the traffic between the device and the Radius client is secure/encrypted, the traffic between the originating user and the radius client is not.  You wouldn't want people using plaintext telnet to access your device and then type their Kerberos password in where it can be sniffed off the network.


The Radius servers support one-time-passwords of the form PIN+PRN for people with 2FA devices where the PIN is established via the Manage Utility, and the PRN is the pseudo-random number displayed on or provided by the 2FA device.  This option is normally enabled, but if you've got a device that reauthenticates on every transaction, as some do, you don't want your users using one-time-passwords.  The PIN and KRB password methods require plaintext passwords (or PAP in the Radius parlance).


This option is always enabled and does not actually appear as a flag option.  The PEAP acronym stands for Protected Extensible Authentication Protocol.  The Radius servers support Microsoft's Challenge Access Protocol (version 2) to authenticate users against NTLMv2 hashes of the their UW NetID Kerberos passwords.  This is the protocol that most wireless accesses utilize.

In order to support PEAP-MSCHAPv2 with the G={UW NetID} authorization method, you may wish to put the user "anonymous" in your normal user access group.  This protocol utilizes an outer envelope that usually appears as "anonymous@{domain}".  The outer envelope is used to tunnel the inner challenge protocol handshaking that supplies the actual username.  The anonymous user is validated in the authorization step, but is never authenticated – it doesn't even have a valid Kerberos principal nor a password.


The PRIV option requires the user have semi-privileged or superuser access based on the authorization method used.  This would allow you to specify the same G={UWNetID} method for two devices (or an administrative alternate Radius server on a single device) while one allows normal access and the other requires privileged access.


The ADMIN option causes the Radius server to assert the " Administrative-User " value for the Service-Type attribute.  For normal users, and for privileged users when the ADMIN option is not spefied, this attribute gets the " NAS-Prompt-User " value.


The EDUROAM option enables visitors from other institutions to access to your device.  Note that authentication and authorization is controlled by the remote institution – there's no way for our Radius server to even know which remote user is trying to log in – you may even see them only as "anonymous@{remote_domain}".  This option overrides whatever authorization option you specified with the Authz field and instead reverts to the Campus method. 


These option select an experimental feature that doesn't scale well.  They also override the authorization method used to determine who can access your device and use the Campus method instead.


The ELB option enables membership in a series of groups (u_radius_elb-f5_{partition}) used by the Enterprise Load Balancing team to control who has access to the various partitions defined on the F5 BIG-IP device.

       (this page intentionally left blank)


  • No labels