Salesforce: Sharing Rules via Public Group & Role

Sharing records using Public Groups may or may not rollup via role hierarchies, this is determined by the object setup in Organization-Wide Defaults and also Public Groups setup.

By default, Salesforce standard objects will grant access via hierarchies, meaning users with higher role hierarchy will be able to view or edit records where the records are viewable or editable by any users below that user in the role hierarchy.

While for custom objects, you can configure the  "Grant Access Using Hierarchies" under Organization-Wide Defaults for that object.

In the Public Group setting, you also can configure to enable "Grant Access Using Hierarchies". Let us see a few scenarios as below:

1. Sharing to Public Group for objects enabled for "Grant Access Using Hierarchies"

1A. Public Group is "Grant Access Using Hierarchies" enabled

This will share records to users with the higher role hierarchy.

reason for the user in Public Group

reason for the user with higher role hierarchy

Group Staff 2 only has 1 user which is Song Lee, when I expand the list, it will show all users able to access the record. From the screenshot below, Jack Bob is the record owner, while Maria Ann and Platform User 1 are users with roles higher than Song Lee's in the role hierarchy.

1B. Public Group is not "Grant Access Using Hierarchies" enabled

Let us use the same object as above, but share it with a different group which is without enabled "Grant Access Using Hierarchies". This will NOT share records to users with the higher role hierarchy. 

** This is applicable for standard objects too

2. Sharing to Public Group for objects NOT enabled for "Grant Access Using Hierarchies"

2A. Public Group is "Grant Access Using Hierarchies" enabled

In this testing, we are using a custom object not enabled for "Grant Access Using Hierarchies", then we create a sharing rule to share with the same group with Grant Access Using Hierarchies as in (1B).

As the result, this share will NOT grant access to the users in the higher role hierarchy.

2B. Public Group is not "Grant Access Using Hierarchies" enabled

The result of this sharing is exactly the same with (2A), where the users in the higher role hierarchy are NOT shared.

3. Sharing to Roles for objects enabled for "Grant Access Using Hierarchies"

The result is similar to (1A), users in the higher role hierarchy will get access.

4. Sharing to Roles for objects NOT enabled for "Grant Access Using Hierarchies"

The result is similar to (2A), users in the higher role hierarchy NOT will get access.

Reference: Controlling Access Using Hierarchies

Salesforce Verification Code

To help protect your organization’s data from unauthorized access, Salesforce by default implement identify verification code. When you login to Salesforce from unknown network, or from new computer / device, or with new browser, or just clean your web browser cache. Salesforce will send you verification code via  mobile SMS or via email, if you do not add mobile number to user user profile.

But, can we skip this verification code? Yes by adding Trusted IP ranges, users in IP ranges can log in without receiving a login challenge for verification of their identity.

Adding trusted IP Ranges (you define a list of IP addresses) to Network Access 
Navigate to Setup | Security Controls | Network Access
This setting will be applicable for the whole users in the org.

Another security measure is to white-list only range of valid IP addresses from which users can log in to Salesforce. User login from IP Addresses not in IP ranges defined will be restricted to access Salesforce. To setup this restriction, navigate to Setup | Manage Users | Profiles - select a profile and scroll down to Login IP Ranges. When user login from this IP ranges, they will not get verification code as well.
This setting will be applicable for all users in the Profile.

In summary:

Network Access (available for all editions)

• Setting trusted IP ranges under Setup | Security Controls | Network Access opens access to users accessing Salesforce from the trusted IP addresses. Users will not be challenged with the 5-digit verification code to authenticate the IP address from where they are logging in. All the customer apps and integration will not need the security token.
• These can only be added or removed by a system administrator. Removing them from the Network Access will not revoke access from these IP addresses.

Profile-Based IP Restrictions (Available in Enterprise, Unlimited, Developer)

• You can set IP Restriction under each profile. This will restrict access, and users will only be able to log in from the IP addresses listed.
• ​Users will not be able to access Salesforce from any IP that is not listed in the range. They will receive a Restricted IP error when logging in.
• ​This setting is recommended for organizations with users who log in only using VPN or their public corporate network IP addresses.
• ​Please make sure that all the IP ranges for your apps and integration are added as well.

Reference:

• Being Asked for an Identity Verification Code on Every Login
• Set Trusted IP Ranges for Your Organization
• Retrieve verification code by SMS, email or Salesforce Authenticator app
• What is the difference between Network Access, Session Settings, and Profile-Based IP Restrictions

Salesforce: Password Policies and Session Timeout

Salesforce provide ability for administrator to define Password Policies and Session Timeout for their organization. Navigate to Setup | Security Controls | Password Policies to define organization password policies, from: expiry days, remember password history, minimum password length, password complexity, maximum login attempt, lockout period and so on. While Session Timeout is configured from Setup | Security Controls | Session Settings.

But, you also may notice that you can find Password Policies and Session Timeout in Profile setting.

So, which policies and setting will be applied to users and why there are two settings for the same thing? Since Winter '15, Salesforce provide finer control over the user experience by Profile, while earlier available setting at Security Control applied to the entire organization. The settings for session duration and password policies at the profile level override the settings at the organization level.

Note:

• When you setup Salesforce initially, Profiles password policies and session timeout setting will follow setting from Security Control.
• When you change password policies and session timeout at Security Control, it will apply to all Profiles setting, as long as setting in Profile haven't change manually.
• You can manually change password policies and session timeout at Profile different with Security Control, and users assigned to this profile will follow setting in Profile rather than Security Control
• Once you change the setting in Profile differ with Security Control, any changes in Security Control will NOT apply to setting in Profile anymore.
• When you create a new custom profile, it will follow setting from Security Control, changes in Security Control will apply to the new custom profile, until you manually change in that profile.
• When you clone a profile with password policies and session timeout has been modified, to a new custom profile, password policies and session timeout in the new profile created will copy from Security Control, not from the original profile used to clone.
• A custom profile has been changed manually will not able to sync with Security Control setting anymore, even you manually align it with Security Control setting, it will not sync again when Security Control setting changed.

Reference:

• Set Session Timeout and Password Policies for Individual Profiles

Salesforce: Two Factors Authentication - 2FA

For Singapore residence, when login to internet banking from Singapore banks, after enter username and password successfully, system will request user to enter security token, it can be generated using a device or delivered by SMS, usually it would be 6 or 8 digits. This is one of usage of two factors authentication (2FA), aka OTP (One Time Password) with what you know (username and password), plus what you have (device), to prove the right person with access and enhance security when username and password only is not secure enough.

For some organization, two factors authentication is required. But, can we have 2FA when login to Salesforce.com? To build two factors authentication as implemented by banks will need a huge cost and a lot of time, but to implement this on Salesforce.com is free of charge. Salesforce has this feature out of the box for all editions. If you are one of the awesome admin, you can configure this for less than an hour (not include training or communication with your users), and you do not need a developer to write any code.

1. Setup
Enable Permission
Create a Permission Set or enable Profile with Two-Factor Authentication for User Interface Logins permission. Users assigned with this profile or added with this permission set will required to enter time-based password.

How user will receive this one-time password? Instead of SMS, user need to install Salesforce Authenticator app in their smart phone as trusted device linked to your Salesforce account, for now only iOS and Android phone.

Install Salesforce Authenticator app
Search for Salesforce Authenticator in App Store for iOS device or in Google Play for Android device.

2. Usage
First Login after Setup
When user login to Salesforce.com for the first time, after permission granted, user need to enter two-word phrase.

Open the Authenticator app in your smart phone, then tap + New Account, enter the phrase shown in the app to Salesforce connect page, then click Connect button. Then you also tap Connect button in the app. Salesforce will email you that new verification method was added to your account.

Once verified, admin or user can check in the user detail page, link next to App Registration: Salesforce Authenticator has changed from Connect to Disconnect.

If you have access to multiple login, the mobile app can handle multiple login with the same device, you can swipe the account to left to delete it.

Normal Login
After successful enter username and password, user will be present with a screen that tell user need to use Authenticator app from user phone to approve login to Salesforce.

Tap Approve button in phone app to continue, once approved this will auto let you login to Salesforce.com

In Summary:
1. Open Salesforce.com from login.salesforce.com (or your custom my domain)
2. Enter username and password, then Log In
3. Approve from your device with Authenticator app

Note:

• after enter username and password successfully, Salesforce will challenge for approval from device, in the login history this step will show with "two-factor required".
• after approve from device, login history will show "Success".

• Salesforce will wait for 90 seconds, otherwise it will tell you "We canceled your request because we didn't receive your approval within 90 seconds".
• For some reason if you can't approve from the device, you can change the verification method by using code from Authenticator app.

3. Recovery
Let's say user delete the Authenticator app incidentally, or have issue with the mobile phone, or lost his mobile phone.

In Salesforce
Only user with Manage User permission, go to user detail and look for App Registration: One-Time Password Generator, then click Disconnect link, this will delete Disconnect link. User need to re-register from Authenticator app when login to Salesforce.com

In mobile phone
Re-install the Authenticator app, and re-do registration process again as above. As admin, you will notice the Disconnect link re-appear again in user detail, after user successfully re-register his device.


Last update: 28 Feb 2017 with Spring '17 release and using Salesforce Authenticator app version 2.8.0 on iOS.


Reference:

• Set Two-Factor Authentication Login Requirements
• Enhancing Security with Two Factor Authentication

Salesforce Login Security

Without SSO (Single Sign On), login from Salesforce only required username and password (username need to be in the format of email address, but may different with email address). But Salesforce give additional security when user login that many admins not aware .

IP Ranges
There are 2 type of IP ranges we can define in Salesforce:

1. Login IP Ranges Restriction in Profile 

When IP ranges is added to profile, user assigned with that profile login NOT from defined IP ranges will be denied. User will see standard error message: Your login attempt has failed. The username or password may be incorrect, or your location or login time may be restricted. Please contact the administrator at your company for help.

But admin will notice it in login history with Status = Restricted IP

Note: even if user IP address is in the range of Trusted IP Address (see point 2. below) but not in Login IP ranges (if defined), user still will not able to login and get the same error message.


2. Trusted IP Ranges in Network Access
This setting will be apply to all users. Users logging in from trusted IP addresses are not asked to activate their computers. User just need to enter their password without additional security token to log in to the API or a desktop client such as Connect for Outlook, Connect Offline, Connect for Office, Connect for Lotus Notes, or the Data Loader.

Here is schema copy from Salesforce on the login process to Salesforce.com:

Identity Verification
If you see above diagram, Salesforce will verify the user if never login from an IP address and not in trusted ranges. This additional verification is enhance security on login process. There are 2 methods of verification:

1. SMS
This feature is turned on by default. You can find this in Setup | Security Controls | Session Settings, look for Enable the SMS method of identity confirmation in Identity Confirmation section. To deactivate this, you need to contact Salesforce support.

If admin do not enter mobile number when create the user account, when user login to Salesforce for the 2nd time (the 1st login will ask to change password), they will be asked to enter mobile number. But, user can opt-out from this feature, by click No thanks.

If user click Remind me later, user will be asked to enter mobile number again.


2. Email
For user opt-out from SMS, they will receive the pass code in email for identity verification.


You also can limit all access to Salesforce to only to those IPs in Login IP Ranges. For example, a user logs in successfully from an IP address defined in Login IP Ranges. The user then moves to a different location and has a new IP address that is outside of Login IP Ranges. When the user tries to access Salesforce, including access from a client application, the user is denied. To enable this option, navigate to Setup | Security Controls | Session Settings and select Enforce login IP ranges on every request. This option affects all user profiles that have login IP restrictions.


Reference:

• Using Login IP Ranges for Stronger User Security
• Restrict Login IP Addresses in the Original Profile User Interface