Showing results for 
Search instead for 
Did you mean: 

Ben Conrad

UCSD 5.2: Proper use of LDAP users and groups?

I'm using UCSD 5.2 and have setup LDAP integration to my Active Directory domain controllers (SSL, port 636).  I'm getting a list of AD objects, I know that is working.

In our AD, users are in an OU named _Users and groups are in an OU named _Groups, both OUs are at the same level, so there are no user accounts in the _Groups OU and no groups in the _Users OU.  I can specify a users OU in the Search Base and I see all the users listed in the Login Users tab and I can log in using a test user because it has automatically been allocated the 'Service End-User'.

Normally, in AD, we assign users to a specific group (like DOMAIN\UCS Portal Users) and would want to assign permissions using the AD groups.  If I specify a Search Base of _Groups I can see the AD groups but I don't see the users any longer.  I cannot login when I can't see the users.

What is the proper way for me to use the existing AD groups and allow several thousand users access to the UCSD user portal?


Jon Glennie


You should be able to select multiple search bases in the LDAP sync settings.  Check the box next to the OU for both your users and your groups and they should all populate into UCSD.

However, AD groups will not work the way you want them to though, and this is currently a big sticking point for us as well.  Other than populating UCSD with a list of groups that you have defined in AD, UCSD will not know anything about who is in the AD groups and you will not be able to assign permissions to end users based on their memberships.  Currently we are in a testing phase and I'm keeping my fingers crossed that they will redesign this in the near future as it seems as though this would be an incredibly desirable feature to have. We can get by for now with only a handful of test users but the steps involved to assign permissions to a large number of users the way we want them to be would be incredibly tedious. 

Hi Ben/Jon,

UCS Director should still honor/sync user to group relationships, however it does so on a 1:1 basis. UCS Director will only honor/acknowledge the first user to group relationship that it discovers for a given user. We are aware this is not adequate as it is very typical for users to have more than one group relationships, we are working on updating this functionality in future releases. When adding the LDAP account to UCS Director, there is a page called "LDAP User Role Filter" that was added in UCSD 5.1 I believe. This allows you to create rules to map users in a specific group with a specific UCS Director role. So if you have an AD group called "admins", you could create a rule here that would map the AD group "admins" to the "system-admin" role in UCSD, for example. As UCSD sync's with AD, it checks the name(s) of the groups that are sync'd from AD against these rules and maps the corresponding users to roles based on the rules. By default, user are mapped to "Service End-User" role if no LDAP User Role Filter is matched to the group(s).

Hope that helps,



Jon Glennie

Thanks Mike, glad to know that this is something you guys are actively working on because honestly there aren't any other cloud products that we are aware of that will be able to handle automating our entire environment like UCSD hopefully will.

Just to be clear though, the user filter rule you describe above will still only map a user to a single group and will not allow, say for example, a user that should have rights in both Group A and Group B to automatically get those rights.  Such a scenario would still have to be handled manually through the use of group sharing and user profiles, correct? 

Hi Jon,

That is correct, if a user is a member of multiple groups, they will still only be associated with a single group (the first group that is recognized by UCSD during sync process) in UCSD. That single user:group relationship can then be mapped to a user role based on the LDAP user role filter.



Content for Community-Ad
This widget could not be displayed.