Self Service - Join a Group - Workflow does not initate

Question

Hi all

I want to create a workflow on the Self Service portal. The choice is the default “Join a group” or possibly a new action.
A normal user should be able to request membership of a group chosen from a list.

If there’s an owner value in “Managed By” send it to the owner for approval or denial, else send it to Helpdesk.
If approved the user should be added as member.

Moreover, I want regular users trigger the approval request but not users having security role of either Helpdesk, HR or of course Super Manager. E.g. a HR representative working In the HR console should not trigger an approval request.

I've created a business rule etc according to this post but I can’t get it to work:
https://www.adaxes.com/tutorials_Delega ... ership.htm

As it turns out the regular user requesting to become a member of a group receives Access Denied after selecting the group in the Self
Service portal, Join a group action.

How is it supposed to work and allow the user to initiate the workflow?
What minimal permissions would a normal user require?

Both the user ( initiator) and "owner" sorts in the default Domain User role / Authenticated users with Read permission to all objects.
Permission for the “Owner”, possibly a regular user in "managed by" of the group has the permission (Write membership) as described in the guide.

Micael

Answer 1

Hello Micael,

As it turns out the regular user requesting to become a member of a group receives Access Denied after selecting the group in the Self
Service portal, Join a group action.

How is it supposed to work and allow the user to initiate the workflow?

When you use Owner (Managed By) as a trustee for a Security Role, it means that the permissions specified in the role are granted only to the user, specified in the Managed By property of a group. If a user that is not specified in the property tries to update membership of the group, they will get Access Denied, because they do not have corresponding permissions.

If you want to grant all users the permissions to modify group membership, you should use Authenticated users security principal as trustee.

Otherwise, you can specify a security group or certain users.

Moreover, I want regular users trigger the approval request but not users having security role of either Helpdesk, HR or of course Super Manager. E.g. a HR representative working In the HR console should not trigger an approval request.

You will need to use a Business Rule triggering Before Adding a member to a group. If a manager (Managed By property) is specified for the group and the initiator is not assigned to either of the Security Roles (Help Desk, HR Manager or Super Manager), the rule will send an approval request to the group manager (first set of actions and conditions). If a manager (Managed By property) is not specified for the group and the initiator is not assigned to either of the Security Roles (Help Desk, HR Manager or Super Manager), the rule will send an approval request to Help Desk (Else If block).

If you need detailed instructions for creating the Business Rule, we will gladly provide them.

Comments

Thanks for the extensive write-up :)

I've sucessfully created the "Before adding or removing... " business rule (Update Group membership) as per the example and created a security role for the owner of the group , i.e. "Managed By" aka owner.
Permission: Allow Read and Write 'Member'
Trustee: Owner (Managed By)
Assigned over: "The OU where their groups are"

If I understand correctly this would allow an almost regular user to update, add or remove members in "their" owned groups, as long they receive a request to process or actually venture into the web interface and manually manage members?

Business Rules: 1 rule encountered while processing your request
'Update Group membership': Send this operation for approval.
The operation is approved automatically, because the user is in the approver list.

How do I get this request created by a another user with only read rights to the directory?
Is it possible to allow a domain user to request membership for a group when the permission allows only to read the directory?

Thanks,

Micael

---

Hello Micael,

If I understand correctly this would allow an almost regular user to update, add or remove members in "their" owned groups, as long they receive a request to process or actually venture into the web interface and manually manage members?

Yes, this will allow group owners to add and remove members from the groups they manage.

How do I get this request created by a another user with only read rights to the directory?
Is it possible to allow a domain user to request membership for a group when the permission allows only to read the directory?

This can be done using a Web Interface action and two Business Rules. The action will be always executed on the currently logged on user and its form will contain only a DN syntax property (e.g. Assistant). The property will be used to specify the group to which the user will be added. The first Business Rule will trigger Before Updating a User and send the operation for approval. It will look like the following:

The second Business Rule will trigger After Updating a User. It will add the user to the group specified in the Assistant property and then clear the property. The rule will look like the following:

---

Thanks. But you lost me definately when trying to prepare for selfservice action join a group ;)

"This can be done using a Web Interface action..."

A modify user with a custom form with only the Assistant attribute specified?
Done. the custom form contain only The "Assistant" field. Only Distribution and security groups are available.
However. The Assistant attribute may already have a value not related to this operation!

Two business rules created, one pre user update and one post update user.
There is a Business rule which will execute for Group membership update (After User has been created), Can't prevent that?!
"Before Adding or removing Group member" with it's own set of approvals.

When executed the user is added to the group and no approval request will be sent because the user (initator) is in the approver list:
The user has the following roles:
- Domain User (Read)
- Self Service, the Self Service Role will allow the user to update itself (Write permission, object = User)
- Report viewer (View)

'Pre-Joining A group': Send this operation for approval.
The operation is approved automatically, because the user is in the approver list.

* ( The user is not specidifed in the 'Managed By' attribute but has only the regular user roles and permissions)

Business Rules: 1 rule encountered while processing your request
'Post-Joining A group': Add 'John Dalton (domain.com\ECusers\Users)' to 'EC Remote Desktop User (domain.com\ECusers\Security Groups)'
Business Rules: 1 rule encountered while processing your request
'Update Group membership': Send this operation for approval.
The operation is approved automatically, because the user is in the approver list.
'Post-Joining A group': Modify the user: clear Assistant

Regards,

---

Hello,

However. The Assistant attribute may already have a value not related to this operation!

As you can see, the Business Rule triggering After Updating a User clears the Assistant attribute. That is why we recommend you to select a DN syntax property that is not involved in other workflows. Currently, Active Directory provides only two single-value DN properties that you can use: Assistant and Secretary.

There is a Business rule which will execute for Group membership update (After User has been created), Can't prevent that?!

Could you, please, be more specific on this point? If a business Rule is configured to trigger Before/After Creating a User, it will not fire upon user updates.

"Before Adding or removing Group member" with it's own set of approvals.

Do we understand correctly that you do not want for this Business Rule to fire in the Self-Service join to group scenario? If that is correct, please, post here or send us (support[at]adaxes.com) a screenshot of the Business Rule configuration.

The operation is approved automatically, because the user is in the approver list.

* ( The user is not specidifed in the 'Managed By' attribute but has only the regular user roles and permissions)

This behaviour is by design. If an operation initiator is the approver, the operation is always approved automatically. Permissions granted to the user by Security Roles do not matter in such cases.