When deploying IMC UAM Radius server, the installation will probably integrate with the Active Directory at the customer through the LDAP protocol.
IMC UAM will use LDAP to synchronize user objects, so the IMC UAM Administrator can apply specific network access services to these user objects.
When using 802.1x with PEAP MSCHAPv2 authentication, an additional service on the IMC server will provide the authentication. This service will ‘join’ the domain, but that is something for a different post.
Once the users have been synchronized with UAM, these users can login on the SelfService Portal (http://imc:8080/selfservice ), where they could perform actions like guest management or BYOD device registration.
The problem : Passwords in clear text on the wire …
The user password cannot be synchronized by UAM, since AD does not allow reading user passwords. So when an LDAP user logs in on the SelfService portal, UAM will check the username and password on the fly with the AD.
This password check is done by a simple LDAP bind to the AD, using the provided credentials. And as you may expect, simple LDAP means clear text.
This is the trace of a user with username “m1” and password “password1.”
The solution : Secure LDAP
UAM supports the configuration of secure LDAP. Support for Secure LDAP (tcp port 636) must first be available on the AD Server.
This is actually very easy : when the AD Server has a valid certificate for server authentication, it will enable support for secure LDAP automatically using that certificate. So by installing an Enterprise CA, domain controllers should get a server authentication certificate or the admin can manually request a domain controller certificate of course.
On the UAM side, the AD certificate must be checked, so the Root certificate (which has signed the certificate used by the domain controller for secure LDAP) must be linked to the LDAP Server object. This requires the root certificate file to be exported as a .der file.
Once the root certificate has been linked to the LDAP server, the SSL option can be enabled and tested.
With this new configuration, the user login will be encrypted over the network with SSL.
So while this is not a default option, I would strongly recommend to activate it for obvious reasons.
About Aruba Networks 
Pingback: HP IMC TACACS Authentication Manager – AD/LDAP link | About HP Networking
Great Article!!!! It helped me to clarify the concepts for the implementation of LDAP within of UAM module.
I would like to ask for your help. I have a doubt in the stage of LDAP sync, I need to sync a users within security group,with a DN:CN=wifi,OU=Usuarios registrados,DC=XXX,DC=cl
I wrote the DN DC=XX,DC=cl in Sub-base DN, and configure the filter:
(&(sAMAccountName=*)(memberOf=CN=wifi,OU=Usuarios registrados,DC=XXX,DC=cl))
But I obtain an error that there are no users that match with this rule
you know how to do this filter?, I try to find information of this, but i had no success.
In advance, thank for your support again,
Hi Jorge, thanks !
In this post:
https://abouthpnetworking.com/2014/11/14/hp-imc-tacacs-authentication-manager-adldap-link/
there is an example of the ldap filter you want to use (but used for the TACACS module).
Some suggestions:
* Use an LDAP browser to verify the CN of the group
* AFAIK, an LDAP query is case-insensitive, but you can give it a try anyway (use cn instead of CN etc)
You can also try to build your ldap query in an external query tool and then move it to UAM.
Hope any of this helps !
Hi,
First of all thank you for the great blog you have set up here. Lots of juicy information.
If I understood properly, there are two moments where the credentials are crossing the network:
1st – When the user fills the credentials on the HTTP self-service portal and then sends them to UAM
2nd – When UAM forwards the credentials to the LDAP server using secure LDAP as explained in this post
If I understood correctly, on the 1st exchange the credentials are crossing the network in clear text. Is this true ? And if so I imagine the solution would be to use HTTPS instead of HTTP.
I’m asking this because I’m having a challange with UAM based HTTPS BYOD portal with self-signed server certificates not supported by IPhones, unless you install them on the device (not really BYOD then).I was wondering if this was a solution to secure the credentials instead of using HTTPS.
Cheers,
Pedro
Hi Pedro,
I am aware of 2 options:
1/ HTTPS: since the uam byod portal is typically installed on a dedicated server (you typically do not want the main IMC network management system to be reachable by the users), so you can *simply* change the certificate used on that server, without impacting the certificate of the main imc server.
2/ use alternate credentials: When importing users from the AD, you can create alternative accounts, and import e.g. the employee id, so that ID can be used as the BYOD password. This avoids having the user enter the corporate password in the initial portal for device registration. (but even then I would recommend HTTPS).
best regards,Peter