In the interests of transparency: this is an affiliate link. See my affiliate disclosure page for an explanation.
AWS has a tutorial about enforcing MFA for all users. The general thrust of the article is to create a policy that allows users without MFA to do nothing other than log in and set up MFA. Having enabled and logged in using MFA, other permissions become available to the user (according to whatever other permissions are assigned).
This works well apart from one snag: having created a user, and set the flag forcing the user to change password on first login, the user cannot log in. Instead the user is greeted with the following error:
Either user is not authorized to perform iam:ChangePassword or entered password does not comply with account password policy set by administrator
The problem lies in a policy statement called “DenyAllExceptListedIfNoMFA”. As its name suggests, for a user without MFA, this blocks all bar the specified actions. In AWS’s recommended policy, the section effectively allows the following actions:
"iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken"
You’ll notice that those actions don’t include anything about changing a password! So without MFA already enabled on your account, there’s no way to change your password when first logging on (if “force password change” is enabled). The trick is to add two more permissions:
"iam:ChangePassword", "iam:CreateLoginProfile",
For a user that has not yet logged into the AWS console, this will allow creation of the user’s login profile and setting a new password.
For anyone reading this: while adding the two mentioned permissions sounds attractive, it does allow users to change their password without MFA, even after activation of MFA. That might be a security risk – AWS has added a note on this to their docs as well: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage.html
Thanks Dennis. I guess the security risk AWS has in mind is locking someone out of an account. To utilise the ChangePassword permission, an attacker would already need to know (or have brute-forced) the existing password. So changing the password would give the attacker no greater access – it would just create a denial-of-service condition for a user logging into the web console. Since this is a user account rather than a service account, that seems like a small risk.
But there may well be some other attack scenario I’ve overlooked?
Yes, when an attacker changes the password – if they have the existing one – it would lock the user out of their account until they reset the password themselves again (e.g. through a password reset email). But a potential attacker wouldn’t be able to get further than that as far as I’m aware. So I guess it should be a small risk, like you mentioned.
In any case, thanks for writing this article!
On the contrary – thanks for reading and taking the time to comment! 🙂