Administrator Access

Credentials

Password authentication is handled through:

• netadmin RADIUS instance
• single local account for backup

Key authentication is handled through:

• local accounts

Roles

• ArubaOS:
  • There is a predefined, uneditable list of roles.
  • Local accounts cannot be created without a role.
  • RADIUS accounts set the role with Aruba-Admin-Role VSA.
    • If the VSA is missing, then a default role is applied.
      • The default role is set in the "Management Authentication Profile".
      • Absence of config default is root
      • API: .mgmt_auth_profile.mgmt_default_role.aaa_auth_mgmt_default_role
      • CLI: aaa authentication mgmt default-role
    • If the VSA is invalid, access is denied.
• Airwave:
  • Roles can be created and edited.
  • Local accounts cannot be created without a role.
  • A RADIUS account uses the Arbua-Admin-Role VSA (same as ArubaOS).
    • If the VSA is missing, access is denied.
    • If the VSA is invalid, access is denied.

netadmin accounts

Role config:

• The default role is set to read-only at the highest possible nodes.
  Rational:
  • Damage control in the case of a misconfigured RADIUS account or ArubaOS behavior change.
  • All controllers are descendants of these two nodes.
• All RADIUS accounts must have the Aruba-Admin-Role set.
  Rational:
  • Implicit authorization is confusing and makes it easy to miss mistakes.
• Accounts that should not have access to the wireless controllers should user the value deny, or a role that is exclusive to AirWave.
  Rational:
  • Not all netadmin accounts should have controller access.
  • Some users need access to AirWave, but not the controllers.
  • A bogus value is the only way to deny access to a netadmin account.
  • A consistent, clear value makes for easy auditing.

Who:

• Members of the Network Engineering and Operations (NEO) team have full access.
• Support staff may have read-only access.
  • This is approved by the wireless team lead or Network Operations Manager. Verbal approval is fine.
• Automation has the least access possible for its tasks.

Local accounts

Config:

To view local users via API, check:

• .mgmt_user_cfg_int
• .mgmt_user_ssh_pubkey
• .mgmt_user_web_cacert

Or from the command line:

• show mgmt-user
• show mgmt-user ssh-pubkey
• show mgmt-user webui-cacert

Note that each of these lists partition¹ the local users. That is show mgmt-user will not show users with ssh pubkey access.

admin user

This account can be created while setting up a controller. We opt to do so, as it eases the painful process of setting up an MD.

If the account is created on setup:

• The username is admin.
• The password is set by the engineer.
• ArubaOS doesn't give a choice on either of these.

The account is created at the device level of the config hierarchy, so it overrides any other config that may be set. This creates a management headache, so we opt to remove the account after the MD connects to the MM.

The account on the MMs is a special case. Aruba, in their infinite wisdom, does not allow it to be deleted, nor the role changed. We opt to set a randomly generated password and throw it away. This effectively disables the account.

nis user

• This account is the backup in case network connectivity is lost. Rational:
  • Entropy happens
• It is configured at the highest possible nodes.
  Rational:
  • Entropy happens
  • Centralized config makes for easy password changes
• Role is root.
  Rational:
  • Full access is required to make network config changes

Server settings

Telnet

Telnet is awful and is rightfully disabled by default. We leave it disabled. Unfortunately, verifying it is still disabled is a little tricky. This config is not part of the JSON that can be retrieved from the API. Instead we must either:

• run the show configuration command from ssh (not the API) for each node
• run show telnet on each device directly (either ssh or API).

To do the latter with the python library, do something like:

mm = arubaos.MobilityMaster(f"isb-mm.{domain}", creds)
for host in [md.name for md in mm.mds()]:
    arubaos.Controller(f"{host}.{domain}", creds).show("telnet")["_data"]

Don't forget to check both MMs as well.

SSH

The issues that are actual exploits in the wild are not able to be configured incorrectly. There are a few knobs that are closer to theoretical weaknesses that we opt to tighten up:

• DSA < RSA
• CBC < CTR
• SHA1 < SHA256 (used in an HMAC; when used for signing, it is more serious)

In the API:

{
  "aaa_ssh_cipher": {
    "cipher_suite": "aes-cbc"
  },
  "aaa_ssh_mac": {
    "hmac-sha1": true,
    "hmac-sha1-96": true
  }
}

Again, we find that disabling DSA (.aaa_ssh_dsa) is missing from the config pulled via API.

Audit trail

Commands run on the controllers, via SSH or API, can be found with the Splunk report ArubaOS command audit.