Bug 9529 - non-ascii characters in legacyExchangeDN
Summary: non-ascii characters in legacyExchangeDN
Status: NEW
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.0.0
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Reported: 2013-01-02 09:01 UTC by Bruno (dead mail address)
Modified: 2021-03-05 11:07 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Bruno (dead mail address) 2013-01-02 09:01:12 UTC

I've a problem to join samba4 (final version) to windows server 2003 R1.
I get the following error message:
db_handler_fold: unable to casefold string [/o=MAILSAMBA/ou=First
Administrative Group/cn=Recipients/cn=Ext_Fátima_Goncalves]
Failed to apply records: ../lib/ldb/ldb_tdb/ldb_index.c:1198: Failed to
re-index legacyExchangeDN in
CN=Ext_Fátima_Goncalves,OU=CENARIO-C,DC=cena-c,DC=pt- Failed to create
index key for atribute 'legacyExchangeDN': Unknown error: Operations error
Failed to commit objects:WERR_GENERAL_FAILURE
join failed -cleaning up
Comment 1 Andrew Bartlett 2013-01-02 10:40:11 UTC
Further details from the mailing list conversation:

This is very interesting.  What is happening is that we seem to be
unable to upper case the Ext_Fátima_Goncalves part of the DN.  It may be
that the string sent to us is not in fact UTF8 (perhaps it was created
in a national code page?), or something else prevents correct

Unlike other strings in Active Directory, this is not handled as a
string by our replication code, so it is not translated between UTF8 and
UTF16 by DRSUAPI.  Also, these posts indicate that this record is meant
to be ASCII (or less) only, probably as a kludge to avoid the issues of
asserting which code page this actually is.


The issue for us is that without knowing which character set this is in
(and it clearly not being UTF8), how can we obtain or what should be the
canonical form for index comparisons?  (We use upper case as the
canonical form). 

The result is probably much the same as what you see with Exchange
above, that these records don't actually work, just that we error out at
a different layer.