You are viewing limited content. For full access, please sign in.

Question

Question

Disable AD User using Custom SDK Activity

asked on November 25, 2019 Show version history

Hi Everyone,

 

As part of a security review, I've been asked to look into automating disabling user's windows accounts when a Separation Form is submitted for LF Forms.  

 

I've been able to modify a C# script (that works outside of Laserfiche) enough to not get any errors, but it doesn't really work either.  It gives a warning that there "No entry points were found in Script 1.cs."

 

Would anyone have ideas on what I'm missing here?  We are using Workflow and Laserfiche 10.4.    I do have a VB script that works outside of Laserfiche if VB is simply a better route than C#.

 

Thanks

namespace WorkflowActivity.Scripting.SDKScriptC
{
    using System;
    using System.Collections.Generic;
    using System.Drawing;
    using System.DirectoryServices.AccountManagement;
    using System.Windows.Forms;
    using Laserfiche.RepositoryAccess;
    using Laserfiche.Workflow.Activities;

    public partial class MainForm : Form
    {
        // Private Method
        private static void DisableADUserUsingUserPrincipal(string username)
        {
            try
            {
                PrincipalContext principalContext = new PrincipalContext(ContextType.Domain);
                UserPrincipal userPrincipal = UserPrincipal.FindByIdentity
                        (principalContext, username);
                userPrincipal.Enabled = false;
                userPrincipal.Save();

            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }

    // Private Method with return type "Boolean" to determine if the method succeed or not.
        private static bool EnableADUserUsingUserPrincipal(string username)
        {
            try
            {
                PrincipalContext principalContext = new PrincipalContext(ContextType.Domain);
                UserPrincipal userPrincipal = UserPrincipal.FindByIdentity
                (principalContext, username);
                userPrincipal.Enabled = true;
                userPrincipal.Save();

                return true;
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }

            return false;
        }


        void Button1Click(object sender, EventArgs e)
        {


            string strUserName = "AD_Username";  // This is a LF Workflow custom token.  Its value is the employee's active directory username

            DisableADUserUsingUserPrincipal(strUserName);

        }

        void Button2Click(object sender, EventArgs e)
        {
                  string strUserName = "AD_Username";  // This is a LF Workflow custom token.  Its value is the employee's active directory username
                  EnableADUserUsingUserPrincipal(strUserName);
        }
    }

}
0 0

Replies

replied on November 25, 2019 Show version history

Are you trying to run this inside of a workflow? If so, then there are some issues with the formatting of the code. For example, it looks like the class is still referring to a Windows form and you have some button click functions in there from the form process.

The default script activity content looks like this

namespace WorkflowActivity.Scripting.Script
{
    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.Data;
    using System.Data.SqlClient;
    using System.Text;

    /// <summary>
    /// Provides one or more methods that can be run when the workflow scripting activity is performed.
    /// </summary>
    public class Script1 : ScriptClass90
    {
        /// <summary>
        /// This method is run when the activity is performed.
        /// </summary>
        protected override void Execute()
        {
            // Write your code here.
        }
    }
}

You need the script class inheritance, and the piece of code you want to execute immediately should be in the Execute() function.

You can include other functions to call from inside the Execute method, but you will need to restructure the code as a script; copying directly from a standalone application will not work.

From the looks of things, the Execute method should be retrieving the token value to a variable using GetToken(), and then calling either the enable or disable method similar to what the button clicks would be doing in the standalone application.

You also need to make sure your Workflow service account has sufficient permissions to enable or disable users in Active Directory or you'll get an access denied error.

NOTE: When running a workflow scripts run as the service user, but when testing code from the script editor they run as the current user.

UPDATE: I changed the default script example to the non-SDK script version since it doesn't look like you'll need the repository access libraries for this task.

3 0
replied on November 25, 2019

To follow up on Jason's feedback, scripts that modify Active Directory are inherently high risk. You'll want to ensure that the service account running Workflow (and thus these scripts) has only the minimum necessary AD privileges to perform the operations.

In your case here, that would be Read / Write on the userAccountControl privilege, which bundles a few other account operations such as password resets. 

Here are two resources on the topic:

  1. Delegating Enable/Disable Account Rights in Active Directory
  2. AD DS – How to Delegate Enable / Disable AD Account Permission

 

Note that you can also use a normal (non-SDK) Workflow Script activity here. All the "SDK Script" activity does is automatically add the Laserfiche Repository Access (RA) libraries to the script. Since you're not interacting with a repository in your script, there's no need to add the overhead of loading the RA libraries.

2 0
replied on November 25, 2019

Adding to this, another consideration is that even if you minimize the access given to the Workflow service account, you will effectively be giving anyone who can run workflow scripts the ability to enable and disable AD accounts by running a workflow, so you'll want to review your Workflow security settings very carefully as well.

3 0
You are not allowed to follow up in this post.

Sign in to reply to this post.