________  ________  ________  ________  ________  ________  ________ 
 ╱        ╲╱        ╲╱    ╱   ╲╱        ╲╱    ╱   ╲╱        ╲╱    ╱   ╲
╱        _╱    ╱    ╱         ╱         ╱         ╱    ╱    ╱         ╱
╱       ╱╱        _╱         ╱       --╱╲__      ╱         ╱         ╱ 
╲_____╱╱ ╲____╱___╱╲________╱╲________╱   ╲_____╱╲___╱____╱╲__╱_____╱

OCI – Unified Authentication with Azure Identities [Part 1]

As a cloud connected organization, Azure Entra ID is likely being used as a central point of identity. You may need to interface with other cloud services at some point, and the issue of authority might come into question. In this case, OCI is a secondary cloud platform that is being integrated into our IT ecosystem.

  • How do we keep Azure as the primary identity authority while permitting users to access both the OCI cloud console and Linux systems within OCI with their existing IDs?

There are many other articles online that walk through configuring SAML SSO, some articles that outline the Linux PAM module, but no articles that combine both with a central identity source. This concept will be covered in several articles with step-by-step instructions and diagrams. There are a lot of ‘gotchas’, so be sure to read all of the below items.

The following diagram can be considered the 1000ft view to this design.

  • The User “Bob” has a single identity in Entra ID. Bob needs to use his existing ID to authenticate to both the OCI Cloud Console (web) and to Linux systems within OCI via SSH. This design needs to be scalable with many OCI tenants.

  • This design requires both a local on-prem domain and an Entra ID tenant, both synchronized by Azure AD Connect.
    • Authentication to the OCI Cloud Console relies on Federated Authentication, where the auth request is passed on to Azure for validation. (Web)
    • The Linux PAM module installed on Linux systems within OCI relies on Delegated Authentication, where the authentication requests are handled directly on the source system via SSSD. (OCI IDCS)

  • Both Entra ID and OCI AD Bridge application are required to sync the SAME user objects and groups to OCI IDCS! (Double trouble).
    • OCI AD Bridge application reflects object status within IDCS as it appears within the domain. If multiple OCI tenants are required, and an AD group is utilized to define which OCI tenant the user can access, removing a user from a tenant-group does not disable the user in said OCI tenant. Only disabling the user object in AD with disable the user within the OCI tenant (but also within all other OCI tenants as well – This is a problem!)
    • Entra ID User and Group Provisioning functions more independently with Enterprise Applications. Each OCI tenant is configured with a dedicated Enterprise App in Azure. If you remove a user assignment from the specific Azure enterprise app, the user gets disabled only within that specific OCI tenant!
  • OCI Linux PAM module relies on SSSD local domain for authentication (OCI IDCS) along with User and Group POSIX IDs.
    • The On-prem domain should utilize an extended attribute on User objects for POSIX — eg. “linuxUID” — Group objects should also utilize an extended attribute “linuxGID”
    • Entra ID unofficially supports extending the schema with custom attributes to pass along into OCI IDCS for both User and Group object types.
    • OCI AD Bridge also supports custom attributes, but only for User objects. Mapping custom attributes to Group objects is not supported.
  • OCI Linux PAM module requires Delegated Authentication to authenticate against IDCS. AD Bridge is a required piece to this solution. There is currently no known way to utilize Federated Authentication to authenticate a user on an OCI Linux box directly to Azure – Such solution would be a direct replacement for the Linux PAM module.