How to Centrally Manage Server User Attributes With Okta
A major driver for any organization’s identity strategy is to have a single authoritative source where security policies are consistently applied. Disparate identity stores lead to disparate controls, which makes it incredibly difficult to adhere to your compliance-mandated security policies. Okta has grown to be the market leader in this space because we enable organizations of all kinds to unify identity across their entire application landscape – in the cloud or on-premises.
Since the introduction of Advanced Server Access, Okta has enabled our customers to extend the same unifying identity principles to the infrastructure layer, centralizing administrative access controls to Linux and Windows servers across any cloud or on-premises environment. This allows IT and Security managers to secure access to critical infrastructure resources across AWS, GCP, Azure, or on-premises, and it provides systems administrators a familiar Single Sign-On experience over SSH and RDP.
As an extension of the Okta Identity Cloud, with Advanced Server Access, your Linux and Windows server user and group accounts are managed via Universal Directory, and automated downstream via Lifecycle Management. As a mechanism to provide further control and flexibility, we are pleased to announce General Availability of a new Advanced Server Access feature: Enhanced User Attributes Management.
The direct relationship between Okta and your servers
To illustrate this new feature, it’s important to understand how Advanced Server Access works with Okta. Advanced Server Access is an integrated Okta application where administrators assign users and groups just like they would Slack, Zoom, or Box, for example, at which point the accounts are automatically provisioned downstream. The difference here is that once users and groups are within the Advanced Server Access application, administrators can take it one level further by explicitly assigning groups to a collection of servers, where the accounts are then provisioned downstream as local server accounts, managed by an agent on the machine. In Advanced Server Access, a collection of servers and their associated permissions is known as a Project. The below diagram illustrates the process of automated server account lifecycle management:
Server account lifecycle management
- Okta Admins assign users and groups from Okta to Advanced Server Access as a downstream application. As an integrated application, users and their respective group memberships are provisioned downstream via the SCIM protocol.
- ASA Admins explicitly assign groups to Projects, which grants authorized access to the servers that are enrolled with the respective Project.
- The Server Agent running on each enrolled server periodically communicates with the ASA API to query for any changes to user status or group membership.
- The Server Agent that acts as the management plane for local accounts creates, updates, and deletes users and groups in accordance with the ASA API.
Eliminating intermediary directory services
A core challenge with dynamic cloud infrastructure is ensuring account and policy consistency when spinning up and down ephemeral resources across various providers such as AWS, Google Cloud Platform, and Microsoft Azure. Account and credential sprawl very quickly becomes a nightmare for IT and Security managers. This only compounds at scale, especially when you have compliance-mandated security procedures to enforce.
A common approach might be to operate a directory service like LDAP between your Identity Provider and your servers, with a local interface on each machine. While this provides a local identity on each machine, the problem with this method is that keeping that directory service in sync is a real distributed system challenge – meaning operational burden that you frankly don’t have the time for. When dealing with highly scalable, elastic cloud infrastructure, the last thing you want is complex configurations or performance bottlenecks holding you back.
This is a pain point that Okta is able to solve through our elegant approach to automated lifecycle management. By establishing a direct relationship between each downstream server and Okta as your source of truth for Identity, you can eliminate any intermediary service from your operations. With the Server Agent periodically polling for any changes within Okta, you can also ensure up-to-date identity information across your entire fleet of servers.
The capabilities we are launching today via the Enhanced User Attributes Management feature enable even more control and flexibility, whether you are spinning up new cloud infrastructure, or deploying Advanced Server Access across existing server environments.
Mastering server user attributes with Okta
Linux and Windows server accounts carry attributes including username, user ID (UID), and primary group ID (GID) to name a few. Users may further personalize their accounts with their preferred shell or home directory, for example. Prior to Enhanced User Attributes Management, the account username was mastered as an attribute in Universal Directory, but UID and GID were assigned as a function of creating an Advanced Server Access Project.
We learned through many customer implementations that this method works perfectly fine when spinning up new infrastructure, but could lead to account conflicts when deploying across existing server environments. The most common example that arose was file share mounts tied to a UID. In order to preserve existing configurations, additional attributes such as UID need to have the same level of consistency across all servers as username. You asked, and we listened.
Thankfully, the core architecture to master server attributes already existed as a function of the integration between Universal Directory and Advanced Server Access. What we are now delivering with Enhanced User Attributes Management is additional user-level attributes included within a user profile in Okta, with the same end-to-end lifecycle management. This includes:
- Unix Username
- Windows Username
- UID
- GID
- Home Directory
- Default Shell
- User description (GECOS field)
As an administrator, you have the option to apply these attributes consistently across every Advanced Server Access Project, or have per-Project overrides for additional flexibility. The below diagram illustrates the flow of attribute data from Okta to downstream servers.
Custom server account attributes mastered by Okta
Better enable velocity at scale with Okta
To keep up with the pace of the business with your supporting cloud infrastructure, you need an Identity-first, cloud native approach to access management. With Okta as the source of truth for your local server accounts, you can:
- Lower your TCO and eliminate performance bottlenecks by removing unnecessary services in favor of a pure SaaS architecture
- Automate the end-to-end lifecycle of local server users and groups with consistency across the entire fleet
- Mitigate the risk of account and credential theft through seamless Single Sign-On backed by short-lived, tightly scoped credentials
Getting started with Enhanced User Attributes Management
To configure custom attributes for your existing Advanced Server Access Team, follow the steps detailed in the Product Documentation. If you are new to Advanced Server Access, learn more about the product or sign up for a free trial today.
