Okta IAM

ACM.164 Creating Okta administrators with separation of duties to prevent privilege escalation

Part of my series on Automating Cybersecurity Metrics. The Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

In the last post we took a look at Okta networking.

Okta Networking

ACM.163 How to limit network access and thereby limit possible attacks on our Okta User Directory

medium.com

In this post we want to configure some users in Okta to administer user management and access.

Okta Identity and Access Management (IAM)

Remember one of our strategies to prevent privilege escalation was to separate user creation from user access assignment as described in this post.

Mitigating CreateUser Privilege Escalation and Back Doors

ACM.143 Preventing an attacker from creating a backdoor user in your cloud account

medium.com

Okta has some built-in roles which customers can use. You can take a look at those roles and what each role can do here:

Custom administrator roles

undefined

However, I’m just going to jump right to the point of this post.

It appears that we may able to achieve our objective of separating the creation of users from the assignment of permissions by creating custom administrator roles in Okta.

Okta IAM Architecture: Objectives and Requirements

Here are the Okta resources we want to create and what we want them to be able to do:

Super Administrator: This is the default user you get when you sign up for Okta. Create new administrators and an IAM architecture with segregation of duties. Then lock away the super administrator credentials and require two people to access that account. (Our root of trust.)

User Administrator: Creation of users and initial user credential management. Only the user administrator can remove MFA devices if a user’s MFA device has been lost or stolen and they cannot get into their account at all. Only the user administrator can remove MFA devices if a user’s MFA device has been lost or stolen and they cannot get into their account at all.

Access Administrator: Permissions management. Assignment of permissions to users. Application configuration (such as integration of AWS and Okta).

Users: Can reset their own passwords or change their MFA device, but not remove MFA. WE don’t want an attacker who has gained access to an Okta session to simply remove the MFA device and add their own.

Role Restrictions:

Prevent assignment of both the User Admin and Access Admin roles roles at to a single user.
Prevent user administration on the Super Admin user.

Creating custom admin roles

Login to the Okta admin panel. If you are an administrator, the Admin button will appear on the top right of the Okta dashboard.

Click on Security > Administrators in the left menu.

Click Create new role.

Create a User Admin Custom Role

First I’m going to create a new User Admin custom admin role with the description below.

Allow the User Admin to perform the following actions. Note that none of these actions allow the User Admin to grant access by adding a user to a group or assigning a user to an application.

Note that I did *not* allow this administrator to reset user’s passwords (to whatever they want so they would know it), or edit user access by assigning group membership or applications. This is key to achieving our above objectives.

Create an Access Admin Role

Next I’m going to create an Access Admin custom role that can configure and assign access, but not create users or administer their credentials.

This user can configure applications and auth servers (so users can log into them for SSO purposes. The administrator will be able to assign users to groups, but not create users or manage credentials.

View custom roles

Back on the roles list, I can click Custom to view the custom roles I’ve created.

Create a “Not Super Admin” group

Next, we need a group of users to define the resource which our User Admin can act upon due to the way Okta works. The resources a role can take an action on is known as a resource set.

Here’s where Okta lacks a feature. I would like to be able to create a group that says “all users except…” but I cannot. So I’m going to create a group that contains all the users except the Super Admin to meet one of our objectives above. We want to allow user administration for all accounts except the super admin user.

Unfortunately, each time we add a new user, we have to remember to add them to this group. On the other hand, this raises awareness of user creation to the Access Administrators because they will have to add the user to the group in order for the User Administartor to act on the user.

Click on Directory > Groups in the left menu.

Create a group named “Not Super Admin” and Save it.

Note that you will have to refresh the page in your browser to see the new group at the time of this writing.

Add all the users except the Super Admin user to the Not Super Admin group. In my case, I haven’t created any other users yet. After I do, I will add them to this group.

Create the User Admin group and assign the User Admin Role

Using the same steps above, create the User Admin group. We are going t create an assignment of a role plus a resource set to this group.

Role: We are going to add our custom user admin role we created above to this group assignment.
Resource Set: We will define a Not Super Admin resource set and assign the Not Super Admin group.

Anyone added to this group will be able to perform the actions the user admin role is allowed to take, but only the resources in the assignment resource set.

Add the group. Name it User Admin. Give it a Description. Click Save.

Add the admin role.

Edit the group and click on Admin roles. Click Edit group assignments.

Define the resources on which the role can act.

Under Resource set click the down arrow. Click Create a resource set.

Add the Not Super Admin Group to the Not Super Admin Resource Set as show below and then click Save resource set.

Now you can see below that we have assigned the User Admin Role to the User Admin Group and it can perform the actions in this role on the Not Super Admin resource set.

Click Save Changes.

Now this role should be able to perform any of the above actions in the User Admin role on users in the Not Super Admin group.

I’m not yet sure how this resource set applies to the Create User action. A new user will not be in the Not Super Admin group since it doesn’t exist yet. Will this role even be able to create a new user? And even it can, it won’t be able to administer the user becuase it cannot add the user to the Not Super Admin group.

We’ll test it out below and make changes as needed.

Create the Access Admin Group

Follow the same steps as above. In this case we want to create an Access Admin group that can take the actions assigned to the Access Admin Role on the Not Super Admin resource set we already created in the last section.

Add the Access Admin group. Give it a Name, Description, and click Save.

Add the role assignment and for the Not Super Admin group the same way we just did. The only difference is that you can select an existing resource set instead of adding a new one.

Select the Role and Resource set. Click Save Changes.

Create the User Admin and Access Admin users

For the purposes of this test I am going to use the first name, last name for our admin users:

User Admin
Access Admin

In your organization you would use actual first and last names of people.

Click Directory > People. Click Add person.

Add the User Admin.

Use an email address your Admin User can access for the username and primary email.
Add the user to the new User Admin group we just created.
Note that although I am currently logged in as a Super Admin (temporarily) I do not set the password.

Click Save and Add Another.

Repeat for the Access Admin user.

Add the new users to the Not Super Admin group

Add the User admin and Access Admin to the Not Super Admin group we created above.

Now Test.

Always test. We’ll do that in upcoming posts.

Logically, what we did above should work. The User Admin should be able to create new users but not view their passwords. The Access Admin cannot create new users but they can do all the things in Okta that give users access to applications and administration.

In theory, the two users should not be able to affect the super admin. In fact, this configuration also is helpful because the User Admin cannot administer a new user until they have been added to the Not Super Admin group. That means that until the Access Admin is aware of and acknowledges that user exists.

The User Access admin can follow the company process to verify the user has access to their own account and has configured MFA before allowing the User Admin to make any changes to that user and before granting that user additional access.

Login as the User Admin.

Because we assign admin privileges to this user the Admin link will appear on the top right. Click it.

Notice that the user sees far less options in the left menu than the super user.

Click Directory > People.

Create a new user and try to add the user to the Not Super Admin group. Note the error message below: “You do not have permission…”

That’s good because that’s what we want — if this is caused by trying to add a group to a user. The User Admin should not be able to do that, only the Access Admin.

Remove the group from the above configuration and try to save again.

The user still does not have permission. As I guessed above, this would fail because a new user does not exist in the Not Super Admin group. We need to adjust the settings of the User Admin group and role to make this work.

Modify our User Admin Role

Let’s see if this user can modify the User Admin Role.

Notice that the only group available is the Not Super Admin group. That’s because we added our assignment of the User Access Role can only act on the Not Super Admin resource set. That resource set only contains the Not Super Admin group. It appears that we will need to adjust the permissions for the Access Admin group as well, because the access admin cannot see or manage the User Admin group or role.

Adjust the groups via the Super Admin user

Log back in as the Super Admin user.

We are going to change our configuration and create a separate role for creating users which is not restricted to the Not Super Admin group. That’s because a new user won’t be in any group. We need to allow the User Admin to create new users without the group restriction.

First let’s modify the User Admin role and remove the Create User permission, because the way the resource set is configured, it can never be used for this role.

Edit the User Admin role.

Uncheck Create Users and save.

Create a new role named “User Create Admin”.

Follow the process above and choose only the Create Users action.

Head back to the User Admin Group. Add a new assignment as we did above.

Create a new resource set. Choose Users. Click Save resource set.

By choosing Users we gave this role the ability to add any user with no restrictions.

Choose the User Create Admin and the All Users Resource set. Assign it to the User Admin group like we did above or the User Admin Role.

Now you should see two roles with different resource sets assigned to the User Admin Group.

Test again

Log back in as the User admin.

Try to create a new user like we did above.

This time it works.

Now try to create a new user and assign a group.

This time, the User Admin cannot see any of the groups for the create user function since the resource set for this action contains no groups. They can’t even select a group to try to add it to a new user on the create user screen.

More testing needed

I’ll need to do some additional testing to make sure these admin users work the way I need but it looks like at least we have a user that can create users but not assign permissions to those users. That at least makes the create user privilege escalation path harder to achieve.

We’ll revisit the Access Admin role when we integrate with AWS and assign users permissions to assume roles in AWS.

Follow for updates.

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab

Summarize