top of page

Migrating from LDAP User Federation to Keycloak as the Sole Identity Provider

Autorenbild: Cevin FreitagCevin Freitag

Aktualisiert: vor 10 Stunden

Introduction

Managing user identities in a complex infrastructure has always been a challenge. For years, we relied on LDAP as our central user federation mechanism. It served its purpose, allowing us to authenticate users across different applications, but as the demand for modern authentication methods grew, maintaining an LDAP-based setup became increasingly cumbersome. The administrative overhead was significant, and the need for a more flexible, scalable solution became apparent.


We made the decision to migrate from LDAP User Federation to Keycloak as our sole Identity Provider (IdP). This transition was not just a technical shift but a strategic one that would simplify authentication, modernise our infrastructure, and improve security. What initially seemed like a daunting task turned into an opportunity to enforce stronger security measures, including a complete rollout of two-factor authentication (2FA). In this post, we’ll walk you through the reasons for this migration, the steps we took, the challenges we faced, and the benefits we gained.


Why Move Away from LDAP?


Complexity and Maintenance Overhead

For years, LDAP had been the backbone of our identity management, but maintaining it came with its own set of challenges. Running an LDAP server infrastructure required specialised expertise, and any configuration changes had to be handled with care. Over time, we realised that maintaining LDAP was creating more work than necessary. It lacked native support for modern authentication protocols like OIDC and SAML, making integrations with newer applications cumbersome. 


Security Concerns

Security was another major factor that prompted our migration. Password management in LDAP was an ongoing challenge. Moreover, LDAP does not natively support multi-factor authentication (MFA), which had become a mandatory requirement for our security strategy. Relying solely on passwords in an era of increasing cyber threats was no longer an option.


It became clear that moving to a modern IAM solution like Keycloak would provide more robust security features out of the box.



The Benefits of Using Keycloak

With Keycloak, we saw an opportunity to modernise our authentication infrastructure significantly. Keycloak provides a centralised authentication platform that supports both OpenID Connect (OIDC) and SAML, making it easy to integrate with modern applications. It also offers built-in MFA, conditional authentication rules, and fine-grained access control, all of which helped us strengthen our security posture.


Another key advantage was the simplification of our infrastructure. By eliminating LDAP, we reduced the number of moving parts in our authentication system, making it easier to maintain and scale. Furthermore, Keycloak’s self-service capabilities empowered users to reset passwords and manage their authentication settings without IT intervention, improving the overall user experience.


How We Migrated 

Keycloak-Einstellungsbildschirm zeigt LDAP-Konfiguration. UI-Name "ldap", Anbieter "Other". Optionen wie "Benutzer entfernen" sichtbar.

1. The Federation Challenge

Our journey began with a critical realisation: we had been using Keycloak’s LDAP User Federation feature, which meant that our users’ credentials were still being verified against the LDAP directory. The moment we disabled LDAP, all federated users would loose their passwords within Keycloak. This presented a major challenge—how would users log in after we cut ties with LDAP?


Instead of treating this as a setback, we saw an opportunity to enforce better security measures. Since every user would need to reset their password anyway, we decided to introduce mandatory two-factor authentication (2FA) for all users. This decision ensured that as we migrated to Keycloak, we simultaneously improved our authentication security across the board.


2. Transitioning Applications to OIDC

With users successfully migrated, the next step was to transition our applications away from LDAP authentication. We started by identifying every system that relied on LDAP and assessed its compatibility with OIDC. Fortunately, all of our used applications supported OIDC authentication, making the transition relatively straightforward.


For each application, we configured Keycloak’s OIDC settings, updated the authentication endpoints, and provided documentation to application teams on how to integrate with the new system. During this phase, we kept LDAP running as a fallback, allowing us to test and troubleshoot issues before fully switching over.


3. Migrating User Data

Before completely decommissioning LDAP, we needed to migrate all users into Keycloak’s internal database. This can be done fairly easy. All that had to be done was to set the users to usynced and remove the link to the federation source.


4. Enforcing Password Resets and 2FA

Once the infrastructure was in place, we enforced a mandatory password reset for all users. As expected, this created some friction, but we supported users through the process with detailed guides and automated password reset workflows. At the same time, we introduced 2FA as a non-negotiable requirement, ensuring that all users enabled an additional layer of authentication.


This move was a resounding success—by the end of the migration, 100% of our users were enrolled in 2FA. What started as a challenge turned into one of the biggest security wins of our transition.


5. Decommissioning LDAP

After successfully migrating users and applications, we reached the final step: shutting down LDAP for good. With all authentication requests now handled by Keycloak, we decommissioned the servers, and celebrated a major milestone in our infrastructure modernisation.


While we had some groups mapped to groups in Keycloak that was not the case for all groups from LDAP. So we added a few more mappers to import the missing groups into our Keycloak to accomplish our goal.  


Screenshot einer Keycloak-Oberfläche, die LDAP-Mapper-Einstellungen zeigt. Links ist ein Menü. Oben sind Tabs: "Settings", "Mappers".

This of course depends on your setup. But you will want to make sure you are not missing any existing groups from LDAP. Otherwise you’ll run into problems, when connecting any not yet OIDC joined applications. So plan carefully. Eg. refactor or simplify your existing groups.


How did we trigger Email resets for all users? Simple bash scripting is your friend:


```bash
#!/bin/bash

# Configuration
KEYCLOAK_URL="https://keycloakURL/auth"
REALM="YourRealm"  # The realm where users exist
ADMIN_REALM="AdminRealm"  # Admin user is in the master realm
CLIENT_ID="admin-cli"
ADMIN_USER="AdminUser"
ADMIN_PASS="AdminPassword"
MAX_USERS=1000  # Adjust as needed

# Get admin token from the master realm
echo "[*] Retrieving admin token from '$ADMIN_REALM' realm..."
TOKEN=$(curl -s -X POST "$KEYCLOAK_URL/realms/$ADMIN_REALM/protocol/openid-connect/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=$CLIENT_ID" \
  -d "username=$ADMIN_USER" \
  -d "password=$ADMIN_PASS" \
  -d "grant_type=password" | jq -r .access_token)

if [[ -z "$TOKEN" || "$TOKEN" == "null" ]]; then
  echo "[!] Failed to get access token. Check credentials."
  exit 1
fi
echo "[+] Token retrieved successfully."

# Fetch all users from the target realm
echo "[*] Fetching all users from '$REALM' realm..."
USER_IDS=$(curl -s -X GET "$KEYCLOAK_URL/admin/realms/$REALM/users?max=$MAX_USERS" \
  -H "Authorization: Bearer $TOKEN" | jq -r '.[].id')

if [[ -z "$USER_IDS" ]]; then
  echo "[!] No users found in realm $REALM."
  exit 1
fi
echo "[+] Retrieved $(echo "$USER_IDS" | wc -l) users."

# Process each user
for USER_ID in $USER_IDS; do
  echo "[*] Removing existing 2FA for user $USER_ID..."

  # Get user's credentials (including TOTP)
  CREDENTIALS=$(curl -s -X GET "$KEYCLOAK_URL/admin/realms/$REALM/users/$USER_ID/credentials" \
    -H "Authorization: Bearer $TOKEN" | jq -r '.[] | select(.type == "otp") | .id')

  # Delete each 2FA credential
  for CRED_ID in $CREDENTIALS; do
    curl -s -X DELETE "$KEYCLOAK_URL/admin/realms/$REALM/users/$USER_ID/credentials/$CRED_ID" \
      -H "Authorization: Bearer $TOKEN" > /dev/null
    echo "[+] Removed existing 2FA for user $USER_ID."
  done

  # Assign required actions (password reset + 2FA)
  echo "[*] Enforcing password reset and 2FA for user $USER_ID..."
  curl -s -X PUT "$KEYCLOAK_URL/admin/realms/$REALM/users/$USER_ID" \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "requiredActions": ["UPDATE_PASSWORD", "CONFIGURE_TOTP"]
    }' > /dev/null

  # Trigger password reset email
  curl -s -X PUT "$KEYCLOAK_URL/admin/realms/$REALM/users/$USER_ID/execute-actions-email" \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '["UPDATE_PASSWORD"]' > /dev/null

  echo "[+] Password reset email sent and 2FA enforced for user $USER_ID."
done

echo "[✔] All users updated successfully!"
```

The Outcome

Looking back, the benefits of this migration were significant:

  • Simplified authentication stack: We now have a single system managing all authentication.

  • OIDC everywhere: Our entire ecosystem now uses a modern authentication protocol.

  • Eliminated legacy infrastructure: No more LDAP servers to maintain.

  • Better user experience: SSO, self-service capabilities, and streamlined authentication workflows.

  • Stronger security: Every user now has MFA enabled, reducing the risk of unauthorised access.

  • Lower costs: Reducing infrastructure complexity directly translated into lower operational overhead.


Lessons Learned

  • Plan thoroughly: Mapping dependencies before migration prevents unexpected surprises.

  • Take a phased approach: Gradual rollout and extensive testing minimise disruptions.

  • Communicate changes clearly: Users need to be informed and trained for a smooth transition.

  • Leverage challenges as opportunities: What seemed like a problem—losing passwords—became an opportunity to enforce 2FA.


Conclusion

Our migration from LDAP User Federation to Keycloak was more than just a technical upgrade—it was a transformation that improved security, simplified authentication, and modernised our infrastructure. The transition allowed us to implement 100% 2FA coverage, eliminate outdated systems, and provide a more seamless authentication experience for our users.


If you’re considering a similar migration, embrace the challenges as opportunities. With the right planning and execution, the benefits far outweigh the challenges. At open200, we specialize in helping organizations successfully navigate these transformations. Our expert consultants and developers can provide you with tailored guidance, ensuring a smooth transition to a modern authentication system, while keeping security, scalability, and user experience at the forefront.


Whether you’re ready to make the switch or simply exploring your options, we’re here to help you take the next step with confidence. Get in touch with us today to learn how we can assist with your migration to Keycloak and enhance your identity management systems.

14 Ansichten

Aktuelle Beiträge

Alle ansehen
bottom of page