Managing and Using Okta Shared Accounts with Okta Privileged Access

Okta recently announced a new SaaS app service account capability for Okta Privileged Access. This includes being able to manage the passwords for Okta users (accounts) that may need to be shared for administrative functions. This article will explore this new capability.

Introduction

Users in Okta may be consumers of Okta services, like SSO, but also administrators of the platform. There is a rich set of roles and permissions that can be assigned to users to perform administrative functions. These may be assigned to individuals or groups.

It has been standard practice to assign groups to roles and permissions then manage membership of those groups through Okta Identity Governance (access requests to get access, time limits to minimise standing privileges and access certification to review any long-term administrative access).

Earlier this year Okta introduced a new capability called Governance for Admin Roles which applied a similar approach to individual assignment to roles and permissions. This was just one of the areas Okta focussed on to tighten up security for the platform. Another was enforcing Mulit-factor Authentication (MFA) to every administrative access to the platform.

Another recently announced capability is managing Okta service (or shared) accounts in Okta Privileged Access. Many Okta deployments setup shared Okta accounts for administrative functions. This may be so that a team can use the same account to perform specific tasks rather than granting admin rights to individual users. It may be that a special account was setup to create API Tokens or for use with legacy agents. Moving these accounts into Okta Privileged Access means that security around access to them can be tightened – increasing to overall security posture of the Okta deployment.

The new capability uses the term “service account”. This does not mean it applies to just service accounts, but rather any shared/functional privileged account.

The capability is automatically enabled in Okta Privileged Access and the associated Okta feature flag will get enabled when it becomes Generally Available. In the meanwhile, you need to work with Okta to get the feature flag turned on.

An Overview of Managing Okta Shared Accounts in Okta Privileged Access

The solution involves both core Okta (Okta WIC) and Okta Privileged Access. There is an in-built synchronisation component between the two platforms.

The steps in setting up a new Okta service accounts are shown in the following figure. This gives an overview of the components and how they work together.

The new account flow is:

1. A new or existing user is assigned to one or more administrative roles in Okta WIC. Technically the user does not need to be an administrator to be used in this capability, but it doesn’t make sense to apply these controls to an ordinary user.
2. The user is flagged as a service account by applying the “Manage with Privileged Access” action.
3. The user is now visible in the new Service accounts view in the Okta administration UI.
4. At the same time, this new account is synchronised across to Okta Privileged Access and placed into an “Unassigned accounts” holding area.
5. The new account is assigned to a Project within a Resource Group. This Project may have specific settings for password complexity, rotation schedule and exclusive checkout.
6. A Policy and Rule must be configured to allow users (Principals) to access that service account. The rule can also apply an Access Request condition and override the Maximum Checkout time.
7. A user who is entitled can reveal/checkout the Okta service account username and password and leverage them to log into Okta

From an Okta (WIC) perspective the capability is leveraging Okta Users and Administrators, but has added the ability to flag an account as a service account and sync it to Okta Privileged Access.

From an Okta Privileged Access perspective the capability is leveraging standard constructs – Resource Groups, Projects with settings, Policies and Rules with controls. It has added a new resource type of “Okta service accounts” alongside servers and secrets (and SaaS app service accounts that will be covered in another article).

An Example

Let’s look at an example of a user that needs to use a shared (service) account. The user is in a group assigned to the appropriate policy with rule to access the account.

The user logs into their Okta Dashboard and clicks on the Okta Privileged Access tile. They are SSO’d to Okta Privileged Access and have the option of Okta Service Accounts under MY PRIVILEGED ACCESS. This shows one Okta account they can use.

They select the account and will see the access methods available. There may be multiple policy rules that apply to this user. In this case there is only one, so only one access method. It’s set to allow the user to show and checkout the account credentials.

They see the Username and Password for the account (the password is masked by default to reduce the risk of shoulder surfing, but they can reveal the password).

This is a complex password that Okta Privileged Access has generated and applied back into Okta (rotated in PAM terminology). There is also a checkout timer set for this access.

They copy’n’paste the Username and Password into a login prompt in another browser window.

From the Okta Dashboard, the user would launch the Admin UI and would then perform any MFA enrolment and/or response as required. They are now in the Admin UI as the service account with only the admin functions that are assigned to that user.

Back in their original Okta Privileged Access session, they close the dialog that showed the username and password. The account is now shown as CHECKED OUT, meaning no other user can access this account until it’s checked back in.

They can wait for the checkout timer to expire and have it checked in automatically. Or they can Check it in themselves. The go to the Checked Out Accounts menu item to see all accounts they have currently checked out. In this case there’s only the account they used above.

The can use the Check in button to return the account to the pool.

It’s worthwhile looking at the Okta system log to see what occurred with the Check In. You can see the access with the account in the bottom three events. Then there are events related to the check in and password rotation starting, the password being updated in Okta by Okta Privileged Access (passed via the synchronisation mechanism), and then the check in and password rotation completing.

The account now has a new password that is not known to the user who last accessed the account.

Considerations for MFA for These Accounts

As mentioned earlier, as part of Okta’s commitment to tighter security around the platform, MFA is now required for all administrative access into Okta. Putting the passwords into the vault does not change this requirement. So, if using this capability with its password rotation there may be times that MFA makes the process less than optimal. This is not a constraint with Okta Privileged Access, it’s just the way that Okta WIC is configured and you would strike the issue with shared accounts not in Okta Privileged Access. Let’s explore different scenarios.

If you are still running an Okta Org that doesn’t require MFA on admin access, either because it’s old or there is an exception in place, there is no issue. You can checkout the username and password and just access Okta and the Admin UI.

If the shared account will only ever be accessed by one user, then the first time you checkout the username and password and go to the Admin UI, you will need to set up MFA as you would with any new account. From then on, each time you check out the shared account you would just use the MFA you’ve already set up.

However, this becomes more challenging if there are multiple users who need to checkout and use the shared account credentials. The first time the shared account is checked out and the Admin UI is accessed, Okta will prompt to setup MFA. The next time when someone else goes to checkout the shared account, Okta will know that MFA has already been set up and prompt for verification against the previously registered factor (which may be the phone or laptop of the prior user). You could try to add another factor, but the enrolment process will want to use the previous factor for verification. This is how MFA works in Okta. How to handle this situation? Some suggestions:

• Encourage each user to remove their factor when they have finished using the shared account (or possibly build some automation using the Factors API to automate this). This is a painful manual process and probably wouldn’t be 100% reliable.
• If the MFA factor being used has a transferrable SID, you could store this SID in a Server in the Okta Privileged Access vault and have a process to reveal the SID and apply it to the factor. This could also be a painful process.
• Have one person in the team, and their authentication factor as the single factor for the shared account no matter who uses it. That way you have a “dual control” approach.
• Use a shared mechanism for authentication, such as a shared phone, shared email address, even a shared physical token stored in a safe. All have been used in the past for similar situations.

This multi-user, one shared account scenario is probably an extreme edge use case, but may need to be considered. Ideally, the plan should be to move away from shared admin accounts in Okta, and Okta is helping this with initiatives to reduce the need for shared admin accounts, like removing the need for API Tokens with agents.

Conclusion

In this article we have looked at the new Okta service account capability, where shared account credentials are stored in Okta Privileged Access, can be revealed and used by entitled users and regularly rotates the password of those accounts. We have provided an overview of the capability, an example of it’s use and a discussion on how this works with the requirement for MFA on all Okta admin access.

Replacing a static/shared password for these accounts with a complex/regularly rotated password will significantly improve the security posture of your business. Ideally the strategic goal would be to remove the shared admin accounts from Okta and move to individual admin assignments, but in the interim the mechanism shown in this article provides a tactical approach to improve security of the Okta environment.