The Criteria subtab allows administrators to determine when the policy should be active. There are seven criteria.
Note
All enabled criteria for a particular policy must evaluate true for that policy to match an authenticating user.
Table 248. Criteria Tabs
Criteria | Description |
|---|
LDAP Filter | The LDAP Filter criteria evaluates to true if the authenticating user matches the filter. Administrators can click the magnifying glass to use the LDAP criteria builder, or enter the appropriate LDAP filter in the space provided. Once the Enabled box is checked and the criteria are saved, users matching the LDAP filter will match the authentication policy criteria. The Match the Built-in Admin Account checkbox provides the option to evaluate the idauto::admin account to true, even though it is not an LDAP object. |
Day of Week | The Day of Week criteria evaluates to true if the user is authenticating on one of the configured days of the week as defined in the configured time zone. If no time zone is specified, the RapidIdentity server's time zone will be used. |
Time of Day | The Time of Day criteria evaluates to true if the user is authenticating during the configured time period as defined in the configured Time Zone. If no time zone is specified, the RapidIdentity server's time zone will be used. |
Source Network | Whitelist means that the criteria will only evaluate to true if the authenticating user is communicating with RapidIdentity from one of the networks in the list. Blacklist means that the criteria will only evaluate true if the authenticating user is communicating with RapidIdentity from a network not in the list. Checking the Enable HTTP Header Processing box will match the X-Forwarded For HTTP header used by proxies and load balancers. Clicking Save allows clients whose IP addresses match the criteria. |
Kerberos | Administrators can allow users to authenticate with a Kerberos-enabled browser. The Kerberos criteria only evaluates to true if Kerberos authentication was successful. Users that do not have a Kerberos-enabled browser could be required to match other criteria or methods (e.g., password then TOTP). To include all users in this use case, the Kerberos policy must be ranked higher than the password policy. |
QR Code | The QR Code criteria only evaluates to true if the authenticating user successfully initated the authentication flow by scanning a QR code. Administrators can allow users to print their own QR Code, or allow other users to print user QR Codes, through the RapidIdentity Portal Profiles module. The option to allow QR Code printing is configured in the RapidIdentity Portal Configuration module, in the Profiles Delegation Definition Manager Action tab. The default QR Code width and height are 2.3125 and 3.5 inches, respectively. A new, Secure QR code must be printed every time a user's password changes since the Secure QR Code is related to the user's password. Administrators must install and ensure the RapidIdentity Connect password filter and ensure that both RapidIdentity Portal and RapidIdentity Federation are configured to be able to pull passwords from the directory service. |
FIDO | The FIDO criteria only evaluates to true if the authenticating user has at least one registered FIDO device. If Inverse Match is checked, then the criteria evaluates to true ONLY if the authenticating user does not have a registered FIDO device. |
