1. Kaseya
  2. Passly
  3. Policy Manager

Working with Passly Authentication Policies 2023

Authentication Policies

The Authentication Policy is the set of instructions you give to the system that dictates what your Passly users need to do in order to gain access when authenticating. The policies will be enforced whenever a user is signing into Passly either directly or via an agent (e.g. Windows Login Agent).

To get to the Authentication Policies, go to Policy Manager → Authentication. When you first access this page, you will be presented with “Default Auth Policy” already made for you. To access the Default Auth Policy, click its name.

Default Auth Policy

The Default Auth Policy is the basic policy that your system operates under for an unspecified user. Like all Authentication Policies, the default policy operates in an “If/then/else” mandatory set of conditional statements.

The default auth policy states that if “User” “is signing in”, then “set allowed methods” is activated, else “deny access“. By rule of the default auth policy, this means that any user attempting to log in must enter their password otherwise access is denied.

You can create as many policies as you require. If you would like to create a custom Authentication policy, please review the “Adding Authentication Policy” section.

 

Adding Authentication Policies

Overview

To add an Authentication Policy, click the “+” button back on the Authentication Policy 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.
  • ELSE IF: When User wants to set up another IF statement by clicking on Add Additional Rule, ELSE IF modifier appears. It has the same logic as IF.
  • 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, then 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 exceptions to your Policy Element/Criteria. When you specifically want to address what will occur if a user/entity fails to meet the “IF” conditions you’ve set, you should set an “ELSE” operator. This option is required and it’s not possible to leave it blank so that users who do not meet the criteria in the “IF” section above will not permitted to log in.

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 “IF” conditions required under one policy.

Note: more specific conditions should be set firstly, more general conditions - secondly. Otherwise, specific conditions will not be applied on a User.

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 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 Agent “Sign In IP” is an External IP of the machine where agent is installed. You can set authentication rights for users both within and outside the IP address range using CIDR or IPv4 format (ex. 127.0.0.1/24 or 127.0.0.1-127.0.0.225). To get machine’s Sign In IP address you may use or any other option.
  • 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 Windows Logon Agent installed, you can do this using the “Internal IP” option. Be aware that this option works only for Windows Logon Agent and only when Remote Desktop Connection is established. Like Sign in IP, you can enter the IP address range using CIDR or IPv4 format.
  • 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.

Adding a new Authentication Policy

More information on adding a specific policy please see this article. 

Have more questions?

Contact us

Was this article helpful?
0 out of 0 found this helpful

Provide feedback for the Documentation team!

Browse this section