Whats everyones best recommendations when deploying MDM/MFA to end users? Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
ThomasThomas (Okta, Inc.)  

Whats everyones best recommendations when deploying MDM/MFA to end users?

Just looking for general "Best Practices/Things to look for" when mass deploying MDM/MFA to end users.


Original Author: Tyler Granlund

Best Answer chosen by Thomas (Okta, Inc.) 
ThomasThomas (Okta, Inc.) 

Tyler,  recommendation - don't use the question challenge.  Enforce Google Aauthenticator or OKTA verified.  Or If you have some budget to spend then you can get the RSA keys. 

Things to be wary of:

IWA (desktop single sign-on) and MFA  shares the same IP whitelist.  It may not impact you however, if you are using desktop single sign-on you would have already captured the gateway IP addresses to determine which campuses will enforce desktop single sign-on.  This IP whitelist is also shared by the MFA functionality to prevent MFA from being invoked while you're in your office (so the users won't be tasked to enter the 6 digit code at their desk) and is only enforced when your outside your office.

Here is the problem:

- Consider a remote office that does NOT benefit from desktop single sign-on since they cannot "see" the IWA server.  These users are working securely within their remote office network therefore they enter their ID and passwords to get into OKTA (no MFA assumed)

- With MFA turned on these users will enter their ID, Password then followed by what ever challenge you setup as MFA ( RSA key, 6 digit code, etc) to get into OKTA

- The problem  is if you don't want users at remote offices to enter the 6 digit MFA code because they are working in a safe environment or if these users don't have smart phones.  Then you'll be forced to provide a means for them to get the 6 digit code (ie buy them a phone or RSA key fob) since they are coming into the office and expect to be able to get into OKTA.  You won't be able to exclude these users from MFA since doing so will also enforce desktop single sign-on, which they would not be able to do, resulting in a failure to enter into OKTA. You'll get a 404 error when the users are directed to the IWA server to test for desktop single sign-on. 

- However, If the assumption is that all users will have a smart phone then you won't have a serious issue .  Just make sure that your BYOD policy states that you can wipe their phones if it gets lost. 

- If your remote users ARE able to do desktop single sign-on successfully then you also dont have an issue. The IP whitelist will cover the remote office and those users will not be forced to enter the additional information. 

The problem is for any office that cannot "see" the IWA server, they will not be able to exclude employees at that office from MFA.  Therefore the assumption is that those employees will need to have a device that will be used to provide the MFA code. You'll need to consider that when rolling out MFA.

Original Author: Christopher Jaggernauth