Narrow Search

Can't find what you need?
Contact Us

Reset Search
    Search Knowledge Base

Restrict Logins

« Go Back


Previous: Outlook Integration Overview

Setting Login Restrictions

To help protect your organization's data against unauthorized access, you have several options for setting login restrictions.

Login Hours

For each profile, you can specify the hours when users can log in.

  1. From Setup, click Manage Users | Profiles.
  2. Select a profile and click its name.
  3. In the profile overview page, scroll down to Login Hours and click Edit.
  4. Set the days and hours when users with this profile can log in to the organization.

To allow users to log in at any time, click Clear all times. To prohibit users from using the system on a specific day, set the start and end times to the same value. If users are logged in when their login hours end, they can continue to view their current page, but they can't take any further action.

The first time login hours are set for a profile, the hours are based on the organization's Default Time Zone as specified in Setup at Company Profile | Company Information. After that, any changes to the organization's Default Time Zone won't change the timezone for the profile's login hours. As a result, the login hours are always applied at those exact times even if a user is in a different time zone or if the organization's default time zone is changed.

Depending on whether you're viewing or editing login hours, the hours may appear differently. On the Login Hours edit page, hours are shown in your specified time zone. On the profile overview page, they appear in the organization's original default time zone.

Login IP Address Ranges

You can control login access on a user's profile by specifying a range of IP addresses. When you define IP address restrictions for a profile, any login from a restricted IP address is denied.

  1. From Setup, click Manage Users | Profiles.
  2. Select a profile and click its name.
  3. In the profile overview page, click Login IP Ranges.
  4. Use any of these methods to change login IP address ranges for the profile.
    • If you want to add ranges, click Add IP Ranges. Enter a valid IP address in the IP Start Address and a higher IP address in the IP End Address field. The start and end addresses define the range of allowable IP addresses from which users can log in. To allow logins from a single IP address, enter the same address in both fields. For example, to allow logins from only, enter as both the start and end addresses.
    • If you want to edit or remove ranges, click Edit or Delete for that range.

Both IP addresses in a range must be either IPv4 or IPv6. In ranges, IPv4 addresses exist in the IPv4-mapped IPv6 address space::ffff:0:0 to ::ffff:ffff:ffff, where ::ffff:0:0 is and ::ffff:ffff:ffff is255.255.255.255. A range can't include IP addresses inside of the IPv4-mapped IPv6 address space if it also includes IP addresses outside of the IPv4-mapped IPv6 address space. Ranges such as to ::1:0:0:0 or :: to::1:0:0:0 are not allowed. You can set up IPv6 addresses in all organizations, but IPv6 is only enabled for login in sandbox organizations from the Spring '12 release and later.

Organization-Wide Trusted IP Address List

For all users, you can set a list of IP address ranges from which they can always log in without receiving a login challenge. See Restricting Login IP Ranges for Your Organization.
When users log in to Apto, either via the user interface, the API, or a desktop client such as Connect for Outlook,Salesforce for Outlook, Connect Offline, Connect for Office, Connect for Lotus Notes, or the Data Loader, Apto confirms that the login is authorized as follows:

  1. Apto checks whether the user's profile has login hour restrictions. If login hour restrictions are specified for the user's profile, any login outside the specified hours is denied.
  2. If the user has the "Two-Factor Authentication for User Interface Logins" permission, Apto prompts the user for a time-based token (which the user may also be prompted to create if it hasn't already been added to the account) upon logging in.
  3. If the user has the "Two-Factor Authentication for API Logins" permission and a time-based token has been added to the account, Apto returns an error if a time-based token is not used to access the service in place of the standard security token.
  4. Apto then checks whether the user's profile has IP address restrictions. If IP address restrictions are defined for the user's profile, any login from an undesignated IP address is denied, and any login from a specified IP address is allowed.
  5. If profile-based IP address restrictions are not set, Apto checks whether the user is logging in from an IP address they have not used to access Apto before:
    • If the user's login is from a browser that includes a Apto cookie, the login is allowed. The browser will have the Apto cookie if the user has previously used that browser to log in to Apto, and has not cleared the browser cookies.
    • If the user's login is from an IP address in your organization's trusted IP address list, the login is allowed.
    • If the user's login is from neither a trusted IP address nor a browser with a Apto cookie, the login is blocked.

Whenever a login is blocked or returns an API login fault, Apto must verify the user's identity:

  • For access via the user interface, the user is prompted to enter a token (also called a verification code) to confirm the user's identity.


  • Users aren't asked for a verification code the first time they log in to Apto.
  • For access via the API or a client, users must add their security token (or time-based token if Two-Factor Authentication on API Logins is set on the user's profile and the user has added a time-based token to his or her account) to the end of their password in order to log in.

A security token is an automatically-generated key from Apto. For example, if a user's password is mypassword, and the security token is XXXXXXXXXX, then the user must enter mypasswordXXXXXXXXXX to log in.

Users can obtain their security token by changing their password or resetting their security token via the Apto user interface. When a user changes their password or resets their security token, Apto sends a new security token to the email address on the user's Apto record. The security token is valid until a user resets their security token, changes their password, or has their password reset.


  • We recommend that you obtain your security token using the Apto user interface from a trusted network prior to attempting to access Apto from a new IP address.

Tips on Setting Login Restrictions

Consider the following when setting login restrictions:

  • When a user's password is changed, the security token is automatically reset. The user may experience a blocked login until he or she adds the automatically-generated security token to the end of his or her password when logging in to Apto via the API or a client.
  • Partner Portal and Customer Portal users aren't required to activate computers to log in.
  • For more information on API login faults, see the Core Data Types Used in API Calls topic in the SOAP API Developer's Guide.
  • If single sign-on is enabled for your organization, API and desktop client users can't log into Apto unless their IP address is included on your organization's list of trusted IP addresses or on their profile, if their profile has IP address restrictions set. Furthermore, the single sign-on authority usually handles login lockout policies for users with the "Is Single Sign-On Enabled" permission. However, if the security token is enabled for your organization, then your organization's login lockout settings determine the number of times a user can attempt to log in with an invalid security token before being locked out of Apto.
  • These events count toward the number of times a user can attempt to log in with an invalid password before being locked out of Apto, as defined in your organization's login lockout settings:
    • Each time a user is prompted to confirm his or her identity (when a user clicks Email me a verification code for example)
    • Each time a user incorrectly adds the security token or time-based token to the end of their password to log into the API or a client

Next: Determine Object Access



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255