Configuring an HTTP proxy

Point the management agent at an HTTP proxy when the MIM server cannot reach Okta directly.

Skip this page if the MIM server can reach your Okta org directly.

The management agent uses the standard .NET proxy environment variables for both OAuth token requests and Okta API requests. It has no proxy settings of its own.

Step 1: Set the environment variables

All Okta traffic is HTTPS, so HTTPS_PROXY is the setting that matters. Add NO_PROXY only if some hosts must bypass the proxy.

Open PowerShell as an administrator:

[Environment]::SetEnvironmentVariable(
    'HTTPS_PROXY',
    'http://proxy.example.com:8080',
    'Machine')

[Environment]::SetEnvironmentVariable(
    'NO_PROXY',
    'localhost,127.0.0.1,.example.com',
    'Machine')

Use machine variables so the setting applies whichever account runs the MIM Synchronization Service.

HTTP_PROXY covers plain HTTP requests and ALL_PROXY acts as a fallback, but neither is needed here. Microsoft documents the full behavior under HttpClient.DefaultProxy.

Step 2: Restart the MIM Synchronization Service

A running service does not pick up later changes to the machine environment. Restart it after adding, changing, or removing any of these variables.

Step 3: Test

Open the Okta management agent properties and retrieve the schema. If that works, run a controlled import.

If it fails, check the proxy address and port, the firewall rules, whether the MIM Synchronization Service account is allowed through the proxy, and the management agent log.

Removing the proxy configuration

[Environment]::SetEnvironmentVariable('HTTPS_PROXY', $null, 'Machine')
[Environment]::SetEnvironmentVariable('NO_PROXY', $null, 'Machine')

Restart the MIM Synchronization Service afterwards. With no proxy variables set, .NET falls back to the proxy configuration of the account running the service, and sends requests directly if that account has none.