The provider tries to delete computed attributes.

[dihedron]

Context

Attributes are opaque entities as far as the Terraform DAG generator is concerned: they are treated as a set of untyped key/value pairs.

Typed attributes (those that are declared as parte of the configuration schema by the plugin itself) can specify if they are computed, in which case the DAG generation engine knows that those attributes should be not be touched by the plan; they may only need to be read back from the server after every change to the object they refer to, but no direct change action should be performed.

LDAP object attributes are a variable set and cannot therefore be specified in the schema: every kind of object has its own specific set of attributes. Moreover LDAP fully supports schema extension, so additional attributes could be added at any time and a strongly typed HCL schema wouldn't be able to support them. The LDAP plugin has to have a flexible mechanism to specify attributes besides dn and class, which are common to all objects.

The problem is that if a .tf does not explicitly specify a computed attribute, Terraform will diff the current state (containing the computed attribute as read back from the server after creation) and the desired state (which does not contain that same attribute) and will interpret the difference as a request to delete the computed attribute.

This is unfortunate, especially when the computed attribute is required.

How to reproduce

Simply run the test case under the tests/ directory, then change an attribute in the .tf file and run terraform apply again: the request will fail because the provider attempts to delete the ou=users attribute of the newly created OU, which is mandatory (being the RDN).

Note

This bug surfaced after merging the pull request about not ignoring the RDN attribute, because RDN is a computed attribute that is also strictly required.

[dihedron]

By reverting pull request #2 I fixed this problem for RDNs. But the problem will still be there when one attempts to work with Active Directory and its internal attributes (cnTSecurityDescriptor, SID etc.). A more general solution must be provided.