🪲 Get-EntraUser -Filter Needs Escaping To Work Properly (at least for the onPremisesImmutableId attribute)

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.Entra or Microsoft.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:

1. Run Get-EntraUser -Filter "onPremisesImmutableId eq '$($ImmutableId)'"` on an ImmutableID from AD
2. 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

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

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

Start by reproducing the issue with Get-EntraUser -Filter using an onPremisesImmutableId containing + or =, then inspect how filter values are passed to the Graph API. Compare the behavior with issue 1477 and the referenced Graph module pull request 2361. Done means special characters work reliably, with coverage for the affected filter path and related values.