Directory Connector

Directory Connector lets FoxIDs use an external directory as the authoritative source for internal users' passwords and selected user data.

The users still exist as internal users in the FoxIDs environment. During password authentication and password lifecycle operations, FoxIDs calls the Directory Connector API instead of validating the password only against the internal FoxIDs user.

Because FoxIDs keeps an internal user record, FoxIDs multi-factor authentication (MFA) handling can be added to users from the external repository. The connector can return MFA-related user settings, such as requireMultiFactor and disabled two-factor methods, and FoxIDs applies those settings to the internal user while the external repository remains authoritative for passwords and selected user data.

For Active Directory, FoxIDs includes an IIS-deployable Directory Connector for Active Directory component.

Use Directory Connector when:

  • You want users to sign in with the normal login authentication method.
  • You want to enable users from an existing directory for OpenID Connect and SAML 2.0 applications through FoxIDs.
  • Your external directory is authoritative for password validation and password changes.
  • You want FoxIDs to keep an internal user record with identifiers, properties, claims, multi-factor authentication (MFA) settings, access assignments, and optionally a local password copy.
  • You want a path to later switch to internal users and password validation in FoxIDs without forcing all users through a password reset.

There is one Directory Connector per environment. When it is enabled, it applies at the environment level.

How it works

FoxIDs performs on-demand synchronisation when a user enters an identifier in a login or recovery flow. It calls synchronise-user before checking the account, creates a FoxIDs user if needed, and updates identifiers, directory-owned properties and claims.

Synchronisation is part of enabling Directory Connector. FoxIDs synchronises at the start of login, recovery and existing-session account checks, and when a refresh token is used for a directory-bound account. Confirmation-code, MFA and Extended UI continuations use the selected account and the normal FoxIDs checks. A failed synchronisation stops the flow.

The response must include a stable, unique directoryUserId. Use the directory's permanent account ID rather than an email, phone number or username. FoxIDs uses this binding to find the same account after identifiers change. Enrolled authenticator apps and FoxIDs access assignments are retained.

When a user enters an identifier, FoxIDs sends that email, phone number or username alone. For existing-session reuse and refresh-token requests, FoxIDs loads the associated user and synchronises by the directory ID stored on that user. Password operations also use the directory ID on the loaded user. It is not stored separately in the login sequence.

The connector returns the complete current user snapshot. FoxIDs replaces directory-owned identifiers, properties and claims, including account disable state, password-change requirements and initial password setup settings. It applies the same account, recovery and MFA checks used for internal users. Unbound internal users are not synchronised or automatically linked.

A synchronisation response with disableAccount: true disables the FoxIDs user and revokes its active sessions and refresh-token grants. If the connector returns the user_deleted error code when synchronising a user by their directory ID, FoxIDs deletes the internal user and revokes their active sessions and refresh tokens. When an identifier-only lookup finds no account, FoxIDs checks any existing directory binding before continuing, so outdated local account data cannot permit login or recovery. The user_not_exists error code alone does not delete an account.

Refresh-token requests check both the original account and an impersonated local account when they are directory-bound. When this synchronisation discovers a disabled or deleted account, FoxIDs revokes its active sessions and refresh-token grants and rejects the current token renewal. The ordinary active-session check validates FoxIDs session state; it does not itself contact the directory. An application that validates an issued access token locally observes the token's expiry rather than FoxIDs session revocation.

Changes become available at the next on-demand account check. There is no background synchronisation process.

Directory Connector can be used as a permanent integration, with users and passwords managed in the external directory, or to gradually migrate users to FoxIDs. For migration, keep the connector enabled while users are provisioned and enable local password copy to save their passwords after successful authentication, password changes or resets through FoxIDs.

Once migration is complete, disable Directory Connector and manage users and passwords directly in FoxIDs. Before switching, create any users who have not yet been provisioned and arrange password setup or recovery for users without a current local password copy. The saved copy reflects the latest successful password authentication, change or reset through FoxIDs; subsequent password changes made only in the external directory are not included.

Lookup protection

When a user enters an email, phone number or username in the sign-in or recovery UI, the directory lookup counts towards a limit shared by all entered identifiers in the current login sequence. The limit uses the environment's Failed login attempt limit, counter lifetime and observation period settings. Successful lookups and failed connector calls both count; successful password authentication does not reset this counter. At the limit, the flow must wait for the observation period or start a new login sequence. Synchronisation for session reuse and refresh-token requests does not use this counter. Password and confirmation-code protections continue to use their existing separate counters.

Login identifiers and directory binding

Users can sign in with their current email, phone number, or username, according to the identifier types enabled on the login authentication method. Before password authentication, the entered identifier must match one of the current identifiers returned by the connector. FoxIDs removes surrounding whitespace from the login input. Email and username comparisons are case-insensitive. Phone numbers use the required international format.

Signing in after identifiers change

When users enter an identifier, FoxIDs synchronises their email, phone number, and username from the directory. The stable directory ID connects them to the same FoxIDs account even when one or all of these identifiers change. Their enrolled authenticator apps and access assignments are retained, and existing access restrictions and MFA requirements continue to apply.

Situation What happens during synchronisation
The user signs in with an unchanged username, while their email or phone number has changed in the directory. FoxIDs updates the same account with the current identifiers returned by the connector.
The user signs in with a new identifier that FoxIDs does not yet know. If the directory returns the new identifier and the same stable directory ID, the user continues with their existing FoxIDs account. This also works when all their identifiers have changed.
The user signs in with an old identifier that the connector no longer returns. Login is rejected with the normal login error, even if they still know the password. The user must use a current identifier of an enabled type.
The connector stops returning an email, phone number, or username. During synchronisation, that identifier is removed from the FoxIDs account. The connector must return at least one current identifier.

For example, a user whose email changes from old@example.org to new@example.org can sign in with new@example.org before FoxIDs knows that address. The connector must return new@example.org and the user's unchanged directory ID. The user keeps the same account and enrolled authenticator apps. Alternatively, they can sign in with an unchanged username if username login is enabled.

The connector must return the complete set of current identifiers that FoxIDs should keep. Omitted or empty values are treated as removed identifiers, and previous values are not retained as login aliases. Only identifier types enabled on the login authentication method can be used for sign-in.

Account conflicts

Each directory user must have a stable, unique directory ID, and their identifiers must not belong to another FoxIDs account. FoxIDs first looks up the entered identifier in the directory, then uses the returned directory ID to find or create the local account. If saving the returned identifiers conflicts with another account, the flow stops. An administrator must correct the conflicting directory or FoxIDs account configuration; accounts are not automatically merged or reassigned.

An existing internal user without a directory binding cannot sign in through Directory Connector. Enabling the connector does not automatically link an existing account to a directory user merely because their email, phone number, or username matches.

Local password copy

The external directory is authoritative while Directory Connector is enabled. FoxIDs does not fall back to the local password hash if the Directory Connector API is temporarily unavailable.

By default, FoxIDs saves a local password copy on the internal user after a successful connector password validation or password lifecycle operation. This can be disabled in the environment settings.

The local password copy is not used while Directory Connector is enabled. It exists to support a later switch to internal users and password validation in FoxIDs without forcing all users through a password reset.

Password lifecycle

User creation and password lifecycle operations are delegated to the Directory Connector API:

  • Password authentication calls the authentication endpoint.
  • Login create-user flow calls the create-user endpoint.
  • User password change calls the change-password endpoint.
  • Set-password and reset-password flows call the set-password endpoint.

Password endpoints receive the stable directoryUserId from the loaded user. The directory checks current account state and credentials when performing the operation. Authentication, password change and password reset return success or an error. User creation returns the created account's directory ID, which FoxIDs uses for a separate synchronisation.

Password operations use the directory ID stored on the loaded FoxIDs user. The connector checks account state and the credential or reset authorisation required for that operation, performs the action and returns success or an error. User identifiers, attributes and claims are returned only by synchronisation.

After a successful password change or reset, FoxIDs records the current password-change time and clears the requirements to change or set a password. It also saves a local password copy when configured. The active sequence then continues with the normal FoxIDs account, recovery and MFA handling.

If an action fails or FoxIDs cannot save the known password changes, the flow stops. A password change already accepted by the directory is not rolled back, and FoxIDs does not automatically repeat the action after a timeout or failed response. The next synchronisation refreshes the local account.

When Enable password policy is enabled, FoxIDs verifies the current directory credential before applying its new-password checks. This can require an additional authentication call before change-password.

FoxIDs does not update its internal password history when Directory Connector is used, because FoxIDs does not necessarily know about all password changes in the external directory.

Password setup and recovery

At the first sign-in, a directory user can set a password using an email or SMS confirmation code, either because they have forgotten their password or because they are required to choose a new one.

To use Forgot your password?, enter a current directory identifier of a type enabled on the login authentication method. FoxIDs synchronises and provisions the account before sending the confirmation code. Email or SMS recovery must be enabled, and the user must have access to the current recovery contact returned by the directory.

After the user verifies the code and submits a new password, FoxIDs calls set-password with the stable directory ID. To require the user to set a password through this flow, return setPasswordEmail or setPasswordSms and the corresponding contact identifier. FoxIDs uses its normal password setup flow.

Confirmation codes are bound to the account they were issued for. Accounts managed through a directory connector use the same code verification flow as other internal users. FoxIDs preserves the normal recovery failure handling without exposing connector diagnostics.

Password policy and error messages

The external directory enforces the password policy. FoxIDs uses the environment password policy when it shows password-policy error messages returned from the connector.

Configure the environment password policy to match the external directory password policy. If they do not match, users can see password guidance that does not reflect the actual external directory requirements.

For example, if the external directory rejects a password because it is too short, FoxIDs uses the environment password minimum length when rendering the error message.

Implement API

You implement a Directory Connector API and configure FoxIDs with its base URL and secret.

The API has a base URL and five endpoints:

  • synchronise-user looks up a user and returns their current account state, identifiers and claims.
  • authentication validates a user's current password.
  • create-user creates a new user in the external directory and returns their permanent directory ID.
  • change-password validates the current password and changes it to a new password.
  • set-password sets a new password without validating the current password.

If the base URL is https://somewhere.org/directory, the endpoints are:

  • https://somewhere.org/directory/synchronise-user
  • https://somewhere.org/directory/authentication
  • https://somewhere.org/directory/create-user
  • https://somewhere.org/directory/change-password
  • https://somewhere.org/directory/set-password

FoxIDs Cloud calls your API from IP 57.128.60.142.
IP(s) can change or be expanded.

Security

Requests are secured with HTTP Basic authentication:

  • Username: directory_connector
  • Password: the configured API secret

The call is HTTP POST with a JSON body.

FoxIDs sends the selected language in the Accept-Language request header, for example Accept-Language: da-DK. In a login flow, this follows the language selected by ui_locales or the browser, with English as the FoxIDs fallback. The API can use this header to localise user-facing messages and must choose its own fallback if it does not support the requested language. This header is sent to all five endpoints.

Synchronisation request

The synchronise-user endpoint receives either a user identifier or a known directory ID. The first lookup in a login or recovery flow uses the entered identifier. FoxIDs uses the stored directoryUserId for existing-session checks and refresh-token requests, and the returned directory ID after create-user.

An initial email lookup:

{
  "email": "user1@somewhere.org"
}

A subsequent account check:

{
  "directoryUserId": "a1b2c3d4"
}

Use directoryUserId as the authoritative lookup key when present. Otherwise, resolve exactly one of email, phone or username. Return HTTP 200 with the complete user snapshot, including disabled accounts. Return the user_deleted error code when the known ID is absent, and the user_not_exists error code when an identifier-only lookup finds no account. Never accept a supplied identifier as proof of account ownership.

FoxIDs selects the request identifier according to the enabled login identifiers. If only username is enabled, an email-shaped input is sent as username. Surrounding whitespace is removed. The input must match a current response identifier of an enabled type; the guessed request field does not restrict which response field can match.

For errors, see Error response.

Success response

The synchronise-user endpoint returns HTTP 200 with a complete user snapshot. When the request supplies a directory ID, the response must contain that same ID. FoxIDs verifies it before saving any returned data. HTTP 204 or an incomplete snapshot is rejected.

{
  "directoryUserId": "a1b2c3d4",
  "email": "user1@somewhere.org",
  "phone": "+4511223344",
  "username": "user1",
  "confirmAccount": true,
  "disableAccount": false,
  "changePassword": false,
  "setPasswordEmail": false,
  "setPasswordSms": false,
  "disableSetPasswordEmail": false,
  "disableSetPasswordSms": false,
  "passwordLastChanged": 1760000000,
  "emailVerified": true,
  "phoneVerified": true,
  "disableTwoFactorApp": false,
  "disableTwoFactorSms": false,
  "disableTwoFactorEmail": false,
  "requireMultiFactor": false,
  "claims": [
    { "type": "name", "value": "User One" },
    { "type": "role", "value": "employee" }
  ]
}

FoxIDs uses the response to create or update the internal user in the environment.

Fields:

  • directoryUserId is required. It must be stable and unique in the external directory and is stored on the internal FoxIDs user.
  • email, phone, and username are optional individually, but at least one must be present. FoxIDs stores the returned values as the internal user's identifiers. Returned user identifier values must uniquely identify a single user in the external directory used by the connector.
  • phone must include the country calling code in international format, for example +4511223344.
  • confirmAccount controls whether FoxIDs should run a confirmation flow to confirm the internal user.
  • disableAccount controls the direct account disable state. A transition to disabled revokes the user's FoxIDs sessions and refresh-token grants.
  • changePassword requires a password change after successful credential verification.
  • setPasswordEmail and setPasswordSms require password setup through the corresponding confirmation-code flow. The contact identifier must be present, and the recovery method must be enabled.
  • disableSetPasswordEmail and disableSetPasswordSms disable the corresponding recovery methods.
  • passwordLastChanged is an optional non-negative Unix timestamp in seconds. When supplied by synchronisation, it updates the password age used by FoxIDs. When omitted, an existing timestamp is retained. A successful password change or reset records the current time in FoxIDs; a later synchronisation can supply the directory's authoritative timestamp.
  • emailVerified controls whether the internal user's email is marked as verified.
  • phoneVerified controls whether the internal user's phone number is marked as verified.
  • disableTwoFactorApp disables authenticator app two-factor authentication for the internal user.
  • disableTwoFactorSms disables SMS two-factor authentication for the internal user.
  • disableTwoFactorEmail disables email two-factor authentication for the internal user.
  • requireMultiFactor controls whether the internal user must use multi-factor authentication.
  • claims is optional. FoxIDs stores the returned claims on the internal user.

Claims support an optional valueType: String, Boolean, Number, JsonObject or JsonArray. The value field remains text; omit valueType for String. FoxIDs preserves the selected type and logs a warning before falling back to text for an invalid value. See claim value types for examples and number limits. The same representation is used for claims sent in create-user requests and returned in synchronisation responses.

FoxIDs ignores claims with a missing, null, empty or whitespace-only type or value. With trace message logging enabled, the response trace includes the received claims before they are filtered. Long trace messages are truncated.

Protected claims, such as sid and auth_time, are also discarded from synchronisation responses.

Authentication request

The authentication endpoint receives the required stable directory ID and current password.

{
  "directoryUserId": "a1b2c3d4",
  "password": "testpass1"
}

Validate current directory account state and the password before returning success. Verify the credential before returning account-specific password-policy guidance.

For errors, see Error response.

Success response

On success, return HTTP 204 with no response body.

Create-user request

The create-user endpoint receives exactly one user identifier, a required password, selected create-user properties, and claims collected during the FoxIDs create-user flow.

{
  "email": "user1@somewhere.org",
  "password": "testpass1",
  "confirmAccount": true,
  "requireMultiFactor": false,
  "claims": [
    { "type": "given_name", "value": "User" },
    { "type": "family_name", "value": "One" }
  ]
}

Fields:

  • Exactly one of email, phone, or username is sent.
  • password is required. Passwordless create-user is not supported with Directory Connector because the Directory Connector API authenticates users with a password.
  • confirmAccount and requireMultiFactor are the requested FoxIDs create-user settings.
  • claims contains the non-identifier claims collected during the FoxIDs create-user flow.

For errors, see Error response.

Success response

On success, return HTTP 200 with the permanent directory ID of the created account:

{
  "directoryUserId": "a1b2c3d4"
}

FoxIDs then calls synchronise-user with this ID to retrieve the complete account and create the internal FoxIDs user.

Change-password request

The change-password endpoint receives the required directory ID, current password and new password. Verify the current credential before returning account-specific policy guidance.

{
  "directoryUserId": "a1b2c3d4",
  "currentPassword": "oldpass1",
  "newPassword": "newpass1"
}

For errors, see Error response.

Success response

On success, return HTTP 204 with no response body. The password change must complete the password requirement in the directory.

Set-password request

The set-password endpoint receives the required directory ID and new password. FoxIDs calls it after authorising the password reset or setup, including confirmation-code verification in recovery flows. The connector must recheck current account state before changing the password.

{
  "directoryUserId": "a1b2c3d4",
  "password": "newpass1"
}

For errors, see Error response.

Success response

On success, return HTTP 204 with no response body. The password reset or setup must complete the password requirement in the directory.

Error response

All endpoints use the same JSON error format. Return an error code supported by the endpoint in the error field and diagnostic details in errorMessage. For example, a rejected password from authentication:

{
  "error": "invalid_password",
  "errorMessage": "Invalid password."
}

Use these HTTP status codes:

  • 401 with the invalid_api_id_secret error code when HTTP Basic authentication is rejected.
  • 400, 401 or 403 for other supported error codes listed in the endpoint table below.
  • 500 for a technical failure in the connector.

The errorMessage field is diagnostic text for the FoxIDs logs and is not shown to the end user. Include the reason for the failure, but never include passwords, API secrets or private keys.

Only the authentication endpoint can return the login_rejected error code, after verifying the user's identifier and password. It can include an optional uiErrorMessage, which FoxIDs displays as plain text on the login form. The API supplies this message in the language selected through Accept-Language:

{
  "error": "login_rejected",
  "errorMessage": "Credentials verified; login rejected by directory policy.",
  "uiErrorMessage": "You cannot log in here. Contact support."
}

If uiErrorMessage is omitted, null, empty or contains only whitespace, FoxIDs shows the same localised general login message as for the invalid_password and operation_rejected error codes. For other supported error codes, FoxIDs ignores uiErrorMessage and selects the user-facing message from its own localised text resources. Diagnostic errorMessage text is never used as a fallback for a user-facing message. See Authentication errors and user privacy for credential-verification requirements.

Errors from authentication, change-password and set-password do not return user data, change the internal account or revoke existing sessions and refresh tokens. Synchronisation applies directory account changes. Rejected authentication and change-password attempts still count towards the existing failed-login limit.

Supported error codes by endpoint:

Error code synchronise-user authentication create-user change-password set-password Meaning
invalid_api_id_secret Yes Yes Yes Yes Yes The HTTP Basic API username or secret is invalid.
user_exists No No Yes No No A user with the supplied identifier already exists in the external directory.
user_not_exists Without directory ID No No No No No directory user matched the identifier-only lookup.
invalid_password No Yes No No No The password in an authentication request was rejected by the directory.
login_rejected No Yes No No No Login was rejected after verifying the user identifier and password. An optional uiErrorMessage is shown on the login form.
invalid_current_password No No No Yes No The current password in a change-password request was rejected by the directory.
create_user_not_supported No No Yes No No The connector does not support creating users in the external directory.
operation_rejected No Yes No Yes Yes The operation cannot be completed, for example because the account is unavailable. FoxIDs logs errorMessage, ignores uiErrorMessage and shows a generic localised failure without changing account state.
user_deleted With directory ID No No No No A known directory ID no longer exists. FoxIDs revokes access and deletes the user during synchronisation.
password_not_accepted No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set was rejected by a directory password rule that does not map to a more specific code.
password_min_length No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set is shorter than the directory password minimum length.
password_max_length No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set is longer than the directory password maximum length.
password_banned_characters No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set contains one or more characters or words rejected by the directory.
password_complexity No Yes Yes Yes Yes Legacy character-complexity error interpreted by FoxIDs as password_character_variation. Use one of the two specific character error codes for new integrations.
password_character_repeat No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set contains excessive character repetition.
password_character_variation No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set does not contain sufficient character variation.
password_email_text_complexity No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set contains the user's email or part of it.
password_phone_text_complexity No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set contains the user's phone number or part of it.
password_username_text_complexity No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set contains the user's username or part of it.
password_url_text_complexity No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set contains text related to the FoxIDs URL.
password_risk No Yes Yes Yes Yes The password being authenticated, used for create-user, changed, or set is known to be risky, compromised, or otherwise unsafe.
password_history No No No Yes Yes The new password was rejected because it has been used before.
password_expired No Yes No No No The supplied password was verified but has expired; the user must change it before authentication can continue.
new_password_equals_current No No No Yes No The new password is the same as the current password. set-password cannot return this error because it does not receive the current password.

When FoxIDs needs to check its own password policy before a password change, it first calls authentication to verify the current password. If the connector returns the password_expired error code from that authentication, the change can continue. The change-password endpoint itself must accept a verified expired current password and return only errors supported for the change operation.

For password-policy errors, FoxIDs uses the environment password policy to show the user-facing error message. See Password policy and error messages.

Return only an error code supported by the endpoint and the supplied directoryUserId, as listed above. An unsupported code, malformed response or unexpected HTTP status is an integration failure and leads to the generic error page. See Troubleshooting browser errors to find the diagnostic details using the identifiers on the error page.

Authentication errors and user privacy

An unauthenticated caller must not be able to determine whether a username or email address exists from a login failure. During password authentication, FoxIDs handles the supported errors as follows:

Connector error User-facing result
invalid_password, operation_rejected, or an unavailable account established during synchronisation The same general login message, such as Wrong email or password., translated into the active language and adapted to the enabled login identifiers.
login_rejected The supplied uiErrorMessage, or the same general login message if it is missing or blank, in the same place on the login form.
password_not_accepted The password-change page with general password-policy guidance.
password_expired or another specific password-policy error The password-change page with the corresponding localised password-policy guidance.

The connector must verify the supplied current password before returning a password-policy error from authentication. Otherwise, a different page or message can let an attacker discover users and confirm their identifiers by guessing usernames or email addresses. For change-password, verify the current password before returning account-specific guidance about the new password. General format checks must not disclose whether an account exists.

If a user is not allowed to log in through this login flow for any reason, first validate the supplied user identifier and password. Only return a rejection based on this restriction after successfully verifying both, so that the restriction cannot reveal whether a guessed identifier belongs to a real user. Return the login_rejected error code from authentication, put the diagnostic reason in errorMessage and optionally provide safe user guidance in uiErrorMessage. If the credentials cannot be verified, return the normal authentication failure without disclosing the restriction.

FoxIDs relies on the connector to verify the credentials before returning the login_rejected error code; a successful account lookup or knowledge of directoryUserId is not sufficient. Before credentials have been verified, show any instructions or buttons for alternative login methods independently of whether the submitted identifier matches an account.

Only synchronise-user reports account state: return a complete snapshot with disableAccount: true for a disabled account, or the user_deleted error code when a known directory ID no longer exists. Password endpoints return the operation_rejected error code if the account is unavailable. Unlike the login_rejected error code, this error does not require a verified password because it never supplies account-specific guidance to the browser.

Keep failure handling consistent across known and unknown identifiers, including observable response timing and protection against repeated attempts. A generic message alone does not prevent account discovery if a different redirect, status or response time reveals the result. Follow the OWASP authentication error guidance when implementing the connector.

API sample

The sample DirectoryConnectorApiSample shows how to implement the Directory Connector API in ASP.NET Core.

Implementations and test clients must follow the endpoint contracts above: HTTP 200 with a complete user snapshot for synchronise-user, HTTP 200 with the created directory ID for create-user, and HTTP 204 with no body for successful password operations.

Active Directory component

FoxIDs includes an IIS-deployable Directory Connector for Active Directory component. The component implements the Directory Connector API for one AD/LDAP domain and can synchronise accounts, validate passwords, change passwords, set passwords, return configured AD attributes as claims, and return configured nested AD group memberships as claims.

Configure

Configure Directory Connector in the environment settings in the FoxIDs Control Client.

  1. Select the Settings tab.
  2. Select the Environment tab.
  3. Find the Directory Connector section.
  4. Enable Directory Connector.
  5. Add the base API URL without the endpoint folder in API URL.
  6. Add the API secret.
  7. Decide whether to save a local password copy.
  8. Configure the environment password policy to match the external directory password policy.
  9. Click Update.

Directory Connector settings