Creates a new rule after the highest-numbered existing rule, or at position 1 if there are no rules.
This command configures rules in the local configuration to override the local user account that a remote authentication server determines a remote user should use to log in to an appliance. The remote authentication server uses one of the following methods to determine the local user account:
Mapping to a local user account according to rules set by the aaa authorization map order [PROBLEM LINK] command.
Directly from an attribute in the remote authentication server's response.
An administrator can use the aaa authorization rules rule commands to override this mapping when the specified conditions are met. Rule criteria include the following:
Authentication type
Remote user name
Local user name (before the override)
LDAP group
LDAP search filter
The first rule that evaluates as "true" will override the initial mapping, and the remaining rules will not considered. If a rule contains multiple criteria, each criterion must be met before the rule itself can evaluate as true. For example, if a rule specifies that the remote user name must be "alice" and that the LDAP group cannot be "group_a", the rule will evaluate as true if the user is Alice, but only if she is not in Group A.
Syntax
aaa authorization rules rule append tail <rule1> [<rule2> ...]
Parameters
rule
A variable argument list. Each match- option is a match criterion. If a criterion lists multiple options, they are ORed, but if there are multiple criteria, they are ANDed (see the example, below).
You can specify any of the arguments, in any order. However, the positive and negative forms of the same argument (for example, match-auth-method and match-not-auth-method) are mutually exclusive. With the no form of a command, the match-not argument is unnecessary because the positive form of the argument will delete both forms.
A rule with no match criteria matches no users. To match all remote users, use match-auth-method remote as the only criterion.
Note
A rule that specifies no mapped local user effectively strips the user of any privileges on the system. The user will be able to log in, but will have no role, and then can only log out.
The following options are available:
comment <comment>—Adds a user-readable annotation that makes the rule easier to understand.dup-delete—Specifies that after the rule is added, any others that are exact duplicates of it (except not showing a comment) are deleted. Deleting duplicate rules prevents inadvertent modifications to the configuration.match-auth-method <method-list>specifies the comma-separated list of authentication methods:radius—RADIUS authenticationtacacs+—TACACS+ authenticationldap—LDAP authenticationremote—any remote authentication. Theremotemethod is a special keyword that matches all remote authentication methods (that is, it is the same as listing all of the other four options).x509-cert—X.509 certificate authentication.
match-not-auth-method <method-list>match-remote-username <name-list>—Matches a specific remote user name.match-not-remote-username <name-list>match-mapped-local-username <name-list>—Matches a specific mapped local user name.match-not-mapped-local-username <name-list>match-ldap-group <group>—Matches a specific LDAP group DN.match-not-ldap-group <group>match-ldap-search-filter search <filter>—Matches a specific LDAP search filter.map-local-user <username>—Expresses the outcome of a matched rule. If a rule matches, the user gets the outcome specified by this parameter, and additional rules are not processed. The outcome fully overrides the results of the local user mapping performed after remote authentication, as configured by the aaa authorization map order command. The user gets the specified mapped local user, as well as the role configured locally for that user.Note
If an unknown user (for example, a deleted user) is specified as the
<username>and the rule matches, the user will be unable to log in.Note
A user with a reject user account is automatically locked out and is not associated with a role by default.
match-x509-cert-san-email <string>—Matches against an email address in the Subject Alternative Name field of the client X.509 certificate.match-x509-cert-san-email-username <string>—Matches against the username of an email address without the domain name in the Subject Alternative Name field of the client X.509 certificate.match-x509-cert-san-upn <string>—Matches against the User Principal Name (UPN) that is encoded in the Other Name field in the Subject Alternative Name field of the client X.509 certificate.match-x509-cert-san-upn-username <string>—Matches against the username of the UPN in the Subject Alternate Name field of the client X.509 certificate.match-x509-cert-subject-cn <string>—Matches against the Common Name (CN) from the subject field of the client X.509 certificate.match-x509-cert-subject <string>—Matches against the subject field in the client X.509 certificate.match-saml-attribute <string>—Matches against the attribute element from the SAML assertion.match-saml-nameid <string>—Matches against the name ID element from the SAML assertion.
Each <xxx-list> parameter mentioned above is a comma-delimited list of strings. Each of the strings involved is either unlikely or unable to include commas; but if a literal comma is needed, it may be backslash-escaped.
Examples
Each of the options beginning with match- is a match criterion. If a criterion lists multiple options, these are ORed; but if there are multiple criteria, these and ANDed. So if you ran this command:
aaa authorization rules rule append tail match-remote-username alice,bob,carol match-not-ldap-group xylophones,yurts,zucchinis
then the rule would match if:
((username == alice || username == bob || username == carol) && !(group == xylophones || group == yurts || group == zucchinis
User mode
Administrator
Supported appliances
This command is supported on the following appliances running the specified releases or later:
Malware Analysis: Before Release 6.4
Central Management System: Before Release 6.4. The
x509-certauthentication method was added in Release 7.9.1. New authorization rules were added to match against the fields in the X.509 certificate in Release 7.9.1. New authorization rules were added to match against the name ID and attribute fields in the SAML assertion in Release 8.7.1.Email Security — Server: Before Release 6.4. The
x509-certauthentication method was added in Release 7.9.0. New authorization rules were added to match against the fields in the X.509 certificate in Release 7.9.0. New authorization rules were added to match against the name ID and attribute fields in the SAML assertion in Release 8.4.1.File Protect: Before Release 6.4. New authorization rules were added to match against the name ID and attribute fields in the SAML assertion in Release 8.3.0.
Network Security: Before Release 6.4. The
x509-certauthentication method was added in Release 7.9.1. New authorization rules were added to match against the fields in the X.509 certificate in Release 7.9.1. New authorization rules were added to match against the name ID and attribute fields in the SAML assertion in Release 8.3.2.Intelligent Virtual Execution - Server: Release 7.9. The
x509-certauthentication method was added in Release 7.9.1. New authorization rules were added to match against the fields in the X.509 certificate in Release 7.9.1.172.