Let the platform do the work

Password Management

Overview

Password Management is used to administer requirements and other policies about user passwords in Sugar. Sugar allows administrators to set up the password requirements, manage the forgot password feature, configure the email template for resetting passwords, etc. Password management is not used to change users' passwords.

Note: For instances that use SugarIdentity, an administrator will need to access SugarIdentity to configure password requirements as well as set up LDAP or SAML authentication. 

Password Requirements

The Password Requirements panel lets you configure minimum and maximum lengths of passwords, as well as what characters are required in passwords. Filling in either of the first two fields, Minimum Length and Maximum Length, will force a requirement for your users to have passwords be more than or less than a given amount of characters. Additionally, use any of the four checkboxes to force character requirements on users' passwords. This can force users to include upper case letters, lower case letters, numbers, or special characters in their passwords. Please note that the configured password requirements also apply to the Sugar Portal and must be respected when the portal user's password is created or changed.

Note: For instances that use SugarIdentity, password requirements are configured in SugarIdentity.

Advanced Options

You can also specify words or other strings that are not allowed in a password, called Regex Requirements. The configurations for Regex Requirements are found in the Advanced Options section of the Password Requirements panel.

Note: For instances that use SugarIdentity, regex password controls are not available.

To set a Regex Requirement, type in code of characters that are not allowed. In the Regex Description field, write a message to users that will show when they try to edit their passwords, explaining what strings are not allowed. For more information on Regex usage, please review the Regular Expressions website at http://www.regular-expressions.info/.

Some examples of regular expressions in password rules are listed below:

Sample Expression Password Rule
Sugar Password cannot contain the word Sugar.
([A-Za-z0-9])\1 Password cannot repeat a letter or number consecutively; for example, AA or 88.
([a-zA-Z]){4,} Password cannot repeat any two consecutive letters; repeat characters or letters must be separated by a special character such as %.
[ \t] Password cannot contain spaces and tabs.
[@#$] Password cannot contain @, #, or $.

User Reset Password

The forgot password feature allows administrators to enable the Forgot Password link to display in the Sugar login window. If a user does not remember their password, they can click this option, enter their user name and their primary email address in Sugar, and a Reset Password link will be emailed, guiding them through the process to reset their forgotten password. For more information on how a user resets his or her password, please view the Getting Started documentation.

Note: For instances that use SugarIdentity, the "Forgot Password?" link is available on the Sugar login screen, but the feature cannot be configured.

The two requirements to utilize Forgot Password feature are:

  • A user has a valid primary email address configured in their User Profile.
  • A system outbound email server (SMTP) is configured in Email Settings.

Administrators have the option to reset user's passwords as well. This can be done with or without SugarIdentity. For more information on resetting a user's password, please review the Resetting User Passwords section of the Users documentation.

Honeypot Validations

Honeypots are a non-intrusive method of human form submission confirmation that is more effective than traditional CAPTCHA. Enabling the honeypot validation option will add an invisible input field to the Forgot Password form which only bots reading the HTML will be able to see. When the bots fill in the honeypot field, Sugar knows to disregard the submission since it was not created by a human, thus preventing unauthorized access to your Sugar instance.

Note: For Sugar instances that use SugarIdentity, Honeypot validation is not available.
PasswordMgmt HoneypotValidations

Email Templates

The reset password email template is available under the Email Templates section, and you can click the Edit button to modify the template. Click the Create button instead if you wish to create a new version of the template.

Note: For instances that use SugarIdentity, the option to create/edit email templates is not available.
PasswordMgmt EmailTemplates

The reset password email template is also available to access in the Email Templates list view by navigating to the Emails module. For more information on Email Templates, refer to the Emails documentation of the Application Guide.

Note: When creating a new version of the reset password email template, be sure to copy the variable "$contact_user_link_guid" from the default Forgot Password Email template as it is not available to select from the variable dropdowns.

User-Generated Password Expiration

Sugar can force users to create new passwords after a given period. Admins can configure this for either specific amounts of time in days, weeks, or months, or after a specific amount of logins. To configure a password expiration, select the radio button next to the expiration period you would like to use and enter the timeframe or amount of logins that the user will be allotted. Once the password expiration is reached, users will see a message upon login, informing them that their password has expired and to create a new password. The user will need to enter their current password along with their new password and confirm the password as well.

Note: For instances that use SugarIdentity, password expiration rules are configured in SugarIdentity
pword-expire

Login Lockout

To prevent unauthorized logins, Sugar includes a configurable lockout function. This means that you will define a specific amount of unsuccessful attempts that a user name can be used to log in before the user name will not be able to log in. You also configure a given amount of time before the restriction is listed in either minutes, hours, or days. To configure Login Lockout, click the radio button next to "Lockout users after {blank} unsuccessful login attempts", fill in the maximum number of attempts allowed and define the timeframe.

Note: For instances that use SugarIdentity, login lockout rules are configured in SugarIdentity
login-lockout-77

Note: When a user has been locked out, the user must wait until the given timeframe has passed. The only way to manually allow a user to log back in is by clicking the Reset User Preferences button in the user's profile.

External Authentication

Sugar can respect external authentication protocols (i.e., LDAP and SAML) to give users a seamless login process via single sign-on (SSO) services. LDAP and SAML configuration options are located in the last two panels of the Password Management page. Click the checkbox next to the external authentication type that you would like to enable. Upon selection, the page's contents will refresh and the chosen protocol will supersede any other Password Management settings.

Note: For instances that use SugarIdentity, LDAP and SAML authentication are configured in SugarIdentity.

Note: If a user logs out of their single sign-on account from outside of Sugar, they will continue to be logged into Sugar.
enable-ldap-saml

The following sections explain LDAP and SAML options in more detail.

Note: Team Management and Role Management are still taken into account when External Authentication is active.

LDAP

Sugar can be configured to accept Lightweight Directory Access Protocol (LDAP) authentication if your organization has implemented LDAP or Active Directory authentication. When users in your system attempt to log into Sugar, the application will authenticate their credentials against your LDAP directory or Active Directory. If authentication is successful, the user is granted access to Sugar. If the authentication is unsuccessful, Sugar will then attempt to verify the provided credentials against its own database of valid user names and passwords.

Before proceeding with the configuration steps, you must first add a user to your Active Directory account for the purpose of authenticating from Sugar to Active Directory to read the LDAP. Make this user a managed service account (MSA) with read-only access to Active Directory. For more information on creating an MSA, please refer to the Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting article on Microsoft's support site. For more information on configuring the Active Directory, please refer to the Microsoft's support site.

Use the following steps to configure LDAP authentication for instances that do not use SugarIdentity:
Note: For instances that use SugarIdentity, configure the LDAP authentication in SugarIdentity.

  1. Navigate to Admin > Password Management and enable the checkbox next to "Enable LDAP Authentication" in the LDAP Support section. 
  2. Complete the fields with information specific to your LDAP or Active Directory account. 
    PW MGMT LDAP Encryption
  3. Click "Save".

Once you have completed the form, you will then need to enable LDAP for users by navigating to Admin > User Management, selecting the desired user, then clicking the Advanced tab in their user profile. Enable the "LDAP Authentication Only" checkbox, then click "Save". Sugar will synchronize the user's Active Directory user name and present the password on the LDAP port. When the user next logs in to Sugar, they will enter their Active Directory username and password.

If the Active Directory authentication server is behind a corporate firewall and your instance of Sugar is hosted in our cloud environment, then refer to the Configuring Your SMTP Server to Work With SugarCloud article to ensure the appropriate IP range is open on your firewall to allow communication with the Active Directory server. A rule will need to be created allowing the LDAP bi-directional communication for the necessary IP range. This can be the standard LDAP port 389 or you can use LDAP over SSL.

LDAP Fields

Fill in the appropriate options in the following fields, and then click "Save" to commit the changes. The following are suggested values for each field, but these may vary depending on your LDAP configuration.

Field Description Suggested Values
Authentication

Check this box to enable the User Name and Password fields.
Note: You must add a service account user (read-only access) to your Active Directory to authenticate via Sugar.

Enter "username@MYSERVER.MYDOMAIN.com" or "domain\\userfirstname.userlastname" for the User Name, and the corresponding Password.
Note: The latter username format requires double backslashes after the domain. Sugar will automatically remove one backslash upon Save.

Auto Create Users

Select this checkbox to create the username in the Sugar database if it does not already exist.
Note: When enabled, a Sugar user is created for every LDAP user logging into the application for the first time. This will occupy an active Sugar license for each created user. Keep this option disabled if you do not wish to create AD users in Sugar.

Typically, this box remains disabled. 
Bind Attribute This is what is used for the Active Directory and is a case-sensitive value. For Active Directory, enter userPrincipalName
Enable LDAP Authentication Uncheck this box if you would like to disable LDAP in your instance.  
Encryption

Select the appropriate option from the dropdown to use StartTLS, LDAPS, or no encryption when connecting to the LDAP server.

  • Select "StartTLS" or "LDAPS" if the LDAP server supports it.
  • Select "none" for no encryption.
Encryption Key

If you are using LDAP with SOAP, enter the encryption key to encrypt user passwords in the Sugar Plug-in for Microsoft Outlook.
Note: The "php_mcrypt" extension must be enabled in the php.ini file.

 
Group Membership

Select this checkbox if you wish to specify that the user is a member of a specific group. 

Group DN: Enter the group DN name.

  • ou=groups
  • dc=example
  • dc=com

Group Name: Enter the group name.

  • cn=sugarcrm

User Attribute: A unique identifier used to check if the user is a member of the group.

  • uid

Group Attribute: The attribute of the group that will be used to filter against the User Attribute.

  • MemberUid
Login Attribute This is what is used for the Active Directory and is case-sensitive. For Active Directory, enter sAMAccountName.
Port Number

Enter the default port number. 

Please refer to the Configuring IP Addresses, Ports and Domains article for port numbers.

Server

Enter the FQDN of your Active Directory Server which should be your Domain Controller.

 

Enter MYSERVER.MYDOMAIN.com.
User DN

Enter the user DN name.
Note: The OU can be called anything you want or any OU that has the users you want to be in your Sugar instance. Please confirm the group is an OU and not a CN. If CN, you can use the designator CN=Users for example.

Enter ou=people, dc=example, dc=com.
User Filter

Enter any additional parameters to apply when authenticating users.

Enter is_user_id=1

SAML

Sugar can be configured to accept Security Assertion Markup Language (SAML) for single sign-on if it is implemented at your organization. When users in your system attempt to log in to Sugar, the application will authenticate them against SAML. If authentication is successful, the user is granted access to Sugar. If the authentication is unsuccessful, Sugar will then attempt to verify the provided credentials against its own database of valid user names and passwords. Sugar supports the use of SAML version 2.0.

Note: For instances that use SugarIdentity, SAML is configured in SugarIdentity.

Use the following steps to configure SAML authentication in Sugar:

  1. Navigate to Admin > Password Management, and place a check in the "Enable SAML Authentication" box in the SAML Authentication panel. 
  2. Enter appropriate values in the fields on the SAML Authentication page. If you have downloaded a metadata file from the identity provider (e.g., Okta, Google, ADFS), then skip to step 3.
    PWMgmt SAMLAuthenticationPage
  3. If you have obtained a metadata file from the identity provider (e.g., Okta, Google, ADFS), then you can import the file by clicking the "Import IdP Metadata File" button. Locate the metadata file you saved then click "Open". Certain fields (e.g., Login URL, SLO URL, Entity ID, X509 Certificate) on the page will be auto-populated with data from the file. Optionally, complete any other desired fields on the configuration page based on your needs.
    Note: If you are using Okta with single logout enabled, then you will need to complete the "Sign Logout Request", Request Signing Private Key", and "Request Signing Certificate" fields in order to digitally sign the logout request. 
  4. Once the necessary fields have been completed, click "Save" to preserve the settings. 

When using ADFS, you will need to export an XML metadata file containing the SAML settings which you will need in order to configure a new trust relationship between Sugar and ADFS to allow communication between the two services. Simply click the "Export Metadata File" button to download the necessary file. Please note that you will only be able to export a file if the required fields have been completed and saved. Once you have the metadata file, follow the steps in the Configuring SSO With Active Directory's ADFS article to configure a new ADFS trust relationship. 

Please refer to the SAML-Toolkits example for more information on how to configure advanced SAML connections.

SAML Fields

The available fields to configure on the SAML Authentication page are as follows:

Field Description
Enable SAML Authentication Uncheck this box if you would like to disable SAML Authentication in your instance. 
Login URL Enter the SAML URL for authentication.
Note: This is the path to the SAML server to which you are authenticating. 
SLO URL Enter the single logout endpoint to which Sugar will send logout requests. When Sugar sends a logout request to the identity provider (e.g., Okta), it will extend that request and terminate active sessions for all other service providers that are sharing the session established via SAML.
Note: Single logout requests can be initiated from either the identity provider or Sugar. 
Entity ID Enter a valid URI for the IdP (identity provider) entity.
Note: Sugar will only accept SAML assertions from this ID. 
SugarCRM Entity ID Enter a valid URI for the service provider entity. 
X509 Certificate Enter the SAML X509 certificate public key. 
Auto-create user Check this box to automatically create a new username in the Sugar database if it does not already exist. When enabled, a new Sugar user is created for every SAML user logging into the application. 
Note: This will occupy an active Sugar license for each created user.
Load login screen in same window to avoid pop-up blocking Enable this option to load the SAML login screen in the current window to prevent pop-up blockers from preventing single sign-on. 
Request Signing Private Key Upload the PEM file containing the private key to be used to sign the AuthN and Logout requests.
Note: The private key must be uploaded in order to sign the logout request, logout response, and/or AuthN request.
Request Signing Certificate Upload the CRT file containing the X.509 certificate to be used to sign the AuthN and Logout requests.
Note: The certificate should match the uploaded private key. 
Request Signing method Select the digital signing method for the logout request, logout response, and/or AuthN request. The recommended options are either "RSA-SHA256" or "RSA-SHA512". 
Sign AuthN Request Check the box to sign the AuthN request using the private key and certificate.  
Note: The "Request Signing Private Key", "Request Signing Certificate", and "Request Signing method" fields must be completed in order to sign the AuthN request.
Sign Logout Request Check this box to sign the logout request using the private key and certificate.
Note: The "Request Signing Private Key", "Request Signing Certificate", and "Request Signing method" fields must be completed in order to sign the logout request.
Sign Logout Response Check this box to sign the logout response using the private key and certificate. 
Note: The "Request Signing Private Key", "Request Signing Certificate", and "Request Signing method" fields must be completed in order to sign the logout response.

If you are using OneLogin, please ensure that only the email address user field is mapped to Sugar's email address field in OneLogin's parameters configuration. Mapping to other fields such as user name is not supported and may prevent authentication.

Note: You must disable the Forgot Password option if you are using SAML authentication.