Using Active Directory GUID with Ecto UUID field

Questions / Help
,
1

I’m attempting to integrate some AD stuff with my app, but I’m stuck on how to use the GUID that is returned with Ecto.

From exldap, I get this back:

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

which is fine, except if I try and load it with Ecto I get the wrong UUID back:

[219, 12, 193, 79, 151, 81, 153, 75, 128, 88, 23, 96, 59, 10, 33, 175]
|> :binary.list_to_bin
|> Ecto.UUID.load

{:ok, "db0cc14f-9751-994b-8058-17603b0a21af"}

Expected: 4FC10CDB-5197-4B99-8058-17603B0A21AF
Actual: DB0CC14F-9751-994B-8058-17603B0A21AF

I’m sure there’ something obvious that I’m overlooking!

1 Like
2

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"}
5 Likes
3

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

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! :grin:

2 Likes
4

Awesome, I’m glad it’s helpful!

1 Like
5

So that has now lead me to this: (Thanks to this post on mixed endian binaries - http://www.petecorey.com/blog/2018/03/19/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"
4 Likes
6

Ah, very nice!

7

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…

8

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.

9

‘How’ would it check that?

10

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.)

11

So for completeness, this is the issue I raised: https://github.com/elixir-ecto/ecto/issues/2660

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 :slight_smile:

1 Like
12

FYI, it’s not at all clear from what I’ve read that GUID’s are always little-endian–it may depend on the source.

13

Well … that makes sense, why would there be any consistency?! :wink:

In this instance I think it will be ok to assume the format, and create a type for for it - as it will only be used for AD integration - but if you are reading that it is not a ‘standard’ then that obviously muddies the water for wider use

1 Like