keycloak_ldap_user_federation with master realm is not working

[spidersouleater]

It's not possible to create a LDAP user federation provider within the Realm "master", anymore.

The problem occurs with the Image "quay.io/keycloak/keycloak:18.0.0-legacy". I'm using the Version 3.8.1 of the terraform-provider-keycloak.

Minimal example to reproduce the Problem:

data "keycloak_realm" "master" {
    realm = "master"
}

resource "keycloak_ldap_user_federation" "ldap_user_federation" {
  name     = "openldap"
  realm_id = data.keycloak_realm.master.id
  enabled  = true

  username_ldap_attribute = "cn"
  rdn_ldap_attribute      = "cn"
  uuid_ldap_attribute     = "entryDN"
  user_object_classes     = [
    "simpleSecurityObject",
    "organizationalRole"
  ]
  connection_url          = "ldap://openldap"
  users_dn                = "dc=example,dc=org"
  bind_dn                 = "cn=admin,dc=example,dc=org"
  bind_credential         = "admin"

  connection_timeout = "5s"
  read_timeout       = "10s"

  kerberos {
    kerberos_realm   = "FOO.LOCAL"
    server_principal = "HTTP/host.foo.com@FOO.LOCAL"
    key_tab          = "/etc/host.keytab"
  }
}

[wann-ap]

+1

[mrparkers]

Hi @spidersouleater, sorry that you're having this issue. I tried the example configuration you provided, and I wasn't able to reproduce the problem. Could you give me some more information so I could investigate this further? Specifically, if you could provide an error message, or provide the output logs after running terraform with the TF_LOG=DEBUG environment variable, that would be very helpful. If you post these logs, make sure to redact them, as they can sometimes contain sensitive information.

[EvgeniyBlinov]

+1
@spidersouleater Did you found any workaround solution?

[spidersouleater]

Hi mrparkers, thanks for your help.

When executing the example configuration no error message seems to appear and everything has been configured correctly. But when you take look in the Keycloak Admin Console you can see that "LDAP user federation provide" has not been created.

keycloak-18.0.2-legacy

• terraform-provider-keycloak 3.9.0

The problem still exists in the recent versions. You can see in the Keycloak Admin Console the missing provider after the Terrafrom execution.

Here are the logs:

• terraform-18.0.2-legacy.log
• keycloak-18.0.2-legacy.log
• cmd.txt

keycloak-17.0.1-legacy

• terraform-provider-keycloak 3.9.0

This seems to be the last Version where everything is fine. You can see in the Keycloak Admin Console the created Provider after Terraform install.

Here are the logs:

• terraform-17.0.1-legacy.log
• keycloak-17.0.1-legacy.log
• cmd.txt

I could find out that Keycloak-18-legacy use a UUID for the Master-Realm and not anymore the String representation "master". That could maybe cause the problems we have.

[kelimutu]

+1

[spidersouleater]

I spent little time with the logs and the Keycloak Api. I could find out that the "parentId" of the following request body to the Endpoint "Component - POST - /{realm}/components" cause our problems.

{
    "name": "openldap",
    "providerId": "ldap",
    "providerType": "org.keycloak.storage.UserStorageProvider",
    "parentId": "master",
    "config": {
        "allowKerberosAuthentication": [
            "true"
        ],
        "authType": [
            "simple"
        ],
        "batchSizeForSync": [
            "1000"
        ],
        "bindCredential": [
            "admin"
        ],
        "bindDn": [
            "cn=admin,dc=example,dc=org"
        ],
        "cachePolicy": [
            ""
        ],
        "changedSyncPeriod": [
            "-1"
        ],
        "connectionTimeout": [
            "5000"
        ],
        "connectionUrl": [
            "ldap://openldap"
        ],
        "editMode": [
            "READ_ONLY"
        ],
        "enabled": [
            "true"
        ],
        "evictionDay": [],
        "evictionHour": [],
        "evictionMinute": [],
        "fullSyncPeriod": [
            "-1"
        ],
        "importEnabled": [
            "true"
        ],
        "kerberosRealm": [
            "FOO.LOCAL"
        ],
        "keyTab": [
            "/etc/host.keytab"
        ],
        "maxLifespan": [],
        "pagination": [
            "true"
        ],
        "priority": [
            "0"
        ],
        "rdnLDAPAttribute": [
            "cn"
        ],
        "readTimeout": [
            "10000"
        ],
        "searchScope": [
            "1"
        ],
        "serverPrincipal": [
            "HTTP/host.foo.com@FOO.LOCAL"
        ],
        "startTls": [
            "false"
        ],
        "syncRegistrations": [
            "false"
        ],
        "trustEmail": [
            "false"
        ],
        "useKerberosForPasswordAuthentication": [
            "false"
        ],
        "usePasswordModifyExtendedOp": [
            "false"
        ],
        "useTruststoreSpi": [
            "ldapsOnly"
        ],
        "userObjectClasses": [
            "simpleSecurityObject, organizationalRole"
        ],
        "usernameLDAPAttribute": [
            "cn"
        ],
        "usersDn": [
            "dc=example,dc=org"
        ],
        "uuidLDAPAttribute": [
            "entryDN"
        ],
        "validatePasswordPolicy": [
            "false"
        ],
        "vendor": [
            "other"
        ]
    }

If we set the UUID for the Master Realm or remove the optional field "parentId" than the Keycloak Api creates the "User Federation" again. I hope the information can help to solve the problem faster.

[mrparkers]

Sorry for taking so long on this. The root problem here is that Keycloak 18 changed the internal ID of the default master realm - it used to be master, but now it's a random GUID. So the provider was making assumptions about the internal ID of this realm, which was causing this issue.

I've opened #707 to fix this.

[mrparkers]

This is fixed in v3.9.1

[spidersouleater]

Hi mrparkes,

i have tested the bugfix version and everything seems fine, now.

Thank you for your help.

[mrparkers]

Of course, thank you for your help with the debugging effort! It saved me a lot of time since I didn't have to do much research to fix this.