In today’s environment of hackers and security incidents, as a Salesforce Administrator, we need to ensure that security of our Salesforce org is tight and access to our orgs aren’t wide open. This is extremely important especially where our orgs have PII (personally identifiable information) or PHI (protected health information) data, we don’t want our company to show up in the news as the next company that has leaked customer data.

This is the last article in a 3-part series covering the security options available for configuring Salesforce access. Based on your industry, the level of data stored in Salesforce, the type of users accessing Salesforce, etc., gauge the level of security best suited for your Salesforce org and implement accordingly.

Catch up on the first two articles: first article | second article

We will be covering the following in this article:

• Use Case: I Want to Specify How a User Logs In
• Use Case: I’m a System Admin and Need to Login As Another User
• Use Case: I’m not a System Admin and Need to Login As Another User
• Use Case: I Need to Create an Integration User
• Use Case: I Have Sensitive Data. How Do a Safeguard It?

Use Case: I Want to Specify How a User Logs In

Let’s say that you do not want users to only log into Salesforce using your custom domain and not the generic login.salesforce.com or you want to default to single signon as your authentication method, bypassing the Salesforce login screen altogether.

You are just a few clicks away from making this happen.

Under Setup, go to Domain Management | My Domain.

To prevent users from logging into login.salesforce.com and only login using your custom domain, click on the “Edit” button in the My Domain Settings section, check the box next to “Prevent login from https://login.salesforce.com.” Click on the “Save” button to save your changes.

Important thing to note: Once this is checked, your users will need to use the custom domain to log into Salesforce via the browser UI, Salesforce1 and third party tools, such as Data Loader, Eclipse, etc. They will not be able to use the default login.salesforce.com.

To specify the authentication method for your users, click on the “Edit” button in the Authentication Configuration section, check the box(es) you wish to use for Authentication Service. Note: By default, Salesforce selects the Login Page (Salesforce’s native username/password). If you want to default this to your SSO configuration, only check the SSO authentication method. In the below illustration, this is the “stsC1PROD” (name of your SSO configuration record). Click on the “Save” button to save your changes.

There may be reasons why despite restricting login to just your custom domain, some users may still need to access the Salesforce login screen and login with the native Salesforce username/password (i.e. your external implementation partners who are not users on your corporate network). This can be accomplished by accessing the following URL: <domain name>/?login.

Use Case: I’m a System Admin and Need to Login As Another User

You’re a System Administrator and in order to test configuration changes or troubleshoot issues, you have a need to log into Salesforce as that user. There is a setting that allows System Administrators the ability to login as any users without their explicit permission.

Additionally, there may be a need for Salesforce or a third party vendor to be granted the ability to log into Salesforce as a user. Salesforce allows you to configure login access policies and set whether any user can grant access or only system administrators.

Depending on your company’s information security requirements, you may not want to just grant System Administrators the ability to login as any user. Rather, leave this feature disabled and have your users explicitedly grant login access. If a system administrator is logged in as another user, any action that is taken as the system administrator will be logged as that user, not as the system administrator.

Look at the setup audit log to see system administrators who have logged in as another user and when they logged out as the user. However, actions performed by the system administrator while logged in as another user are not tracked and viewable in the user interface. This data may be available via Event Monitoring (available at additional cost).

Go to Setup | Security Controls | View Setup Audit Trail

A user can explicitly grant login permissions by having them go to My Settings | Personal | Grant Account Login Access, select the login duration for System Administrator and save changes.

To set the login access policies, go to Setup | Security Controls | Login Access Policies.

Step 1. Check the checkbox and/or radio buttons to set the login policy. Click the “Save” button to save changes.

Use Case: I’m not a System Admin and Need to Login As Another User

You may have super users to whom you’d like to delegate some basic troubleshooting duties to, allow them to perform administrative tasks such as helping users configure list views, reports, dashboards or manage a subset of users in your Salesforce org (reset password/maintain user records), but are not system administrators.

This can be done by setting up the users in a Delegated Administrative Group.

Go to Setup | Security Controls | Delegated Administration

Step 1. Click on the “New” button.

Step 2. Provide the information and save changes.

• Delegated Group Name

• Developer Name

• “Enable Group for Login Access” – check the box if you want to give users in this delegated administration group the ability to login as other users

Step 3. Set up the permissions for this Delegated Group and save changes:

• Delegated Administrators: Select user(s) who will be assigned to this Delegated Administration Group
• User Administration: Select the role(s) that this group will administer/assign the role to users
• Assignable Profiles: Profiles that the users in this group can manage, assign users to, login as
• Assignable Permission Sets: Ability to assign these permission set(s) to users managed by this delegated group
• Assignable Public Groups: Ability to assign these group(s) to users managed by this delegated group
• Custom Object Administration: Ability to custom object(s) to users managed by this delegated group  

Go to Setup | Manage Users, the delegated administrator will be able to login as or administer any user who has the login and edit links next to their names.

Use Case: I Need to Create an Integration User

As your Salesforce org needs to interface with other systems to send and retrieve data, changes are you will need to create an integration user for that purpose.

To increase security measures by restricting access to that which is only needed for that integration point, the recommendation would be to create a different integration user for each integration need. I know this approach may be cost prohibitive as each user account means another license count.

Many times, vendors will take the easy way out and tell you that the integration user accounts need to be a system administrator in your Salesforce org. The integration account needs to make changesets and deploy? Manage users? View All Data? Modify All Data? I have yet to run into a case where an integration account must be associated with the system administrator profile. Instead, I explain our strict security guidelines and work closely with the vendor to strip down the permissions to only that which is truly needed. Yes, this takes time and troubleshooting, but in the long run, you’d have a more secured integration user record.

Here are things to consider for the integration user account:

• What CRUD access do you need for each object?
• Limit the apps and tabs it needs access to
• Login IP Ranges: Obtain the IP addresses from the vendor to ensure access is only permitted if coming from the vendor’s IP addresses.
• API only user: This should be checked. This means that no one can interactively log into Salesforce with the username/password.
• Password Never Expires: This should be checked or else this user account will adhere to your org’s password policies. If the password expires, the integration will fail.
• Review each system and administrative permission and remove all unnecessary permissions.
• Remove any unnecessary apex classes and visual force pages

Note: During the initial setup, the vendor may need the user’s security token. If this is the case, you will need to associate the integration user to the system administrator profile to obtain the security token. Once that is done, revert the integration user back to its own integration profile.

Use Case: I Have Sensitive Data. How Do a Safeguard It?

Your Salesforce org may have PII (personally identifiable information) or PHI (protected health information) data and therefore, you need to safeguard that data from possible misuse.

Here are a few things to consider as you configure your Salesforce org with tighter security controls in mind.

• If there are multiple business units sharing the same Salesforce org but should not see each other’s data, consider a private sharing model by setting the OWD (org wide defaults) to private rather than public only or public read/write. Further access can be opened up with record owner or criteria sharing rules.
• When setting up profiles, should all users have the ability to export reports or only managers via a permission set?
• If you have encrypted fields like SSN, birthdate, consider whether all users should have the ability to view encrypted data or only certain profiles? For example, system administrators most likely do not have a business need to see the full SSN, so they should not have the “view encrypted data” permission, but a customer service rep would need to view the SSN or birthdate to validate the customer’s identity.
• If users only access Salesforce while in the office (on the company network) during work hours, consider establishing login hours and login IP ranges on their profile.