Synthèse
One thing that comes as a surprise is that native Okta attack paths are relatively short when compared to our security models of Active Directory (AD) and Microsoft Entra ID. There are multiple reasons for this: Okta does not support group nesting and only users can be members of groups Many theoretical privilege elevation paths are intentionally mitigated by only allowing Super Administrators (the most privileged role in Okta) to modify users, groups, and applications that have role assignme
One thing that comes as a surprise is that native Okta attack paths are relatively short when compared to our security models of Active Directory (AD) and Microsoft Entra ID. There are multiple reasons for this: Okta does not support group nesting and only users can be members of groups Many theoretical privilege elevation paths are intentionally mitigated by only allowing Super Administrators (the most privileged role in Okta) to modify users, groups, and applications that have role assignments, built-in or custom Lateral movement between connected computers is extremely limited by the absence of built-in device management capabilities, such as Group Policy. Moreover, Okta authentication is not integrated with popular remote computer management protocols like RDP, SSH, SMB, WMI, or WinRM On the other hand, real-world Okta deployments are seldom isolated and often contain inbound and outbound trust relationship in the form of SAML/OIDC SSO, password replication, or group membership synchronization. These hybrid or cross-technology relationships are part of OktaHound’s data model.