In today’s identity landscape there is a growing need to prove one’s identity beyond just a username and password. Growing threats from hackers and annoying ransomware have people and businesses implementing tighter and tighter security on everything from network access to hosted services like Microsoft’s Office 365 (O365).
Common security additions include using multi-factor authentication (MFA) services that link to a user’s device, such as a phone, that requires the user to be in possession of the device and perform a specific set of actions as part of their authentication attempt. These actions may include viewing a code on their phone that is then entered into the application/website they are accessing, answering a phone call, responding to a push notification, etc. When using this type of MFA security, if an account is compromised but the unintended user does not have the linked MFA device then the account still cannot be accessed.
However, when it comes to using MFA security with O365 you need to have a federated connection, or at least that is a common approach. Organizations will often have their MFA service of choice tied to a preferred authentication source, like NetIQ’s Access Manager, and then using federation, link O365 to that authentication source.
But, there is a downside.
When using federation with O365 and NAM, it works perfectly with browsers and even clients on standard laptops and desktops (Windows & OS X). The downside is trying to use the basic setup with a mail client on a smartphone (Android or iOS). When configuring a federated O365 account in a mail client on your smartphone, it will work initially but after a few hours it will begin throwing different security alerts and prompting you to re-authenticate the federated account in the settings.
Luckily, this is not a dooms day scenario and it does have a resolution.
In most Identity Management (IDM) environments that include O365, there is a connection between the IDM and O365 spaces that is responsible for provisioning O365 accounts and keeping the accounts in sync. In a non-federated O365 environment this includes synchronizing account passwords from IDM to O365, however, in a federated O365 domain this is not possible. Because the O365 domain is federated, O365 will not accept password updates from IDM connections. O365 is not doing the authentication since it is a federated domain so O365 does not want the password.
It is the very fact that O365 does not accept passwords from IDM that causes the errors with smartphone mail clients. Typically, when a password is set in O365 there are certain values set on the account, however, with O365 federated domains these values do not get set automatically because passwords are not accepted by O365. This means that in order to resolve this issue, just update these attributes programmatically from your IDM system and the error goes away.
The O365 attributes in question are:
- LastPasswordChangeTimestamp
- StsRefreshTokensValidFrom
It seems that populating either of these attributes, which are both part of the O365 MSolUser class, causes the issue to go away on any smartphone client. The format of the date for both attributes is “Mar 26, 2018 9:30:44 AM”.
And, these attributes cannot be populated as part of the account creation process if the account is created by an IDM provisioning process. The account must be created first without these values and then updated with the values in a separate transaction. Logically, you cannot have a password last set timestamp at the time of creation. The account needs to be created before it can have a “last set” or “last changed” type history.
Even if the actual password cannot be synchronized from IDM to O365, the O365 driver/connector in IDM can still detect the password change in IDM and update these values based on that activity. In today’s landscape, account claiming is growing in popularity and part of that process typically includes setting a password. That is a great trigger for an IDM connection to update these values in O365 to enable the federated account for smartphone access.
At the time of this blog article’s creation, we have not seen a need to update/maintain these values over time, only that they need to have been set at least once for the smartphone client’s to work properly.
Below are few other key details to keep in mind if you encounter this issue:
- This is not the result of a product issue of NetIQ Access Manager
- This is not the result of a product issue of NetIQ Identity Manager
- This is not the result of a product issue of O365
- This is not the result of a product issue of the MFA service of your choice
- Populating these values in O365 does not impact accessibility with other methods of access, i.e. browser or standard clients.
- These values cannot be populated as part of the O365 account creation event. They must be applied separately.