{"id":5745,"date":"2021-08-16T17:52:03","date_gmt":"2021-08-16T16:52:03","guid":{"rendered":"https:\/\/rakhesh.com\/?p=5745"},"modified":"2021-08-16T17:52:03","modified_gmt":"2021-08-16T16:52:03","slug":"azure-ad-password-change-and-all-that","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/azure\/azure-ad-password-change-and-all-that\/","title":{"rendered":"Azure AD password change and all that"},"content":{"rendered":"

Here’s what I want to do:<\/p>\n

I am creating new accounts on-prem and setting a password. I want the new account user to change their password at first login. Due to the nature of our environment I would prefer they go to Azure AD to set their new password and also register for MFA (rather than RDP to a server for instance and be prompted to change password).<\/p>\n

Attempt 1: Graph API passwordProfile<\/h3>\n

This Graph API property<\/a> seems to be just what I want! I set a JSON object with the following properties and I can change passwords:<\/p>\n

{\r\n  \"forceChangePasswordNextSignIn\": true,\r\n  \"forceChangePasswordNextSignInWithMfa\": false,\r\n  \"password\": \"string\"\r\n}<\/pre>\n
In terms of permissions when using an Application Registration, the docs<\/a> say one needs the following:<\/p>\n
\"\"<\/p>\n
I wanted to use application permissions as this was going to run via a script, and found that granting the 3 permissions mentioned there did nothing. Then I found a StackOverflow post<\/a> where someone mentioned that adding the App Registration to the “Password Administrator” role does the trick. I tried that and it worked.<\/p>\n
Of course, when I say “it worked” I don’t mean it really worked. :) I did the following:<\/p>\n
$passwordProfile = @{\r\n    forceChangePasswordNextSignIn = $true\r\n    forceChangePasswordNextSignInWithMfa = $true\r\n    password = $Password\r\n}\r\n\r\nUpdate-MgUser -UserId ${UserName}${UserDomain} -PasswordProfile $passwordProfile<\/pre>\n
And Graph politely told me:<\/p>\n
\"\"<\/p>\n
Huh!<\/p>\n
I tried again, but this time without the two forceChangePassword<\/code> properties. That worked and I was able to login to Office.com with the password… but it’s a bummer as I was really interested in setting the forceChangePassword<\/code> properties.<\/p>\n
Also, very frustratingly this does not writeback the password to on-prem AD. I waited for about 30 mins but the on-prem password never changed. However, if I were to change the password in the cloud (for example at https:\/\/account.activedirectory.windowsazure.com\/ChangePassword.aspx<\/a>) then it does sync back to on-prem.<\/p>\n
Attempt 4: Same as above, but slightly different<\/h3>\n
I actually stumbled upon this later, hence the attempt 4. I realized that the following works:<\/p>\n
$passwordProfile = @{\r\n    forceChangePasswordNextSignIn = $true\r\n    password = $Password\r\n}\r\n\r\nUpdate-MgUser -UserId ${UserName}${UserDomain} -PasswordProfile $passwordProfile<\/pre>\n
Notice there’s no forceChangePasswordNextSignInWithMfa<\/code>. This too does not sync to on-prem AD, but it does force the user to change password upon first login to the cloud… and that of course syncs back to on-prem AD.<\/p>\n
In theory all I thus need to do is create a new account in on-prem AD, set a password, wait for it to sync to Azure AD and then run the cmdlet above and set the same password as on-prem AD… this way the user can login on-prem if needed, but the first time they hit the cloud (which they inevitably have to do sooner than later) they will have to change their password and it syncs back to on-prem. Just what I want!<\/p>\n
Attempt 2: Graph API resetPassword method<\/h3>\n
Graph API has a resetPassword method<\/a>. This isn’t very helpful though as it does not support application permissions, and even in the case of delegated permissions it only accepts certain roles (doesn’t support “Helpdesk Administrators” or “Password Administrators” for instance).<\/p>\n
\"\"<\/p>\n
I have no idea whether this will sync back to on-prem AD too. From the docs<\/a> it sounds like it will:<\/p>\n
This flow writes the new password to Azure Active Directory and pushes it to on-premises Active Directory if configured using password writeback. The admin can either provide a new password or have the system generate one. The user is prompted to change their password on their next sign in.<\/p><\/blockquote>\n
Attempt 3: Azure AD<\/h3>\n
Azure AD PowerShell cmdlets can work with app registrations so I tried the following:<\/p>\n
Connect-AzureAD -TenantId $tenantId -ApplicationId $appId -CertificateThumbprint $cert\r\n \r\nSet-AzureADUserPassword -ForceChangePasswordNextLogin:$true -Password (ConvertTo-SecureString \"$Password\u201d -AsPlainText -Force) -ObjectId $userId<\/pre>\n
This too worked… exactly as the Graph API request in attempt 4. It set the password in the cloud and forced a password change upon login to the cloud… but as with the Graph API it didn’t writeback the password I set to on-prem AD. Of course, once the user set a password that synced back.<\/p>\n
I don’t understand why the password doesn’t sync back when it’s set via Graph or Azure AD powershell.<\/p>\n
I found the following in the docs<\/a>:<\/p>\n
\"\"<\/p>\n
I guess the Azure AD PowerShell could be said to come under the unsupported administration operators (but I am not sure<\/em>) and thus not supported? Graph API will work via the resetPassword<\/code> method (which I didn’t try) as that’s the API meant for resetting, while the passwordProfile<\/code> property updating is something else?<\/p>\n
Users changing their password in the cloud comes under the supported scenario so that’s why that works.<\/p>\n","protected":false},"excerpt":{"rendered":"
Here’s what I want to do: I am creating new accounts on-prem and setting a password. I want the new account user to change their password at first login. Due to the nature of our environment I would prefer they go to Azure AD to set their new password and also register for MFA (rather … Continue reading Azure AD password change and all that<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[887],"tags":[982,1016,1015,272],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/5745"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=5745"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/5745\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=5745"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=5745"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=5745"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}