The HP IMC UAM BYOD (Bring Your Own Device) solution allows the on boarding, registration and authentication services for user devices on a customer network.
HP IMC UAM Module includes the BYOD functionality with the component which is named “EIP Server” : End User Intelligent Profiling. This end-user profiling (fingerprinting) can be performed based on 3 methods (or combination of these methods):
- DHCP Client Profiling : Most Operating Systems have a unique set of request options in the DHCP discover packet.
- Client MAC Address : Each MAC Address can be linked to a Vendor through the OUI (Organizationally Unique Identifier, the first 6 digits of the MAC Address)
- HTTP User Agent : Typically includes the client browser and OS / Platform.
Once a device has been profiled, different authentication or access policies can be applied based on the Endpoint types. In this post, I will review the profiling methods.
Method 1 : DHCP Client Profiling
This is a sample DHCP Discover packet of a Windows XP client:
The option 55 contains a list of requested parameters (and in a specific order!), so for this example the option order would be : 1,15,3,6,44,46,47,31,33,249,43. Take note of the HEX version of this list : 01-0f-03…f9-2b (this will be reported to UAM !).
So how does UAM get this information ? Well, the only device which will certainly see the DHCP packets is the DHCP Server itself.
HP IMC UAM has a DHCP Agent plugin for Windows and Linux DHCP Servers, install file can be found in the UAM Install media:
The DHCP plugin must be installed locally on the Windows/Linux DHCP Server, and must be configured with the IP Address of the UAM Server. After install and configuration, the DHCP Service must be restarted.
Every time the DHCP server sends a DHCP ACK packet to a DHCP Client, it will report this information to the UAM Server. This trace shows the combined DHCP ACK to the client and the notification to UAM (10.0.1.100):
In this detail of the UAM notification packet (note UDP port 1810), the data of the DHCP Client can be found (Wireshark does not recognize this format, so we need to look in the data section of the trace):
- MAC Address : 00-0c-29-ed-90-7f
- IP seems reversed : 0a-0b-00-0a (10.11.0.10 > 10.0.11.10 from original DHCP)
- DHCP Option list (01-0f-03… f9-2b), this matches the original DHCP Discover list.
On the DHCP Server, the Plugin can be configured with additional logging to help in case of troubleshooting.
This example sets the level to debug:
After restarting the DHCP Service (which includes the Agent DLL plugin), the install folder will contain new log files:
In the detailed log file, the DHCP client information (MAC / IP) and the raw data to be sent to UAM (which includes the ordered parameter list) can be found (note I have used multiple clients, so the client MAC/IP will not match the trace earlier used in the post!)
The UAM Server has a number of DHCP Profiling rules, which allows it to ‘recognize’ the client OS. On the IMC Server, these rules can be found under:
User – User Endpoint – Endpoint Profiling – DHCP Character:
When we query for the originally found DHCP Parameter list for a Windows XP Client, we find a match:
IMC UAM contains many DHCP Character definitions, but these can be customized or added based on your own needs. See this post from Chris Young to add a DHCP Character set for the Nintendo Wii:
http://kontrolissues.net/2013/02/25/adding-custom-device-fingerprints-to-the-hpn-byod-solution/
The resulting discovery for a client can be found under the User – Endpoint Management:
Through the Endpoint details, the DHCP Option 55 can be reviewed and the resulting analysis of UAM ( Windows XP > PC):
Method 2 : Client MAC Address
This is an easy one, the client MAC Address will be looked up in the OUI table of UAM, if there is a match, UAM knows the client Vendor:
Since the test client is a VMWare Virtual Machine, the client MAC Address (00:0c:29:xx:xx:xx), it will not be recognized by default:
So we can add the new MAC range:
Once added, we need to re-evaluate the client endpoint information, so to trigger this, we need to “Clear Endpoint Information” first. Once cleared, the client needs to perform a DHCP Renew (not shown here) to show up on the Endpoint list with the updated information:
In the details page, the new Vendor is now shown:
Method 3 : HTTP User Agent
The client HTTP User Agent will be captured by the EIP BYOD Onboarding portal, when the user accesses the http://imc-eip-module-ip:8080/byod page (or the SSL version on 8443).
So how does the client get to this page ? Well, this requires a Comware device with the Portal redirect function (but that is for a different post).
So here we assume that the client ends up on the UAM BYOD web page, were the client HTTP Agent string will be captured, and analyzed by UAM.
This is a sample client web page (from a manual client to BYOD page connection), where the user connects to the http://imc-eip-ip:8080/byod page:
The resulting trace shows the client HTTP user-agent:
UAM has several definitions of the User-Agent, which will be screened for a match, this is the complete list:
When the string Windows NT 5.1 is used for the query, the resulting client OS / Endpoint type will be reported:
When the Endpoint details are reviewed, the additional User Agent will be shown. In this example the Endpoint Type was already determined by the DHCP method, so it will only report the User Agent:
Summary
Well, this post took a bit longer than I expected, but I felt the 3 methods should be covered together, so apologies for the length 🙂
Anyway, now you know a bit more about the device fingerprinting process of UAM.
About Aruba Networks 
Congratulations on this very good article, the depth of analysis is very enlightening.
I would like to ask for help on a problem that is happening in our configuration BYOD.
We have a Wireless solution with HP WX 5004 and an IMC platform for BYOD access.
I configured IMC for guest access. One condition for this configuration is not give to guest an “autoregister” access, the creation of the account shall be made by the recepcionist.
When a new guest start the connection for the WIFI SSID, he will be associated to a onboarding VLAN (2132) and must be redirected for IMC Portal. Then the guest must write the user/password and if it´s correct the IMC changes the VLAN of this user depending of the device of connection (VLAN 2133 for PC or VLAN 2134 for mobile).
Once the user/device is authenticated, it´s disconnected for the for WIFI and reconnected in the new VLAN.
The issue of the solution occurs when a guest connects to the SSID and it’s redirected to the portal, if this guest do not enter your username/password and off the WIFI, when he’s connected again, the device directly enters the VLAN Service (2133 or 2134) without asking the password.
I disabled in IMC “MAC transparent authentication” in User>User Access Policy>Service Parameters>System Settings>User Endpoint Settings
Also, I uncheck the option “Transparent authentication on portal Endpoints” for the Access services, in User > User Access Policy > Access Service > Access Service Details.
Do you know how to fully disable “Transparent authentication” for endpoints?
Hi Jorge,
Thanks, glad you liked it.
From your input, I have the impression that the Access Service which is bound to the byodanonymous user has too many scenario’s (or is used for both byodanonymous and guest access)
I would recommend to create 2 Access Services:
1/ Access Service “Service byodanonymous”
* only bound to Access User byodanonymous
* default Access Policy forbid
* Access Scenario:
IF guest SSID
THEN access Policy VLAN 2132
2/ Access Service “Service Guest”
* bound to guest users by the guest manager
* default Access Policy forbid
* Access Scenario’s:
IF guest SSID and device type PC
THEN Access Policy VLAN 2133
IF guest SSID and device type Mobile
THEN Access Policy VLAN 2134
Using a single Access Service cannot accomplish what you want (and I like to have a clear distinct set of rules (Access Services) for onboarding (byodanonymous) and actual network access).
For the system to work, the transparent mac-authentication is required, so make sure to enable the option “MAC transparent authentication” under
User>User Access Policy>Service Parameters>System Settings>User Endpoint Settings
The other option “Transparent authentication on portal Endpoints” has nothing to do with this and only applies when the classic IMC Portal authentication is used (this is the portal authentication which does not perform device fingerprinting). Changing this option will not have any impact on your setup.
Hope this helps !
Peter,
Thank you very much for your answer, it seems I have an error of concepts in the design of my service to guests.
From what I understand from your explanation exists a first access service “service byodanonymous” that associates the guest’s MAC with byodanonymous user using MAC authentication.
Then there will be a second service, “Service guest” to associate the user/password granted and the type of device.
My question is how UAM difference of both services, I have not seen the ability to prioritize access services.
Hi Jorge,
As long as UAM does not know the identity of the endpoint (e.g. device of new guest connects), the endpoint (represented by a MAC) will be bound to the byodanonymous account (see User > User Endpoint > Endpoints). So during the initial authentication, the mac-auth will take place, but there is no Access Service bound to a MAC user account.
Instead, the MAC address is bound to a User object, and this user object is actually bound with an Access Service. Since the initial user is byodanonymous, and this user is bound to the Service byodanonymous, the device of a new guest will be authenticated and authorized (vlan assignment) based on this Access Service (typically the onboarding vlan).
In the onboarding vlan, the guest should be redirected to the byod registration page (see portal redirect posts).
On the byod registration page, the network admin can configure multiple guest login scenario’s:
* login with a predefined account (made by a guest manager using the selfservice portal)
* pre-register a new user account (guest account is created, but in pending state, must be approved by guest manager using selfservice portal)
* auto-register: new guest accounts are auto-approved
In either of the above scenario’s, a new user (guest) account is created. At the time of registration on the BYOD portal, the endpoint (MAC) will be released from the byodanonymous user and bound to this new user account. Since the guest user is bound with another Access Service, all future logins of the MAC Address will now be processed based on the guest user Access Service (and should place you in the authorized guest vlan, possibly with distinction pc/mobile).
Hope this helps !
Hello Peter,
You mentioned earlier that the “DHCP agent” is available for Linux DHCP server, but I can find ONLY the windows version in the UAM 7.1 package.
There is however a “DHCP plug-in” for Windows and Linux in the IMC 7.1 platform package.
However this plug-in’s seems to be for a other usage, deferent from the BYOD you mentioned in this blog.
To add more confusion, the UAM administration guide refers to the IMC deployment guide for the installation of the “DHCP agent”, and the IMC deployment guide described the installation of the “DHCP plug-in”.
Can you tell me where to find the bites fir the Linux version of the “DHCP agent”.
Thanks
Ray