Using Active Directory GUID with Ecto UUID field

This was a cool little problem!

First step, find the “correct” format of the expected UUID “4FC10CDB-5197-4B99-8058-17603B0A21AF”

iex(50)> Ecto.UUID.dump("4FC10CDB-5197-4B99-8058-17603B0A21AF")
{:ok, <<79, 193, 12, 219, 81, 151, 75, 153, 128, 88, 23, 96, 59, 10, 33, 175>>}

Hmmm, some of those numbers look similar. Let’s look at them side by side (aligned by comma):

[79,  193, 12,  219, 81,  151, 75,  153, 128, 88, 23, 96, 59, 10, 33, 175]
[219, 12,  193, 79,  151, 81,  153, 75,  128, 88, 23, 96, 59, 10, 33, 175]

In chunks:

[79,  193, 12,  219,  |  81,  151,   |  75,  153,  |  128, 88, 23, 96, 59, 10, 33, 175]
[219, 12,  193, 79,   |  151, 81,    |  153, 75,   |  128, 88, 23, 96, 59, 10, 33, 175]

So for some reason (someone else may understand the reason) the first 4 numbers are reversed, then the next two, and the next two again, but all the rest after that match (which is why “8058-17603B0A21AF” is decoded correctly).

So you can write a function to convert as follows:

defmodule Test do
  def convert(list) do
    {first4, rest} = Enum.split(list, 4)
    {second2, rest} = Enum.split(rest, 2)
    {third2, rest} = Enum.split(rest, 2)

    Enum.reverse(first4)
    |> Enum.concat(Enum.reverse(second2))
    |> Enum.concat(Enum.reverse(third2))
    |> Enum.concat(rest)
  end
end

Which can then be used for the desired output:

iex(55)> list = [219, 12, 193, 79, 151, 81, 153, 75, 128, 88, 23, 96, 59, 10, 33, 175]
[219, 12, 193, 79, 151, 81, 153, 75, 128, 88, 23, 96, 59, 10, 33, 175]
iex(56)> Test.convert(list) |> :binary.list_to_bin() |> Ecto.UUID.load()
{:ok, "4fc10cdb-5197-4b99-8058-17603b0a21af"}

Thank you!!
I spent so long looking at it, I couldn’t see that the first 3 parts were reversed!

Which with some googling leads to:

Variant bits aside, the two variants are the same except that when reduced to a binary form for storage or transmission, variant 1 UUIDs use “network” (big-endian) byte order, while variant 2 GUIDs use “native” (little-endian) byte order. In their textual representations, variants 1 and 2 are the same except for the variant bits.

When byte swapping is required to convert between the big-endian byte order of variant 1 and the little-endian byte order of variant 2, the fields above define the swapping. The first three fields are unsigned 32- and 16-bit integers and are subject to swapping, while the last two fields consist of uninterpreted bytes, not subject to swapping. This byte swapping applies even for version 3, 4, and 5 UUID’s where the canonical fields do not correspond to the content of the UUID

So I think that explains the ordering of the first 3 parts.

Thankyou again!

Awesome, I’m glad it’s helpful!

So that has now lead me to this: (Thanks to this post on mixed endian binaries - Pete Corey - Building Mixed Endian Binaries with Elixir)

iex(65)> << a::32, b::16, c::16, d::16, e::48 >> = [219, 12, 193, 79, 151, 81, 153, 75, 128, 88, 23, 96, 59, 10, 33, 175] |> :binary.list_to_bin
<<219, 12, 193, 79, 151, 81, 153, 75, 128, 88, 23, 96, 59, 10, 33, 175>>

iex(66)> << a::32-little, b::16-little, c::16-little, d::16-big, e::48-big >>
<<79, 193, 12, 219, 81, 151, 75, 153, 128, 88, 23, 96, 59, 10, 33, 175>>

iex(67)> << a::32-little, b::16-little, c::16-little, d::16-big, e::48-big >> |> Base.encode16
"4FC10CDB51974B99805817603B0A21AF"

And then a nice little function to swap:

def swap_endians(<< a::32, b::16, c::16, d::16, e::48 >>) do
  << a::32-little, b::16-little, c::16-little, d::16-big, e::48-big >>
end

[219, 12, 193, 79, 151, 81, 153, 75, 128, 88, 23, 96, 59, 10, 33, 175]
|> :binary.list_to_bin()
|> swap_endians()
|> Base.encode16()

"4FC10CDB2D51974B99805817603B0A21AF"

Ah, very nice!

And all this means that somewhere, they’re getting converted to/from integers by code which is not aware of the different byte-ordering between variants. My guess is Ecto, might be worth a bug report…

Yea, I was wondering if it was Exldap (which calls out to eldap) as that is where the list came from, or if it is Ecto as it is not making sure that the endians are correct.

I’ll have a play in a bit with some other UUID libs and see if I can come up with where the issue is

Edit:
Thinking about it, that is how it is stored in AD, so it’s not really anything to do with Exldap, so yea would seem more likely that Ecto is not checking endiness.

‘How’ would it check that?

I would hope there would be bits specifying the variant at a fixed location, octet-wise, and they would include that. But of course this is MS we’re talking about, so who knows. (A few minutes with google produced a lot of discussions but no real answer.)

So for completeness, this is the issue I raised: Endiness check for UUIDs · Issue #2660 · elixir-ecto/ecto · GitHub

Basic gist is that there is a difference between a UUID and a GUID (I always assumed they were the same) - that difference being the endiness, so it’s not really down to Ecto.

I’m just going to create a new type for it and use that instead - I’ll update this post with it when I get back around to looking at that app