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.
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.
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.
I just configured a Sophos UTM cluster based on software version 9. I was able to configure the appliance via WebAdmin and I could access the User Portal without any problems. The customer is using a Citrix based environment with Internet Explorer 9. IE9 is configured to use the Sophos UTM cluster as proxy server. The customer was able to access the User Portal, but he couldn’t access the WebAdmin page.
When they tried to access the WebAdmin page, the page isn’t shown correctly. The page is crippled and you don’t get the login options for entering username and password. We tried different settings, like adding the page to the trusted websites and to the proxy exemptions. Nothing seemed to help. We asked mighty Google for help and we found the following thread.
The following snippet from the thread solved the problem:
Had one of my guys have this problem already… remove the URL for the UTM from the Compatibility View list (in his case, he had to uncheck the “view intranet sites in compatibility view” checkbox in IE).
The customer changed this Group Policy Object in Active Directory and everybody was happy.
The Aruba Networks Remote Access Points is a nice feature for branch offices or home workers. I use a RAP5WN at home and I configured different SSID’s on the RAP. The SSID’s are in tunnel mode, split-tunnel mode or bridge mode. The bridge mode connections are for my home devices, like my girls iPad and iPhone.
The RAP5WN has four 10/100 FastEthernet ports. I configured wired ap profiles for these ports and they are also configured in bridge mode. All devices in bridge mode receive an IP address from my local internet router (ADSL) and this works without any problems. Devices in bridge mode can directly communicate with each other.
My local internet router has some port forwarding rules configured so I can access the server from the internet. After using the Aruba RAP and physically moving the server from the local router to the Aruba RAP, I couldn’t access the server anymore. I did some more testing and noticed that I couldn’t connect to any device behind the RAP, when I tried to connect to the devices through the uplink port of the RAP.
I checked the configuration of the RAP and especially the wired AP profiles. I couldn’t find any related configuration parameters to change this behavior. Eventually I found the solution within the AP system profile. The setting Session ACL solved my problem. The explanation for the setting is: Session ACL applied on uplink of a remote AP. By default the session acl parameter is configured as ap-uplink-acl. This acl contains the following entries:
ip access-list session ap-uplink-acl
any any udp 68 permit
any any svc-icmp permit
any host 184.108.40.206 udp 5353 permit
I changed this setting to the session acl allowall to permit all traffic on the uplink interface.
ap system-profile “custom-ap-system-profile”
I was able to connect remotely to the server after applying the session acl allowall to the AP system profile, which is connect to the correct AP Group. Problem solved!!
The AeroHive user, which is created by default, gets a landing page, when logging into https://myhive.aerohive.com. The user can choose between the HiveManager Online and the Redirector.
When the users chooses the HiveManager Online or the Redirector, the user has the option to return to landing page by choosing the MyHive option in the upper right corner.
Subsequent users don’t get the landing page by default and don’t have the option to choose the MyHive option. Subsequent users (even if the belong to the group Configuration and Monitoring) don’t have the permissions to access the Redirector.
The default user has the option to provide access to the landing page. This configuration is done per user and can only be done by the default user. Just edit the user and enable the option “Give user access to MyHive landing page”.
When the users logs in to his HiveManager page, he will get the landing page to choose between the HiveManager Online and the Redirector.
Last week I have installed a Microsoft UAG array. I installed Microsoft ForeFront Unified Access Gateway 2010 including Service Pack 1. When using an array configuration you have to deploy Microsoft’s Network Load Balancing (NLB) for redundancy and load balancing purposes. I configured NLB with multicast and IGMP support. I had configured some HTTPS trunks and some HTTP trunks for http-to-https redirection.
Everything was working perfectly and I decided to install the update KB2585140 (ForeFront UAG SP1 Update 1). The main reason for installation was the introduction of SharePoint 2010 with Office Web Apps and Lync web services publishing.
The installation process was easy and completed without any errors. I noticed that after installing the update I couldn’t activate any configuration changes. Everything I hit Activate I receive the following error message:
The Activation works again by deleting all HTTP trunks and only use HTTPS trunks. The customer started a support call with Microsoft and Microsoft acknowledges this behavior when installing the update on an array configuration. At first Microsoft advised to “break” the array and use a stand-alone server deployment. If that isn’t an option we should uninstall the update. We are told that the current configuration will get to the configuration state prior to the installation.
This morning the customer received another e-mail from Microsoft stating at more and more calls were logged with the same issues. The issues now has the highest priority for the Microsoft UAG developers. Microsoft couldn’t tell when the issue will be fixed, but I guess very soon.
So when using a Microsoft UAG array configuration DON’T install Microsoft UAG SP1 Update-1.