Working with Passly Authentication Policies

Authentication Policies

Adding Authentication Policies

Overview 

To add an Authentication Policy, click the “+” button back on the Authentication Policy Dashboard page. You’ll be brought to a pop up window that prompts you to create a new Authentication Policy from scratch. In order to build a policy, you must customize its components. The components of a typical Authentication Policy are as follows:

• Policy Name: This option allows you to give a title to your custom policy. It is recommended that the title matches the specific function of the policy, such as its designated user base or set of actions.
• IF: The IF modifier is the initial conditional statement that begins the authentication policy. It states that “IF” a selected policy element meets the selected criteria, the conditional statement will move to the next step of the policy, found in the “THEN” section. The IF modifier can also be read/interpreted as “when”. 
• Policy Element: The Policy Element serves as the “Who/What” of the conditional statement. It is the element in which the policy derives a target for an action/set of actions. 
• Criteria: The Criteria is the condition that must be met by the designated Policy Element in order to activate the course of action set in place by the policy. There are a multitude of combinations unique to every policy element, which will be explained in depth further into the article. 
• AND/OR: In advanced Authentication Policies, you can further specify the Policy Element by selecting the “AND” or the “OR” operation. If “AND” is selected, all criteria must be met to go to the “THEN” section. If “OR” is selected, than only one of the criteria must be met to go to the “THEN” section.
• THEN: The next step in the Authentication Policy creation process is to specify what action/set of actions will be executed should the target fulfill the “IF” criteria. The five actions that can be selected are listed in further detail later in the article. There are no limits to how many “THEN” actions you can select.
• ELSE: If you are making an Authentication Policy rule, there are sometimes exceptions to your Policy Element/Criteria. If you specifically want to address what will occur if a user/entity fails to meet the “IF” conditions you’ve set, you can create an “ELSE” operator.
  Note: This option is required
  

You can also create multiple rules within the Authentication Policy by pressing the “add Additional Rule” button at the top of the creation page. This option is useful if you have multiple sets of “ELSE IF” conditions required under one policy. 

Creating an Authentication Policy

Passly’s Authentication Policy tool ensures that you have complete control over who and what can access your Passly license. Below is a thorough breakdown of the many options of a Passly Authentication Policy. 

IF

Policy Elements and their Criteria

• User: Users are the individual people who have been successfully provisioned under your Passly account. They can be manually added or uploaded via a Directory. When creating a User-element policy, you have four criteria to choose from:
• Is Signing in: This is the criteria previously highlighted in the default auth policy, as it is the most basic action a user can take. This will always evaluate to True and is only needed if it is the only criteria.
• Is Member of Group: You can filter your policy by groups, with stricter or looser requirements based on whether the user is a member of a group. Refer to the “Groups” Article for more information.
• Is Not a Member of Group: You can filter your policy by groups, with stricter or looser requirements based on whether the user is not a member of a particular group. 
• Is Member of Role: You can filter your policy by role, with stricter or looser requirements based on whether the user is a member of a role. Refer to the “Roles” Article for more information. 
• Has Attribute: You can set filters based on attributes on the Users’ records. These attributes are near the bottom of the User Profile and you can add as many attributes as you’d like. Based on these, you can filter the policy. You will need to enter both the attribute name and the value as parameters in the policy and can choose which condition you’d like for the policy (ie. Attribute = Value; Attribute Contains Value, etc).
• Sign In Time: If you would like to create a policy that allows for certain permissions to be granted/denied depending on the time of day,  you may do so with the Sign In Time option. To set a time, first select “Is Before” or “Is After” in the criteria. A third option will appear to set the designated time frame for your Authentication Policy. The Time Zone set will be that of the user’s system.
• Sign In Location: If you would like to create a policy that allows for certain permissions to be granted/denied depending on the current location of the user, you may do so with the Sign In Location option. From here, you can select the criteria to indicate a specific Country, State, City or Postal Code. Once you have selected your type of location, you are then prompted to provide the condition the user’s location must fulfill (is, is not, starts with, ends with, etc.). You can combine multiple locations if you are using the “AND” operator.
• Sign In IP: If you would like to create a policy that allows you to grant/deny permissions based on the External IP address of the machine authenticated to Passly, you can do this using the “Sign In IP” option.

  For Windows Logon agents “Sign In IP” is an External IP of the machine where the agent is installed.

  To get machine’s Sign In IP address you may use https://www.myexternalip.com/ or any other option. (Passly processes “Sign in IP” as an IP address from the incoming TCP package)

  
• Internal IP: If you would like to create a policy that allows you to grant/deny permissions based on the Local IP address of the machine which is connected via Remote Desktop Connection to the machine with WLA installed, you can do this using the “Internal IP” option. It works only for WLA when Remote Desktop Connection is established.

  To get machine’s Internal IP address you may use command netstat -n | find ":3389" | find "ESTABLISHED"where “3389” is a default port number that is used for RDP connection. The command should be executed on the machine that has an active RDP connection to the machine with WLA installed. (Passly processes “Internal IP” as an IP address sent from WLA agent as “caller_ip” header)

  
  
• Sign In Device: You can set an Authentication Policy starting with the simple condition of whether or not the user’s device is, or is not, trusted by Passly using this option. 

THEN

Select an Action

• Set Allowed Methods: The key part of an authentication policy is determining how a user should authenticate their credentials in order to access Passly. Of course, the first and most basic way to authenticate is to enter a password. The “Set Allowed Methods” button allows you to customize how you want users to log in. If this policy is going to be used for a Windows Logon Agent, you will need to uncheck the Set Allowed Methods You are then prompted to select Available Password Authentication Methods, which includes the following:
• Simple Password: This option allows the user to make a simple traditional passphrase/password. They must follow the requirements to set an acceptable password to use for the platform (8-20 characters long, contains letters and numbers, etc.)
• Synced Active Directory Password: If a user or entity is a part of a synced active directory, this option allows them to use a previous password associated with that directory.
• Windows Authentication: This allows a user to login using Windows Authentication. To enable Windows authentication, please read the “Windows Logon Agent” guide.
  Note:  If this policy is going to be used for a Windows Logon Agent, you will need to uncheck the Set Allowed Methods option. 
• Require 2FA: Passly features its own two-factor authentication service and allows for alternative methods of two factor authentication as well. Once selecting the “Require Two-Factor Auth”, you are able to select the following available 2FA methods:
• One-Time Passcodes: This option uses TOTP to generate an 8-digit rotating PIN that the user will need to enter into Passly. This can, most easily, be generated using the Passly Authenticator mobile app, though other Authenticator apps can also be configured.
• Passly Push Authentication: This option requires that the Passly Authenticator app be installed and configured on the user’s mobile device and that internet is available on both the machine and device.
• Universal 2nd Factor (U2F) Token: This option allows users to utilize their U2F token, such as a YubiKey, to complete the 2FA process.
  Note: If this policy is going to be used for a Windows Logon Agent, you will need to select the Require 2FA option. 
• Set Session Lifetimes: The “Set Session Lifetimes” option allows you to customize how long users/entities will remain logged into Passly, and how often the login token refreshes itself. The “Access Token Lifetime” dictates how frequently Passly refreshes itself, and the “Refresh Token Lifetime” sets the timeframe in which the current Passly session will remain active. You can also select whether or not you want to sign out of Passly when closing out your current browser session. For example, Google Chrome ends the current session when closing all tabs/windows. If you select this option, you’ll need to log in again to continue using Passly. By Default, the “Set Session Lifetimes” option, Passly refreshes the access token every 15 minutes for a 480 minute, or 8 hour, lifetime. 
• Trust Device: This option allows you to toggle how long an individual device can be trusted when 2FA is enabled. Once selecting “Allow devices to be trusted when using 2FA”, you have two options to trust devices:
• Verified devices stay trusted unless they haven't been seen for ‘X’: This option allows you to set the limit on how long a user can stay logged out of Passly until they have to verify their device again. As long as the user logs in at least once in the time frame, their device is still trusted. Additionally, the time frame is reset to the beginning. For example, if you set the option to “Verified devices stay trusted unless they haven't been seen for 30 days”, a user can stay logged out of Passly for 29 days, and, if they successfully login, it will be another 30 days of inactivity for their device to be marked as not trusted.
• Devices must be verified every ‘X’: This option allows you to automatically enforce 2FA and require the user to go through the Trust Device process again after a fixed amount of time. Unlike the previous option, the timer does not reset when the user logs in, only resetting at the discretion of the account holder.  
• Deny Access: If you wish to exclude a user, group, or any other class of individuals/entities from your Passly account, you may do so using the “Deny Access” option. This will block the attempted sign in and create an audit log entry containing details of the request. It is important to use caution when using this option as part of your Authentication Policy. For example, if you have your “IF” statement set to “user” and “is signing in” selecting “Deny Access” as your “THEN” statement will prevent any user from accessing Passly, including yourself.

ELSE

The “ELSE” function works similarly to the “AND” function, except it is used to specify what the system should do to entities that do not fill the “IF”, “ELSE IF” requirements. By default, a Policy Element is included in the Policy. This option allows you to set what the system should do in their case. 

Adding an Authentication policy

You can add as many policies as you wish both under authentication and provisioning policies.

Adding a new Authentication policy.

1. Log into your Passly tenant https://(company-name).my.passly.com
2. Select Policy Manager.
   
3. Select Authentication.
   
4. Select the Blue Sign in the bottom right corner.
   
5. Name the Policy.
   

From here you are going to select one of the following Elements.

• Users - Users can be triggered by Sign-in, Role membership, Group membership or a specific attribute.
  
• Sign In time - This is going to allow for a trigger trigger before or after a specific date/time.
  
  
• Sign In Location - Country, State, City.
  
  Select from the following options. 
  
• Sign in IP - Select whether the IP/ Subnet is within the range or outside of a range.
  
  Note: CIDR notations can be used here for ranges.
• Internal IP - elect whether the Internal IP/ Subnet is within the range or outside of a range.
  
• Sign In Device - Device is trusted or not trusted.
  

These are the elements you are using to trigger to the authentication requirements.

Next we select one of the following Actions.

• Set Allowed Methods - The passwords types that can be accepted.
  
• Require 2FA - Which 2FA options are to be used.
  
• Set Session Lifetimes - These settings control how long the user will remain logged before they are signed out.
  
• Trust Device - Set the requirements to Trust a device.
  
  Trusted devices do not require 2FA each time they are accessed. We are setting an arbitrary time length for users.
• Deny Access
  

Note: Care should be taken when working with the Authentication policies. We do not recommend changing the Default Authentication policy until you have tested the new policy you wish to use. Applying a bad policy can lock users out of the tenant or an endpoint

Working with the Default Policy

• Changing the Default Policy to require all users to use 2FA - https://support.idagent.com/hc/en-us/articles/360007548657 

Working with Office 365

• Working with Service accounts and Office 365 - https://support.idagent.com/hc/en-us/articles/360005105878 

Working with a Windows Logon Agent

• Deploying a Windows Logon Agent - https://support.idagent.com/hc/en-us/articles/360005103037