Default mapping explained with example for Admin logon using AAA in vSZ
- Question- When should I use default mapping with SZ admin login using RADIUS and how does it work.
- As we know that RADIUS Vendor-specific attribute "Ruckus-WSG-User" is used to map the AD user to a locally created admin-user on SZ and that AD user is given the same role (access-level) as the local admin-user on SZ.
- The “default-mapping” option is used when no “Ruckus-WSG-User” attribute is returned by RADIUS server during successful authentication, but we would still want that AD user to be assigned a specific role/access-level on SZ which is defined by mapping to an Admin "user-group" on SZ. Default-mapping was introduced from SZ 5.1.2 version onwards.
- One of the most common use-cases of Default mapping for SZ admin using RADIUS/AAA is when you have users from different Groups on AD and you want to maintain a difference in SZ access-level between users of two different groups on AD :-
- For example, I have some admin users on AD (say admin1 and admin2) and I have made them a member of AD group “szadmin_fullaccess”. I want these AD users to be authenticated using RADIUS and get Super Admin access.
- On the other hand, I also have other domain users on AD ( say Bob, Alice etc.) who I just need to provide Read_only access to SZ and they are a member of “domain users” group on AD. Now, I am going to show how we can achieve this using default-mapping. I am going to use SZ ( any version 5.1.2 & above), Windows Server as NPS and AD.
Configuration on AD side :-
1. Created AD user “Bob” and added it to security group “Domain Users”
2. Create an AD User “admin1” and move it to an AD group ““szadmin_fullaccess”.
Configuration on vSZ side :-
1. Now, we move to vSZ and create a local admin user “admin_full_access” and give it a random password. Note that this local password would not be utilized if the authentication is happening using AAA.
2. Now, we go to Groups under Administrator and inside the already existing user-group “Super Admin Group”, we include our newly created local admin “admin_full_access” to assign this user super-admin privileges.
3. Next, we would create another admin User-Group called “read_only_access” and give it “Read-Only Network admin” permission and we would not map any local admin to this. This is because we would like SZ to automatically generate a local user into this group by leveraging “default-mapping”.
4. Then, we configure the NPS details under Administration > Admin & Roles > AAA > Create. Realm needs to be same as the domain name. Select PAP as the protocol. As per our requirement explained earlier, we need to enable “default mapping” and select user group as “read_only_access” and select “auto-generate” under administrator option. This config ensures that if the authentication is successful but RADIUS server does "not" return the Ruckus-WSG-User VSA attribute, then that AD user will be mapped to this user-group (read_only_access) and SZ will auto-generate a local admin user on SZ corresponding to it.
Configuration on NPS side :-
1. Now we move to NPS side and add the vSZ IP as a RADIUS client. This portion is pretty-straightforward so skipping for the sake of brevity.
2. Go to Network Policies under Policy section on the NPS and create a new policy say “szadmin_full_access” and select “unspecified” as type of network access server and click Next to add the conditions.
3. In the specify conditions, click “add” and select “Windows Groups”. Click “add” again and select the AD group ” szadmin_fullaccess”. Click OK > Click Next and then select “Access Granted” and click “Next”.
4. Now, we get the option of selecting the authentication methods, we must select PAP as one of the auth methods for SZ admin logon to support. Now, select “Next” and click No if a warning about unsecure auth appears to proceed further.
5. Select “Next” and go the “Configure Settings” page and select “Vendor specific” from the Radius Attributes. Click on “Add”. Scroll to the BOTTOM of this window and select “Vendor-Specific” and click on Add.
6. Click on “Add” again. Select “Enter Vendor Code” to modify the Vendor Code and enter in the value 25053. Click on “Yes. it does conform”.
7. Now select “configure attribute”. Modify the “Vendor-Assigned attribute number” to 10. Change the “Attribute format” to String from Hexadecimal. Change the “Attribute value” to the local SZ admin which we want our AD admins to mapped to. In our case it would be the value “admin_full_access”.
8. Now click “OK” and review your settings and the click “Finish” to complete the network policy settings.
9. Note that the above rule was to authenticate the users from the specified AD group and then return the Vendor-specific attribute to match the local user created on SZ. Now, we need to create another rule for Domain Users who would just end up with Read only access and will not return any vendor-specific attribute on authentication and therefore SZ will map them using the settings specified under “Default Mapping”. The steps for this rule are same as above except :
A. Under Windows Groups, choose “Domain Users”.
B. Skip the Vendor specific attributes configuration.
10. We would call the second rule as “sz_read_only_policy” and have given it a processing order 2 so that this rule is checked after the first rule “szadmin_full_access” is not matched :-
11. Now we are done in terms of configuration on all sides and it’s time to test it.
Testing and Validation :-
1. Go to “Test AAA” section and first we would test our AD user “admin1” which is supposed to get Super Admin access as per the policy configured. We can see it got mapped to the local user “admin_full_access” which is a member of Super Admin user group on SZ. (Make sure to add the realm/domain in the user name) :-
2. Now, we would test “Bob” who is regular Domain user and is supposed to get only Read_only access of SZ. We can see that Bob has been mapped to the default role and SZ has auto-generated a user “user-4246746” under user-group “read_only_access” confirming Bob will only have read_only access to it.
