2

I'm having a similar problem as this unanswered question: https://stackoverflow.com/questions/15766589/objectguid-from-active-directory-returns-only-one-part-of-the-array

Reading the "objectGUID" property from Active Directory works fine in Windows, but on Mono I cannot make sense of the return value.

Using C# on Windows, .NET Framework 4, 64-bit architecture, the type comes back as System.Byte[] which is easily converted to Guid. This is the raw data that is returned:

00000000h: 52 09 11 26 50 D2 5F 40 B0 DC 0C A7 06 4C E8 27

However on Mono 3.2.5, Ubuntu 13.10, 64-bit architecture, the type comes back as System.String. This is the raw data that is returned:

00000000h: 52 09 11 26 50 EF BF BD 5F 40 EF BF BD EF BF BD
00000010h: 0C EF BF BD 06 4C EF BF BD 27

I'm seeing a pattern with the EF BF BD sequence...

Another way I was able to look at it was to display the actual byte sequence (converting each char to Int32 on mono) producing this telling output: (Windows on the left, Mono on the right)

Win  Mono
---- ----
82    82
9     9
17    17
38    38
80    80
210   65533
95    95
64    64
176   65533
220   65533
12    12
167   65533
6     6
76    76
232   65533
39    39

Notice how anytime the number is >=100-ish on the left, it is converted to 65533 on the right? Fact: byte.MaxValue is 255 Fact: The hexadecimal number 100 is equal to the decimal number 256 (1 higher than byte.MaxValue) Fact The decimal number 100 is equal to the hexadecimal number 64 Don't know if any of that is related...

I feel like the data is there, I just cannot figure out how to get at it. Or maybe this is simply a Mono bug and the data is and always will be totally corrupted.

Any thoughts?

Improve this question
5
  • 2
    Yes, ef bf bd is a "magic number", it is the utf-8 encoding for '�'. Or U+FFFD, the Unicode replacement character. It tends to pop up when bytes are converted to a string and the byte value does not match a Unicode codepoint. Why your program is trying to interpret a guid as though it was a utf-8 encoded string and produces a utf-8 result instead of utf-16 is utterly unguessable. Nothing to look at.
    – Hans Passant
    Commented Dec 12, 2013 at 21:11
  • Not sure how else I could interpret it. It's exactly how mono is returning it (as a string) as opposed to a byte[] like Microsoft .NET Framework
    – Chris Ray
    Commented Dec 12, 2013 at 21:59
  • 1
    Well, good thing you've got all the source and can completely debug and fix this :)
    – Hans Passant
    Commented Dec 12, 2013 at 22:34
  • I was hoping it wouldn't come to that :) Seems daunting to even get started debugging the mono runtime. Any advice?
    – Chris Ray
    Commented Dec 13, 2013 at 13:53
  • 2
    Hans, your comment caused me to begin digging through mono source, which led me to the fact that they are using Novell.Directory.Ldap underneath, which led me to find this github project: github.com/EventStore/csharp-ldap which was easy to build (build.bat) which allowed me to follow a simple provided sample to get the objectGUID as a Base64 encoded format, which is easily decoded to byte array and handed to Guid constructor, and voila my Guid in mono! Thanks for responding. Feel free to post an answer suggesting using Novell.Directory.Ldap directly and I'll accept it.
    – Chris Ray
    Commented Dec 13, 2013 at 15:04
Related questions
0
Missing "ADODB" assembly with Mono?
4
How should I access Active Directory from a C# application running on mono in Linux?
2
Active directory and LDAP libraries
Load 7 more related questions Show fewer related questions

0

Reset to default

Browse other questions tagged or ask your own question.