Forbid acess to Rich client: Adobe Campagin

[Shruti1]

Hi All,

Hope you guys are doing well.

I want to disable users who left the organization or no longer on project WITH ADMIN ACESS. If I disable users who already left OR Revoke their admin acess , all the technical workflows which are created by them and running are throwing error and go on paused state.

I do not want this to happen. Is there any way to achieve this by not doing lot of manual work(restart workflow by another user).

I dont want to go with the approach where we can modifiy the "last moddifies by /Created by " for that wkf --as we have so many teach wkfs and its hard to do

One of the approach I found is to reset their password and keep the same with support team

Another approach i found is :to check the second option in screen shot is to forbid their acess to console--so that if another person will try to login with the credentials of THOSE USERS who left  ---they will not be able to login with that account  credential

Please let me know if this approach is fine?

if we check the check box "forbid acess from rich client" what will happen?

I am not very sure on this just tried in UAT nad it was showing

Any other solutions are welcome.

Thanks in advance..!

[Craig_Thonis]

Hi Shruti,

I can confirm that the two solutions that you highlighted are the recommended methods to remove access to a user outside of removing the actual user account from the system.

In particular they are recommended to be used in parallel as one will prevent rich client access and changing the username/password will prevent any possible access from the web.

Regards,

Craig

[AmitRaghuwanshi]

Hi @Shruti1,

Both the approaches mentioned by you are not full proof. Please find the potential issues you might face and also my recommendation,

1. First approach you mentioned might not work if a user has their fall-back or backup email configured. They might try to rest their password via fall-back email id so to avoid this, you should first update their profile first and remove their backup email before resetting their password
2. Second approach you mentioned will only restrict the access from Rich client but these folks still can access the thin client using browser and API’s (if any)

I will recommend, along with above two steps, you update the profile of these Admins and fix the IP range to Application server IP range only so these users cannot access both thin and rich client from anywhere. You can do this from Add a trusted IP mask option.

In addition, you should also ask your campaign server Admin to configure the Adobe campaign server access restricted to only certain IP ranges. This can be achieved via small changes in your Application server configuration file(Admin can include org specific IP ranges which also include the IP range of VPN). This will ensure no one are allowed to access the Adobe campaign client console from personal network or without connecting to VPN.

Hope this helps.

With Regards,

Amit

[Shubham_Goyal__]

Hi @Shruti1 ,

In my opinion, the 'disabled' is the best/simple solution for revoking access for former users if in case you worry that technical workflows created/started by them will throw errors now for this, you can get all the workflows created by these users (via @createdBy) and then perform Right click>Actions>Purge History>Unconditional Stop>(start the workflow again). Now this will help you to transfer the ownership of the workflow from those users to your name (or anyone who starts them again).  

Br,

Shubham

[Denis_Bozonnet]

Hi @Shubham_Goyal__ 

All the above is true, to the exception of "Unconditional Stop", use the normal restart or stop/start function and do not use "Unconditional Stop" unless the stop is actually not stopping the workflow. When you let the system stopping the worklfow, it purges the temporary tables and all associated resources it uses, unconditional stop does not do that as it kills the process and cleaning the resources aren't guaranteed.

What you can also do BEFORE you disable the user is a workflow that would list the workflows this user has started, use entity xtk:workflowLogin, this will give you the list of operators having started a workflow from there depending on the recurrence of the workflow, you could restart automatically the workflows and restart manually the few that are recurring multiple times in a day...This way workflows are restarted with an existing user

Once all workflows started by the operator have been restarted, you can actually disabled the operators in full... Sadly you won't be able to delete the operators as you would have plenty of references all over the places for this operators and it'd be a very difficult to cut these dependencies to actually delete the user.

Hope this helps,

Thanks

Denis