-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
LdapConnection does not handle passwords containing UTF-8 characters on Linux #82601
Comments
It does seem very similar, except that in the one that was closed it was never confirmed if ProtocolVersion was set to 3.0 or not, and on this one it does seem like the right version is set. It is interesting that @t00 mentions that this worked fine on 5.0 and has regressed since then, I wouldn't expect that since IIRC we didn't fully support sasl_bind in 5.0, but I may be misremembering. @t00 can you confirm which versions of the S.DS.Protocols package work for you and which ones don't? |
Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014 Issue DetailsDescriptionWhen using LdapConnection with a password containing point symbol (£) on Linux, the server consistently responds with Invalid Credentials error code. When browsing the code, SessionOptions.ProtocolVersion does not seem to affect the way password is marshalled to ldap_sasl_bind function, LdapPal.StringToPtr function is always used (StringToHGlobalAnsi, StringToAnsiString) meaning the pound character will be converted to ANSI codepage or dropped. This issue leaves out a lot of users using non-latin characters without access to LDAP authentication through dotnet, running on Linux. Reproduction Steps
Expected behaviorIf ProtocolVersion is set to 3, marshalling should be done using UTF8, as described on https://www.ibm.com/docs/en/zos/2.1.0?topic=routines-ldap-sasl-bind-ldap-sasl-bind-s as well as parameter LDAP_OPT_UTF8_IO should be set. Actual behaviorInvalid Credentials response is returned. Regression?Functionality work on my automated tests in dotnet 5, not sure what have changed internally in dotnet. Known WorkaroundsDo not use special characters in a password? Configurationdotnet 6 LTS, latest Manjaro Other informationadd label: area-System.DirectoryServices
|
I cannot check version 2 on dotnet 5, but on dotnet 6 version 3 does not work on Linux with the same AD but works on Windows just fine. |
That would be great, thanks so much for checking. As an FYI, for this particular library (and for this particular APIs that you are calling) we have different implementations for Windows and Linux, so what would work best to get the information that we need is if we can have a repro in the same OS (so in this case Linux) and perhaps even against the same AD and same credentials. Essentially, if we can get that info, as well as which version of a NuGet package you are using when it breaks and which version you are using when it works would get us most of what we need. 😄 |
I prepared a test project which have shown that dotnet 5, 6 and 7 behave the same way which contradicts what I had mentioned before - sorry for confusion. It might have been working fine with some other libraries on the system but it would be impossible to reproduce again so please assume dotnet 5 did not work with unicode as well. What indeed continuously does not work is unicode password on both AD and ApacheDS I am using for tests. Also interestingly ApacheDS refuses working with ProtocolVersion 2 while AD works if the credentials are not unicode. Here is test code which I ran:
Below are results on Linux:
And here are same test results on Windows:
Clearly unicode tests are passing on Windows and only ProtocolVersion 2 expectedly fails on a few occassions. |
Sorry forgot to mention, using DirectoryServices.Protocols version 6.0.1. After upgrading to the latest 7.0.0 it seems dotnet 5 is not supported anymore but the remaining tests on Linux fail on exactly same tests:
|
@joperezr Do you have any updates on how the issue is progressing on your end? |
Hello, I have a similar problem but on WINDOWS. I'm not sure if it is linked to this problem. I can open a new issue for this if needed. We are using DirectoryServices.Protocols version 7.0.0. |
@joperezr Will this issue be fixed in upcoming .NET 8? It might be a niche use case to use LdapConnection in dotnet on Linux, but still this is a serious bug in an integral part of the released framework :( |
Thanks for the ping. Unfortunately we didn’t get a a chance to fix this issue during .NET 8 release. @dotnet/area-system-directoryservices is this something that we think we can get to for .NET 9? Alternatively, @t00 it would be awesome if you happen to be interested in helping us and contributing a PR with a fix 😃 |
Not sure if we can handle it in .NET 9, most likely will rely on community contribution. |
Seems to be already fixed by #76127 |
Description
When using LdapConnection with a password containing point symbol (£) on Linux, the server consistently responds with Invalid Credentials error code.
When browsing the code, SessionOptions.ProtocolVersion does not seem to affect the way password is marshalled to ldap_sasl_bind function, LdapPal.StringToPtr function is always used (StringToHGlobalAnsi, StringToAnsiString) meaning the pound character will be converted to ANSI codepage or dropped.
This issue leaves out a lot of users using non-latin characters without access to LDAP authentication through dotnet, running on Linux.
Reproduction Steps
Expected behavior
If ProtocolVersion is set to 3, marshalling should be done using UTF8, as described on https://www.ibm.com/docs/en/zos/2.1.0?topic=routines-ldap-sasl-bind-ldap-sasl-bind-s as well as parameter LDAP_OPT_UTF8_IO should be set.
Actual behavior
Invalid Credentials response is returned.
Regression?
Functionality work on my automated tests in dotnet 5, not sure what have changed internally in dotnet.
Known Workarounds
Do not use special characters in a password?
Configuration
dotnet 6 LTS, latest Manjaro
Other information
add label: area-System.DirectoryServices
The text was updated successfully, but these errors were encountered: