AD-Joined: Okta Advanced Server Access Offers New Flexibility

According to the Verizon 2021 Data Breach Investigations Report, servers are the #1 most-targeted asset in security incidents. This means that critical server infrastructure, whether native to the cloud or on-premises, must be prioritized as part of an organization’s modern security posture.

To this end, Okta Advanced Server Access (ASA) enables organizations to securely manage privileged access to critical infrastructure resources—including Linux and Windows servers—by automating the configuration of users, groups, and policies, at any scale, through the Okta Identity Cloud. With ASA, customers can enforce least privilege with a simple SaaS deployment model that extends the full platform of Okta to modern server infrastructure, all without needing to manage credentials or shared accounts. Deployment for these capabilities is complete in days to weeks, not years.

Based on customer demand, we strived to make ASA a comprehensive server IAM solution, regardless of whether organizations are running Windows or Linux workloads. To date, ASA has supported Remote Desktop Protocol (RDP) connections to Windows Servers by installing an agent on the server and managing a local account. However, many enterprise deployments of Windows Server make heavy use of Active Directory-joined users, specifically for policy and permissions management, and we wanted to build a more seamless approach for these use cases. 

That’s why we’re happy to announce the General Availability (GA) of ASA support for AD-joined users. This new “agentless” approach allows you to link multiple Active Directory (AD) accounts to a singular Okta identity, using ASA as the authoritative access control point for all your Windows Servers.

With AD-joined user support, you can now enable “passwordless” RDP authentication using ephemeral credentials through ASA, without needing to install the ASA agent on the Windows server or use a Windows local account. This means that users can’t bypass ASA and RDP directly to servers using static credentials; they must access the server through ASA, which is minting the ephemeral credentials used to authenticate on the target Windows server.

AD-joined user support gives you more flexibility to deploy ASA in the most optimal model for your use case. For example, you may still want to use the agent-based approach for “break glass” scenarios, whereas the AD-joined approach may be better suited for use cases such as standard AD account logins. 

With the new AD-joined support, ASA customers have a place to centrally manage and synchronize available AD servers, and an audit system to track RDP connections and any changes to servers.

AD-joined is now GA for ASA customers. You can learn more, including how to get started in a few simple steps, by visiting our AD-Joined documentation.