Chapter 19. Storage Security
Like IP infrastructure, the storage infrastructure must be protected from security vulnerabilities such as denial of service (DoS) and other malware attacks. In addition, elevation of privileges can also occur if a guest’s account is not managed properly. These security risks can result in data being stolen, corrupted, and applications not functioning properly. Because of its broad capabilities, unique security considerations must be addressed when deploying the storage infrastructure in your network. The Cisco MDS 9000 NX-OS software supports advanced security features that provide security within a storage-area network (SAN). These features protect your network against deliberate or unintentional disruptions from internal or external threats.
This chapter discusses the following key topics:
• Authentication, Authorization, and Accounting (AAA): This section discusses the concepts of authentication, authorization, and accounting. Later in this section, we discuss server groups, server monitoring, remote and local AAA services, server distribution using CFS, and implications of merging RADIUS and TACACS+ configurations.
• User Accounts and RBAC: This section discusses user roles, rules, and policies related to user roles, along with RBAC sample configuration.
• Port Security: This section discusses port security configuration and verification.
• Fabric Binding: This section discusses fabric binding configuration and verification. Later in this section, we compare port security with fabric binding features.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 19-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
Table 19-1 “Do I Know This Already?” Section-to-Question Mapping”
Caution
The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.
1. Which of the following statements are INCORRECT regarding TACACS+? (Choose two answers.)
a. TACACS+ uses the TCP transport protocol to send data between the AAA client and server, making reliable transfers with a connection-oriented protocol.
b. TACACS+ provides independent, modular AAA facilities. Authorization can be done without authentication.
c. TACACS+ encrypts passwords only.
d. TACACS+ is an open protocol supported by multiple vendors.
2. The LDAP client/server protocol uses which TCP port number for transport requirements?
a. 2003
b. 1812
c. 389
d. 49
3. Which of the following statements are CORRECT regarding user roles on MDS 9000 Family switches? (Choose two answers.)
a. User roles contain rules that define the operations allowed for the user who is assigned the role.
b. Each user role can contain multiple rules, but each user cannot have multiple roles.
c. Up to 16 rules can be configured for each role.
d. User roles cannot be used to create VSAN administrators.
4. Which of the following statements are TRUE regarding the port security feature? (Choose two answers.)
a. Port security binds the fabric at the switch level.
b. Port security requires activation on a per-VSAN basis.
c. Port security cannot be distributed by CFS.
d. Port security uses pWWNs/nWWNs or fWWNs/sWWNs.
5. Port security can be configured using which of the following methods? (Choose three answers.)
a. Manual Database Configuration
b. Auto-Learning without CFS Distribution
c. Fabric Binding
d. Auto-Learning with CFS Distribution
6. Which statements are TRUE regarding the fabric binding feature? (Choose two answers.)
a. The fabric binding feature helps prevent unauthorized switches from joining the fabric or disrupting current fabric operations.
b. Fabric binding is configured on a per-VSAN basis.
c. Fabric binding can be distributed by CFS and hence configured automatically on each switch in the fabric.
d. Fabric binding uses pWWNs/nWWNs.
7. Which databases are managed by the fabric binding feature? (Choose two answers.)
a. Configuration database
b. Inactive database
c. Active database
d. Startup database
Foundation Topics
Authentication, Authorization, and Accounting
The authentication, authorization, and accounting (AAA) feature verifies the identity of, grants access to, and tracks the actions of users managing a switch. All Cisco MDS 9000 Family switches use Remote Authentication Dial-In User Service (RADIUS), Terminal Access Controller Access Control System Plus (TACACS+), or Lightweight Directory Access Protocol (LDAP) protocols to provide solutions using remote AAA servers. The AAA Services can also be provided locally by the switch. This security feature provides a centralized user account management capability for AAA servers.
AAA uses security protocols to administer its security functions. If your router or access server is acting as a network access server, the communication between your network access server and the RADIUS, TACACS+, or LDAP security server is through AAA.
Based on the user ID and password combination provided, switches perform local authentication or authorization using the local database or remote authentication or authorization using an AAA server. A preshared secret key provides security for communication between the switch and AAA servers. This secret key can be configured for all AAA servers or for only a specific AAA server. This security feature provides a central management capability for AAA servers.
In this chapter, we concentrate on AAA functionality on Cisco MDS switches. Cisco MDS switches can be accessed using various methods, including the command-line interface (CLI) or Simple Network Management Protocol (SNMP). You can access the CLI using the console (serial connection), Telnet, or Secure Shell (SSH). You can secure the access to any switch in the Cisco MDS 9000 Family using the AAA switch functionalities. AAA switch functionality on any switch in the Cisco MDS 9000 Family can be configured using the CLI, Data Center Network Manager (DCNM), or an SNMP application.
Authentication
Authentication is the process of verifying the identity of the person or device accessing the switch. This identity verification is based on the user ID and password combination provided by the entity trying to access the switch. Cisco MDS 9000 Family switches allow you to perform local authentication (using the local lookup database) or remote authentication (using one or more RADIUS or TACACS+ servers).
Authorization
Authorization provides access control. It is the process of assembling a set of attributes that describe what the user is authorized to perform. Based on the user ID and password combination, the user is authenticated and authorized to access the network as per the assigned role. We discuss user roles later in this chapter. You can configure parameters that can prevent unauthorized access by a user, provided the switches use the TACACS+ protocol.
AAA authorization is the process of assembling a set of attributes that describe what the user is authorized to perform. Authorization in the Cisco NX-OS software is provided by attributes that are downloaded from AAA servers. Remote security servers, such as RADIUS, TACACS+, and LDAP, authorize users for specific rights by associating attribute-value (AV) pairs, which define those rights with the appropriate user.
The following authorization roles exist in all Cisco MDS switches:
• Network operator (network-operator): Has permission to view the configuration only. The operator cannot make any configuration changes.
• Network administrator (network-admin): Has permission to execute all commands and make configuration changes. The administrator can also create and customize up to 64 additional roles.
• Default-role: Has permission to use the GUI (DCNM and Device Manager). This access is automatically granted to all users for accessing the GUI.
• server-admin: Predefined system role for server administrators.
These roles cannot be changed or deleted. You can create additional roles and configure the following options:
• Configure role-based authorization by assigning user roles locally or using remote AAA servers.
• Configure user profiles on a remote AAA server to contain role information. This role information is automatically downloaded and used when the user is authenticated through the remote AAA server.
Note
If a user belongs to only one of the newly created roles and that role is subsequently deleted, the user immediately defaults to the network-operator role.
Accounting
The accounting feature tracks and maintains a log of every management configuration used to access the switch. This information can be used to generate reports for troubleshooting and auditing purposes. Accounting logs can be stored locally or sent to remote AAA servers. The default maximum size of the accounting log is 250,000 bytes and cannot be changed.
Configuration operations are automatically recorded in the accounting log if they are performed in configuration mode. Additionally, important system events (for example, configuration save and system switchover) are also recorded in the accounting log.
Server Groups
You can specify remote AAA servers for authentication, authorization, and accounting using server groups. A server group is a set of remote AAA servers implementing the same AAA protocol. The purpose of a server group is to provide for failover servers in case a remote AAA server fails to respond. If the first remote server in the group fails to respond, the next remote server in the group is tried until one of the servers sends a response. If all the AAA servers in the server group fail to respond, that server group option is considered a failure. If required, you can specify multiple server groups.
AAA Service Configuration Options
AAA configuration in Cisco MDS 9000 Family switches is service based. You can have separate AAA configurations for the following services:
• Telnet or SSH login (DCNM and Device Manager login)
• Console login
• iSCSI authentication
• FC-SP authentication
• Accounting
In general, server group, local, and none are the three options that can be specified for any service in an AAA configuration. Each option is tried in the order specified. If all the options fail, local is tried.
Note
Even if local is not specified as one of the options, it is tried by default if all AAA servers configured for authentication are unreachable. The user has the flexibility to disable this fallback.
AAA Server Monitoring
An unresponsive AAA server introduces a delay in the processing of AAA requests. An MDS switch can periodically monitor an AAA server to check whether it is responding (or alive) to save time in processing AAA requests. The switch marks unresponsive AAA servers as dead and does not send AAA requests to any dead AAA servers. The switch periodically monitors dead AAA servers and brings them to the alive state when they respond. This monitoring process verifies that an AAA server is in a working state before real AAA requests are sent its way. Whenever an AAA server changes to the dead or alive state, an SNMP trap is generated, and the MDS switch warns the administrator that a failure is taking place before it can impact performance.
Figure 19-1 depicts AAA server states.
Figure 19-1 AAA Server States
The monitoring interval for alive servers and dead servers is different and can be configured by the user. AAA server monitoring is performed by sending a test authentication request to the AAA server.
The AAA server monitoring parameters can be configured globally for all servers or individually for a specific server. The global configurations will apply to all servers that do not have individual monitoring parameters defined. For any server, the individual test parameter defined for that particular server will always get precedence over the global settings.
Remote AAA Services
Remote AAA services provided through RADIUS and TACACS+ protocols have the following advantages over local AAA services:
• User password lists for each switch in the fabric can be managed more easily.
• AAA servers are already deployed widely across enterprises and can be easily adopted.
• The accounting log for all switches in the fabric can be centrally managed.
• User role mapping for each switch in the fabric can be managed more easily.
If you prefer using remote AAA servers, follow these guidelines:
• Ensure that a minimum of one AAA server should be IP reachable.
• Be sure to configure a desired local AAA policy because this policy is used if all AAA servers are not reachable.
• Make sure AAA servers are easily reachable if an overlay Ethernet LAN is attached to the switch.
• Ensure SANs connected to the switch have at least one gateway switch connected to the Ethernet LAN reaching the AAA servers.
RADIUS
RADIUS is a distributed client and server system implemented through AAA that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco switches and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.
You can add up to 64 RADIUS servers. RADIUS keys are always stored in encrypted form in persistent storage. The running configuration also displays encrypted keys.
Example 19-1 shows the steps required to configure RADIUS on MDS Switch.
Example 19-1 RADIUS Configuration on MDS Switch
! Entering configuration mode switch# configure terminal ! Configuring the host IP and the preshared key for the selected RADIUS server. In this example, the host is 10.71.58.91 and the key is RadKey. switch(config)# radius-server host 10.71.58.91 key RadKey ! Configuring the destination UDP port number to which the RADIUS authentication messages should be sent. In this example, the host is 10.71.58.91 and the authentication port is 2003. The default authentication port is 1812, and the valid range is 0 to 65366. switch(config)# radius-server host 10.71.58.91 auth-port 2003 ! Configuring the destination UDP port number to which RADIUS accounting messages should be sent. The default accounting port is 1813, and the valid range is 0 to 65366. switch(config)# radius-server host 10.71.58.91 acct-port 2004 ! Configuring the AAA server to be used for accounting purposes. If neither the authentication nor the accounting options are specified, the server is used for both accounting and authentication purposes. switch(config)# radius-server host 10.71.58.91 accounting ! Configuring the global timeout period in seconds for the switch to wait for a response from all RADIUS+ servers before the switch declares a timeout failure. The time ranges from 1 to 1440 seconds. switch(config)# radius-server timeout 30 ! Configuring the number of times (3) the switch tries to connect to a RADIUS server(s) before reverting to local authentication. By default, a switch retries transmission to a RADIUS server only once before reverting to local authentication. You can increase this number up to a maximum of five retries per server. switch(config)# radius-server retransmit 3 ! Configuring the dead timer interval value in minutes. The valid range is 1 to 1440 minutes. The dead timer specifies the interval that the MDS switch waits, after declaring that a RADIUS server is dead, before sending out a test packet to determine if the server is now alive. switch(config)# radius-server deadtime 5 switch(config)# end ! Verifying RADIUS server details switch# show radius-server retransmission count:3 timeout value:30 deadtime value:5 total number of servers:1 following RADIUS servers are configured: 10.71.58.91: available for authentication on port:2003 available for accounting on port:2004 RADIUS shared secret:******** ! Verifying the radius-server statistics switch# show radius-server statistics 10.71.58.91 Server is not monitored Authentication Statistics failed transactions: 0 sucessfull transactions: 0 requests sent: 0 requests timed out: 0 responses with no matching requests: 0 responses not processed: 0 responses containing errors: 0 Accounting Statistics failed transactions: 0 sucessfull transactions: 0 requests sent: 0 requests timed out: 0 responses with no matching requests: 0 responses not processed: 0 responses containing errors: 0 ! Creating a server group named DCCORE and configuring the radius server at IPv4 address 10.71.58.91 to be tried first within the server group DCCORE. switch(config)# aaa group server radius DCCORE switch(config-radius)# server 10.71.58.91 switch(config-radius)# end ! Verifying radius-server groups switch# show radius-server groups total number of groups:2 following RADIUS server groups are configured: group radius: server: all configured radius servers deadtime is 5 group DCCORE: server: 10.71.58.91 on auth-port 2003, acct-port 2004 deadtime is 5
TACACS+
TACACS+ is a security application implemented through AAA that provides a centralized validation of users who are attempting to gain access to a router or network access server. TACACS+ services are maintained in a database on a TACACS+ daemon that typically runs on a UNIX or Windows NT workstation. TACACS+ provides for separate and modular authentication, authorization, and accounting facilities.
TACACS+ is a client/server protocol that uses TCP (TCP port 49) for transport requirements. All switches in the Cisco MDS 9000 Family provide centralized authentication using the TACACS+ protocol. TACACS+ has the following advantages over RADIUS authentication:
• Provides independent, modular AAA facilities. Authorization can be done without authentication.
• Uses the TCP transport protocol to send data between the AAA client and server, making reliable transfers with a connection-oriented protocol.
• Encrypts the entire protocol payload between the switch and the AAA server to ensure higher data confidentiality. The RADIUS protocol only encrypts passwords.
You need to configure the TACACS+ preshared key to authenticate the switch to the TACACS+ server. The length of the key is restricted to 64 characters and can include any printable ASCII characters (white spaces are not allowed). You can configure a global key to be used for all TACACS+ server configurations on the switch. You can override this global key assignment by explicitly using the key option when configuring an individual TACACS+ server.
By default, the TACACS+ feature is disabled in all switches in the Cisco MDS 9000 Family. You must explicitly enable the TACACS+ feature to access the configuration and verification commands for fabric authentication. When you disable this feature, all related configurations are automatically discarded.
Example 19-2 shows the steps required to configure TACACS+ on an MDS Switch.
Example 19-2 TACACS+ Configuration on MDS Switch
! Entering configuration mode. switch# configure terminal ! Enabling TACACS+ in the switch. switch(config)# feature tacacs+ ! Configuring the TACACS+ server identified by the specified IPv4 address. switch(config)# tacacs-server host 171.71.58.91 warning: no key is configured for the host ! Configuring the TCP port for all TACACS+ requests. switch(config)# tacacs-server host 171.71.58.91 port 2 warning: no key is configured for the host ! Configuring the TACACS+ server identified by the specified IPv4 address and assigning the secret key. switch(config)# tacacs-server host 171.71.58.91 key TacKey ! Configuring the timeout period for the switch to wait for a response from the specified server before it declares a timeout failure. switch(config)# tacacs-server host 171.71.58.91 timeout 25 ! Assigning the global secret key (in encrypted format) to access the TACACS+ server. This example specifies 7 to indicate the encrypted format being used. If this global key and the individual server keys are not configured, clear text messages are sent to the TACACS+ server(s). switch(config)# tacacs-server key 7 3sdaA3daKUngd ! Configuring the global timeout period in seconds for the switch to wait for a response from all TACACS+ servers before the switch declares a timeout failure. The time ranges from 1 to 1440 seconds. switch(config)# tacacs-server timeout 30 ! Configuring the dead-time interval value in minutes. The valid range is 1 to 1440 minutes. The dead timer specifies the interval that the MDS switch waits, after declaring a TACACS+ server is dead, before sending out a test packet to determine if the server is now alive. switch(config)# tacacs-server deadtime 5 switch(config)# end ! Verifying TACACS+ server Configuration switch# show tacacs-server Global TACACS+ shared secret:******** timeout value:30 deadtime value:5 total number of servers:1 following TACACS+ servers are configured: 171.71.58.91: available on port:2 TACACS+ shared secret:******** timeout:25 ! Verifying tacacs-server statistics switch# show tacacs-server statistics 171.71.58.91 Server is not monitored Authentication Statistics failed transactions: 0 successful transactions: 0 requests sent: 0 requests timed out: 0 responses with no matching requests: 0 responses not processed: 0 responses containing errors: 0 Authorization Statistics failed transactions: 0 successful transactions: 0 requests sent: 0 requests timed out: 0 responses with no matching requests: 0 responses not processed: 0 responses containing errors: 0 Accounting Statistics failed transactions: 0 successful transactions: 0 requests sent: 0 requests timed out: 0 responses with no matching requests: 0 responses not processed: 0 responses containing errors: 0 ! Creating a server group named DCCORE and configuring TACACS+ server at IPv4 address 171.71.58.91 to be tried first within the server group called the DCCORE. switch(config)# aaa group server tacacs+ DCCORE switch(config-tacacs+)# server 171.71.58.91 switch(config-tacacs+)# end ! Verifying tacacs-server groups switch# show tacacs-server groups following TACACS+ server groups are configured: total number of groups:1 group DCCORE: server 171.71.58.91 on port 2 deadtime is 5
LDAP
The LDAP provides centralized validation of users who attempt to gain access to a Cisco MDS 9000 switch. LDAP services are maintained in a database on an LDAP daemon that typically runs on a UNIX or Windows NT workstation. You must have access to and must configure an LDAP server before the configured LDAP features on your Cisco switch are available.
LDAP provides for separate authentication and authorization facilities. LDAP allows for a single access control server (the LDAP daemon) in order to provide each service authentication and authorization independently. Each service can be tied into its own database in order to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon.
The LDAP client/server protocol uses TCP (TCP port 389) for transport requirements. Cisco MDS devices provide centralized authentication with use of the LDAP protocol.
Clients establish a TCP connection and authentication session with an LDAP server through a simple bind (username and password). As part of the authorization process, the LDAP server searches its database to retrieve the user profile and other information.
You can configure the bind operation to first bind and then search, where authentication is performed first and authorization next, or to first search and then bind. The default method is to first search and then bind.
The advantage of searching first and binding later is that the distinguished name (DN) received in the search result can be used as the user DN during binding rather than forming a DN by prepending the username (cn attribute) with the baseDN. This method is especially helpful when the user DN is different from the username plus the baseDN. For the user bind, the bindDN is constructed as baseDN + append-with-baseDN, where append-with-baseDN has a default value of cn=$userid.
LDAP has the following guidelines and limitations:
• You can configure a maximum of 64 LDAP servers on the Cisco NX-OS device.
• Cisco NX-OS supports only LDAP version 3.
• Cisco NX-OS supports only these LDAP servers:
• OpenLDAP
• Microsoft Active Directory
• LDAP over Secure Sockets Layer (SSL) supports only SSL version 3 and Transport Layer Security (TLS) version 1.
• If you have a user account configured on the local Cisco NX-OS device that has the same name as a remote user account on an AAA server, the Cisco NX-OS software applies the user roles for the local user account to the remote user, not the user roles configured on the AAA server.
To access a remote LDAP server, first create a profile for it on the Cisco NX-OS device. Parameters specific to a server can be added to its profile. These include the use of SSL transport, the target port number on the server, the request timeout period, the root distinguished name (the bind user) and password, and search referrals.
Connectivity to LDAP servers over TLS (via SSL) is RFC4513 compliant. This requires that the identity presented by the server during secure transport negotiation must exactly match both the server profile name and the certificate on the switch. Matching may be by IP address or host name in the certificate “Subject Alternative Name.” This is the preferred method. If there is no match, the common name (CN) in the certificate “Subject” is checked. Server certificates are installed separately on the Cisco NX-OS devices.
Note
By default, when you configure an LDAP server IP address or host name on a Cisco NX-OS device, the LDAP server is added to the default LDAP server group. You can also add the LDAP server to another LDAP server group. Starting from Cisco MDS NX-OS Release 8.2(1), when TCP port 636 is configured, the connection establishment securely starts with an SSL or TLS negotiation. For other ports, this is done explicitly using the enable-ssl keyword.
You can specify one or more remote AAA servers to authenticate users using server groups. All members of a group must be configured to use LDAP. The servers are tried in the same order in which you configure them. You can configure these server groups at any time, but they take effect only when you apply them to an AAA service.
Cisco MDS 9000 Series switches support group-based user roles. You can create a group on the LDAP servers and also create a group with the exact same name on the Cisco MDS switch and then add users to the group. The user role attribute is inherited by the user from the group that is configured. This can be accomplished using the Microsoft LDAP Server’s built-in memberOf attribute. If you wish to use the memberOf attribute, ensure that you create a role name on the switch. The role name must be the same as the group name on the LDAP server. A user can be part of multiple groups, but only one group should be part of the switch role.
Example 19-3 shows the steps required to configure LDAP on an MDS switch.
Example 19-3 LDAP Configuration on MDS Switch
! Entering configuration mode. switch# configure terminal ! Enabling LDAP. By default, the LDAP feature is disabled on the Cisco NX-OS device. You must explicitly enable the LDAP feature to access the configuration and verification commands for authentication. switch(config)# feature ldap ! Configuring the IPv4 or IPv6 address or hostname for an LDAP server. The enable-ssl keyword ensures the integrity and confidentiality of the transferred data by causing the LDAP client to establish a Secure Sockets Layer (SSL) session prior to sending the bind or search request. switch(config)# ldap-server host 10.10.1.1 enable-ssl ! Configuring the rootDN for the LDAP server database and the bind password for the root. The rootDN is used to bind to the LDAP server to verify its state. You can also configure the TCP port to use for LDAP messages to the server. The range is from 1 to 65535, and the default TCP port is the global value or 389 if a global value is not configured. switch(config)# ldap-server host 10.10.1.1 rootDN cn=manager,dc=dccore,dc=com password S5M3Tm timeout 30 ! Configuring the global TCP port to use for LDAP messages to the server. The default TCP port is 389. The range is from 1 to 65535. switch(config)# ldap-server port 5 ! Configuring a global timeout interval that determines how long the Cisco NX-OS device waits for responses from all LDAP servers before declaring a timeout failure. switch(config)# ldap-server timeout 7 ! Configuring the global dead-time interval. The dead-time interval specifies the time that the Cisco NX-OS device waits, after declaring that an LDAP server is dead, before sending out a test packet to determine if the server is now alive. The default value is 0 minutes. The range is from 1 to 60 minutes. switch(config)# ldap-server deadtime 6 ! Creating an LDAP server group and configuring the LDAP server as a member of the LDAP server group. switch(config)# aaa group server ldap DCCOREServer1 switch(config-ldap)# server 10.10.1.1 switch(config)# exit ! Configuring the default AAA authorization method for the LDAP servers. DCCOREServer1 is a server group. The ssh-certificate keyword configures LDAP or local authorization with certificate authentication, and the ssh-publickey keyword configures LDAP or local authorization with the SSH public key. switch(config)# aaa authorization ssh-certificate default group DCCOREServer1 switch(config)# exit ! Verifying the AAA authorization configuration switch# show aaa authorization pki-ssh-cert: group DCCOREServer1 pki-ssh-pubkey: local AAA command authorization: ! Verifying LDAP server switch# show ldap-server timeout : 7 port : 5 deadtime : 6 total number of servers : 1 following LDAP servers are configured: 10.10.1.1: idle time:0 test user:test test password:******** test DN:dc=test,dc=com timeout: 30 port: 389 rootDN: cn=manager,dc=dccore,dc=com enable-ssl: true ! Verifying the LDAP server group configuration switch# show ldap-server groups total number of groups: 1 following LDAP server groups are configured: group DCCOREServer1: Mode: UnSecure Authentication: Search and Bind Bind and Search : append with basedn (cn=$userid) Authentication: Do bind instead of compare Bind and Search : compare passwd attribute userPassword Authentication Mech: Default(PLAIN) server: 10.10.1.1 port: 389 timeout: 30 Search map:
Local AAA Services
When remote AAA servers time out, a local login is attempted, depending on the fallback configuration. For this local login to be successful, a local account for the user with the same password should exist. The system stores the password information in encrypted form. The user is authenticated if the username and password exist in the local authentication configuration. The username command configures local users and their roles.
You can enable/disable fallback to a local database in case the remote authentication is set and all AAA servers are unreachable (authentication error). The fallback is set to local by default in case of an authentication error. You can disable this fallback for both console and ssh/telnet login. Disabling this fallback will tighten the security of authentication. You can enable/disable the fallback using the (no) aaa authentication login default fallback error local command. Replace default with console in this command to disable fallback to the console.
Note
If fallback is disabled for both default and console, remote authentication is enabled, and servers are unreachable, the switch will be locked.
AAA Authentication and Authorization Process
The following steps explain the authentication and authorization process:
1. When you try to log in to the Cisco MDS 9000 Family switch using the Telnet, SSH, DCNM or Device Manager, or console login options, the authentication process starts.
2. After you have configured server groups using the server group authentication method, an authentication request is sent to the first AAA server in the group.
• If the AAA server fails to respond, the next AAA server is contacted and so on until the remote server responds to the authentication request.
• If all AAA servers in the server group fail to respond, the servers in the next server group are contacted.
• If all configured methods fail, by default, the local database is used for authentication.
3. When you are successfully authenticated through a remote AAA server, the following possible actions are taken:
• If the AAA server protocol is RADIUS, user roles specified in the cisco-av-pair attribute are downloaded with an authentication response.
• If the AAA server protocol is TACACS+, another request is sent to the same server to get the user roles specified as custom attributes for the shell.
• If user roles are not successfully retrieved from the remote AAA server, the user is assigned the network-operator role if the aaa user default-role command is enabled. You are denied access if this command is disabled.
4. When your username and password are successfully authenticated locally, you are allowed to log in, and you are assigned the roles configured in the local database.
Figure 19-2 shows a flow chart of the authorization and authentication process for RADIUS remote AAA service.
Figure 19-2 Switch Authentication and Authorization Flow for RADIUS Remote AAA Service
You can enable or disable fallback to a local database in case the remote authentication is set and all AAA servers are unreachable (authentication error). The fallback is set to local by default in case of an authentication error. You can disable this fallback for both console and ssh/telnet login. Disabling this fallback will tighten the security of authentication.
AAA Server Distribution
Configuration for RADIUS and TACACS+ AAA on an MDS switch can be distributed using the Cisco Fabric Services (CFS). The distribution is disabled by default.
After the distribution is enabled, the first server or global configuration starts an implicit session. All server configuration commands entered thereafter are stored in a temporary database and applied to all switches in the fabric (including the originating one) when you explicitly commit the database. The various server and global parameters are distributed, except the server and global keys. These keys are unique secrets to a switch and should not be shared with other switches.
Only switches where distribution is enabled can participate in the distribution activity. A distribution session starts the moment you begin a RADIUS/TACACS+ server or global configuration.
Radius configuration distribution can be configured using the radius distribute command, and TACACS+ server distribution can be configured using the tacacs+ distribute command.
After the implicit distribution session has started, you can check the session status using the show tacacs+ distribution status and show radius distribution status commands for TACACS+ and RADIUS server distribution, respectively.
After you issue the first configuration command related to AAA servers, all server and global configurations that are created (including the configuration that caused the distribution session start) are stored in a temporary buffer, not in the running configuration. To commit the configuration changes, you can use the radius commit or tacacs+ commit command.
Discarding the distribution of a session in progress causes the configuration in the temporary buffer to be dropped, and the distribution is not applied. To discard the RADIUS session in-progress distribution, use the radius abort or tacacs+ abort command. To clear the ongoing CFS distribution session (if any) and to unlock the fabric for the RADIUS or TACACS+ feature, use the clear radius session or clear tacacs+ session command.
Merging RADIUS and TACACS+ Configurations
The RADIUS and TACACS+ server and global configuration are merged when two fabrics merge. The merged configuration is applied to CFS distribution-enabled switches.
When merging the fabric, be aware of the following conditions:
• The server groups are not merged.
• The server and global keys are not changed during the merge.
• The merged configuration contains all servers found on all CFS-enabled switches.
• The timeout and retransmit parameters of the merged configuration are the largest values found per server and global configuration.
Note
If a conflict occurs between two switches in the server ports that are configured, the merge fails.
Use the show radius distribution status or show tacacs+ distribution status command to view the status of the RADIUS or TACACS+ fabric merge.
User Accounts and RBAC
Cisco MDS 9000 Series switches use role-based access control (RBAC) to define the amount of access that each user has when the user logs in to the switch.
With RBAC, you define one or more user roles and then specify which management operations each user role is allowed to perform. When you create a user account for the switch, you associate that account with a user role, which then determines what the individual user is allowed to do on the switch.
User Roles
User roles contain rules that define the operations allowed for the user who is assigned the role. Each user role can contain multiple rules, and each user can have multiple roles. For example, if role1 allows access only to configuration operations, and role2 allows access only to debug operations, users who belong to both role1 and role2 can access configuration and debug operations. You can also limit access to specific VSANs, VLANs, and interfaces.
If you belong to multiple roles, you can execute a combination of all the commands permitted by these roles. Access to a command takes priority over being denied access to a command. For example, suppose a user has RoleA, which denied access to the configuration commands. However, the user also has RoleB, which has access to the configuration commands. In this case, the user has access to the configuration commands.
The Cisco MDS 9000 Family switch provides the following default user roles:
• network-admin (superuser): Complete read and write access to the entire switch.
• network-operator: Complete read access to the switch. However, the network-operator role cannot run the show running-config and show startup-config commands.
• server-admin: Predefined system role for server administrators.
Roles can be used to create VSAN administrators. Depending on the configured rules, these VSAN administrators can configure storage features (for example, zone, fcdomain, or VSAN properties) for their VSANs without affecting other VSANs. Also, if the role permits operations in multiple VSANs, the VSAN administrators can change VSAN membership of F or FL ports among these VSANs.
A custom role user with network-admin privileges is restricted to modify the account of other users. However, only the admin can modify all user accounts.
You can modify the user privileges by performing the following tasks:
1. Modify the role using console authentication.
If you set up the console authentication as local, log on using the local-admin user and modify the user.
2. Modify the role using remote authentication.
Turn off the remote authentication. Log on using the local-admin privileges and modify the user. Turn on remote authentication.
3. Modify the role using LDAP/AAA.
Create a group in LDAP/AAA and rename the group network-admin. Add the required users to this group. The users of this group will now have complete network-admin privileges.
Rules
The rule is the basic element of a role. A rule defines what operations the role allows the user to perform.
Up to 16 rules can be configured for each role. The user-specified rule number determines the order in which the rules are applied. Rules are applied in ascending order. For example, rule 1 is applied before rule 2, which is applied before rule 3, and so on. A user not belonging to the network-admin role cannot perform commands related to roles.
Note
A deny-all statement is assumed as rule 0 so that no action is possible for a user role unless explicitly permitted.
Each rule consists of a rule number, a rule type (permit or deny), a command type (for example, config, clear, show, exec, debug), and an optional feature name (for example, FSPF, zone, VSAN, fcping, or interface).
Regardless of the read-write rule configured for a user role, some commands can be executed only through the predefined network-admin role. For example, if user A is permitted to perform all show commands, user A cannot view the output of the show role command if user A does not belong to the network-admin role.
In cases where a default role is applicable to all users, and a configured role is applicable for specific users, consider the following scenarios:
• Same rule type (permit or deny): If the default role and the configured role for a specific user have the same rule type, the specific user will have access to all the rules of both the default role and the configured role.
If the default role, say A, has the following rules:
• rule 5 permit show feature environment
• rule 4 permit show feature hardware
• rule 3 permit config feature ssh
• rule 2 permit config feature ntp
• rule 1 permit config feature tacacs+
and a specific user is assigned to the following role, say B, with one rule:
• rule 1 permit config feature dpvm
the specific user will have access to the rules of both A and B.
• Different rule type: If the default role and the configured role for a specific user have different rule types for a particular rule, the default role will override the conflicting rule statement of the configured role.
If the default role, say A, has the following rules:
• rule 5 permit show feature environment
• rule 4 permit show feature hardware
• rule 3 permit config feature ssh
• rule 2 permit config feature ntp
• rule 1 permit config feature tacacs+
and a specific user is assigned to the following role, say B, with two rules:
• rule 6 permit config feature dpvm
• rule 2 deny config feature ntp
rule 2 of A and B are in conflict. In this case, A overrides the conflicting rule of B, and the user is assigned the remaining rules of A and B, including the overridden rule:
• rule 6 permit config feature dpvm
• rule 5 permit show feature environment
• rule 4 permit show feature hardware
• rule 3 permit config feature ssh
• rule 2 permit config feature ntp → Overridden rule
• rule 1 permit config feature tacacs+
User Role Policies
You can define user role policies to limit the switch resources that the user can access, or to limit access to interfaces, VLANs, and VSANs.
User role policies are constrained by the rules defined for the role. For example, if you define an interface policy to permit access to specific interfaces, the user does not have access to the interfaces unless you configure a command rule for the role to permit the interface command.
If a command rule permits access to specific resources (interfaces, VLANs, or VSANs), the user is permitted to access these resources, even if the user is not listed in the user role policies associated with that user.
Configuring the VSAN policy on Cisco MDS 9000 Family switches requires the ENTERPRISE_PKG license.
You can configure a role so that it allows tasks to be performed only for a selected set of VSANs. By default, the VSAN policy for any role is permit, which allows tasks to be performed for all VSANs. To selectively allow VSANs for a role, set the VSAN policy to deny and then set the configuration to permit or the appropriate VSANs.
Users configured in roles where the VSAN policy is set to deny cannot modify the configuration for E ports. They can only modify the configuration for F or FL ports (depending on whether the configured rules allow such configuration to be made). This is to prevent such users from modifying configurations that may impact the core topology of the fabric.
RBAC Sample Configuration
Example 19-4 shows the steps required to configure RBAC on an MDS switch.
Example 19-4 RBAC Configuration on MDS Switch
! Entering configuration mode. switch# config terminal ! Creating a role and entering role submode to configure description for the role. switch(config)# role name sangroup switch(config-role)# description Selective SAN group ! Configuring rules for the sangroup role. Allowing users belonging to the sangroup role to perform all configuration commands except fspf config commands. switch(config-role)# rule 1 permit config switch(config-role)# rule 2 deny config feature fspf switch(config-role)# rule 3 permit debug feature zone switch(config-role)# rule 4 permit exec feature fcping ! Deleting rule 3 switch(config-role)# no rule 3 ! Configuring VSAN policy for sangroup role to deny and permitting selective VSANs from VSAN 15 through 20. switch(config-role)# vsan policy deny switch(config-role-vsan)# permit vsan 15-20 switch(config-role-vsan)# end ! Verifying sangroup role switch# show role name sangroup Role: sangroup Description: Selective SAN group Vsan policy: deny Permitted vsans: 15-20 ------------------------------------------------- Rule Type Command-type Feature ------------------------------------------------- 1 permit config * 2 deny config fspf 4 permit exec fcping
Port Security
All switches in the Cisco MDS 9000 Family provide port security features that reject intrusion attempts and report these intrusions to the administrator. Typically, any Fibre Channel device in a SAN can attach to any SAN switch port and access SAN services based on zone membership. Port security features prevent unauthorized access to a switch port in the following ways:
• Login requests from unauthorized Fibre Channel devices (Nx ports) and switches (xE ports) are rejected.
• All intrusion attempts are reported to the SAN administrator through system messages.
• Configuration distribution uses the CFS infrastructure and is limited to those switches that are CFS capable. Distribution is disabled by default.
• Configuring the port security policy requires the ENTERPRISE_PKG license.
To enforce port security, configure the devices and switch port interfaces through which each device or switch is connected, and activate the configuration.
• Use the port World Wide Name (pWWN) or the node World Wide Name (nWWN) to specify the Nx port connection for each device.
• Use the switch World Wide Name (sWWN) to specify the xE port connection for each switch.
Each Nx and xE port can be configured to restrict a single port or a range of ports. Port security policies are enforced on every activation and when the port tries to come up. The port security feature uses two databases to accept and implement configuration changes:
• Configuration database: All configuration changes are stored in the configuration database.
• Active database: This database is currently enforced by the fabric. The port security feature requires all devices connecting to a switch to be part of the port security active database. The software uses this active database to enforce authorization.
You can instruct the switch to automatically learn (auto-learn) the port security configurations over a specified period. This feature allows any switch in the Cisco MDS 9000 Family to automatically learn about devices and switches that connect to it. Use this feature when you activate the port security feature for the first time because it saves tedious manual configuration for each port. You must configure auto-learning on a per-VSAN basis. If enabled, devices and switches that are allowed to connect to the switch are automatically learned, even if you have not configured any port access.
When auto-learning is enabled, learning happens for the devices or interfaces that were already logged in to the switch and the new devices or interfaces that need to be logged in in the future. Learned entries on a port are cleaned up after you shut down that port if auto-learning is still enabled.
Learning does not override the existing configured port security policies. So, for example, if an interface is configured to allow a specific pWWN, auto-learning will not add a new entry to allow any other pWWN on that interface. All other pWWNs will be blocked even in auto-learning mode.
No entries are learned for a port in the shutdown state. When you activate the port security feature, auto-learning is also automatically enabled. You cannot re-activate port security until auto-learning is disabled or deactivated and activated again.
By default, the port security feature is not activated in any switch in the Cisco MDS 9000 Family. When you activate the port security feature, the following apply:
• Auto-learning is also automatically enabled, which means
• From this point, auto-learning happens for the devices or interfaces that were already logged in to the switch and also for the new devices that will log in in the future.
• You cannot activate the database until you disable auto-learning.
• All the devices that are already logged in are learned and are added to the active database.
• All entries in the configured database are copied to the active database.
After the database is activated, subsequent device login is subject to the activated port-bound WWN pairs, excluding the auto-learned entries. You must disable auto-learning before the auto-learned entries become activated.
When you activate the port security feature, auto-learning is also automatically enabled. You can choose to activate the port security feature and disable auto-learning.
If a port is shut down because of a denied login attempt, and you subsequently configure the database to allow that login, the port does not come up automatically. You must explicitly issue a no shutdown CLI command to bring that port back online.
The port security feature can also use the Cisco Fabric Services infrastructure to enable efficient database management, providing a single point of configuration for the entire fabric in the VSAN, and enforce the port security policies throughout the fabric.
All the configurations performed in CFS distributed mode are stored in a pending (temporary) database. If you modify the configuration, you need to commit or discard the pending database changes to the configurations. The fabric remains locked during this period. Changes to the pending database are not reflected in the configurations until you commit the changes.
The first action that modifies the existing configuration creates the pending database and locks the feature in the VSAN. After you lock the fabric, the following situations apply:
• No other user can make any configuration changes to this feature.
• A copy of the configuration database becomes the pending database.
If you commit the changes made to the configurations, the configurations in the pending database are distributed to other switches. On a successful commit, the configuration change is applied throughout the fabric, and the lock is released.
Learned entries are temporary and do not have any role in determining whether or not a login is authorized. As such, learned entries do not participate in distribution. When you disable learning and commit the changes in the pending database, the learned entries become static entries in the active database and are distributed to all switches in the fabric. After the commit, the active database on all switches is identical.
If you discard (abort) the changes made to the pending database, the configuration remains unaffected, and the lock is released.
Note
Port activation or deactivation and auto-learning enable or disable do not take effect until after a CFS commit if CFS distribution is enabled.
Port Security Configuration
Port security can be configured using the following three methods:
• Method 1: Manual Database Configuration
• Method 2: Auto-Learning without CFS Distribution
• Method 3: Auto-Learning with CFS Distribution
Method 1: Manual Database Configuration
Example 19-5 shows the steps required to configure port security by manually configuring the port security database.
Example 19-5 Manual Port Security Configuration on MDS Switch
Step 1 Enable port security. switch# configure terminal switch(config)# feature port-security Step 2 Manually configure all port security entries into the configure database on each VSAN. You can add the port security entries by various ways. Some of the samples are shown below. switch(config)# port-security database vsan 2 ! Configuring the specified sWWN to only log in through port channel 10. switch(config-port-security)# swwn 20:01:33:11:00:2a:4a:66 interface port-channel 10 ! Configuring any WWN to log in through the specified interfaces. switch(config-port-security)# any-wwn interface fc1/1 - fc1/6 ! Configuring the specified pWWN to only log in through the specified fWWN. switch(config-port-security)# pwwn 20:11:00:33:11:00:2a:4a fwwn 20:81:00:44:22:00:4a:9e ! Configuring the specified nWWN to log in through the specified fWWN. switch(config-port-security)# nwwn 26:33:22:00:55:05:3d:4c fwwn 20:81:00:44:22:00:4a:9e ! Configuring the specified pWWN to log in through any port in the fabric. switch(config-port-security)# pwwn 20:11:33:11:00:2a:4a:66 ! Configuring the specified pWWN to log in through the specified interface in the specified switch switch(config-port-security)# pwwn 20:11:33:11:00:2a:4a:66 swwn 20:00:00:0c:85:90:3e:80 interface fc2/1 ! Configuring any WWN to log in through the specified interface in any switch. switch(config-port-security)# any-wwn interface fc2/1 Step 3 Activate port security on each VSAN. This turns on auto-learning by default. switch(config)# port-security activate vsan 2 Step 4 Disable auto-learn on each VSAN. switch(config)# no port-security auto-learn vsan 2 Note: You can combine step 3 and 4 using the command port-security activate vsan 1 no-auto-learn Step 5 Copy the running configuration to the startup configuration This saves the port security configure database to the startup configuration. switch(config)# copy running-config startup-config Step 6 Repeat Step 1 through Step 5 for all switches in the fabric.
Method 2: Auto-Learning Without CFS Distribution
Example 19-6 shows the steps required to configure port security using auto-learning without CFS distribution.
Example 19-6 Auto-Learning Port Security Configuration without CFS Distribution
Step 1 Enable port security. switch# configure terminal switch(config)# feature port-security Step 2 Activate port security on each VSAN. This turns on auto-learning by default. switch(config)# port-security activate vsan 2 Step 3 Wait until all switches and all hosts are automatically learned. Step 4 Disable auto-learn on each VSAN. switch(config)# no port-security auto-learn vsan 2 Step 5 Copy the active database to the configure database on each VSAN. switch# port-security database copy vsan 2 Step 6 Copy the running configuration to the startup configuration. This saves the port security configure database to the startup configuration. switch# copy running-config startup-config Step 7 Repeat Step 1 through Step 6 for all switches in the fabric.
Method 3: Auto-Learning with CFS Distribution
Example 19-7 shows the steps required to configure port security with auto-learning and CFS distribution.
Example 19-7 Auto-Learning Port Security Configuration with CFS Distribution
Step 1 Enable port security. switch# configure terminal switch(config)# feature port-security Step 2 Enable CFS distribution. switch(config)# port-security distribute Step 3 Activate port security on each VSAN. This turns on auto-learning by default. switch(config)# port-security activate vsan 2 Step 4 Issue a CFS commit to copy this configuration to all switches in the fabric. At this point, all switches are activated, and auto-learning. switch(config)# port-security commit vsan 2 Step 5 Wait until all switches and all hosts are automatically learned. Step 6 Disable auto-learn on each VSAN. switch(config)# no port-security auto-learn vsan 2 Step 7 Issue a CFS commit to copy this configuration to all switches in the fabric. At this point, the auto-learned entries from every switch are combined into a static active database that is distributed to all switches. switch(config)# port-security commit vsan 2 Step 8 Copy the active database to the configure database on each VSAN. switch# port-security database copy vsan 2 Step 9 Issue a CFS commit to copy this configuration to all switches in the fabric. This ensures that the configure database is the same on all switches in the fabric. switch(config)# port-security commit vsan 2 Step 10 Copy the running configuration to the startup configuration, using the fabric option. This saves the port security configure database to the startup configuration on all switches in the fabric. switch# copy running-config startup-config fabric
Verification of Port Security
Port security can be verified using the commands shown next.
The show port-security database commands display the configured port security information as shown in Example 19-8.
Example 19-8 Verification of Port Security Database
switch# show port-security database -------------------------------------------------------------------------------------- VSAN Logging-in Entity Logging-in Point (Interface) -------------------------------------------------------------------------------------- 1 21:00:00:e0:8b:07:d9:1d(pwwn) 20:0d:00:05:30:00:95:de (fc1/7) 1 50:06:04:82:bc:02:c3:84(pwwn) 20:0c:00:05:30:00:95:de (fc1/6) 2 20:00:00:05:30:00:95:df(swwn) 20:0c:00:05:30:00:95:de (port-channel 5) 3 20:00:00:05:30:00:95:de(swwn) 20:01:00:05:30:00:95:de (fc1/1) [Total 4 entries]
The show port-security database active command displays the activated database as shown in Example 19-9.
Example 19-9 Verification of Port Security Active Database
switch# show port-security database active -------------------------------------------------------------------------------------- VSAN Logging-in Entity Logging-in Point (Interface) Learnt -------------------------------------------------------------------------------------- 1 21:00:00:e0:8b:06:d9:1d(pwwn) 20:0d:00:05:30:00:95:de (fc1/7) Yes 1 50:06:04:82:bc:02:c3:84(pwwn) 20:0c:00:05:30:00:95:de (fc1/6) Yes 2 20:00:00:05:30:00:95:df(swwn) 20:0c:00:05:30:00:95:de (port-channel 5) Yes 3 20:00:00:05:30:00:95:de(swwn) 20:01:00:05:30:00:95:de (fc1/1) [Total 4 entries]
The show port-security status command displays the port security status as shown in Example 19-10.
Example 19-10 Verification of Port Security Status
switch# show port-security status Fabric Distribution Enabled VSAN 1 :No Active database, learning is disabled, Session Lock Taken VSAN 2 :No Active database, learning is disabled, Session Lock Taken ...
The show port-security violations command displays the violations in the port security database as shown in Example 19-11.
Example 19-11 Verification of Port Security Violations
switch# show port-security violations
--------------------------------------------------------------------------------------
VSAN Interface Logging-in Entity Last-Time [Repeat count]
--------------------------------------------------------------------------------------
1 fc1/7 21:00:00:e0:8b:07:d9:1d(pwwn) Jul 9 08:32:20 2019 [20]
20:00:00:e0:8b:07:d9:1d(nwwn)
1 fc1/6 50:06:04:82:bc:02:c3:84(pwwn Jul 9 08:32:20 2019 [1]
50:06:04:82:bc:02:c3:84(nwwn)
2 port-channel 5 20:00:00:05:30:00:95:de(sww Jul 9 08:32:40 2019 [1]
[Total 2 entries]
Fabric Binding
The fabric binding feature helps prevent unauthorized switches from joining the fabric or disrupting current fabric operations. It ensures ISLs are enabled only between specified switches in the fabric binding configuration. Fabric binding is configured on a per-VSAN basis. It uses the Exchange Fabric Membership Data (EFMD) protocol to ensure that the list of authorized switches is identical in all switches in the fabric.
Fabric binding binds the fabric at the switch level. It authorizes only the configured sWWN stored in the fabric binding database to participate in the fabric. Fabric binding cannot be distributed by CFS and must be configured manually on each switch in the fabric.
The switch login uses both port security binding and fabric binding for a given VSAN. While port security complements fabric binding, they are independent features and can be enabled or disabled separately.
On MDS 9000 Family switches, fabric binding requires either the MAINFRAME_PKG license or the ENTERPRISE_PKG license.
The fabric binding feature must be enabled in each switch in the fabric that participates in the fabric binding. By default, this feature is disabled in all switches in the Cisco MDS 9000 Family. A user-specified fabric binding list contains a list of switch WWNs (sWWNs) within a fabric. If an sWWN attempts to join the fabric and that sWWN is not on the list, the ISL between the switch and the fabric is automatically isolated in that VSAN, and the switch is denied entry into the fabric.
To enforce fabric binding, configure the sWWN to specify the xE port connection for each switch. Enforcement of fabric binding policies is done on every activation and when the port tries to come up. In a Fibre Channel VSAN, the fabric binding feature requires all sWWNs connected to a switch to be part of the fabric binding active database; the domain ID is optional.
The fabric binding feature maintains a configuration database (config-database) and an active database. The config-database is a read-write database that collects the configurations you perform. These configurations are enforced only upon activation. This activation overwrites the active database with the contents of the config-database. The active database is read-only and is the database that checks each switch that attempts to log in. You cannot activate the fabric binding database on the switch if entries existing in the configured database conflict with the current state of the fabric. For example, one of the already logged-in switches may be denied login by the config-database. You can choose to forcefully override these situations. When you save the fabric binding configuration, the config database is saved to the running configuration.
Fabric Binding Configuration
Example 19-12 shows the steps required to configure fabric binding on an MDS switch.
Example 19-12 Fabric Binding Configuration on MDS Switch
Step 1 Enable the fabric-binding feature. switch# configure terminal switch(config)# feature fabric-binding Step 2 Configure a list of sWWNs for devices that are allowed to access the fabric. You can also add the sWWN of another switch for a specific domain ID to the configured database list. switch(config)# fabric-binding database vsan 2 switch(config-fabric-binding)# swwn 21:00:05:30:23:22:22:22 switch(config-fabric-binding)# swwn 20:00:00:05:30:00:4a:1e domain 101 Step 3 Activate the fabric binding database. To forcefully activate the fabric binding database, use the force option. switch(config)# fabric-binding activate vsan 2 [force] Step 4 Copy the fabric binding active database to the fabric binding config database. switch# fabric-binding database copy vsan 2 Step 5 Save the fabric binding configuration. switch# copy running-config startup-config Step 6 Verify the fabric binding configuration. ! Verifying the fabric-binding database switch# show fabric-binding database -------------------------------------------------- Vsan Logging-in Switch WWN Domain-id -------------------------------------------------- 2 20:00:00:de:fb:25:b8:80 0xb1(177) [Local] 2 21:00:05:30:23:22:22:22 Any 2 20:00:00:05:30:00:4a:1e 0x65(101) [Total 3 entries] ! Verifying the fabric-binding active database switch# show fabric-binding database active -------------------------------------------------- Vsan Logging-in Switch WWN Domain-id -------------------------------------------------- 2 20:00:00:de:fb:25:b8:80 0xb1(177) [Local] 2 21:00:05:30:23:22:22:22 Any 2 20:00:00:05:30:00:4a:1e 0x65(101) [Total 3 entries] ! Verifying the fabric-binding statistics switch# show fabric-binding statistics Statistics For VSAN: 2 ------------------------------------ Number of sWWN permit: 0 Number of sWWN deny : 0 Total Logins permitted : 0 Total Logins denied : 0 ! Verifying the fabric-binding status switch# show fabric-binding status VSAN 2 :Activated database ! Verifying the fabric-binding violations. In VSAN 2, the switch was found in the list, but has a domain ID mismatch. switch# show fabric-binding violations --------------------------------------------------------------------------------------VSAN Switch WWN[domain] Last-Time [Repeat count] Reason -------------------------------------------------------------------------------------- 2 20:00:00:05:30:00:4a:1e [0xeb] Nov 25 05:46:14 2003 [2] Domain mismatch
Port Security Versus Fabric Binding
Port security and fabric binding are two independent features that can be configured to complement each other. Table 19-2 compares the two features.
Table 19-2 Fabric Binding and Port Security Comparison
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 20, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.
Review All Key Topics
Review the most important topics in the chapter, noted with the key topic icon in the outer margin of the page. Table 19-3 lists a reference to these key topics and the page numbers on which each is found.
Table 19-3 Key Topics for Chapter 19
Memory Tables and Lists
Print a copy of Appendix C, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix D, “Memory Tables Answer Key,” also on the companion website, includes completed tables and lists to check your work.
Define Key Terms
Define the following key terms from this chapter, and check your answers in the Glossary.
authentication
authorization
and accounting (AAA)
AAA Server
Secure Shell (SSH)
Remote Authentication Dial-In User Service (RADIUS)
Terminal Access Controller Access Control System Plus (TACACS+)
Lightweight Directory Access Protocol (LDAP)
Internet Small Computer Interface (iSCSI)
Fibre Channel Security Protocol (FC-SP)
distinguished name (DN)
base DN
bind DN
OpenLDAP
Microsoft Active Directory
Secure Sockets Layer (SSL)
Transport Layer Security (TLS)
memberOf attribute
cisco-av-pair
Cisco Fabric Services (CFS)
fcping
FSPF
DPVM
port World Wide Name (pWWN)
node World Wide Name (nWWN)
switch World Wide Name (sWWN)
fabric port WWN (fWWN)
Exchange Fabric Membership Data (EFMD)
References
Cisco MDS 9000 Series Security Configuration Guide, Release 8.x: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/mds9000/sw/8_x/config/security/cisco_mds9000_security_config_guide_8x.html
Cisco Nexus 5600 Series NX-OS System Management Configuration Guide, Release 7.x: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/system_management/7x/b_5600_System_Mgmt_Config_7x.html
Configure MDS LDAP TechNotes: https://www.cisco.com/c/en/us/support/docs/voice/mds/118979-config-mds-00.html