Closed cnotin closed 1 year ago
Thanks for reporting, I'll look into this. Or, you can submit a PR if you already have a plan how it should be implemented ๐
Here's a visual example if that helps ๐
Bytes="c6 b5 61 b3 f6 0a 29 a8 47 89 5c 48 17 79 3c fd f1"
-> GUID="b361b5c6-29f6-47a8-895c-4817793cfdf1"
And indeed it's the user's object ID (which here is myself who AAD registered the device)
I'll try a PR soon
Here we go with the PR: https://github.com/Gerenios/AADInternals/pull/57 I haven't tested it yet but please let me know if you like it before I do ;)
I'm referring to this code about the
1.2.840.113556.1.5.284.3
OID: https://github.com/Gerenios/AADInternals/blob/1561dc64568aa7c1a411e85d75ae2309c51d0633/Device_utils.ps1#L122-L123The code describes it as "ObjectId", same as in your article (very good one btw! thanks for sharing ๐): https://aadinternals.com/post/deviceidentity/#device-certificate-dkpub-dkpriv
When reading this, I understood it as meaning the device's Object ID. It felt redundant considering we already have the Device ID with
1.2.840.113556.1.5.284.2
, but I ignored this feeling... Anyway, I couldn't find the corresponding device in my AAD...Then I found https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dvrj/850786b9-2525-4047-a5ff-8c3093b46b88 and https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dvre/76747b5c-06c2-4c73-9207-8ebb6ee891ea which describe
1.2.840.113556.1.5.284.3
as:And indeed, when looking for this "ObjectId" in my AAD, I confirm it refers to the Object ID of the user who registered the device, not the device's Object ID ๐
So I suggest to rename it to "AuthUserObjectId" for example, to make it more explicit which object it refers to. What do you think? I wanted to report it as an issue before submitting a PR because I see several other references in the code to fix, so I would have several tests to do after renaming to ensure there's no regression.