Use this link to share with your colleagues:
Setting Up Multi-Factor Authentication (MFA) in PatronManager: https://help.pm.leapevent.tech/a/1483320
Having all your data in one place is what makes PatronManager effective, and securing all that data is important! Multi-Factor Authentication, or MFA for short, is an effective way to increase protection for user accounts against common threats like phishing attacks and stolen passwords.
Salesforce provides several options for setting up MFA, but only one method is compatible with PatronManager. In this article, we'll guide you to the correct setup process, specifically looking at:
- What MFA is and how it works
- Which kinds of users are required to have MFA
- Important notes for configuring MFA in PatronManager
- How to enable MFA
- Useful resources
- Authentication methods and examples
- Frequently asked questions
Ready? Let's jump in!
Want to learn more and see it in action?
Check out this recorded webinar, co-hosted with our expert friends at Data Geeks Lab:
Timestamps:
- 4:45 - What is MFA?
- 7:25 - What is the Salesforce rule?
- 10:23 - Why is MFA important?
- 14:26 - Why not SMS verification codes?
- 16:30 - Why does MFA matter for non-profit organizations?
- 18:10 - MFA verification options for PatronManager users
- 21:55 - Demo: Salesforce Authenticator
- 26:30 - Demo: Time-Based One Time Password (for other authenticator apps or for use with a password manager)
- 34:56 - Demo: enable MFA for users in PatronManager
- 41:12 - Demo: unlocking a user
- 45:07 - Q&A
What is MFA?
Multi-Factor Authentication adds another layer of security to your login process by requiring users to enter two or more pieces of evidence — or factors — to prove they’re who they say they are. One factor is something the user knows, such as their username and password. Other factors are verification methods that the user has in their possession, such as an authenticator app on their phone. A familiar example of MFA at work is the two factors needed to withdraw money from an ATM. Your ATM card is something that you have and your PIN is something you know.
By tying user access to multiple, different types of authentication factors, it’s much harder for a bad actor to access your PatronManager account. For example, even if a user’s password is stolen, the odds are very low that an attacker will also be able to guess or hack a code from the user’s authentication app.
Who needs to use MFA?
All internal users at your organization.
As of February 2022, Salesforce will contractually obligate organizations to use multi-factor authentication for internal logins. That means anyone who logs in to your PatronManager account. Think of it this way: you want your patron and donor data to be safe, right? Therefore, anyone who can log in and see information about your patrons must have their login access secured with MFA.
The PatronTech Admin user is exempt.
Due to our relationship with Salesforce and our internal access control mechanisms, MFA requirements don't apply to PatronManager's administrative login. In fact, you must not enable MFA for the PatronTech admin user, as this prevents us from maintaining and supporting your account.
Portal users are exempt.
Portal user logins (how your patrons can log in on the Public Ticketing Site) are already sufficiently secure, because those users can only view limited data that is specific to their Contact (such as their Order History and Donation History). Therefore it's not necessary for those users to have MFA - and you don't want to present them with a hurdle when they go to buy tickets!
Some organizations use Chatter-specific user licenses to enhance collaboration in Salesforce/PatronManager without giving those users much more access. If you're not sure what this means, it likely doesn't apply to you. If you do use Chatter licenses:
- Chatter Plus and Chatter Only licenses ARE required to use MFA
- Chatter External and Chatter Free licenses are exempt from MFA requirements
Automated API access used by most Salesforce integrations is secured in other ways, and doesn't require MFA. If you already use a third-party app integration (for example, FormAssembly or Volunteers for Salesforce), you shouldn't need to do anything.
If you set up a new integration after enabling MFA, you'll likely be prompted to authenticate as part of the integration authorization process, but that should only be necessary the first time.
If you experience issues with an integration, reach out to the app vendor for assistance.
MFA and PatronManager: important considerations
To ensure your MFA roll-out is successful and compatible with PatronManager, be sure to pay special attention to the following:
Enable MFA via permission set, and do NOT assign the permission to the PatronTech Admin user
This is the method Salesforce recommends in the guide linked below. While it's possible to enable MFA by Profile, that method is NOT compatible with PatronManager. Be certain to:
- Create a permission set to apply MFA
- Assign the permission set to all users at your organization
- Do NOT assign the permission set to the PatronTech Admin user
- Do not assign the permission set to PatronPortal users
If your organization uses PatronPortal, double-check your settings
If your patrons use Portal to log in on your Public Ticketing Site for special discounts or presale access, you don't want to slow them down by requiring extra login steps. Portal user access is already heavily restricted, so MFA isn't necessary for these folks.
5. Ensure that "Session Security Level Required at Login" is blank
If you find that it's set to "High Assurance", edit the Profile and change it to "None". It should look like this:
Prepare and document your access recovery plan
Important! If a user loses their authentication device, they will need assistance from an admin at your organization to log in to PatronManager. If you are an admin at your organization, you must have an access recovery plan in case you get locked out yourself.
Consider these best practices:
- Each admin should register at least two verification methods.
- Keep a backup security key in a secure place at work, such as a safe.
- Make sure at least two users at your organization have permissions to manage users in Setup. This way, if one admin user is locked out, the other admin user can help them.
Enabling MFA
Salesforce has put together an excellent set of materials to help you get up and running with MFA! We strongly recommend following the steps outlined in the Salesforce Admin MFA Rollout Guide - it covers the entire process from preparation, to communication and change management, to which authentication methods are available.
If you prefer just the highlights, here's what to do:
1. Prepare yourself
You (the admin) should read this whole article, watch the webinar above, and read through the Salesforce rollout guide linked above. You'll feel much better if you understand what's happening, and your rollout will be much smoother if you're well prepared!
- Are you clear on the different authentication methods, and do you know which ones you'll recommend?
- Are you ready to help users with questions downloading or connecting an authenticator app?
- Do you have your second admin equally prepared, so that you can help each other if one of you gets locked out? The buddy system is important!
- Have you read through the steps to disconnect an authentication method and/or provide a temporary verification code, in case a user forgets or loses their phone?
2. Give users instructions to connect an authenticator app
They can do this in advance if it makes them more comfortable; they can also wait until they're prompted after you've enabled MFA. If you're using another authentication method (see below) your process may differ; for the simplest scenario using Salesforce Authenticator or another authenticator app, we've put together these instructions you can send to your users.
3. Create a permission set for MFA
Next you'll create the permission set; assigning this to users is how you'll turn on MFA.
3.2. Click New
3.3. Name and describe the permission set
- Label: "MFA Authorization for User Logins"
- API Name: autofills
- Description: "Assigning this permission set enables multi-factor authentication for that user."
- Save
3.4. In System Permissions, edit and check the box for "Multi-Factor Authentication for User Interface Logins"
Where you'll find this depends on your organization's configuration. If your screen looks like this, scroll down and click on "System Permissions" first, then click to edit the resulting page:
Or, if your screen is really long with lots of scrolling, click Edit at the top and scroll (or better, CTRL+F) to find the right checkbox field:
In either case, the checkbox you need to find, check, and save is called "Multi-Factor Authentication for User Interface Logins":
3.5. Don't forget to save!
4. If you plan to use physical security keys, enable them for your users
If your organization will be using a physical security key, like YubiKey or Google's Titan Security Key, you will need to adjust another setting to allow verification using this method.
Note that some physical security keys may only work with certain browsers, such as Google Chrome.
5. Communicate, communicate, communicate
Not everyone enjoys surprises: before you enable MFA, make sure you've talked to your users and prepared them. After those real-life conversations, it's a great idea to send them an email with the specific date you plan to enable MFA, and include a link to those instructions again.
6. Assign the permission set to users
You don't have to do this all at once, you can do a few users at a time.
And remember, never assign this permission set to the PatronTech Admin user!
You can do this from the Permission Sets related list on a user record in setup, or you can do it for multiple users at once from the permission set itself as shown below.
Useful resources
Here are some materials from Salesforce that you may find helpful. Many are linked above, and collected here for easy access:
- Salesforce Admin MFA Rollout Guide
- Salesforce Multi-Factor Authentication FAQs
- Preparing your access recovery plan
- Recovering MFA access for a user
- Want to practice first? Check out this Trailhead for a hands-on learning resource
Authentication method examples
We know this can feel a bit overwhelming; we recommend going through the Salesforce guide linked above for clear step by step instructions and suggestions, and checking out the webinar at the top of this article for demonstrations.
Once you've gone through those things and if you're not sure which authentication methods to use, here are some examples and suggestions.
Each user can have different authentication methods configured for their login, and can even set up more than one method so they have a backup!
With this option, the user will download the app to their phone and connect it to their login. It's very easy to set up - in Salesforce the user will enter in a temporary passphrase provided by the app, and that takes care of connecting the app to the user's login. They only have to do this once.
Once it's connected, anytime they log in and need MFA verification, the app on their phone will automatically show a message asking if they're trying to log in. All they'll have to do is tap a button to approve, and they're done! Nothing extra to type in, very quick and easy.
Good for:
Just about anyone! Especially users who aren't in PatronManager that often, who don't want to have to type in extra numbers while logging in, and who are pretty much guaranteed to always have their phone with them. For example:
- Executive directors
- Development directors
- Marketing directors
Special considerations:
This is a (free) app the user will need to have on their own phone. Older phones sometimes have a short delay between the login attempt and the approval option appearing on the phone, while with newer devices it's pretty much instant.
By enabling location services and setting a trusted location (like the box office) in the app, users can automatically authenticate much of the time (as long as their phone is in that physical location when they log in).
These apps are simple to set up and use. Configuration typically involves scanning a QR code with the device when prompted by the app, and again, they only need to do that once.
Once it's connected, when the user logs in and is prompted to authenticate, they'll open the app on their device to find a short numeric code. They'll then type in that code to authenticate their login (similar to how email verification codes worked before, just in an app on their phone instead of in their email).
Good for:
Most users. If a user already has an authenticator app they use with other logins, they may also prefer to keep everything in one place.
Special considerations:
The time-based one time passcode (TOTP) the user will need to type in changes every 20-30 seconds, so folks who type slowly may find this method challenging. Those users will likely prefer the Salesforce Authenticator app instead.
The TOTP is constantly regenerated, so these apps may be faster to use on older phones than waiting for a prompt from the Salesforce Authenticator.
Several password managers, like LastPass and 1Password, support time-based one time passcodes, or TOTP. This allows a user with access to the password manager to get their MFA authentication code via that method, without needing to use an app on their personal cell phone. Check out the webinar at the top of this article for more info and a demonstration of this method.
Good for:
Users and organizations who are already accustomed to password managers, or users who want to be able to authenticate without having to use their personal device.
Special considerations:
Support for TOTP is typically only included with paid versions of password managers. This method is slightly less secure (particularly if the username and password are stored in the same place), but it meets Salesforce requirements.
A physical key is a special little USB dongle, which the user plugs into the USB port on the computer to verify that they're allowed to log in. A couple examples are Yubikey and Google Titan key.
Good for:
Part-time users, student users, or volunteer users, who don't want to (or shouldn't be asked to) use their personal device as an authentication method.
We recommend labeling the devices for each user login, and keeping the devices in a secure place, like with the box office cash box; that way the user can pick up their secure access key at the same time they pick up their till. Think of it like checking out the keys to special equipment for the day.
Special considerations:
You will need to purchase one key per user login; as of this writing, pricing is generally between $30-$60 per key. Be sure to purchase a key with the correct USB connection for the computer you'll be using (e.g. USB-A vs USB-C).
Note that PatronManager does not supply these products and we are unable to answer questions about them.
Some devices have biometric recognition built in, like Apple Touch ID or Windows Hello for facial recognition. Salesforce allows these biometric or physical recognition features as an authentication method.
Salesforce has more information on enabling biometric recognition here.
Good for:
Users logging in on a dedicated device that has this type of recognition enabled for them already.
Special considerations:
Even if you set up biometrics, we recommend setting up a secondary MFA authentication method as well, just in case.
FAQs
Email, SMS text messages, and phone calls aren’t allowed as MFA verification methods because email credentials are more easily compromised, and text messages and phone calls can be intercepted. It’s a lot harder for bad actors to get control of an actual mobile device or physical security key than it is to infiltrate an email account or hack a cell phone number.
For all the data security reasons outlined above and discussed in the webinar, we recommend setting up MFA to secure your account at your earliest convenience. Salesforce has announced a contractual obligation for all organizations to enable MFA for their users by February 2022.
This requirement will eventually be enforced by Salesforce, so at some point users won't have a choice. Your users' experience will be much better if you roll out MFA voluntarily and with good communication rather than having it happen unexpectedly one day.
Because you'll enable MFA by assigning a permission set to each user, you can roll this out at your own pace. A user won't be prompted to use MFA until they have the permission set assigned.
If you use the Salesforce Authenticator app and enable location services enabled on your device, you can turn on a feature to “always allow logins from this location”. Once you mark a given location (like your box office) as trusted, the MFA approval will often happen automatically as long as that’s where your device (i.e. your phone) is located when you log in to PatronManager. You may still be prompted from time to time or once a day, but not for every login.
This option is only available with the Salesforce Authenticator app, not with third-party apps.
The process that PatronManager uses to administer your account, release updates, and provide support is not compatible with Salesforce's MFA functionality as it exists today. Therefore it is imperative that you do not assign the MFA permission to our PatronTech Admin user.
Rest assured, our access to your account is fully secured. PatronManager staff members are authenticated before they can access your PatronManager account, and all login activity is tracked.
If a user loses or forgets their mobile device or security key, you can:
- Disconnect the lost verification method
- This is necessary if their device is lost; if they know it's in a safe place and just don't have it with them, you could skip this step.
- Re-establish login access by issuing a temporary verification code for the user
See Recover MFA Access in Salesforce Help for more details and specific steps.
Remember! You are your organization's best line of defense against security threats. Before helping someone access your PatronManager account, make sure they are who they claim to be.
Don't provide access automatically in response to an email or a text message - if you can't speak to the user in person, get on a video call, or call them directly on a verified phone number to confirm their identity and their situation.
If a user changes phones and needs to set up a new authentication app, head to their user record in Setup and disconnect the verification method associated with their old phone. They'll be prompted to set up a new authenticator next time they log in.
See Recover MFA Access in Salesforce Help for more details and specific steps.
If you choose to use a physical Security Key, like YubiKey or Google's Titan Security Key, you will be able to unplug or remove the physical Security Key after logging in. In other words, the key does not need to stay plugged in for the entire session.
If you’re the only admin for your Salesforce environment, you need a special backup plan just for you! For example, what’s your recourse if you forget your mobile phone at home or accidentally lock your security key in your car? Consider keeping a backup physical security key in a secure place at work, such as a safe.
We are not your best resource for helping users regain access to PatronManager. If a bad actor is trying to access your data, your organization's staff are the people best equipped to verify that the user is who they say they are, and that they are supposed to have the access they're requesting. You know your colleagues best!
Think of your access to PatronManager like the keys to a locked file cabinet full of sensitive donor data. You probably wouldn't give your office manager permission to unlock that file cabinet for anyone who happened to know the name of a staff member, would you?
Nope - and you wouldn't want them to! PatronPortal users are extremely restricted in what they can access and how they can log in. They don't pose a security risk to your PatronManager account, and aren't included in the Salesforce MFA requirement. To avoid frustrating your patrons and discouraging them from purchasing tickets, be sure to follow these steps to exempt Portal users from MFA.