When client1 is operational, client2 can be added relatively easy.Įnsure a policy and a separate set of attributes, if needed, exist. crypto ikev2 name-mangler GET_NAMEĪaa authorization group psk list default name-mangler GET_NAME The mangler splits the email address into username and domain portion and uses only one of them (username in this case) to choose the name of authorization policy. The clients should use an email address of (X is 1 or 2, dependent on the client). In this case, extract the username portion of the identity sent by the clients. crypto ikev2 authorization policy Client1Įnsure that this new policy used by the clients that connect. policy-map TESTĪssign AAA attribute list to an authorization policy. In this case, policy-map was previously configured. Note: Remember that the entity assigned via attributes must exist locally. aaa attribute list Client1Īttribute type interface-config "ip mtu 1300" protocol ipĪttribute type interface-config "service-policy output TEST" protocol ip This example shows complete work for client1 then it shows how to add another client/user.ĭefine a AAA attribute list. There are a few things needed to assign AAA attributes to a particular session. aaa new-modelĬrypto ikev2 authorization policy default Cisco recommends the use of certificates whenever applicable. The greatest limitation of this configuration is usage of pre-shared key (PSK) as the authentication method. This configuration is for reference only and is not meant to be optimal, only functional. The hub configuration is divided into two parts:īasic connectivity configuration, which outlines the configuration needed for basic connectivity.Įxtended configuration, which outlines the configuration changes needed in order to demonstrate how an administrator can use the AAA attribute list to perform per-user or per-session configuration changes. Tunnel protection ipsec profile default Hub Configuration aaa new-modelĪaa authorization group psk list default default In this configuration, notice that only change is identity between Client1 and Client2 (displayed in bold). Spoke configuration is here for reference. Spoke ConfigurationĪs mentioned previously, most of the actions in this documentation are performed on the hub. For Cisco recommendations on cryptography, visit the Next Generation Encryption page on. The configurations in this document are intended to show a basic setup, with smart defaults as much as possible. A hub router (ASR) and two spoke routers (ISR) are utilized, which simulate clients. The topology used in this exercise is basic. Refer to Cisco Technical Tips Conventions for more information on document conventions. If your network is live, make sure that you understand the potential impact of any command. All of the devices used in this document started with a cleared (default) configuration. The information in this document was created from the devices in a specific lab environment. ISR G2 routers have the ipbasek9, securityk9, and hseck9 feature licenses enabled. Integrated Services Routers Generation 2 (ISR G2) - 3945e - called "bsns-3945e-1"Ĭisco IOS® Software Release 15.2(4)M1 and 15.2(4)M2ĪSR routers have the adventerprise and ipsec feature licenses enabled. Integrated Services Routers Generation 2 (ISR G2) - 3925e - called "bsns-3925e-1" This list does not outline the minimum requirements, but reflects the state of the device throughout the test phase of this feature.Īggregation Services Routers (ASR) - ASR 1001 - called "bsns-asr1001-4" The information in this document is based on, but not limited to, these software and hardware versions. There are no specific requirements for this document. Such deployments are typically proof-of-concept labs, new deployment testing, or troubleshooting.ĭynamic configuration is important on the concentrator/hub side where different policies or attributes should be applied on a per-user, per-customer, per-session basis. This is desired in certain scenarios, especially when rapid deployment or test is required. This configuration example demonstrates how to use local Authentication, Authorization, and Accounting (AAA) attribute list in order to perform dynamic and potentially advanced configuration without the use of external Remote Authentication Dial-In User Service (RADIUS) server.
0 Comments
Leave a Reply. |