Booches.nl

Connecting the world…

Problems provisioning AP324?

I had to provision some AP324 APs on a standalone Aruba Mobility Controller. The controller runs AOS 8.2.0.2 code and functions as standalone controller. So what could be a problem when provisioning an AP324 via the GUI??? Well during the provisioning I couldn’t choose the desired custom AP group. I can only choose from both default AP groups: default and NoAuthApGroup.

Hhhhmmm, what could be the problem? I created a new AP group with default settings and even changed the settings from my custom AP group to match the settings from the default AP group, but still no option. So I guess this is some kind of bug in the 8.2.0.2 code……..

Eventually I configured the AP via the CLI to get it provisioned in the correct AP group with the correct parameters and that is working fine. Remember: the AP324 is an AP with external antennas so you need to configure the antenna gain during the provisioning. The exact value of the antenna gain can be found in the data sheet. I used the CLI configuration below to provision the AP.

# clear previous provisioning ap list
clear provisioning-ap-list

# enter config mode and configure parameters
config t
provision-ap read-bootinfo ap-name a8:bd:27:cc:50:8e
provision-ap installation indoor
provision-ap a-ant-gain 5.8
provision-ap g-ant-gain 3.8
provision-ap external-antenna
provision-ap ap-group my-ap-group
provision-ap no syslocation
provision-ap no remote-ap

# view the configured parameters
show provisioning-params

# provision the AP
provision-ap reprovision ap-name a8:bd:27:cc:50:8e

# clear provision list and parameters
clear provisioning-ap-list
clear provisioning-params

The AP is configured with the correct parameters, which can also be verified from the GUI….

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.