# Settings

## About

The **User Federation Settings** page in Keycloak allows administrators to **configure how Keycloak connects to an external identity source**, such as LDAP or Active Directory. These settings determine how users are queried, authenticated, synchronized, and represented within Keycloak.

Each federation provider added to a realm has its own set of configuration options grouped by purpose - **connection settings, synchronization settings, edit mode, mappers, and advanced options**.

<figure><img src="https://3632859567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPd6ktrA5pPLsZJktj2fm%2Fuploads%2FlUr06ES2jWbbPsUvNh3s%2Fkeycloak-user-federation-settings-1.png?alt=media&#x26;token=587aa030-cc88-4402-bb4f-6a19e8739105" alt=""><figcaption></figcaption></figure>

## Providers

In Keycloak, **Federation Providers** are external identity systems that Keycloak can connect to in order to **authenticate users and fetch user data**. This allows Keycloak to delegate user storage and validation to systems like **LDAP**, **Active Directory**, or **Kerberos**, instead of managing users solely within its internal database.

<figure><img src="https://3632859567-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPd6ktrA5pPLsZJktj2fm%2Fuploads%2FNmaH8mQV0TdCxetnAByZ%2Fkeycloak-user-federation-settings-2.png?alt=media&#x26;token=11789a88-67ad-4880-8881-1af50deb8d40" alt=""><figcaption></figcaption></figure>

### Available Providers in Keycloak

#### 1. **LDAP Provider**

The **LDAP provider** is the most commonly used User Federation provider. It allows Keycloak to connect to any LDAPv3-compatible directory, including:

* OpenLDAP
* 389 Directory Server
* Microsoft Active Directory (in LDAP-compatible mode)
* Apache Directory Server

**Key Capabilities:**

* Read users from LDAP
* Sync user attributes (name, email, department, etc.)
* Authenticate against LDAP credentials
* Map LDAP groups to Keycloak groups
* Optional write-back to LDAP (if enabled)

**Use Cases:**

* Internal SSO for enterprise apps
* Reusing corporate LDAP as source of truth
* Hybrid identity setups (e.g., Keycloak + LDAP + OIDC)

#### 2. **Kerberos Provider**

The **Kerberos provider** integrates Keycloak with a Kerberos-based authentication infrastructure, commonly used in environments like:

* Microsoft Active Directory (Kerberos protocol layer)
* MIT Kerberos
* Heimdal Kerberos

**Key Capabilities:**

* Support for **SPNEGO (Smart SSO) / GSSAPI** — allows **browser-based SSO** using Windows credentials
* Authenticate users using their **Kerberos tickets** without needing to type credentials manually
* Works well in domain-joined enterprise networks

**Use Cases:**

* Seamless SSO in **Windows-based environments** (e.g., auto-login with Active Directory credentials)
* High-security enterprise environments where **Kerberos is mandated**
* Legacy systems using Kerberos tickets for access control

**Notes:**

* Requires domain-joined machines and correct DNS setup.
* Keycloak must have a valid service account with Kerberos credentials.
* Not used for user storage — only for **authentication**.
* Often used alongside LDAP for full user resolution.

### General Notes on Federation Providers

* **Ordering Matters**: If multiple providers are configured, Keycloak queries them in the order they appear.
* **Search Behavior**: During login or sync, Keycloak will check each provider for the username match.
* **Provider Visibility**: You can enable or disable a provider without deleting it.
* **Provider Type & SPI**: All providers implement Keycloak’s **User Storage SPI**.

### Typical Architecture with Providers

A realm may include:

* **LDAP provider** → To source user attributes and credentials
* **Kerberos provider** → To authenticate users silently (via tickets)
* **Local users** → For service accounts, admins, or fallback login

Each user is associated with a specific storage provider internally using a **federation link**.