I recently configured IMC UAM with LDAP synchronization at a customer. Some of the users would be allowed access to specific Wireless networks, others would not get access.
So to make the ongoing administration for the customer easier, it was decided to go for the AD Group based synchronization, so based on a specific AD Group membership, a different UAM Access Service would be assigned.
Since UAM will sync all users, an Access Service “No-Access” was defined, in which the “access forbidden” access policy was set and no other scenario’s were defined. This “No-Access” access service was set as the default for the UAM sync policy.
At this point, I could add the required AD Groups, and link them to the required Access Services. That was what I had expected …
The problem : AD LDAP Query returns only 1000 records…
When trying to select the actual AD groups, I could not find the groups in the list and the query function did not resolve the name either. So I checked the group type in the AD, but it was just a normal security group, so that was not the issue.
So Wireshark was fired up to trace the LDAP communication between UAM and the AD.
What I found is that the UAM query for group function in the LDAP sync policy wizard is not really a query. UAM will first request the complete list of groups through LDAP, and then apply the query string as a display filter in the UI.
So after reviewing the actual LDAP query (all groups), I noticed that only 1000 groups were returned, altough more groups existed in the AD. Since the 2 groups which were needed were not in this returned list, the UI query (or filter) of these groups did not return our groups either of course.
The solution : Update AD LDAP Policy to support more records per query
After checking on Google, the Active Directory MaxPageSize was found to be the source of this 1000 record limit. This value controls the maximum number of records which are returned in a single query. Once the value was updated to 2000, it started working just fine.
This was the procedure on the domain controllers performed by the domain admin. This was based on this Microsoft article : http://support.microsoft.com/kb/315071
The new value is updated on the fly, no need for restarting any server or services.
Query the Existing value
Update the value
About Aruba Networks 
Excellent Article, Just want to add that in the newer version of IMC, you can retrieve more than 1000 records without any change on the DC side as i am syncing 3000+ Users
I want to ask regarding “AD Group based synchronization” Can you kindly provide me more details on the SyncPolicy you have under LDAP service. In my current setup, i am doing User sync only, but the customer is asking for Group based Auth which is fairly easy to manage.
The problem i am facing is the WirelessUser Group is under an OU which has the type CN and users are an attribute ( memberof). I want to know if it is possible to create a sync policy which can pull only the members with the Group which in SubbaseDN field is an CN=WirelessUserGroup, OU=Corp, OU=ABC,OU=NET
OR, there is a way to auth the users in real time through the ldap by just confirming the membership inside the group
The group based sync is not used to synchronize only members of the selected groups, but to assign an Access Service based on an AD group membership. For this to work, UAM first needs to retrieve the user account from the AD, including the user group membership (user – memberOf AD field). Once the user and his group membership has been retrieved, UAM will parse the configuration of the LDAP Sync policy.
Under the LDAP sync policy, you can add AD Groups, and assign an Access Service. When there is no match for any of the groups, the LDAP Policy default Access Service will be assigned to the user.
In your case, you try to achieve (if I understand it correctly):
* only members of the AD group WirelessUserGroup should be allowed access to the network
So to achieve this, you should:
1/ define a new Access Service “No Access”. No scenario’s are defined, the default Access Policy should be set to “Access Forbidden”
2/ configure the LDAP sync policy. Set the default Access Service to “No Access”. Add the AD Group WirelessUserGroup and assign the existing Wireless-Access-Service to the group
When UAM performs a full sync, all users under the LDAP Sync policy sub-base DN will be synced. Users member of the WirelessUserGroup will be assigned the Wireless-Access-Service (and granted access to the network), while the other users will be assigned the “No Access” Access Service (and will be denied access to the network).
This also means that all users (access and no-access)will be visible in UAM (should be no problem, licensing is concurrent user login based, not named users).
If you do not want this, the LDAP policy has an option “sync users as needed”. In this case, at the moment a user connects to the network, UAM will lookup the user info and apply the policy, so the user list in UAM will be a more cleaned up list, as opposed to listing all users.
Do realize that this option will not limit the users to only the WirelessUser Group. When a non-WirelessUser group user account tries to connect, UAM will still lookup the user, find it, but based on the LDAP Sync Policy, it will apply the “No Access” Access Service and reject the login. The user will be listed in UAM however from this point.
Last note : the subbase dn applies to the location of the user object in the AD (OU based!), it has no relation to any group membership or the location of the group in the AD.
Thank you for your detailed input, So this is clear that the SubBaseDN, cannot point to a CN under an OU. We are basically migrating from Cisco to HP solution and the customer already has this group created under an OU=Corp and the type is CN.
So can i conclude,that in order to have AD-GroupBased Sync, the Group should have the type “OU”, so we can retrieve all the users within this group and apply the wireless policy accordingly.
Thank you again for your valuable input.!
It is important to see the difference between the location of a user in the directory and the groups a user belongs to.
A user can exist on only 1 location in the Directory, this will be some Organizational Unit (OU). The path for this location is the Distinguished Name (DN).
This means the LDAP policy subbase DN a starting point for searching user objects under a location (OU) in the AD.
An AD can have OU structures based on locations, business departments etc. But it will typically not match your network security structure.
Let’s take the example of an AD with an OU Belgium and an OU France. Inside OU Belgium, there is an OU Sales and OU Marketing, same inside the OU France.
Now some users (spread over these OUs) are allowed wireless access.
Since the OU structure does not match the security requirement (and you do not want to re-arrange the OUs for this), it should be clear that the subbase DN option cannot be used to select these users.
The subbase DN will in this case just point to the domain level location (for example dc=domain,dc=com), so the sync policy will be syncing all users found under this location (all users from Belgium, France etc).
All users will be listed in UAM, so the assignment of which user gets which Access Service will control if a user is allowed access or not. This is where the AD Group Based “Access Service” assignment will help you. (see other reply for the setup).
The AD group which is used to assign Access Service to users does not need to be under the subbase DN.
Thank you for the explanation, it is perfectly clearly to me now. Can you let me know under which field i can specify the AD Group inside the Access Service?
An Access Service contains all the rules (scenario’s) for a specific login (user). When you want different rules for different people (user groups), you must create multiple Access Services, and assign each user the desired Access Service.
You will never control groups inside an Access Service.
The LDAP Server must be configured to AD group based service assignment.
Once this is done, the LDAP sync policy wizard will prompt your for the groups, so this will be the place (once the LDAP Server has been modified) where you can assign the Wireless user group to the user Access Service. There you can also set for instance the default Access Service to “No Access” , so all other users will not be allowed access.
Remember to manually create the “No Access” Access Service first, with the default Access Policy set to “access forbidden”.
Got it, So inside LDAP server, i will set ServiceSyncType to “Based on AD Group”, Sync Policy prompts me for the Group itself and from there i map the Group to Access Service.. Excellent.Thanks a lot, i will try this and post the results shortly!
Thanks a lot Peter, i was able to authenticate users based on their AD Group membership