KB11624 - [PPS] Suggestions for reducing the impact of an unreachable authentication server

This article describes a method for quickly restoring network access to users when a back-end authentication server fails or becomes unreachable.

How best to quickly restore network access to users when:

• The authentication servers have failed. 

 

• The network link between the PPS and the auth servers is unavailable.

Suggestions on reducing the impact of a failed backend authentication server:

The purpose of this article is to provide suggestions on how to reduce the impact of a failed backend authentication server or network interruption that prevents the PPS from communicating with the backend authentication server. This article in no way should be construed as the ONLY method for working around this type of issue.

Note: It must also be strongly emphasized that implementing this procedure removes security from your network. During this time, ANY user can connect and gain access to the network and all resources normally protected by the PPS and Infranet Enforcer (IE). Special consideration should be taken before implementing this solution, especially for networks that utilize wireless networking. It is much easier to prevent an unwanted user from connecting to a wired port than it is to prevent an unwanted user from accessing the wireless network. 

Note: During the use of the Anonymous server, the PPS does not ask for credentials. Instead it assigns a unique name to each user logging in. For example, the user name would be recorded in the User Access log as “AnonUser1234”. If the user is logging in via the agentless access method, it would also record that host’s IP address. There is no IP address at layer 2 authentication, so the IP address would be displayed as 0.0.0.0

Below are some common deployment scenarios that we will discuss.

• Scenario without Infranet Enforcers

 

• Scenario with Infranet Enforcers

 

Preparation:

For either scenario, the easiest way to allow your users to access the PPS and eventually network resources is to leverage the ANONYMOUS authentication server on the PPS. This auth server will not prompt the user for credentials during an agentless authentication and will accept ANY set of credentials for AGENT (OAC) authentication.

To create an ANONYMOUS authentication server, perform the following procedure:

1. Logon to the PPS’s administrator page:
   
    

• Navigate to the Authentication section and select Auth. Servers.

 

• Click the New drop-down menu and select Anonymous Server:
  
   
• Type a name for the server and click Save Changes:
  
   

The next step is to create a role, which can be assigned to the realm, that will be used ahead of all other roles; if required.

To create the new Role, follow the steps below:

• Click the Auth. Servers menu item to confirm that the server has been added successfully.
  
   
  1. Navigate to the Users section and select User Roles > New User Role:
     
      
• Type a name for the new User Role and click Save Changes:
  
   

Optional: If you have firewalls, to which you push Resource Policies, consider creating an all access policy and assign that policy to the Anon. User Role. This will make all network resources available to all users, during the backend authentication server outage. 

To create the resource policy, perform the following procedure:

• You will now see this page. You will need to adjust the Agent and/or Agentless settings depending on your environment. Be sure to click Save Changes after any edit is made on each screen.
  
   
  1. Navigate to UAC > Infranet Enforcer > Resource Access:
     
      
• Click New Policy and fill in the fields, as shown in the following images:
  
  
   

 

Implementation:

Now that the preparation is done, implement the following; only when the backend authentication server goes down or becomes unreachable.

• Click Save Changes. At this point, the PPS will push this resource to all of the connected Infranet Enforces. Don’t worry, this policy will only be applied to users who are mapped to the Anon. User Role.
  
  Optional: You can create a simple host check policy to use with this configuration. You can still check for Anti-Virus and Firewalls on the users’ PCs. Additionally, if your network infrastructure utilizes a PKI such as the Microsoft Certificate Authority, you can write a host check policy to look for a user certificate or machine certificate before allowing access to the Anon. User Role. 
  
  For information on how to create the Host Check Policy, consult the PPS Admin Guide.
  1. Edit all of your realms that are accessible to the users and change the Auth Server to the DR-Anonymous-Auth server. Navigate to the General section of your user realms.
     
      
• Change the Auth Server to DR-Anonymous-Auth and then click Save Changes.
  
  

 

• Now, move to the Role Mapping section and add the Anon-User-Role to the realm. Click the Role Mapping tab.
  
   
• Click New Rule to create the new rule. Be sure to add the Anon. User Role to the Selected Roles dialog box. Also, select the Stop processing rules when rule matches checkbox. Click Save Changes:
  
   

Once the connection to the backend auth server has been restored, you will want to remove the role mapping policy and reset the authentication server back to its previous setting.  By doing this, you should now be able to authenticate and gain normal access to the network.

• A screen, similar to the one below should display. Move the newly created rule to the top position in the list. Do this by placing a check mark next to the rule and then click the up arrow.
  
  Before moving the rule:
  
  
  After moving the rule: