-
Notifications
You must be signed in to change notification settings - Fork 37
Description
Thanks for reporting the bug. Please ensure you've gone through the following checklist before opening an issue:
- Make sure you can reproduce this issue using the latest released version of
Microsoft.EntraorMicrosoft.Entra.Beta. - Please search the existing issues to see if there has been a similar issue filed.
Describe the bug
I was struggling to figure the best way to identify AD users in Entra without filtering for values that are prone to updates in either AD or Entra (like SamAccountName/mailNickname/UPN/mail/etc.
I've ran into this issue quite a few times and was never able to get it working right using some of the other possible attributes, in particular the onPremisesImmutableId.
Previously, I have created my query like below:
# Convert AD ObjectGUID to Entra onPremisesImmutableId
$ImmutableId = [System.Convert]::ToBase64String($ADUser.ObjectGUID.ToByteArray())
$EntraUserByImmutableId = Get-EntraUser -Filter "onPremisesImmutableId eq '$($ImmutableId)'"
When I tested for this, it actually worked at first! ...But then I tried it on myself and it suddenly wasn't able to find my account.
So I started running this on more users, eventually realizing that only certain users were failing to be found with most being successful. From there, I cross-referenced the failed values and realized that the common denominator amongst the un-findable users was the fact that they all had + and = in their onPremisesImmutableId property. Went and asked GPT as I have admittedly rarely used the actual Graph API or APIs in general and it recommended the following:
# Convert AD ObjectGUID to Entra onPremisesImmutableId
$ImmutableId = [System.Convert]::ToBase64String($ADUser.ObjectGUID.ToByteArray())
$encoded = [System.Uri]::EscapeDataString($ImmutableId)
$EntraUserByImmutableId = Get-EntraUser -Filter "onPremisesImmutableId eq '$($encoded)'"
And that fixed it, I was able to find the previously mentioned users which were not being returned by my original -Filter query!
To Reproduce
Steps to reproduce the behavior:
- Run Get-EntraUser -Filter "onPremisesImmutableId eq '$($ImmutableId)'"` on an ImmutableID from AD
- Make sure the ImmutableID contains + or = (and possibly other special characters?) or else the bug won't be found
Expected behavior
You should be able to find any user with ImmutableID regardless of what characters are in the value, having the script handle more of the obsecure encoding issues.
Debug Output
⚠ ATTENTION: Be sure to remove any sensitive information that may be in the logs.
Debug Output
DM me if you want the debug output, thanks.Module Version
1.0.12
Environment Data
PSVersion 5.1.26100.7019
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.26100.7019
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Screenshots
Fails to find some users (presumably due to special characters breaking the URL query):

Succeeds to find users (presumably due to encoding the characters so the URL query isn't broken):

Additional context
-
I believe that there was previous attempts to note this behavior for Get-EntraUser specifically in issue 1477 by @thatpowershellguy. Based purely on the fact that he was also in a hybrid environment, I'm presuming that hybrid identities are much more prone to having special characters in their values, just a guess though.
-
Additionally, I believe this was also noted as a bug in the Graph module as well in issue 2280 by @fug4zi. This was then handled by @timayabi2020 in pull 2361 for that module.
My biggest concern based on the second point is that it seems like this bug probably applies to any function that uses -Filter and has values which can contain special characters since certain attributes are more prone to unexpexpected special characters.