HPE Aruba switches have the concept of user-based tunnelling. In short, the wired connections behave like a wireless connection. All traffic from the wired client is tunnelled to the central controller. This provides functions like central firewalling and micro-segmentation by blocking inter-user traffic.
Yesterday I had a customer complaining that multiple clients weren’t able to communicate. After investigation the problem focused on one HPE 2930F stack. The stack had been working without problems, but now I found the following error message in the logging.
I 01/17/20 10:16:01 05563 dca: ST1-CMDR: Failed to apply user role
THIN_CLIENT_UBT-3007-3_7Z4q with tunnel redirect to 8021X
client F44D306E2DB9 on port 3/21 as user tunnel is not operational.
I couldn’t find a lot on the internet concerning this issue. I only found something on EventID 5563 in the Aruba Event Log Reference Message Guide for ArubaOS-Switch 16.08.
The EventID description is This log event informs the user that Tunneled-node-server-redirect is enabled in the user role but per user tunnel feature is disabled.
I checked the switch “show tunneled-node-server”, and the feature is enabled. I deleted the “tunneled-node-server” configuration and reapplied the configuration to the switch, but still the same error message.
To solve the problem: CHECK THE LICENSES ON THE MOBILITY MASTER
Jan 17 07:39:10 stm: <304109> <5640> <WARN> |stm| No available license type PEFNG for Tunneled Node 54:80:28:cf:4a:4b
A switch consumes a license for user-based tunnelling.
Split Tunneling is technique, which is used very often in (SSL) VPN scenario’s. The RAP-5WN access points has multiple Ethernet ports to connect different components, like workstations or printers. You can configure the usual user roles and other settings on these Ethernet ports.
You can also configure Split Tunneling per Ethernet port. When using Split Tunneling the connected components received an IP address from the company DHCP server. By using access-control lists you can specify the traffic, which is tunnel through the RAP to the central controller. Traffic, which isn’t tunneled, is NAT’ted to the local network by using the IP address of the RAP on the local network.
The configuration example below shows you how to configure Split Tunneling for an Ethernet port on a RAP-5WN. I don’t show you the provision and creation of a VAP for the remote access points. I assume that the RAP is already provisioned and currently all traffic is tunneled to the central controller.
1. The first step involves the creation of the access-control list to specify the traffic to tunnel and the traffic to bridge locally. The access-list shows that the DHCP services (udp/67 and udp/68) and traffic to the network 10.10.10.0/24 is tunnel to the central controller and all other traffic is locally bridged. This is the most important step when configuring Split Tunneling.
ip access-list session rap-split-tunnel-policy
any network 10.10.10.0 255.255.255.0 any permit
any any svc-dhcp permit
any any any route src-nat
2. Next you need to create a user role and associate the previously create access-list to the user role.
access-list session rap-split-tunnel-policy
3. The user role needs to be tied to a AAA profile.
aaa profile “rap-split-tunnel-aaa_prof”
4. The following step contains the configuration of a wired-ap-profile.. The wired-ap-profile contains the VLAN information for the connected component, the forward-mode and you can enable/disable the Ethernet port. The configured wired-ap-profile puts the client in VLAN 50, enables the port and puts the port in Split Tunnel mode.
ap wired-ap-profile “rap-split-tunnel-wired-ap_prof”
switchport access vlan 50
5. You have all the basics configured and next you need to configure the Ethernet port profile. This profile combines the AAA profile and the wired-ap-profile.
ap wired-port-profile “rap-split-tunnel-wired-port_prof”
6. The last step is to tie the wired-port-profile to the appropriate AP group. I configured a separate group for remote access points, called remote-o1. The configuration ties the wired-ap-profile to Ethernet 4 on the RAP-5WN.
You are now ready to go!!
While configuring a TrendMicro IMSVA appliance I tried to configure different URL filtering policies using built-in Windows Active Directory groups, like “Domain Users” in conjunction with user/group name authentication. Configuring policies with built-in groups weren’t functioning properly. The policies just weren’t matched, while I knew for sure that the user is a member of the specified group. So I started a research. After reading the documentation (IWSVA Adminstrator’s Guide) more carefully I found the solution to my problem. The Administrator’s Guide contains the following notes:
Since the ‘member’ attribute is incomplete in some built-in groups that exist in Active Directory (such as ‘Domain Users’), IWSVA will not be able to obtain membership information for these groups through LDAP search. Trend Micro recommends you create policies based on user-defined groups instead of built-in groups.
To configure IWSVA to listen on port 3268, the Microsoft Active Directory server that IWSVA uses should have the Global Catalog enabled.
Since the member attribute is not replicated to the Global Catalog for all group types, and because the memberOf attribute derives its value by referencing the member attributed (called back links and forward links, respectively), search results for members of groups, and groups which a member belongs, can very. Search results depend on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups that the user belongs to (global groups or domain local groups), and whether the users belongs to universal groups outside the local domain.
I tried to verify this information with Softerra’s LDAP browser and found the “flaw”. All users within the Active Directory are member of the Domain Users group and most of them have the Domain Users group as Primary Group. When looking at the CN=Domain Users with the LDAP browser I only see 12 members, while the Active Directory contains 700+ user accounts.
I changed the policy to match a user-defined group, which I checked with the LDAP browser first, and the matching works perfectly. I guess this is another RTFM story!
Today I received the question about allowing users to changes his/her password through webmail, whereby webmail is published via an ISA server 2006 reverse proxy. This is possible, but it requires the configuration of LDAPS to authenticate users.
I started by configuring a Certificate Authority (CA) on a member server in the domain. During the installation of CA a root certificate is generated. You need to export this root certificate with private key. Next I imported the certificate on the reverse proxy server, but didn’t mark the private key as exportable. So the root certificate cannot be exported from the reverse proxy server with its private key in the future. I checked if binding to the Active Directory is possible by using the tool ldp.exe.
The last part is configuring LDAP Validation in ISA. Go to Configuration –> General –> Specify RADIUS and LDAP Servers. First you need to add a LDAP server set, like shown in the following picture.
Important when configuring the LDAP server set is the usage of the FQDN as LDAP server hostname. This FQDN should be exactly the same compared to the FQDN mentioned in the imported root certificate.
The last step is configuring the LDAP server mapping, which is also shown below.
Because I don’t want to add a domain name during the login procedure on the OWA login page, like DOMAIN\USER, I use the Login Expression wildcard character * and link that to the configured LDAP server set. Now you can login with just username and password, instead of domain\username and password.
Next I configure a OWA Publishing policy like always, but on the Listener I use LDAP as authentication mechanism. On the Listener Forms tab you can enable or disable the options:
These options add some extra option to the OWA login page. Another step to configure is the allowed users. In most environments I use the group Domain Users as allowed OWA group, because mostly all users are allowed to use OWA, else you need to configure a separate user group in Active Directory. On the Users tab you remove the All Authenticated Users and click Add. You need to define a new user group, like shown below.
This means that if you are member of the group Domain Users, you are allowed to use OWA.
The last step is configuring the public path. When logged in to OWA, you have the option to change your password through the options page. To use this feature, you need to added another path to the Path configuration in the reverse proxy server. The path, which should be added, is /iisadmpwd/*, where the External Path is the same as the Internal Path.
Over at isaserver.org, Thomas Shinder wrote a great post about using LDAPS with OWA and multiple domains. The article is called LDAP Pre-Authentication with ISA 2006 Firewalls: Using LDAP to Pre-Authenticate OWA Access.
I have a customer running a Barracuda SPAM firewall 300. The customer has the specific request that only the administrator can look at Quarantine messages and users shouldn’t get their own Quarantine inbox. To accomplish this I have configured the Quarantine Type: Global.
I see that all Quarantine messages are delivered in the globally configured mailbox. But sometimes the Barracadu still automatically creates an Account Address under the Users tab. The user from that Account has than the ability to look at their own quarantine messages. I thought it would help to configure the option New User Quarantine State to No, but this has no affect.
Does somebody know who to disable the function to automatically create User Accounts on the Barracuda SPAM firewall 300…??