Booches.nl

Connecting the world…

Factory reset Mobility Controller managed by Mobility Master

With the introduction of ArubaOS 8, HPE Aruba Networks introduced the Mobility Master appliance. A Mobility Master appliance takes care of all the control-plane features within your deployment. A Mobility Master provides better user experience, flexible deployment, simplified operations and enhanced performance. Mobility Controllers are added to the Mobility Master as regular controllers and all configuration for the Mobility Controllers is done on the Mobility Master console to provide centralized management.

The question arises: is it as easy as it was to factory reset a Mobility Controller managed by a Mobility Master?

The answer: yes it is, but you need to take one extra step!!

I took a Mobility Controller from the shelve and wanted it to be configured as a standalone controller with ArubaOS 8. The controller was running 6.5 code, but the backup partition already contained an 8.0 code image and was previously managed by a Mobility Master during a workshop. I upgraded the 8.0 code image to the latest 8.2 code image and booted the controller from that partition.

I tried to log in with the credentials from the 6.5 code, but that wasn’t working anymore and I had no clue with credentials were used during the 8.0 workshop. So I started with the default password recovery which is very simple and straightforward. Connect to the console with username “password” and password “forgetme!“. Normally you would configure a new management user and “write erase” the configuration, but this is by default not possible in this scenario. Once you enter “config terminal” you receive the following message.

(controller) *#configure t
This controller is managed by a Mobility Master.
Configuration changes can only be performed on the Mobility Master.

Okay, so maybe I can do a “write erase” directly….

(controller) *#write erase
All the configuration will be deleted and the controller will be reloaded. Press ‘y’ to proceed : [y/n]: y
You do not have permission to execute this command

No, so what’s next? The clue is the command “local-config enable

(controller) *#local-config enable
Warning: ‘local-configure enable’ should only be used for debugging. This will disableAuto-Rollback feature. Please use the command ‘local-configure disable’ after you are done.
Configuration Mode Is Enabled.

Now you have the option to enter “config terminal” and add a new management user, log in with the new user and “write erase” the configuration. Next I rebooted the controller and started with a fresh, factory default controller with ArubaOS 8 software.

(controller) *#configure t
Enter Configuration commands, one per line. End with CNTL/Z

(controller) *(config) #mgmt-user admin root
Password:************
Re-Type Password:************
(controller) ^*(config) #end
(controller) ^*#write mem

Saving Configuration…

Partial configuration for /mm/mynode
————————————
Contents of : /flash/ccm/partial/0/p=sc=mynode.cfg
mgmt-user admin root d442d5b0011f409d930efc3f1a4409d5abb80c1a47e5247626
Configuration Saved.
(controller) *#exit

User: admin
Password:
(controller) *#write erase
All the configuration will be deleted and the controller will be reloaded. Press ‘y’ to proceed : [y/n]: y
Write Erase successful

System will now restart!

ClearPass and InTune Integration Guide

Lately, I have been “playing” with the integration between ClearPass and Microsoft InTune. I found this very good integration guide at the AirHeads Community. I downloaded the Integration Guide and started clicking. In the end, I wasn’t able to sync any attributes from InTune into the EndPoint database. I consulted Aruba TAC and they couldn’t find the problem either. The ClearPass side was configured correctly. The next step should be consulting Microsoft…….

Yesterday I had to change some settings on my own Azure Portal. I needed to configure another App Registration including some custom permissions. Since I never ever have done anything with Azure, I just follow all guides step-by-step. This guide added another (logical) step after changing the required permissions for the Registered App. I had to click “Grant Permissions” after changing the permissions.

So I did the same step for the ClearPass-InTune app registration and the ClearPass API started to fetch the InTune attributes. So if you follow the ClearPass InTune Integration Guide v3.0 you have to add this step after you reached page 19.

 

 

 

 

Download a copy of the integration guide: ClearPass TechNote Extensions – Microsoft Intune Integration v3.0

HPE switch and SSH filetransfer

Upgrading firmware on switches, routers and/or firewalls is a common task for network administrators. Normally I am used to downloading the new firmware from the console of the switch. I normally download the software from a (T)FTP server. While configuring a bunch of HPE 2930F switches for SSH access I noticed that I had the option to configure “ip ssh filetransfer”.

I was curious what I would be able to do with this command and I figured out that it is useful for uploading new firmware to the switch. With the command I am able to upload software from a session on my laptop to the switch. I tested this in my home network with a firmware upgrade of my own HPE 2930F switches.

At first I enabled the “ip ssh filetransfer” option. Ofcourse you need to configure the regular SSH access to the switch, but I guess everybody enables SSH and disables Telnet by default!!!

2930F-01(config)# ip ssh
filetransfer Enable/disable secure file transfer capability.

I downloaded the new software image to my laptop and copy the software via SCP to the switch as primary flash image.

MacBook:Downloads rjn$ scp WC_16_05_0003.swi admin@10.10.1.3:/os/primary

The software is copied directly to the switch. You can check this on the switch:

2930F-01# show flash
Image Size (bytes) Date Version
—————– ———— ——– ————–
Primary Image : 28793113 12/08/17 WC.16.05.0003
Secondary Image : 20530856 10/26/16 WC.16.02.0014

You can also copy the file as secondary flash image and change the boot image via:

2930F-01(config)# boot system flash secondary

To activate the new software, just reload the switch. And don’t forget to get a backup of the configuration first.

Aruba Airwave 8.2.4 and no CLI / shell access

BE AWARE: reading and applying this blog is at your own risk. Following the below procedure could affect the support validity on your Aruba AirWave appliance.

All AirWave firmware versions prior to 8.2.4 gave you shell access to the CentOS operating system. Once you upgrade from 8.2.3 to 8.2.4 you receive the message that the root user won’t be used anymore and you need to log in with the user ampadmin.

Your system has been converted to use AMPCLI. You may now log in as ampadmin. If you lose the password for ampadmin you may log in as amprecovery (password recovery) on the console to reset the ampadmin password.

Remove any OS user accounts you may have created to complete the securing of the system.

Once you log out, the linux shell will no longer be accessible.

Starting from 8.2.4 you only have a basic options menu and no shell access anymore. To me, this is a burden because I cannot install VMware Tools anymore or configure scheduled backups to offsite storage. Luckily there is a way to restore the shell access, but the guidelines below need to be applied directly after the upgrade from 8.2.3 to 8.2.4 and cannot be done on a new 8.2.4 installation.

Some additional information: /etc/passwd file stores essential information, which is required during login i.e. user account information. /etc/passwd is a text file, which contains a list of the system’s accounts, giving for each account some useful information like user ID, group ID, home directory, shell, etc. /etc/passwd contains the following entry before you start the upgrade.

root:x:0:0:root:/root:/bin/bash

Just start the upgrade as you always do, but do not log off after the upgrade is completed. Take another look at the /etc/passwd file and especially the entry for the user root.

root:x:0:0:root:/root:/sbin/nologin

The entry changed and /sbin/nologin disables the shell access for the root user. Change the entry to the default value and you are good to go!!! You should still have access to the shell after logging off or rebooting the appliance.

ClearPass & Sophos Mobile Control

A lot of companies are using MDM to control and manage their (mobile) assets. By connecting the MDM solutions to HPE Aruba ClearPass an organization has the possibility for advanced context-aware access for a (mobile) device to the corporate network, wired and wireless. ClearPass supports multiple MDM solutions via built-in “External Context Servers”, like Airwatch and MobileIron.

The MDM solution from Sophos, Sophos Mobile Control, has no built-in integration with ClearPass. I needed to help a customer to link ClearPass with Sophos Mobile Control, because the customer would like to distinguish BYOD from corporate devices. All corporate devices are managed via Sophos Mobile Control. In this setup, Sophos Mobile Control uses an MSSQL database to store all relevant information. One of the tables in the MSSQL database stores the Wi-Fi MAC address from the asset. I use this table to distinguish the BOYD devices from the corporate devices. If the MAC address of the device is present in the database, the device is a corporate device.

I started by adding the MSSQL database as an authentication source to the ClearPass configuration. The customer created a dedicated SQL user with read-only access to the database. The MSSQL database is added in ClearPass under Configuration – Authentication – Sources. I added a source from the type “Generic SQL DB”.

The next step involves the creation of a proper SQL filter statement. I would like to have the Wi-Fi MAC address as output from the SQL filter. The following SQL filter is used for this (with special thanks to the customer, who had some more experience with SQL statements!!!!)

SELECT LOWER(deviceproperty.value) AS mac_address FROM deviceproperty INNER JOIN device ON deviceproperty.deviceid = device.deviceid WHERE deviceproperty.propertykey = ‘Wi-Fi MAC address’ AND device.managed = ‘managed’ AND deviceproperty.value = ‘%{Connection:Client-Mac-Address-NoDelim}’;

I would like to use the MAC address as a string in the authentication/authorization process. In the end I will check if the MAC address in the RADIUS requests matches a MAC address in the Sophos MDM database. The SQL filter is added in the Filter option within the Authentication Source, like in the image below. Just go to the Attributes tab and choose the option Add More Filters.

The Authentication Source is added to the appropriate Service as Authorization Source. I always add the Source first, before I start to configure some Roles and Role Mappings, because I would like to see which output I receive from the MSSQL database. There are two possible outcomes:

  1. The MAC address exists in the MSSQL database
  2. The MAC address doesn’t exist in the MSSQL database

If the MAC address exists in the MSSQL database, you will see the value of the MAC address in the Access Tracker.

As you can see the MAC address is listed without any delimiter. If the MAC address doesn’t exist in the database, the MAC address won’t be listed in the Access Tracker and you will see the following Alert Message.

Now that we know, which information we receive in the Access Tracker during an authentication request, we can configure the correct Roles and Role Mappings. In this example I assign the Role [VDI Trusted] to the device, when the MAC address from the device equals the MAC address in the MSSQL database.

The last step is easy. Just configure the appropriate Enforcement Policy and Profile you match the Role and set the correct attributes on the Wi-Fi or wired network.