Issue between Teleport and LDAP

[ionutcbn]

I am trying to use the Desktop Access feature of Teleport.
I am running Teleport from a container with self-signed certificates (these will be a local installation) and I have followed the tutorial procedure but at the end the log show
2022-10-21T08:26:18Z INFO [CA] Generating TLS certificate {0x9c65788 0xc00149e8b0 CN=svc-teleport 2022-10-21 16:26:18.139143769 +0000 UTC [] [{2.5.29.37 false [48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 130 55 20 2 2]} {2.5.29.17 false [48 49 160 47 6 10 43 6 1 4 1 130 55 20 2 3 160 33 12 31 115 118 99 45 116 101 108 101 112 111 114 116 64 99 101 114 116 115 105 103 110 100 101 109 111 46 108 111 99 97 108]}] 1 [ldap:///CN=T4MCluster,CN=Teleport,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=xdemo,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint]}. common_name:svc-teleport dns_names:[] locality:[] not_after:2022-10-21 16:26:18.139143769 +0000 UTC org:[] org_unit:[] tlsca/ca.go:874 2022-10-21T08:26:18Z ERRO [WINDOWS_D] initializing LDAP client, will retry error:[ ERROR REPORT: Original Error: *ldap.Error LDAP Result Code 1 "Operations Error": 000004DC: LdapErr: DSID-0C090A37, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563� Stack Trace: /go/src/github.com/gravitational/teleport/lib/srv/desktop/ldap.go:73 github.com/gravitational/teleport/lib/srv/desktop.(*ldapClient).readWithFilter /go/src/github.com/gravitational/teleport/lib/srv/desktop/ldap.go:87 github.com/gravitational/teleport/lib/srv/desktop.(*ldapClient).read /go/src/github.com/gravitational/teleport/lib/srv/desktop/windows_server.go:1124 github.com/gravitational/teleport/lib/srv/desktop.(*WindowsService).updateCAInNTAuthStore /go/src/github.com/gravitational/teleport/lib/srv/desktop/windows_server.go:1094 github.com/gravitational/teleport/lib/srv/desktop.(*WindowsService).updateCA /go/src/github.com/gravitational/teleport/lib/srv/desktop/windows_server.go:545 github.com/gravitational/teleport/lib/srv/desktop.(*WindowsService).initializeLDAP /go/src/github.com/gravitational/teleport/lib/srv/desktop/windows_server.go:369 github.com/gravitational/teleport/lib/srv/desktop.NewWindowsService /go/src/github.com/gravitational/teleport/lib/service/desktop.go:200 github.com/gravitational/teleport/lib/service.(*TeleportProcess).initWindowsDesktopServiceRegistered /go/src/github.com/gravitational/teleport/lib/service/desktop.go:53 github.com/gravitational/teleport/lib/service.(*TeleportProcess).initWindowsDesktopService.func1 /go/src/github.com/gravitational/teleport/lib/service/supervisor.go:539 github.com/gravitational/teleport/lib/service.(*LocalService).Serve /go/src/github.com/gravitational/teleport/lib/service/supervisor.go:276 github.com/gravitational/teleport/lib/service.(*LocalSupervisor).serve.func1 /opt/go/src/runtime/asm_amd64.s:1571 runtime.goexit User Message: updating NTAuth store over LDAP: fetching existing CAs: fetching LDAP object "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=xdemo,DC=local": LDAP Result Code 1 "Operations Error": 000004DC: LdapErr: DSID-0C090A37, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563�
I have tried everything:

1. Tried to see if the Teleport CA certificate is published accross the network (like the Troubleshooting suggests): IT IS
2. Imported both certificates (from Teleport and LDAP) as te tutorial suggests.
3. Put the LDAP certificate (PEM encoded) into the teleport.yaml file, instead of the path.
4. Tried insecure flag in teleport.yaml
5. Tried to debug with ldapsearch: secure interrogations with added password work, those without password do not work.

I am completely at a loss and do not know what to try.

[kamirendawkins]

I know this is older question, but I ran into this issue as well during a cluster rebuild. Our steps that landed us in this situation:

1. Have a Working Primary Cluster and AD connection.
2. Replace Primary Cluster with a full wipe of all data.
3. Regenerate the Teleport user-ca.pem for use on the AD Stack.
4. Remove the old Trusted CA and add the New CA.

Automation bit us during step 4 where the Teleport Service attempted to start so the Node cached somethings it seems. Enter #2838.

Based on this issue it would be safe to assume that the node is caching ad connection details and just needed us to purge that once we had fully removed the now invalid CA.

It would appear that if the service attempts a connection before the certs are primed across the network, which in this question they are now propagated, the client lands in a bad state and dumping /var/lib/teleport becomes necessary to get things back in working order.

I am sure someone from Gravitational could answer more to the technicals of why this occurs but this did at least unblock us.

[ionutcbn]

My issue was caused by a time delay between the DC and Teleport, which was causing the TLS handshake to fail.

[chaghu]

Thanks, I did that and now everything is fine

[drafboll]

Thanks a lot that was my problem too