-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GSSAPI appears to fail with fqdn #84
Comments
As you surmised, it's probably environment-specific. Running klist should tell you the SPN of the domain controller in the ticket cache (ldap/dc.fq.dn); if the FQDN part is identical to what you get back from the SRV query, I can't explain it. Anyhow, a GSSAPI bind never failed for me in that way, neither on Linux nor on Windows.
Hostnames in TLS certificates don't have the final dot, so a straight comparison will fail. Whether that dot should be accomodated is debatable. |
Is it possible to request that info via ldap?
Is it possible to discover what it would need via the api? or would it just need to be trial and error?
Yep: https://datatracker.ietf.org/doc/html/rfc3546#section-3.1 Would be nice if the error message somehow indicated what was being searched for vs what was found, as I literally had to guess that was the problem as I wasn't aware that the resolver crate returned the trailing dot. I'll submit a bug report to them and see if they deem it worth doing anything about. One thing I'm really big on is offering as much as can be given about why something failed in my user facing code, though I don't force that philosophy on anybody else, merely suggesting it. Rustc itself is such an excellent example of error messages done right. |
No, it's pure Kerberos.
It shouldn't be trial and error, the FQDN ought to work. I'm not sure about cross-domain trusts and their interaction with Kerberos and DNS, but that's a very advanced topic and probably not the issue here. |
Closing for lack of feedback and inability to reproduce. |
Oh sorry didn't have time to do additional tests and I just left that employer, so I'm not able to do so anymore. |
It seems the gssapi bit is failing if I pass the fqdn of the server I connected to:
Reason: GSSAPI operation error: ClientCtx::step failed The specified target is unknown or unreachable ', src\ad.rs:33:41
Could just be an environment specific thing? Or maybe just an active directory thing? Here's the code that actually works for me:
Also FWIW, native-tls fails without truncating that root dot (i.e. 'www.example.com.' needs to be 'www.example.com') Not sure whether the native-tls maintainers would consider that a feature or a bug.
The text was updated successfully, but these errors were encountered: