-
Notifications
You must be signed in to change notification settings - Fork 19
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
Explicitly adding channel bindings on the client #240
Comments
Hi! PRs are absolutely welcomed, and encouraged!! About the suggested change, however, my guess is that it was not intended for the Line 275 in 55ae932
If we add a method to set the Since I’m not the most familiar with NTLM, I’ll cc other people: @TheBestTvarynka @RRRadicalEdward |
I believe that the quoted line is meant to be executed on the server when accepting the security context sent from the client. So, the channel bindings must have been already supplied by the client -- for which the current API lacks the method, hence my inquiry. But of course, let the other contributors chime in. |
For reference on channel bindings in the SSPI API just search "channel_bindings" in the FreeRDP source code: https://github.com/search?q=repo%3AFreeRDP%2FFreeRDP%20channel_bindings&type=code I had forgotten that detail, but it looks like the channel binding is passed through an SSPI input buffer of type SECBUFFER_CHANNEL_BINDINGS. However, I suppose you want a Rust API as well? |
I would like to have the rough equivalent of the |
In the current API I see no way to add channel bindings to an
Ntlm
context when authenticating a client. (Motivation: AD can be configured to refuse authentication from an LDAP client doing an NTLM bind over a TLS connection if the channel bindings AvP is not supplied.)Adding a method to
Ntlm
which sets thechannel_bindings
field to the suppliedChannelBindings
struct does the right thing protocol-wise, i.e., the channel bindings AvP is correctly calculated and added to the AUTHENTICATE message. Would a PR with this kind of addition be appropriate, or is there another preferred way to add this functionality to the library?The text was updated successfully, but these errors were encountered: