Category: SAN

Home / Category: SAN

LDAP(s) Configuration on Brocade switches

26/10/2021 | SAN | No Comments

Brocade LDAPs

In this tutorial we will go through the steps that need to be followed in order to implement LDAP(s) Microsoft Active Directory on Brocade SAN switches.
Authenticating with a local user on any network devices is not only time consuming, but also very dangerous in terms of security.

Before making any changes to your infrastructure, it is always recommended to make a copy of your switch configuration. Always make sure to perform changes onto testing devices before replicating them to your production environment.

On Fabric OS we have the possibility to use LDAP or LDAPS. As you can tell by its name, LDAP is the simple & unsecure protocol, and LDAPS uses certificates to perform the secure authentication.

Certificate for LDAPs service

  1. Log in to your switch using an priviledged account
  2. To list the available certificate on the switch, use the command:
    seccertmgmt show --all
  3. To create the Certificate Signing Request (.csr) use:
    seccertmgmt generate -csr ldap
  4. Note the file name created in the previous step. File should end with .csr extension.
  5. To export the CSR file from the switch use the following command. Make sure to have any FTP client ready for transfer.
    seccertmgmt export -csr ldap -protocol ftp
  6. Have the CSR file signed by your certificate administrator.
  7. First, we will import the CA (root & intermediate) bundled certificate.
    seccertmgmt import -ca -client ldap
  8. If you don’t know how to combine root & intermediate CA certificate, please check Enable HTTPS protocol on Brocade switches under Combining Root and Intermediate certificate.
  9. Next, we will import the bundled certificate again, under server role. Use the same file as on step 6.
    seccertmgmt import -ca -server ldap
  10. Finally, we will import the switch/client certificate that we exported in the previous step, and which should be signed by our certificate administrator.
    seccertmgmt import -cert ldap
  11.  At this point, we have completed LDAP certificates, we can continue with implementation.

Switch authentication methods

There are several methods to authenticate on the switch but we will make use of two. We will use LDAPS as primary authentication and Local DB as secondary. The secondary authentication comes in force if LDAP does not respond or if a local account & password is matched.

To see the current configuration use:

aaaconfig --show
Fabric OS - Show authentication methods
Brocade – Show authentication methods

To add an LDAP server to the switch use the following command:

aaaconfig --add <LDAP server FQDN> -conf ldap -d <domain name>

Where <LDAP server FQDN> is the Fully Qualified Domain Name of the LDAP server, for example

Where <domain name> is the domain name where the LDAP server resides in.

Finally, we will configure LDAP as primary authentication method, and local database as secondary:

aaaconfig --authspec "ldap;local"

LDAP supported configurations

In the picture below we see different authentication configurations. In this tutorial we will use Option 3: LDAPv3 with TLS and Certificate over port 389

LDAP Authentication Supported Configurations
Brocade LDAP Authentication Supported Configurations

LDAPS implementation

Prior to performing any other configuration, we will have to create authentication groups in LDAP, or Active Directory in our case. Make sure to create the desired groups in AD so that we can make the link between them and the switch configuration.

In this example I have created an AD group called “STORCOM FOS Admins”. This LDAP group will be mapped against the local admin role on the switch.

To map the LDAP group with the SAN switch role, use the following command:

ldapcfg --maprole "STORCOM FOS Admins" admin

To add extra attributes, for example domain ID’s, use the following command:

ldapcfg -- mapattr "STORCOM FOS Admins" -l "admin=1-128" -h 128 -c admin

For more available attributes, please check Brocade Fabric OS Command Reference.

To see the existing role mappings, use:

ldapcfg --show

To unmap a role, use:

ldapcfg --unmaprole "STORCOM FOS Admins" admin

Any suggestion or question? Leave a reply below, or feel free to contact us. Also make sure to subscribe to our mailing list to get the latest updates.

Disable Telnet Port 23 on Brocade Switches

Are you considering to disable Telnet port 23? Then this article will help you out.

It’s obvious that more and more companies start investing on the security aspect of their environment. We see that the legendary legacy protocols, such as http, ftp or telnet ports, become useless day by day. As the technology evolves, new more secure protocols become as a new standard.

Prior to FOS 5.3.0 you could turn off the Telnet sevice by executing the configuration command on the switch. However, the latest FOS versions do not support altering communication services by the configuration command. Instead, we will need to modify the ipfilter database and deny traffic on port 23.

Before we start, let me give you a short guide on the steps we will take. As you probably know, the ipfilter is a table where the incoming and outgoing traffic rules are defined. Every switch by default has 2 ipfilters: IPV4 and IPV6. In short, we will:

  • Clone the existing Ipfilter
  • Remove the rule to allow traffic on port 23
  • Define new rule to deny traffic on Telnet port 23
  • Save and activate the new iptables configuration

View existing iptable configuration

To show the current ip filter rules, enter: ipfilter –show

STORFOS:FID128:storcom> ipfilter --show

Name: default_ipv4, Type: ipv4, State: active
Rule    Source IP                               Protocol   Dest Port         Action
1     any                                            tcp       22            permit
2     any                                            tcp       23            permit
3     any                                            tcp       80            permit
4     any                                            tcp      443            permit
5     any                                            udp      161            permit
6     any                                            udp      123            permit
7     any                                            tcp      600 - 1023     permit
8     any                                            udp      600 - 1023     permit

Name: default_ipv6, Type: ipv6, State: active
Rule    Source IP                               Protocol   Dest Port         Action
1     any                                            tcp       22            permit
2     any                                            tcp       23            permit
3     any                                            tcp       80            permit
4     any                                            tcp      443            permit
5     any                                            udp      161            permit
6     any                                            udp      123            permit
7     any                                            tcp      600 - 1023     permit
8     any                                            udp      600 - 1023     permit

Clone existing configuration

Go ahead and clone both iptable configurations. In the example above, they are named: default_ipv4 and default_ipv6. I will give the clones a new name: BlockTelnet_ipv4 and BlockTelnet_ipv6.

ipfilter --clone BlockTelnet_ipv4 -from default_ipv4
ipfilter --clone BlockTelnet_ipv6 -from default_ipv6

Save the clones you just created

ipfilter --save BlockTelnet_ipv4
ipfilter --save BlockTelnet_ipv6

Modify the cloned ipfilters

Next, we will remove rule 2 which permits traffic on port 23, then define a new rule that denies traffic on port 23.

To remove Rule 2 on the cloned ip tables, enter:

ipfilter --delrule BlockTelnet_ipv4 -rule 2
ipfilter --delrule BlockTelnet_ipv6 -rule 2

Use the following command to deny traffic on TCP port 23

ipfilter --addrule BlockTelnet_ipv4 -rule 2 -sip any -dp 23 -proto tcp -act deny
ipfilter --addrule BlockTelnet_ipv6 -rule 2 -sip any -dp 23 -proto tcp -act deny

Save configuration and activate ipfilters

To save the modified ipfilter clones, enter:

ipfilter --save BlockTelnet_ipv4
ipfilter --save BlockTelnet_ipv6

Before you activate, you can double-check the new configuration by entering the command:

ipfilter --show BlockTelnet_ipv4
ipfilter --show BlockTelnet_ipv6

Finally, you can activate the new ipfilters

ipfilter --activate BlockTelnet_ipv4
ipfilter --activate BlockTelnet_ipv6

Removing an ipfilter

Alternatively, if you think need need to clean up the ipfilter policies, it is very easy to do it. Use the following command:

STORFOS:FID128:storcom> ipfilter --delete BlockTelnet_ipv6
This will delete the IP filter policy.
ARE YOU SURE (yes, y, no, n): [no] y


Read here related articles for Brocade switches:

Any suggestion or question? Leave a reply below, or feel free to contact us. Make sure to subscribe to our mailing list to get the latest.

SANnav SSL Certificate

SANnav Management Portal utilizes by default a self-signed certificate, which in most cases is considered as vulnerability. Therefore, it is highly recommended to replace it by a CA signed certificate. The SSL/TLS certificate ensures that the connection between clients and the server is secure.

The replacement is done in 2 steps. First, we will create a Certificate Signing Request, which will be signed by our Certificate Authority. Then the signed certificate will be imported to the SANnav. In addition, you will also need the root and the intermediate certificates to be imported.

Make sure to read the SANNav Management Portal guide for detailed information.

Creating SANnav Certificate Signing Request

  1. Log in to your SANnav server (RedHat/CentOS)
  2. Additionally, create a new directory under /root/, you can call it /root/certificates/
    cd /root
    mkdir certificates
    cd /root/certificates
  3. To start, we will create the certificate signing request (.csr)
    openssl req -newkey rsa:2048 -nodes -keyout sannav.key -out sannav.csr
  4. Enter the certificate information regarding to your host and the company information
  5. Let your SANnav (sannav.csr) be signed by your Certificate Authority

At this point you would have received the signed certificate, together with the accompanying root and intermediate certificate.

Replacing the self-signed certificate

  1. Copy your signed certificate, together with the company’s root and the intermediate certificate to /root/certificates/
  2. First, we will need to merge the root and the intermediate certificate into one file. Use the following command:
    cat intermediate_certificate.crt root_certificate.crt > bundleCertificate.pem
  3. Launch the script found under /<sannav-installation-directory>/bin/
  4. Complete the certificate file paths as requested by the wizard:
    – Enter the path for the ssl certificate including file name: /root/certificates/sannav.cer
    – Enter the path for the ssl key including file name: /root/certificates/sannav.key
    – If you have root and intermediate CA certificates, please chain them into a single certificate file and provide the path to the file. Press enter to skip this step. /root/certificates/bundleCertificate.pem
  5. Run the script found under /<sannav-installation-directory>/bin/ to restart SANnav
  6. Restart your browser and you’re SANnav Management Portal will show a valid certificate.

Read here related articles about SANnav Management Portal
Preparing RHEL / CentOS Server for SANnav
Installing SANnav Management Portal 2.0

Any suggestion or question? Leave a reply below, or feel free to contact us.
Make sure to subscribe to our mailinglist to get the latest. No spam. Promised!

Installing SANnav Management Portal 2.0

22/12/2019 | SAN | 1 Comment

In our previous article, we have gone through the installation steps of RHEL/CentOS, and the basic configuration of SANnav. This article will further focus on implementing the prerequisites and installing SANnav Management Portal.

Before we start, make sure to read Preparing RHEL / CentOS Server for SANnav and SANNav Management Portal guide.

Implementing prerequisites

    1. If you are not the owner of the server, make sure to have the root privileges on your Linux system.
    2. Uninstall other applications from your server.
    3. If you have previously installed Docker, uninstall it.
    4. ‘Ensure that the entire physical server (boot, log, and data) runs on a single partition. In my case, I have 3 partitions and an LVM but I’m using virtual disks on the underlying layer.
  • Ensure that lsof and nslookup packages are installed on the server.
    1. To install, use the command:
yum install lsof, bind-utils
  • The ‘umask’ for the root user must be set to 0022.
    1. By default root has already this value, if not use the following command to change it:
umask 0022
  1. Open /etc/security/limits.conf and add the following line at the end: elasticsearch – nofile – 65536
    vi /etc/security/limits.conf
  2. Port 22 is by default in use for SSH. You either keep it for SSH and use it for SANNav repository or change it to another port. To change the default SSH configuration, open /etc/ssh/sshd_config, uncomment #port 22 and change it to 8022.
    Restart SSHD service using the command:

    systemctl restart sshd
  3. Port 80 must also be available. If you are using a firewall in your environment, make sure to open the ports. I would recommend to disable the firewall during installation and enable it after implementing SANnav. See also firewall requirements on the guide.
  4. It is required to have IP forwarding enabled. You can verify using the following command:
    /sbin/sysctl net.ipv4.ip_forward

    To enable IP Forwarding permanently, open the /etc/sysctl.conf file and add the following lines:
    # Enable IP Forwarding for SANnav
    net.ipv4.ip_forward = 1

  5. Ensure that hostname -i resolves to an IP address. If your server is in your domain, hostname -f must resolve to an FQDN.
  6. Ensure that nslookup is successful when launched against other servers.
    If not, verify that /etc/hosts, /etc/nsswitch.conf and that your network card interface is valid.

Installing SANnav Management Portal

I have already downloaded the .tar.gz (compressed packaged) file of SANnav. Using WinSCP I transferred it from my Windows computer to the /root/ directory of the RHEL server.

  1. Locate the file you downloaded and extract it using the command:
    tar -xvzf Portal_2.0.0-distribution.tar.gz
  2. Inside the /bin/diag there is a script which tests the prerequisites. Go to Portal_2.0.0_rc_bld204/bin/diag/ and launch

    Verify SANNav Prerequisites
    Verify SANNav Prerequisites
  3.  On the screenshot above, the check claims that nslookup failed but it’s a false positive warning. Didn’t check further but it’s probably due to the package name having another name under RHEL. Launching nslookup commands towards my hosts works like a charm.
  4. To start the installation script, go to /<copied folder>/bin and launch

    SANnav installation script
    Installing SANnav using the single-node installation script
  5. On the following screen, accept the License Agreement to continue the installation.
  6. Once the installation of Docker is completed, the setup will proceed with SANnav installation.
  7. At a certain point, you are asked to select the method of communication between SANnav Management Portal and SAN Switches. If you don’t plan to use https and your switches are not configured, select 0 for http. If your switches are already using https connections, select option 1. Optionally you can also select 2 which is https then http.

    SANnav port configuration
    SANnav port configuration
  8. The setup will continue for about 20 minutes. Once it has completed you can launch the client web page on http://<your sever ip>

    SANnav Management Portal 2.0
    SANnav Management Portal web interface.

If you are considering to install a CA-signed certificate, make sure to follow the steps from SANnav: Installing CA signed SSL.

To enable https protocol on your Brocade switches, use the steps as described on Enable HTTPS protocol on Brocade switches.

Any suggestion or question? Leave a reply below, or contact us. Make sure to also subscribe to our mailing list.

Enable HTTPS protocol on Brocade switches

11/12/2019 | SAN | 11 Comments

This article will focus on implementing CA-signed certificates and enabling the HTTPS protocol on Brocade switches. I assume you already have a Certificate Authority implemented and you can sign certificates requests.

Required/used freeware

Putty: Used to connect to the switch.
Alex’s FTP Server: Used to upload and download files from or onto the switch.
OpenSSL: Used to convert and test certificate files.
Dos2Unix: Used to convert Windows-created filed to Unix/Linux files.

Deprecated commands:
seccertUtil CLI will be deprecated. Use secCertMgmt for Certificate related operations.

The command seccertUtil is replaced by secCertMgmt.

It is highly recommended to back up your switch configuration before performing any changes. For tracing purposes, I have configured my Putty terminal to log every session. It will also flush the log file frequently.

Generating Certificate Signing Request (.csr) file

To list available certificates on the switch use the command:

seccertmgmt show -all

To create the .csr file in interactive mode type

seccertmgmt generate -csr https
Generate the Certificate Signing Request
Generate certificate signing request file on Brocade switch

Generate the file and export it locally. Accordingly, request your CA to have it signed.

The following command exports the .csr file in an interactive mode:

seccertmgmt export -csr https -protocol ftp
Export Certificate Signing Request
Export Certificate Signing Request (.csr) file using FTP

Preparing certificates for import

I signed the client’s certificate and got it in a .cer file. I also have the Root and Intermediate certificates in my possession.

Brocade switches require to have root and intermediate certificates merged into one file. The merge order is also important, first the Root certificate then the Intermediate. Work your way up the chain to the root certificate.

Before merging the certificates we will convert them to .pem files. To convert them from .cer to .pem file format use the following command

openssl x509 -in <certificate path & file name> -out <certificate path & file name>
Convert certificate .cer to .pem file
Converting certificate .cer files to .pem file format
Convert certificate files from .cer to .pem format
Converting certificate .cer files to .pem file format

Combining Root and Intermediate certificate

To merge the certificates use the Windows copy command. The /B parameter prevents Windows to append ASCII characters (CTRZ – Z) to the file.

copy /B <file name path 1> <file name path 2> <destination file name path>
Merge certificate files
Merging root and intermediate certificate files

Converting Windows files to Unix

Files created in Windows are sometimes incorrectly read in Unix/Linux. It’s because of Windows handling i.g. newlines and carriage returns in a different way.

In order to “clean” the certificates, we will use the tool dos2unix to convert them into Unix files.

dos2unix.exe <file name>

The file is rewritten and the output is saved under the same location.

Convert windows to unix files
Use dos2unix to convert Windows files to Unix-readable files

Testing certificates

Additionally, we can test the certificate chain and our client certificate using the following command.

openssl verify -verbose -purpose sslserver -CAfile <root certificate.pem> <switch certificate.pem>
Test certificate
Testing client certificate compatibility with the certificate authority chain

Importing certificates

First, we will import the root certificate using the command below.

seccertmgmt import -ca -server https
Importing CA root certificate
Importing CA chain certificate onto the switch

Finally, we can import the switch certificate file.

seccertmgmt import -cert https
Importing client certificate
Importing the client’s certificate onto the switch

We have enabled the switch to communicate over HTTPS protocol and HTTP requests are redirected to HTTPS.

I’ve noticed my Brocade Network Advisor claims that the switch is unreachable after installing the certificate. Finally, I got this resolved by performing a hareboot. The hareboot restarts the web linker daemon which is responsible for web communication.

Any suggestion or question? Leave a reply below, or feel free to contact us. Make sure to subscribe to our mailing list to get the latest.

Brocade ISL Trunk configuration

07/11/2019 | SAN | 4 Comments

One of the most interesting parts of administrating FC switches is implementing ISL’s (Inter-Switch Links) between 2 datacenters. In this article, we will cover the steps that need to be taken in order to create a fabric. We assume that the physical link (cabling) has already been set up and that the switch is already configured.

On the demonstration below I’m using Brocade SAN switches G62-series running Fabric OS version 8.0.2e.

  1. We start off by disabling the switch.
    FOS_STORCOM1:admin> switchdisable
  2. Next, we need to configure the port speed of the ports which will be inter-connected.
    FOS_STORCOM1:admin> portcfgspeed -i <port number> -f <port speed>

  3. Brocade SAN switches can be easily configured using the configure command. Once entered  it will lead you through some important configuration steps.
  4. Next, we’ll need to calculate the ISL distance. A rule of thumb will be to multiply the real physical distance with 1.5 to get the ISL distance.
    real_distance_km x 1.5 = ISL_logical_distance

    In my case, I have two switches with a physical distance of 146 km. I will use 220 km as ISL distance.

  5. To activate the port in LS (Long Distance Dynamic) mode enter the following command
    FOS_STORCOM1:admin> portcfglongdistance <port number> LS 1

    A vc_link_init value of 1 uses the ARB fill word (default). A value of 0 uses IDLE. The required value might depend on the link being used. The commands must be repeated for each ISL port.

  6. Optionally, you can enable the QOS on the ISL ports by using the following command:
    FOS_STORCOM1:admin> portcfgqos --enable <port number>
  7. To check and confirm the port parameters use the following command:
    FOS_STORCOM1:admin> portshow <port number>
  8. At this step the port is ready. Enable the switch and the ports using the following commands
    FOS_STORCOM1:admin> switchenable
    FOS_STORCOM1:admin> portcfgpersistantenable <port number>
  9. Log on to the second switch and perform the same operations from Step 1 to Step 7
  10. Your SAN fabric should be ready now. Verify it using the following commands:
    FOS_STORCOM1:admin> fabricshow
    FOS_STORCOM1:admin> trunkshow

The article Essential troubleshooting command lines every Storage Administrator should know offers interesting stuff related to the switch administration.

A complete command line list and other switch administration can be found on the Brocade Fabric OS Administration Guide.

Any suggestion or question? Leave a reply below, or feel free to contact us. Make sure to subscribe to our mailing list to get the latest.