The Criteria subtab allows administrators to determine when the policy should be presented to a particular user. There are seven types of criteria available for directing this decision.
Note
All enabled criteria for a particular policy must evaluate true for that policy to match an authenticating user. Otherwise, the policy will be rendered inactive for that user.
Table 61. 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 Backup Administrator account to true, even though it is not an LDAP object. This provides the ability to access the server even when the Administrator is locked out. |
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. |
Kerberos | Administrators can allow users to authenticate with a Kerberos-enabled browser. The Kerberos criteria only evaluates to true if Kerberos authentication was successful. |
QR Code | The QR Code criteria only evaluates to true if the authenticating user successfully initated the authentication flow by scanning a QR code. |
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. |
