Active Directory Bidirectional Group Management

Description:

This document describes how to set up Access Requests and Certification for AD-sourced groups imported into Okta.

Pre-requisites:

• IGA license to manage AD groups in Okta.
• Active Directory integrated with Okta and proper service account permissions to manage groups in AD. Refer to “Group Push” permissions in this document: https://help.okta.com/en-us/content/topics/directory/ad-agent-about-service-account.htm
• All the user’s managerID is populated in Okta UD for access requests. ( At this time of writing i am using workflows to do access requests, This will be native functionality in H2 2024. I will update this document once the new feature is released)

Use Case:

AD groups are used for securing access to applications, servers and other network resources. It is important for businesses to automate access to these AD groups with proper approvals and also run certification campaigns for certain groups which provides access to higher privileged resources.

Steps to implement the features:

In this procedure we will implement two features 

• Enable Access Certification campaigns for AD groups
• Enable Access Request for AD groups.

Enable Access Certification campaigns for AD groups

1. To do proper campaigns and access requests we need to identify owners of AD groups if they are available. In that way we can route the certification campaign and access requests to the proper owner for approval. In order to standardize on group owners, You can either have the group owners set in Active directory groups directly, Which can be synced into Okta or you can map the owners for those AD groups directly in Okta UD. Once you populate the owners or if owners for groups is not a requirement please proceed to the next step.

2. Go to the Identity Governance – Access Certifications

3. Create a resource campaign. 

If you want to set up a periodic campaign, click the check box, Make this recurring and setup the rest.

4. Select the resource type group and select the AD groups you want to be certified.

5. You can either specify all users to be certified or you can also specify an expression where only certain users from the group need to be certified.

6. You can select multi level approval. In the below example I have set up the user manager as first step and group owner as second level. In both the cases you can setup a fall back reviewer incase if the primary person heads for PTO 

7. For remediation select the appropriate options. You can also run a workflow on completion of the specific campaign. 

Note: You can also run a workflow upon decision is complete on a resource. Go to workflow and select an Okta event and you should see the event below, Which can start the flow.

8. Click on the schedule campaign.
9. Campaign will launch as per schedule. If you want to start immediately you can click on the campaign and select actions and hit launch.

Enable Access Requests for AD groups

At this time of writing AD group objects are not synchronized to Access Requests as resources. But API support is available. We will create an access request with Okta Wworkflows for fulfillment in this demo.

Create an OAuth Service application

1. In order to manage the directory groups in Okta, Setup an OAuth service app with proper scopes as per below screenshot.

2. Click add to create a key and copy the PEM format of the private key to a file. This is required to configure the workflow in the next step. You won’t be able to copy this back once you save the keys. Also copy the clientID.

3. Under API scopes grant the below scopes.

4. Setup the Admin role for the application to grant only required permissions to manage groups from a specific directory. Head to Security – Administrator

Go to roles and create a role and set up the required permissions as per screenshot below.

5. Once the role is created go to resources and attach resources to the role. In the below screenshot I have provided access to manage all groups for both the directories that I have integrated in the tenant. If you just have 1 please select only that directory.

6. Now attach the admin role to the application. Go to admins and add the role to the app.

Setup the Okta workflows.

1. Go to Workflow – Workflow Console and create a folder in left called ADaccessrequest download the flopack from https://github.com/krishvenkatraman-okta/AD-Biderectional-group/blob/main/adGroupaccessrequest.folder and import the file to the folder. You should see two flows as below

2. Go to connections and make sure you are connected to the Okta instance you are managing the AD group.
3. Open the 001 – IGA Trigger for AD access request – go to the call flow card as provided in the below screenshot and update the Okta URL and clientID for the app which you copied from the previous step.

4. Go to the next concatenate card and replace the first part of the okta URL in text 1 with your domain. Do not replace the entire thing. It should be https://<oktaURL>/api/v1/directories/

5. Save the flow and open the 001 – GET Okta Access Token workflow, This is the flow to get the access token from Okta. 
6. Go to the JWT Sign card and paste the private key you downloaded from the app during the app setup in the last section.

7. In the API connector RAW request card. Just create a new connection with auth type as none.

8. Save the flow and turn on both the flow.

Setup Workflow delegated Admin role for access request to call actions.

1. Now setup delegated workflows role, So you can sync all the delegated workflows to IGA tool, Where you can call a custom workflow action inside workflow.

Create a delegated workflow role with below permissions.

2. Setup the resources. For this example I am using all workflows as a resource set. But you can also create a delegated workflow and also scope it down to specific resource set for delegated admin role permissions.

3. Add the admin role to the access request app.

Create Access Request

1. Go to Identity Governance – Access requests.
2. Go to setting – Resources – Workflows check whether all the delegated workflows show up else click on update now. Also click on Manage access and make sure your team has access to it.

3. Click on Configuration lists and create a configuration list for your domain. I have set up two domains for this. jeykrish.com and bloodline.com. Click on Add item and add a custom list. 

Note: As of today, We don’t sync AD groups to our Access request tool. This feature will be coming soon. For now we will create a custom list and use this in our workflow. (Please make sure list have the same AD group names as we have in Okta) 

4. Now let us go to Access requests from the left panel and create a new form. Below is my form configuration.

Note: If you have just one AD, You don’t need the first question. The first question is to allow users to pick which domain they are requesting group access.

5. Now create a new question for Pick an AD group and on the right, map the data source to the custom configuration list we created in step 3.

6. Click the logic in the top and select show this field only if the domain is selected to the configuration list. This is to filter the AD groups to domain. Again you leave this section if you have only one AD domain.

7. Repeat the above steps if you have multiple AD domains and different configuration lists.
8. Next create a question for type of access, Whether it is add or remove from group. This will be a custom option.

9. Now click on approval and assign it to the requester’s manager.

10. Finally click on action to call a workflow and pass on the parameters to the selected workflow which we imported in the previous step.

11. Click on the logic and make sure this is set to show after manager approval.

12. Publish the form and you can test the access request now.