Skip to main content
Nintex Community Menu Bar

Hello !

I have another question regarding the management of the AD since K2 Five 5.5.
I need to know the list of all users who are part of an AD group.
I use the "GetUsersByGroup" method of the "AD User" SMO and it works fine as long as the input group composition is only users. However, other AD groups can enter the composition of AD groups, and even at several levels.
We need an SMO that can handle this recursive case.
Does anyone know if this exists?

If yes, many thanks for help !

Hi annick, 



 



I don't believe K2 has a dedicated SmartObject out-of-box that goes that deep recursively with functionality, but there is a service instance you can create additional AD SmartObjects from that may help. See the following help documentation:



 



Active Directory 2 Service Type    - Note: There is a "ResolveNestedGroups" service key option that could help you when you work with SmartObjects in this service.



 



You may have to write something custom to get to the reporting capability that your looking for. To go recursively that deep in Active Directory could potentially become resource intensive if you have large, nested groups. You may also have to keep in mind nested groups that belong to other trusted active directory domains. The the main use case for the out-of-box AD SmartObjects is to help with task assignment and other security related items in workflows and forms, so some reporting criteria requirements may require extra customization.

Regards,




Jason


Further to what Jason says there is also another key ReturnAllUsersInNestedGroups.



 



Also performance is definitely a concern if you are trying to do this over your entire domain if it is anything other than a small AD.



 



What I have done in the past is that if I need this level of functionality for an application, I create a new Service instance with these options turned on. I then create a new SmartObject on the secondary service instance and use that for the specific application that needs to do this type of resolution.



 



That way the rest of the K2 set-up still works as normal and the specific app that needs to deal with nested resolution is the only one that consumes the slower service.



 



This may not however be suitable for your needs but trying to think about structuring things by creating new groups for your app to use, maybe under a new container (you can also specify a lower level LDAP string when you create a new instance of the AD 2 service and work with items only under that leaf).


Hello Jason and Paul !
Thank you very much for your quick responses!
By combining your 2 solutions, it works perfectly.



Thanks again and have a great day!



 



Annick


Glad we could help!


Reply