Skip to main content

In one of the workflows we are using we send emails out to a number of users. This could be anywhere from a single user up to a handful or more. Currently we query a group in a specific OU and return a list of names. Those names are popped into the TO line of an email and sent out. This works OK until recently a user was added that had the same first and last name of another user and despite them being in 2 separate OUs both users were emailed instead of one. 

So it became clear that a more precise way of sending emails needed to be done. AS the Administrator I'm not as familiar with Nintex actions as the developers but they are out of office for a few days and this is something of a security issue.

Can a collection be passed into the QUERY LDAP action such that the query becomes

(&(objectClass=user)(CN={workflowvariable:user_name}))

or is there a query that can accept a delimited string of users to pull back a string of email addresses? I've not been able to find this capability in the ldap query syntax and it doesn't sound too efficient.

Ideas?

What if instead of returning the names from the group, you return the samaccountname of the user.  This is the users ID, which would be unique.  That would resolve to the correct user in the notification. 


Currently we are using an LDAP Path to the Roles OU and in the query we are using:

(&(objectclass=group)(CN={WorkflowVariable:sp_groupname2}))

where sp_groupname2 is the name of the AD group 

when output is set to samaccountname it returns the name of the AD group

when output is set to member it returns the name of the AD group members

So if there is some way of saying..don't send me the fqdn of each member but instead send me only their emails, that would be ideal as it would avoid having to do more processing downstream.


Ok, dug into this a little bit more.  If you're querying on the Group in LDAP, you can only return names.  However what you can do is query on the users, and then look for users that are part of that group, and then return the samaccountname, which should be unique for each user.  After "memberOf" you need to list the full path in LDAP to the group.  

199931_pastedImage_4.png

199927_pastedImage_1.png


That worked with a group that has a single user but when I put in a group that has multiple users I got the 'No results returned'


Ok, did some more digging.  Assuming you only have the group name here is how you would get the distinguished name (which is the group path in LDAP), and then feed that into another query to get all your users.  It's returning a collection, so you need to capture the results in a collection variable.  That may be why you had the issue with groups with multiple members.  

First Step

Query the Group Name to get the distinguishedName

199933_pastedImage_2.png

Second Step

Query on users looking for those who are part of the group, but looking at where the memberOf equals the distinguished name. 

199937_pastedImage_3.png


What eneded up working was, I just had to change the LDAP Path to stop using the FQDN and instead use LDAP://Company.Local Then it worked like a charm!

Thanks!


I'm curious, could you post the before and after of the LDAP path you used then?  I'm not familiar with FQDN.  


The original was like LDAP://Company.Local/OU=Roles,OU=XXX,OU=CLients,DC=Company,DC=Local

While this worked for a group with a single user in it, the query was failing for groups with multiple users.

Changing the LDAP Path to LDAP://Company.Local allowed both single and multi user groups to be queried successfully.


The LDAP query does not return more than 1000 results,  could you provide a solution for that?


Reply