With the HP UAM BYOD Module, any new device will need to be onboarded (registered) to the network.
This onboarding process may include 1 or more steps:
- Link the device to a User account : Requires access to BYOD Portal and login with an existing UAM or LDAP (AD) account
- Request a certificate to access the 802.1x secured wireless network
In this article, the focus is on the step to reach the BYOD Portal.
Onboarding Network background
Since the device is unknown to UAM when it connects the first time, it should not be allowed full access, but only access to the BYOD Portal registration page. For this purpose, a limited network will be setup, which is referred to as the “Onboarding network”.
So users connecting to the BYOD Onboarding SSID will initially be placed into a dedicated Onboarding vlan. This will require a L3 Gateway device and a DHCP Scope + Relay for the Onboarding subnet.
This network (vlan) should be restricted by an ACL on the L3 gateway to allow access to the BYOD Portal only.
The BYOD Portal itself (EIP – Endpoint Intelligent Profiling Server component) will be running on the IMC UAM server or on an IMC Slave Server (my preference, since Guests do not get direct access to master IMC Server).
From the new device, the user would need to access http://ip-address-of-eip-server:8080/byod (or :80, depending on the port config).
The Challenge : Getting the user automatically on the BYOD Portal page
Now, you can try to explain users to visit this URL manually after they make a connection, but it would be easier if they would be automatically redirected to the BYOD Portal page when they open a Browser.
The Solution : Comware Portal Redirect
Comware devices have a feature which is known as Portal authentication. Basically Portal authentication means Web Authentication, so when a user tries to access the network, a Web page with username/password login will be presented.
Comware has local and remote portal authentication options:
- With local portal authentication, a Web page with login information is running on the local device. This is a quite common solution for traditional Guest Web Access. It is still used today for example by the Comware wireless controllers (known as Unified Controllers now). It works fine, but only basic pages are supported.
- With remote portal authentication, the Portal Web login pages are hosted by an IMC (sub)server. The advantage is more advanced pages, and possibly the same page set for multiple controllers. (in case of local portal, the pages must be manually copied between controllers).
Anyway, in both these cases, Comware had a feature already which could redirect the user traffic to either the local portal page or the IMC hosted portal page.
So the trick with BYOD is : we will not implement Portal authentication on the Comware device (remember, we are trying to use the BYOD solution!), but we can take advantage of the basic URL Redirect function of Comware to get the users to the BYOD page.
In short : no portal authentication, only the portal redirect !
No Portal Authentication ?
But since the Comware device will not perform portal authentication (only the redirect), how can a user ever come “online” ?
Well, from Comware Portal authentication point of view, it will never come online. However, after registering the device on the BYOD Portal page, the next time the device is authenticated, it will be assigned (by UAM RADIUS) to a specific byod mobile or guest vlan. These are different from the onboarding, and they do not have the Portal Redirect enabled on the L3 interfaces , so the BYOD device will be online and will be able to access resources in their final vlan.
Portal Redirect Process
Fine, so here it makes sense to understand how the Portal redirect works. These are the basic steps:
- Admin enables Portal authentication on the Onboarding VLAN L3 Interface, this will effectively block all traffic (default portal ACL)
- User connects and “should” get an address through DHCP/DHCP Relay.
- User opens browser, tries to access http://www.hp.com
- User Device will send dns request for http://www.hp.com (to DNS IP Provided by DHCP server)
- DNS “should” respond with public IP of http://www.hp.com (default Portal ACL will block this by default!)
- User Device will send TCP SYN to public IP on TCP port 80.
- On Comware Device, there is a TCP-Cheat process, which will spoof *all* target IP addresses and respond to the TCP SYN (for incoming traffic on TCP port 80)
- After TCP 3-way handshake completes (between User Device and TCP-Cheat process), User browser will send HTTP GET
- Comware TCP-Cheat will respond with an HTTP ‘moved’ message, which will point the the URL set by the Administrator (for byod setup : http://ip-of -eip:8080/byod for example)
- User Browser “should” now connect to the ip-of-eip and show BYOD page (default Portal ACL will block this by default!)
Portal Free-rule Exceptions
Some things to remember here:
- There is no DNS hi-jack, so DNS must work ! We will need to make sure that DNS Server is reachable. This will be the first exception rule for the default Portal ACL.
- Initial DHCP will work by default if you configure DHCP Relay, since this initial Address assignment is broadcast based. The DHCP Renewal however, is a unicast exchange between the user device and the DHCP Server. Again, we will need an exception rule for the default Portal ACL.
- For simple testing, from the user device a connection to http://1.1.1.1 should always work (since it does not rely on DNS)
These exceptions are called “portal free-rules”. Depending on firmware version and hardware, these will be very basic (src/dst IP based) or will support also TCP filtering (would be preferred).
Configuration example for Comware5 device
First we need to define a Portal Server object (this IP will be permitted in the Portal ACL).
The BYOD Portal would run on 10.0.1.100 in this example.
<comware5>sys System View: return to User View with Ctrl+Z. [comware5]portal server uam ip 10.0.1.100 url http://10.0.1.100:8080/byod
Enable portal server on Onboarding VLAN Interface, this will activate the default Portal ACL (deny all, redirect tcp port 80 to TCP-Cheat)
[comware5]interface Vlan-interface 21 [comware5-Vlan-interface21]portal server uam method layer3 [comware5-Vlan-interface21]quit [comware5]
Enable the port free-rule with exceptions (IP addresses which must be reachable : DHCP Server for unicast DHCP Renew, DNS Server IP)
In this example IP 10.0.1.111 would be DHCP and DNS.
[comware5]portal free-rule 10 source any destination ip 10.0.1.111 mask 32
Configuration example for Comware7 device
This example was made with the HP VSR (Virtual Service Router), which is using Comware7.
Like Comware5 config, we need to define a Portal Server object (this IP will be permitted in the Portal ACL).
<comware7>sys System View: return to User View with Ctrl+Z. [comware7]portal web-server uam [comware7-portal-websvr-uam]url http://10.0.1.100:8080/byod [comware7-portal-websvr-uam]quit
Enable portal server on Onboarding VLAN Interface, this will activate the default Portal ACL (deny all, redirect tcp port 80 to TCP-Cheat)
[comware7]interface Vlan-interface 21 [comware7-Vlan-interface21]portal enable method direct [comware7-Vlan-interface21]portal apply web-server uam [comware7]
Enable the port free-rule with the exceptions (IP addresses which must be reachable : DHCP Server for unicast DHCP Renew, DNS Server IP)
In this example IP 10.0.1.111 would be DHCP and DNS and the UDP port 67 and 53 can be used for DHCP and DNS filtering.
[comware7]portal free-rule 20 source ip any destination ip 10.0.1.111 32 udp 67 [comware7]portal free-rule 30 source ip any destination ip 10.0.1.111 32 udp 53
Conclusion
So it does not matter if you are implementing the HP BYOD with MSM or Unified Wireless controllers, a Comware Portal Redirect device is always required for the onboarding redirect. This can be done by an existing Comware device, or through the VSR running on an ESXi host.
About Aruba Networks 
Thank you Peter for the detailed explanation,I have a scenario which is pretty similar to what you described and that is as:
IMC deployed in distributed mode ( Base Platform on one Server, UAM on another, Remote DB/MS SQL Server )
MSM Controller for wireless Users
MSR 3040 for Portal Redirection
Now Portal Redirection is working perfectly fine and has the free Rules added to both IMC servers,DNS and DHCP.
The SSID is Guest which is MAC-Based Auth, Any user will be redirected to BYOD page and is assigned onboarding VLAN, depending on existing user(LDAP) or self-account register (Guest) user is registered to the cosponsoring VLAN
The issue:
Users are able to redirect to the BYOD page and register but the only behavior i need to know if the user moves from onboarding to Guest Vlan by itself or he needs to deassoicate and re-associate which makes no sense.
In my case, i have to register, then on the same page i authenticate and nothing happens after which i disconnect and connect again to same SSID and now i am connected to Guest VLAN.
One thing i noticed, while discovering MSM via SNMP on the Base platform, i cannot see any SOAP service inside the configure tab while if i do the same in Centralized IMC (LAB setup) i can view it. Do you know if this is SOAP service on MSM is responsible for moving the user from Onboarding to Guest/Corp VLAN?
The vlan assignment is part of the radius access-accept packet, which is sent at the time the authentication takes place.
When the guest initially makes a connection, the mac is unknown, so the mac-auth is based on the byodanonymous account (and the associated Access Service).
After the user registers the device, the client device mac address will be linked to the user account, so any future authentication attempts will be processed based on the Access Service associated with the user account. That user Access Service will push the user vlan when the user authenticates.
The key part is to understand that the new authorization information will only take effect at the next authentication attempt (since the vlan is delivered through the radius access accept).
There is a Radius standard which allows for the dynamic (radius based) update of the session authorization parameters. This is called CoA (change of authorization). So when the Radius server (UAM) knows that settings have been changed (e.g. when user registers a device), it can push the new vlan or ACL to the access device (radius client).
Depending on the implementation, the access device will perform re-authentication (which will trigger the new access-accept) or it could apply the new authorization parameters(vlan/acl) on the fly to the existing session.
In case of the MSM however, CoA is not supported, so a different mechanism had to be used to ensure the user is assigned to the new vlan.
The MSM supports a SOAP API, which can be used for all kinds of administrative actions (like defining guest users : the MSM Guest Managemenent Software is an example of an application that uses the SOAP interface).
One of the actions which can be done through the SOAP API is a wireless user disassociate (based on the client mac). Once a wireless user has been disassociated, the client device will try to reconnect, which will trigger a new authentication attempt (and this will result in the new vlan being assigned to the user).
For the MSM Wireless controllers, the UAM team has implemented this SOAP API in order to have a triggered user disassociated.
On the MSM Controller, you need to enable the SOAP interface (under management), but SOAP over HTTPS is not supported, so that must be disabled.
The SOAP settings in IMC are not defined on the platform device, but under the UAM Access Device (radius client). When the MSM Access Device is opened and the device type is set to HP(General) (this is required for MSM!) the SOAP settings can be configured.
Once this is done, the user will be disassociated after registering a device, and will be reauthenticated and assigned to the new vlan. It just takes 10-30 seconds for the client device to release/renew the IP address for the new subnet.
On the MSM Controller, you can use the System Log (Unfiltered) to verify if the SOAP disassociate was executed.
Thanks a lot Peter for the descriptive reply. Your explanation solved the issue within seconds: )
Want to ask one more Question regarding dot1x User Authentication, Windows 7 users are connecting to dot1x SSID with single sign-on and they are passing login credentials in windows format: MS\john. UAM takes “MS\john” as Login and it fails instantly. By modifying SSID profile, when we input the user manually without domain it solves the issue. On the UAM i have tried the following:
1. Under Service Parameters -> System Settings -> System Parameters -> Username Prefix Conversion Mode : Change to suffix/Remove ( Tried Both )
2. LDAP Service : LDAP Server : Account Format : Remove Prefix/Unchanged ( Tried Both )
3. Under Domain Assisted PEAP Authentication : Changed Operating System to Windows Server 2003 or earlier
check out netopscommunity, there is a similar request here:
http://www.netopscommunity.net/forums/-/message_boards/message/61486
I already referred to this forum earlier and tired all the mentioned steps. Even the support provided me this link . Anyway i think i will retry the options and restart the IMC service, i will keep you posted if this issue resolves!
You are amazing! Keep up the good work!
Peter
I have a problem, when connect to the network and redirect to the page of byod the message is “The user is not online”. Always the same message with any device.
You know why?
Regards
Hi Daniel,
I have had this as well, for me it always happened to be one of these issues:
* DHCP Server did not have the UAM plugin installed (or plugin was not properly configured/not started).
This is required, since the pluging will allow the mapping of the user MAC (learned through radius accounting) to the user IP (the incoming source IP on the BYOD portal).
* The authenticating device (controller/switch) was not configured with radius accounting to the UAM server.
* The device accessing the BYOD portal had both a wired and wireless connection, and the session to the BYOD was done using the wired connection.
The result is that the source IP of the incoming connection on the BYOD portal cannot be mapped to the user online MAC address.
I hope one of these helps for you !
Hi Peter, thanks for your feedback
The plugin is installed succesfully, the message is DHCP Service server is running and DHCP Agent is working.
I,m not sure about my controller Unified 830 is configured with radius accounting, how will i do that?
Regards
Hi Daniel,
this would a sample configuration to activate a guest SSID with MAC-authentication using the IMC UAM RADIUS for authentication, authorization and accounting.
Sample includes 1 VLAN, create more VLANs are required by your setup.
#
port-security enable
#
vlan 19
#
radius scheme uam
server-type extended
primary authentication 10.0.1.100
primary accounting 10.0.1.100
key authentication simple hp
key accounting simple hp
user-name-format without-domain
#
domain uam
authentication default none
authorization default none
accounting default none
authentication lan-access radius-scheme uam
authorization lan-access radius-scheme uam
accounting lan-access radius-scheme uam
#
mac-authentication domain uam
#
interface WLAN-ESS19
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 19 untagged
port hybrid pvid vlan 19
mac-vlan enable
port-security port-mode mac-authentication
#
wlan service-template 19 clear
ssid sample-unified-guest
bind WLAN-ESS 19
service-template enable
#
Thanks Peter,
Oh yes this had alredy configured, but in the IMC not have to configure anything for this authentication?
Regards
Hi Daniel,
you should have the normal byod/uam configuration applied on UAM:
* create access device (radius client) – make sure correct IP address and secret are used (check with wireshark in case of doubt)
* create an access policy for the byod onboarding vlan (no special auth (like eap), it will access mac-auth/PAP by default)
* create an access service which contains this access policy
* bind the byodanonymous user to the access service
Can also enable more logging under the UAM system log settings.
This will generate more info in a log file on the IMC server, in the uam\log folder.
It is kind of a raw log file, but you can find lots of info in there.
Hi Daniel,
This is my first time to implement HP BYOD solution and i have followed a guide from HP website, specifically, from the UAM BYOD configuration guide. My objective is to perform an auto guest registration.
My issue is that after I managed to connect to the test SSID then obtain an IP address, I am redirected to a login page that has no other option but to use an existing account.
Appreciate your help in advance.
Thanks,
Sherwin
Which version of UAM are you using ?
Older versions required User Access Policy > Customize Terminal Pages > Self Service > Enable Guest Preregistration link
best regards,Peter
Hi Peter,
When I have the below command on the Unified controller, by client are not able to connect to the SSID.
port-security port-mode mac-authentication
“interface WLAN-ESS0
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 100 to 101 untagged
port hybrid pvid vlan 101
mac-vlan enable
port-security port-mode mac-authentication
“
Got is working, thanks
Does the comware portal redirect entry have to be specifically on the L3 Gateway device or on a device connected on the same VLAN?
i am having one trouble. all is configured correctly, but when the guest is moved to the portal captive appears ” timeout in connection” would you know what could be ? below the configuration:
version 5.20.109, Release 2607P32
#
sysname HP
#
clock timezone Brasilia minus 03:00:00
#
dhcp relay server-group 1 ip 172.17.3.12
#
radius trap authentication-error-threshold
radius log packet
#
domain default enable system
#
dns resolve
dns proxy enable
dns server 172.18.46.2
dns source-interface Vlan-interface3
#
telnet server enable
#
port-security enable
portal server spdm ip 172.17.3.12 url http://172.17.3.12:8080/byod
portal free-rule 30 source ip any destination ip 172.17.3.12 mask 255.255.255.255
portal free-rule 31 source ip any destination ip 172.17.3.254 mask 255.255.255.255
#
ip http acl 199
#
mac-authentication timer offline-detect 60
mac-authentication timer quiet 15
mac-authentication domain hgg
#
wlan country-code US
#
wlan auto-ap enable
wlan auto-persistent enable
#
password-recovery enable
#
acl number 199
rule 65534 deny
vlan 1
#
vlan 3
description vlan portal
#
vlan 11
#
vlan 13
description vlan rede notebook
#
vlan 14
description vlan rede movel
#
vlan 15
description vlan guest
#
vlan 20
#
vlan 58
description rede wirelless notebook
#
vlan 59
vlan 60
description rede portal guest
#
vlan 61
description rede guest
#
vlan 62
#
radius scheme brigadeiro
server-type extended
primary authentication 172.17.3.12
primary accounting 172.17.3.12
key authentication cipher $c$3$5Wl6413foeKjkaZkf47HLn+WD7Ur9KqYpsE=
key accounting cipher $c$3$j4+W7qIfzpPywexsBceUCO9dBAyGc0Rgd/w=
user-name-format without-domain
#
domain hgg
authentication default none
authorization default none
accounting default none
authentication lan-access radius-scheme brigadeiro
authorization lan-access radius-scheme brigadeiro
—- More —-
accounting lan-access radius-scheme brigadeiro
access-limit disable
state active
idle-cut disable
self-service-url disable
domain system
access-limit disable
state active
idle-cut disable
self-service-url disable
#
pki domain hgg
crl check disable
#
pki domain spdm
#
user-group system
group-attribute allow-guest
#
local-user 00-fe-12-34-56-78
password cipher $c$3$lSRexWPdXvbwvSGAUwVEZ7ZjsPSdncmlk4klJQeKrgPKn0nO
service-type lan-access
local-user 48-86-e8-88-c5-24
password cipher $c$3$lSRexWPdXvbwvSGAUwVEZ7ZjsPSdncmlk4klJQeKrgPKn0nO
service-type lan-access
local-user 48-86-e8-88-c5-24
password cipher $c$3$s4oDn1fXg5+wYh5uk5sbgjdZdPQceUy8tEbv5VS+2ibMHynw
service-type lan-access
local-user admin
password cipher $c$3$sN2dqFNGIaQZyu/BcFrYYpWxc0up5zPX
authorization-attribute level 3
service-type ssh telnet
service-type web
#
wlan guest-tunnel aggregation-ac
#
wlan rrm
dot11a mandatory-rate 6 12 24
dot11a supported-rate 9 18 36 48 54
dot11b mandatory-rate 1 2
dot11b supported-rate 5.5 11
dot11g mandatory-rate 1 2 5.5 11
dot11g supported-rate 6 9 12 18 24 36 48 54
dot11a calibrate-power threshold 80
dot11bg calibrate-power threshold 80
wlan service-template 1 crypto
ssid SPDM MOVEL
bind WLAN-ESS 0
cipher-suite ccmp
security-ie rsn
ptk-lifetime 604800
client forwarding-mode local
service-template enable
#
wlan service-template 2 crypto
ssid SPDM NOTEBOOKS
bind WLAN-ESS 1
cipher-suite ccmp
security-ie rsn
gtk-rekey method time-based 604800
client forwarding-mode local
service-template enable
#
wlan service-template 3 clear
ssid SPDM VISITANTES
bind WLAN-ESS 2
service-template enable
#
ssl server-policy spdm
pki-domain spdm
ssl server-policy hgg
pki-domain hgg
#
interface NULL0
#
interface Vlan-interface1
ip address 172.17.1.254 255.255.255.0
#
interface Vlan-interface3
ip address 172.17.3.254 255.255.255.0
#
interface Vlan-interface11
#
interface Vlan-interface13
#
interface Vlan-interface20
—- More —-
interface Vlan-interface60
ip address 172.17.60.254 255.255.255.0
dhcp select relay
dhcp relay server-select 1
portal server spdm method direct
#
interface Vlan-interface61
ip address 172.17.61.254 255.255.255.0
#
interface Vlan-interface62
ip address 172.17.62.254 255.255.255.0
#
interface GigabitEthernet1/0/1
port link-type hybrid
port hybrid vlan 3 58 to 62 tagged
port hybrid vlan 1 untagged
port hybrid pvid vlan 3
#
interface GigabitEthernet1/0/2
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 3 58 to 62 tagged
—- More —-
interface WLAN-ESS0
port link-type hybrid
port hybrid vlan 1 untagged
port hybrid pvid vlan 59
mac-vlan enable
port-security port-mode psk
port-security tx-key-type 11key
port-security preshared-key pass-phrase cipher $c$3$ww5nXpLTRpXVRtDNVvZXmwJiPwoNAWKt3axLMOcQwBcO
#
interface WLAN-ESS1
port link-type hybrid
port hybrid vlan 1 untagged
port hybrid pvid vlan 58
mac-vlan enable
port-security port-mode psk
port-security tx-key-type 11key
port-security preshared-key pass-phrase cipher $c$3$C8a3wAs3WAVIAJ4u1XIAfgocl+LwQH84WpjD8a8EBIGj
interface WLAN-ESS2
port link-type hybrid
port hybrid vlan 1 untagged
port hybrid pvid vlan 61
mac-vlan enable
port-security port-mode mac-authentication
mac-authentication domain hgg
#
nqa entry imclinktopologypleaseignore ping
type icmp-echo
destination ip 172.17.3.253
frequency 270000
#
wlan ap-group default_group
ap ap1_dir
ap ap2_dir
nqa entry imclinktopologypleaseignore ping
type icmp-echo
destination ip 172.17.3.253
frequency 270000
#
wlan ap-group default_group
ap ap1_dir
ap ap2_dir
#
wlan ap ap1_dir model MSM430-AM id 4
map-configuration apcfg.txt
serial-id CN3ADWY0RT
radio 1
service-template 1 vlan-id 59
service-template 2 vlan-id 58
service-template 3
radio enable
radio 2
service-template 1 vlan-id 59
service-template 2 vlan-id 58
service-template 3
radio enable
wlan ap ap2_dir model MSM430-AM id 3
map-configuration apcfg.txt
serial-id CN41DWY0BK
radio 1
service-template 1 vlan-id 59
service-template 2 vlan-id 58
service-template 3
radio enable
radio 2
service-template 1 vlan-id 59
service-template 2 vlan-id 58
service-template 3
radio enable
#
wlan ips
malformed-detect-policy default
signature deauth_flood signature-id 1
signature broadcast_deauth_flood signature-id 2
signature disassoc_flood signature-id 3
signature broadcast_disassoc_flood signature-id 4
signature eapol_logoff_flood signature-id 5
—- More —-
signature broadcast_deauth_flood signature-id 2
signature disassoc_flood signature-id 3
signature broadcast_disassoc_flood signature-id 4
signature eapol_logoff_flood signature-id 5
signature eap_success_flood signature-id 6
signature eap_failure_flood signature-id 7
signature pspoll_flood signature-id 8
signature cts_flood signature-id 9
signature rts_flood signature-id 10
signature addba_req_flood signature-id 11
signature-policy default
countermeasure-policy default
attack-detect-policy default
virtual-security-domain default
attack-detect-policy default
malformed-detect-policy default
signature-policy default
countermeasure-policy default
#
ip route-static 0.0.0.0 0.0.0.0 172.17.3.250
snmp-agent
snmp-agent local-engineid 8000000B034431924278DC
snmp-agent community read public
snmp-agent community write private
snmp-agent sys-info contact lab
snmp-agent sys-info location lab
snmp-agent sys-info version v2c v3
snmp-agent target-host trap address udp-domain 172.17.3.12 params securityname public v2c
snmp-agent target-host trap address udp-domain 172.17.3.13 params securityname v2c
#
nqa schedule imclinktopologypleaseignore ping start-time now lifetime 630720000
#
ssh server enable
#
ip https acl 199
ip https ssl-server-policy hgg
ip https enable
user-interface con 0
user-interface vty 0 4
acl 199 inbound
authentication-mode scheme
user privilege level 3
#
I go trough the step. But i still have problem when the client open browser request eg: http://www.google.com it’s not redirect to byod page.
But still can use manual http://ip_address:8080/byod/