Several years ago (can it really have been 2009?) I wrote up a solution for using tacacs+ as the authentication and authorization source for BIG-IP user management. Much has changed in five years: new roles have been added to the system, tmsh has replaced bigpipe, and unrelated to our end of the solution, my favorite flavor of the free tacacs daemon, tac_plus, is no longer available! This article will cover all the steps necessary to get a tacacs+ installation established on a Ubuntu server, configure tacacs+, configure the BIG-IP to utilize that tacacs+ server, and test the installation. Before that, however, I'll address the role information necessary to make it all work.

BIG-IP Remote Role Details

There are quite a few more roles than previously. The table below shows all the roles available as of TMOS version 11.5.1.

Role Role Value
admin 0
resource-admin 20
user-manager 40
auditor 80
manager 100
application-editor 300
operator 400
certificate-manager 500
irule-manager 510
guest 700
web-application-security-administrator 800
web-application-security-editor 810
acceleration-policy-editor 850
no-access 900

In addition to the role, the console (tmsh or disabled) and partition (all, Common (default) or specified partition) settings need to be addressed.

Installing tac_plus

First, download the tac_plus package from pro-bono to /var/tmp. I'm assuming you already have gcc installed, if you don't, please check google for installing gcc on your Ubuntu installation. Change directory to /var/tmp and extract the package.

 

cd /var/tmp/
#current file is DEVEL.201407301604.tar.bz2
tar xvf DEVEL.201407301604.tar.bz2

 

Change directory into PROJECTS, configure the package for tacacs, then compile and install it. Do these steps one at a time (don't copy and paste the group.)

 

cd PROJECTS
./configure tac_plus
make
sudo make install

 

After a successful installation, copy the sample configuration to the config directory, and copy the init script over to the system init script directory, modify the file attributes and permissions, then apply the init script to the system.

 

sudo cp /usr/local/etc/mavis/sample/tac_plus.cfg /usr/local/etc/
sudo cp /var/tmp/PROJECTS/tac_plus/extra/etc_init.d_tac_plus /etc/init.d/tac_plus
sudo chmod 755 /etc/init.d/tac_plus
sudo update-rc.d tac_plus defaults

 

Configuring tac_plus

Now that the installation is complete, the configuration file needs to be cleaned up and configured. There are many options that can extend the power of the tac_plus daemon, but this article will focus on authentication and authorization specific to the BIG-IP role information described above. Starting with the daemon listener itself, this is contained in the spawnd id. I changed the port to the default tacacs port, which is 49 (tcp).

 

id = spawnd {
  listen = { port = 49 }
  spawn = {
    instances min = 1
    instances max = 10
  }
  background = no
}

 

Next, the logging locations and host information need to be set. I left the debug values alone, as well as the binding address. Assume all the remaining code snippets from the tac_plus configuration are wrapped in the id = tac_plus { } section.

 

  debug = PACKET AUTHEN AUTHOR

  access log = /var/log/access.log
  accounting log = /var/log/acct.log

  host = world {
    address = ::/0
    prompt = "\nAuthorized access only!\nTACACS+ Login\n"
    key = f5networks
  }

 

After the host data is configured, the groups need to be configured. For this exercise, the groups will be aligned to the administrator, application editor, user manager, and ops roles, with admins and ops getting console access. Admins will have access to all partitions, ops will have access only to partition1, and the remaining groups will have access to the Common partition.

 

  group = adm {
    service = ppp {
      protocol = ip {
        set F5-LTM-User-Info-1 = adm
        set F5-LTM-User-Console = 1
        set F5-LTM-User-Role = 0
        set F5-LTM-User-Partition = all
      }
    }
  }
  group = appEd {
    service = ppp {
      protocol = ip {
        set F5-LTM-User-Info-1 = appEd
        set F5-LTM-User-Console = 0
        set F5-LTM-User-Role = 300
        set F5-LTM-User-Partition = Common
      }
    }
  }
  group = userMgr {
    service = ppp {
      protocol = ip {
        set F5-LTM-User-Info-1 = userMgr
        set F5-LTM-User-Console = 0
        set F5-LTM-User-Role = 40
        set F5-LTM-User-Partition = Common
      }
    }
  }
  group = ops {
    service = ppp {
      protocol = ip {
        set F5-LTM-User-Info-1 = ops
        set F5-LTM-User-Console = 1
        set F5-LTM-User-Role = 400
        set F5-LTM-User-Partition = partition1
      }
    }
  }

 

Finally, map a user to each of those groups for testing the solution. I would not recommend using a clear key (host configuration) or clear passwords in production, these are shown here for demonstration purposes only. Mapping to /etc/password, or even a centralized ldap/ad solution would be far better for operational considerations.

 

  user = f5user1 {
    password = clear letmein
    member = adm
  }
  user = f5user2 {
    password = clear letmein
    member = appEd
  }
  user = f5user3 {
    password = clear letmein
    member = userMgr
  }
  user = f5user4 {
    password = clear letmein
    member = ops
  }

 

Save the file, and then start the tac_plus daemon by typing service tac_plus start.

Configuring BIG-IP

Now that the tacacs configuration is complete and the service is available, the BIG-IP needs to be configured to use it! The remote role configuration is pretty straight forward in tmsh, and note that the role info aligns with the groups configured in tac_plus.

 

auth remote-role {
  role-info {
    adm {
      attribute F5-LTM-User-Info-1=adm
      console %F5-LTM-User-Console
      line-order 1
      role %F5-LTM-User-Role
      user-partition %F5-LTM-User-Partition
    }
    appEd {
      attribute F5-LTM-User-Info-1=appEd
      console %F5-LTM-User-Console
      line-order 2
      role %F5-LTM-User-Role
      user-partition %F5-LTM-User-Partition
    }
    ops {
      attribute F5-LTM-User-Info-1=ops
      console %F5-LTM-User-Console
      line-order 4
      role %F5-LTM-User-Role
      user-partition %F5-LTM-User-Partition
    }
    userMgr {
      attribute F5-LTM-User-Info-1=userMgr
      console %F5-LTM-User-Console
      line-order 3
      role %F5-LTM-User-Role
      user-partition %F5-LTM-User-Partition
    }
  }
}

 

Note: Because we defined the behaviors for each role in tac_plus, they don't need to be redefined here, which is why the % syntax is used in this configuration for the console, role, and user-partition. However, if it is preferred to define the behaviors on box, that can be done instead and then you can just define the F5-LTM-User-Info-1 attribute on tac_plus. Either way is supported. Here's an example of the alternative on the BIG-IP side for the admin role.

 

    adm {
      attribute F5-LTM-User-Info-1=adm
      console enabled
      line-order 1
      role administrator
      user-partition All
    }

 

Final step is to set the authentication source to tacacs and set the host parameters.

 

auth source {
  type tacacs
}
auth tacacs system-auth {
  debug enabled
  protocol ip
  secret $M$2w$jT3pHxY6dqGF1tHKgl4mWw==
  servers { 192.168.6.10 }
  service ppp
}

 

Testing the Solution

It wouldn't be much of a solution if it didn't work, so the following screenshots show the functionality as expected in the GUI and the CLI.

F5user1

This user is in the admin group, and should have access to all the partitions, be an administrator, and be able to not only connect to the console, but jump out of tmsh to the advanced shell. You can do this with the run util bash command in tmsh.

User 1 - Administrator GUI

User 1 - Administrator CLI

F5user2

This user is an application editor, and should have access only to the common partition with no access to the console. Notice the failed logins at the CLI, and the partition is firm with no drop down.

User 2 - App Editor GUI

User 2 - App Editor CLI

F5user3

 

 

 

 

This user has the user manager role and like the application editor has no access to the console. The partition is hard-coded to common as well.

User 3 - User Manager GUI

User 3 - User Manager CLI

 

F5user4

Finally, the last user is mapped to the ops group, so they will be bound to partition1, and whereas they have console access, they do not have access to the advanced shell as they are not an admin user.

User 4 - ops GUI

User 4 - ops CLI