How to obtain Azure Access Directory access tokens from a non-interactive process running on-premises, without sharing secrets?

0
votes

The standard pattern to authenticate a non-interactive process on Azure Active Directory is to either:

  1. Use managed identities, when the service is running on Azure.
  2. Use the OAuth 2.0 client credentials flow whenever managed identities are not available.

However, #1 is not available for services running on-premises, and #2 requires the sharing of secrets, which adds a lot of operational complexity - key storage, protection and rotation.

Question:

For a setup in which Azure Active Directory has been federated with Active Directory (see diagram), is there a way for non-interactive services running on-premises to obtain access tokens from Azure Active Directory without sharing any secrets? All the required trust relationships seem to be in place, but is there a way to get it done?

Setup Diagram

1
azureoauth-2.0azure-active-directory

1 Answers

0
votes

The short answer is yes.

Components

  1. An Azure Active Directory tenant federated to an Active Directory, able to do Single Sign On using Windows Authentication.
  2. An Application Registration with user_impersonation permissions granted.
  3. A specific configuration for your MSAL request.

Details

In order to achieve this, you need to make use of the OAuth 2.0 on-behalf-of flow, and in order to do so, you need to create an Application Registration on AAD. Make sure to "Grant Admin Consent" for the "user_impersonation" scope of every API you would like your on-premises applications to be able to access. Typical examples are:

  • Azure Key Vault.user_impersonation
  • Azure SQL Database.user_impersonation
  • Azure Storage.user_impersonation
  • Microsoft Graph.user_impersonation

but really, there is no limit. Also, notice there is a minimal security impact because you are not granting any permissions. You are just allowing any users able to authenticate against this Application Registration to go ahead and try to access the granted resources under their own permissions.

Once the Application Registration is ready, you'll need to use the following code to get the tokens:

const string ApplicationRegistrationId = "the id";
const string Tenant = "YourDomain.com";

// Any user name will do as long as it's in your domain. This is because AAD will redirect the request to the federated Identity Provider, which will then use Kerberos, which will the real user.
const fakeUsername = "[email protected]";

// The user_impersonation scopes you want to access. They need to have been granted on the Application Registration. The example below is for Azure Storage:
var scopes = new string[] { "https://storage.azure.com/user_impersonation" };

var app = PublicClientApplicationBuilder.Create(ApplicationRegistrationId).WithAuthority(Tenant).Build();
var authenticationResult = await app.AcquireTokenByIntegratedWindowsAuth(scopes).WithUsername(fakeUsername).ExecuteAsync();
// Go ahead and use the AccessToken from authenticationResult.AccessToken

Diagram

enter image description here

Notes

I have not found the approach described above documented anywhere else, but it is proven to work, and given that it removes the need to share any secrets - no management, rotation, etc. - it would be great to see it documented by Microsoft.

It is particularly applicable and useful in corporate environments with a hybrid setup, i.e. services running on-premises and resources deployed to Azure.