However, I prefer to verify these kinds of changes, but I’m apparently missing something since I’m not able to see the values in PasswordProfile.
If I run Get-MgUser -UserId user01@test.com -ExpandProperty PasswordProfile, I get this error message:
get-mguser : Parsing OData Select and Expand failed: Property 'PasswordProfile' on type 'microsoft.graph.user' is not a navigation property or complex proper
ty. Only navigation properties can be expanded.
Status: 400 (BadRequest)
ErrorCode: BadRequest
On the other hand if I run Get-MgUser -UserId user01@test.com | Select -ExpandProperty PasswordProfile, I get the following:
Yeah I can’t figure it out either. I thought it was as simple as not including the -Property or -Select on the Get-MGUser call… but nothing worked. IMO this whole module is trash. Especially compared to AzureAD or MSonline. I’ll be waiting for someone else to come tell us the secret sauce on this. What a joke.
Unfortunately that just seems to make things even odder.
I’m on 2.19.0 and I’m seeing the same behavior on both PS 5.1 and PS 7.4.3. Same behavior on my work-tenant and my developer-tenant.
Though I’m getting a fancy green color for the properties on 7.4.3
Testing an upgrade to 2.20.0, but no change for me:
Just to add to this I can say that I was seeing similar behavior with the ‘Manager’ property.
It too contains a number of sub-properties and I didn’t see any of them at first, when doing Get-MgUser -UserId user01@test.com -Property Manager | Select-Object -ExpandProperty Manager. It just showed me this:
Id DeletedDateTime
-- ---------------
However if i run Get-MgUser -UserId user01@test.com -ExpandProperty Manager, I don’t get the ‘Parsing OData Select and Expand failed…’ error message i saw with the PasswordProfile-property, it just lists the DisplayName, Id, Mail and UserPrincipalName of the user in question. And if I pipe the above to Select-Object -ExpandProperty Manager. I actually get an ID matching the correct manager.
Id DeletedDateTime
-- ---------------
12345678-1234-1234-1234-1234567890123
I haven’t got much time right now, so I’ll be back with more info later. But no, I’m not getting anything with that on PS 7.4.3 / MSGraph 2.20.0 (Dev-tenant).
On PS 5.1 / MSGraph 2.19.0 (Work-tenant) I get this error:
I tried copying the entire command and just changing the UPN to a valid for either tenant.
I also tried with just to first part of the cmdlet and that just gave me this on both tenants and PS versions:
Name Value
---- -----
@odata.context https://graph.microsoft.com/v1.0/$metadata#users(passwordProfile)/$entity
passwordProfile
If that works, I’d try removing all versions of the Graph module and just installing just the latest one. I’ve had weird problems when multiple versions are installed side-by-side.
I’m using the same query as in Invoke-MgGraphRequest cmdlet used previously: https://graph.microsoft.com/v1.0/users/testuser01@xxxxx.onmicrosoft.com?$select=passwordProfile.
This all started in my work-tenant - which has most of the accounts synced from on-prem AD. However, we’d added a number of cloud-only accounts and those accounts should be excluded from the default forced password change. I’d thought I’d find it directly in Entra, but no such luck.
With a little digging I found the PS to change the setting, which seemed to work (at least it gave no error message). But when I went to verify the change I ran into this whole mess.
My Dev-tenant is entirely cloud-only, no on-prem connectivity at all.
Just to be entirely sure I reran the above on my Work-tenant (PS 5.1 / MGraph 2.19.0) on both my personal synced user and one of the new cloud only accounts and I’m still not seeing values on either the ‘ForceChangePasswordNextSignIn’ or ‘ForceChangePasswordNextSignInWithMfa’ property.
I have done some additional testing and as far I can tell when you set ForceChangePasswordNextSignIn to $false it doesn’t actually have the value $false. It’s either $true or $null.
All that work for a $null-value?
Don’t get me wrong @matt-bloomfield. Thank you! I really appreciate the work you put into this, but this is just infuriating!
All the accounts I’ve tested against previously have been existing accounts, but with your last comment I set up two entirely new accounts in my Dev-tenant. ‘mfatest’ was setup as a regular user with licensing and MFA set via CA-policies and group membership. ‘nomfatest’ was assigned a license directly and was excluded from MFA in the CA-policy.
If I update the ForceChangePasswordNextSignInWithMfa-property it actually sets a $false-value in the ForceChangePasswordNextSignIn-property instead of a $null!