Bug #55
AD password encoding doesn't support non-ASCII characters
| Status: | New | Start: | 01/06/2009 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | Core | |||
| Target version: | 1.2.x branch | |||
| Problem in version: |
Description
Thomas found that if a password contains special characters (like "é", "à", etc.), LSC says that password modification succeed, we cannot authenticate with this new password. In fact, the old one is still valid :/
It may be a wrong charset used to encode the password. Default charset on Windows systems is CP1252.
History
Updated by Anonymous about 1 year ago
Looks like the character encoding could be solved: "Windows uses little-endian UCS-2 as the character set" from http://www.eyrie.org/~eagle/journal/2007-07/010.html
Updated by Jonathan Clarke about 1 year ago
As stated there, this may well be related to issue #57 - we don't handle binary attributes well, we just make them into Strings, which is OK for userPassword, etc, but not when we really need the binary value!
Updated by Jonathan Clarke 9 months ago
- Target version changed from 1.1.1 to 1.1.x branch
There has been no activity on this, and 1.1.1 is going to be released. Retargeting for later in 1.1 branch.
Can someone who has access to an AD server confirm this is still broken?
Updated by Jonathan Clarke 5 months ago
- Priority changed from Normal to Low
- Target version changed from 1.1.x branch to 1.2.x branch
This won't be implented in the 1.1 branch now, since all development focus is on 1.2 and future versions.
Retargeting for 1.2.x.