please consider ignore case difference when apply

[fsdrw08]

currently there is different terraform plan result when the attribute case from tf resource different from the ldap server, e.g. when config attribute name objectclass, and run terraform plan, it will cause

resource "ldap_entry" "group_admins" {
      ~ data_json = jsonencode(
          ~ {
              - objectClass  = [
                  - "top",
                  - "groupofuniquenames",
                ]
              + objectclass  = [
                  + "top",
                  + "groupofuniquenames",
                ]
                # (2 unchanged attributes hidden)
            }
        )

for now, I had to make every attribute case match with the ldap server,e.g. objectclass -> objectClass.

[l-with]

@fsdrw08 Thank you for helping to improve the provider. From my point of view, you name two topics. Please make this into two issues for a clearer and more comprehensible approach to the topics.

[fsdrw08]

@fsdrw08 Thank you for helping to improve the provider. From my point of view, you name two topics. Please make this into two issues for a clearer and more comprehensible approach to the topics.

done, here is the new issue separate from this topic https://github.com/l-with/terraform-provider-ldap/issues/72

[l-with]

Please describe the terraform flow to produce this situation.

[fsdrw08]

I use opendj, you can run it via docker, here is a docker compose example, ref: OpenDJ Preparation

  opendj:
    image: openidentityplatform/opendj:latest
    hostname: opendj.example.com
    ports:
      - "1389:1389"
      - "1636:1636"
      - "4444:4444"
    volumes:
      - ./opendj/bootstrap/data/:/opt/opendj/bootstrap/data #initial data
      - ./persistence/opendj:/opt/opendj/data #opendj data
    environment:
      - BASE_DN=dc=openidentityplatform,dc=org #should be yours base DN

the ldif of initial data in my case

dn: ou=People,dc=openidentityplatform,dc=org
objectClass: organizationalunit
objectClass: top
ou: People

after docker-compose up, run the terraform to apply ldap entry
provider information:

# This file is maintained automatically by "terraform init".
# Manual edits may be lost in future updates.

provider "registry.terraform.io/l-with/ldap" {
  version     = "0.5.6"
  constraints = ">= 0.5.6"
  hashes = [
    "h1:cqTRL6dknCj0b6yLFX+4ZNFFMnuqbpJ0PcAaE6smQ0k=",
  ]
}

provider config:

provider "ldap" {
 ...

  bind_user     = "cn=Directory Manager"
  bind_password = "password"
}

terraform code

resource "ldap_entry" "user_admin" {
  dn = "uid=admin,ou=People,dc=openidentityplatform,dc=org"
  data_json = jsonencode({
    objectclass       = ["top", "inetOrgPerson", "organizationalPerson", "person"]
    userPassword      = ["{SSHA}9tYIWTF0A7+ipgncHEJJhRL9Vb/pydxL4A=="]
    cn                = ["admin"]
    sn                = ["admin"]
  })
}

after applied, re-apply or run terraform plan again, it shows

 # ldap_entry.user_admin will be updated in-place
  ~ resource "ldap_entry" "user_admin" {
      ~ data_json         = jsonencode(
          ~ {
              - objectClass  = [
                  - "top",
                  - "inetOrgPerson",
                  - "organizationalPerson",
                  - "person",
                ]
              + objectclass  = [
                  + "top",
                  + "inetOrgPerson",
                  + "organizationalPerson",
                  + "person",
                ]
                # (3 unchanged attributes hidden)
            }
        )
        id                = "uid=admin,ou=People,dc=openidentityplatform,dc=org"
        # (2 unchanged attributes hidden)
    }

[l-with]

Thank you for the detailed information. I can repoduce this. Refering to the discussion on this issue 129 for the go ldap library it seems to be possible that there are LDAP server implementations that allow to define schemes with case sensitive attribute names. Thus I would prefer to implement this optional, for instance with a possible exeception definition by an attribute "case_sensitive_attributes".

There are two import aspects:

1. It would be CPU intensive, since for ignoring the case there has to executed a loop over all attributes, which can be very many.
2. The implementation would be a little bit complex.

It's not such a big effort to name the attributes in the Terraform code according to the schema definition case sensitive, is'nt it?

[fsdrw08]

yes, I think it is not a big problem, but maybe we should add some note message in the provider document to remind the case sensitive issue

[l-with]

release 0.7.0 has two new features to solve this