Support session-based auth for policy objects

[benzander]

Describe the bug

Hi folks, I'm not able to get the session based authentification working.

"remote_auth = false" works without any problem, but remote_auth = true fails once I try a terraform plan

terraform plan ╷ │ Error: Failed to read TransportZones: The credentials were incorrect or the account specified has been locked. (code 403) │ │ with data.nsxt_policy_transport_zone.tzO-default, │ on 010_transportzones.tf line 6, in data "nsxt_policy_transport_zone" "tzO-default": │ 6: data "nsxt_policy_transport_zone" "tzO-default" { │

The NSX-T Manager logs a successfull authentification

nsx-manager> get log-file syslog follow | find admin 2022-05-13T10:40:44.643Z nsx-manager NSX 18019 SYSTEM [nsx@6876 audit="true" comp="nsx-manager" level="INFO" subcomp="http"] UserName="admin@.243.9", ModuleName="ACCESS_CONTROL", Operation="LOGIN", Operation status="success" 2022-05-13T10:40:45.494Z nsx-manager NSX 1905 - [nsx@6876 comp="nsx-manager" subcomp="node-mgmt" username="admin" level="INFO" audit="true"] admin 'GET /api/v1/node' 200 718 "" "terraform-provider-nsxt" 0.829900 ^C Fri May 13 2022 CEST 12:40:48.124 nsx-manager>

Looks like the provider is able to recieve a session token via https://>/api/session/create but it is not setting the X-XSRF-TOKEN header correctly

Reproduction steps

1. try basic authentification with remote_auth = false
2. try terraform plan to make sure your user & pw is ok etc.
3. switch to remote_auth = true
4. try a terraform plan again

Here my versions:
TF: v1.1.9
NSX-T Provider: v3.2.7
NSX-T Manager: 3.2.0.1.0.19232400

Expected behavior

I'm expecting the TF provider to work the same way with remote_auth = false and remote_auth = true

Additional context

Provider Config:

terraform { required_version = ">= 1.1.4" required_providers { nsxt = { source = "vmware/nsxt" version = "3.2.7" } }

provider "nsxt" { host = "nsx-t-manager..de" allow_unverified_ssl = true max_retries = 10 retry_min_delay = 500 retry_max_delay = 5000 remote_auth = true }

Username & PW set via environment variables: export NSXT_USERNAME="admin" export NSXT_PASSWORD="VMware1-VMware1-"

[alagoutte]

hi @benzander

What the source authentication on your NSX Manager ? VIDM or LDAP ?

Because there is some change with last release (not longer need to set remote...)

[benzander]

Hi @alagoutte it's LDAP (Active Directory over LDAP). But the behaviour is different if I try to use a domain user.

When I try to use the local admin the nsx manager logs a successful authentication as described above . When I use a domain user Terraform says: terraform plan ╷ │ Error: Failed to retrieve NSX version (403 ). Please check connectivity and authentication settings of the provider │ │ with provider["registry.terraform.io/vmware/nsxt"], │ on 000_init.tf line 21, in provider "nsxt": │ 21: provider "nsxt" {

The nsx manager logs: 2022-05-13T13:36:52.013Z gtahtbvu10291 NSX 18019 SYSTEM [nsx@6876 audit="true" comp="nsx-manager" level="INFO" subcomp="http"] UserName="@.de@.243.9", ModuleName="ACCESS_CONTROL", Operation="LOGIN", Operation status="failure"

The user and pw is correct. I just need to remove remote_auth and it works. But basic auth together with LDAP makes it terrible slow as the nsx-manger does an LDAP authentication for each and every API call.

[annakhm]

Hi @benzander, remote_auth is a vidm-specific setting that I believe is no longer required for NSX > 3.2. Its purpose it to set "Remote: " header. Is that the behavior you're expecting? I'm not aware of any use for remote_auth outside of vidm. Unfortunately, for policy resources we don't support session management (no SDK support for this) and indeed auth would slow things down. This support is on the roadmap.

[benzander]

Hello @annakhm, I thought vidm was just an example. But if remote_auth is vidm specific that would explain why its not working with LDAP backed authentication.

My expectation was that the TF provider sets the X-XSRF-TOKEN header instead of doing basic authentication.

[annakhm]

If you don't mind I'll change the topic of this issue to reflect the fact that session-based auth is not yet supported for policy resources. We're waiting for SDK support to make this happen.

[benzander]

Absolutely ok for me. Thanks. :-)