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:
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:
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.