Signed-off-by: Brendan Thompson <[email protected]>

Signed-off-by: Brendan Thompson <[email protected]>

Signed-off-by: Brendan Thompson <[email protected]>

Signed-off-by: Brendan Thompson <[email protected]>

…stroy

Co-authored-by: KenSpur <[email protected]>

…ashicorp#1315

…e-insensitive

…en a user update fails

…ontrols` block

- Make `sign_in_frequency_authentication_type` and
  `sign_in_frequency_internal` both Optional + Computed and remove their
  default values.
- Handle the setting of these default values in the
  `expandConditionalAccessSessionControls()` function.
- Expand test coverage to all reasonable permutatons of the properties
  in this block to ensure no trailing diff or incorrect setting of
  values in the request.

…lease to v4.0.1

… for `azuread_group`

…ssignment_policy`

…`app_role`, `oauth2_permission_scope`, `identifier_uris`, `optional_claims`, and `required_resource_access`

…_application_registration

…om template

The `/instantiate` operation can return a 404 whlst also processing the
request completely normally. This leads to orphaned objects in the
directory, and a resource that cannot successfully Create.

Work around this by polling for the application and service principal
that you'd expect to see created out-of-band, whenever a 404 is
received. Also set a temporary `displayName` for the application, as
this is the only means we have to identify the resulting object is the
one we are looking for.

Unfortunately this means that this workaround cannot be implemented for
the `azuread_application_from_template` resource, since that resource
intentionally avoids changing the implicitly created
`user_impersonation` scope - this will get created with nonsensical
display names / descriptions in the consent flow. Since the whole point
of the standalone resource is to inherit scopes from the template, this
makes it infeasible to add this workaround there.

…ner/hamilton` - depends on manicminer/hamilton#285