The Delegated AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. page provides a variety of directory and authentication management options. There are options for Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management., and LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services.. Select the option to set up from the list at the top of the screen.
Important: If you do not already have an Active Directory (AD) integration, you can click Configure Active Directory to go to Directory Integrations and install and configure the Okta AD agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations..
Delegated authentication makes your users' Okta credentials the same as their AD credentials. Enable it if you want Active Directory (AD) to authenticate your users when they sign into Okta.
Instance-level Delegated Authentication
This feature moves delegated authentication (Del Auth) enablement from the orgThe Okta container that represents a real-world organization.-level to the instance-level. While preserving current Del Auth functionality, instance-level Del Auth is optimized for use in environments with multiple AD instances. It allows admins to delegate authentication on a per AD-instance level to support more granular authentication scenarios such as the following:
- Configure Okta to be the authentication master for users in some AD instances.
- Configure AD to be the authentication master for users in the remaining AD instances (meaning users log in using their Windows credentials).
Continue to rely on Okta to provision to all AD instances.
Once Instance-Level Del Auth is enabled by Okta Support, you can configure it in Directory > Directory Integrations > Active Directory > Settings. Your former org-level delegated authentication settings are preserved but no longer managed from Security > Authentication > Active Directory.
Enabling Desktop Single Sign-On (SSO)
You can configure your Desktop SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. mode, failover settings, and Integrated Web Authentication (IWA) web applications in this section. Desktop SSO allows users to be automatically authenticated by Okta, and any apps accessed through Okta, whenever they sign into your Windows network. Okta's IWA Web AppAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. uses Microsoft's IWA and ASP.NET to authenticate users from specified gateway IPs. For installation and configuration procedures, see Okta IWA Web App for Desktop SSO.
Important: Before you can configure LDAP delegated authentication, you must install and configure the Okta LDAP agent.
Enabling Delegated Authentication (LDAP)
Delegated authentication makes your users' Okta credentials the same as their LDAP credentials. Enable it if you want LDAP to authenticate your users when they sign into Okta.
- In Delegated Authentication, click Edit.
- Select Enable delegated authentication to LDAP.
- Click Save.
Allowing end users to change or reset their LDAP passwords in Okta
You can allow your end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. to change their LDAP passwords in Okta. When end users' passwords expire, they are prompted to change them the next time they attempt to sign into Okta.
End users can change their passwords from their Home page by clicking the drop down menu by their name, then Settings > Account > Change Password.
- In Delegated Authentication, click Edit.
- Make sure that Enable delegated authentication to LDAP is selected.
- Under LDAP Password Policy, select Users can change their LDAP passwords in Okta.
- In the Password Rules Message field, describe the password policy rules that your end users must follow when changing their passwords.
- Select Users can reset forgotten LDAP passwords in Okta.
- Click Save.
Note: This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature; contact Okta Support to enable it. It requires Okta Java LDAP Agent version 5.3.0 or later. This feature works with any LDAP distribution that correctly sets the pwdReset attribute to TRUE when a password is expired (for example, OpenLDAP and IBM)5.3.0. Make sure to uninstall any pre-5.3.0 versions of the agent before you install version 5.3.0 or higher. For agent installation and uninstallation instructions, see Installing and Configuring the LDAP Agent.
End User Password Reset
Select Users can reset forgotten LDAP passwords in Okta to allow your end users to reset forgotten LDAP passwords. When you create or import and activate new users, they are prompted for a secondary email address on their Welcome page. After end users enter an address, they receive a confirmation email asking them to verify the change.
If end users forget their passwords, or their LDAP account gets locked from too many failed sign in attempts, they can click the Forgot password? link on the Okta Sign On page to reset the password using email or SMS.
- Reset via email: End users enter their username or email address and then click the Send Email button. Users then receive an account password reset email that expires in 24 hours. This resets both the user’s Okta and LDAP passwords. For users who click the Forgot password? link because an account was locked, this changes their LDAP password and unlocks their account.
- Reset via SMS: End users enter their username or email address and then click the Send Text Message button. This prompts a text message containing a password reset code. Once received, users enter the code from their phone and continue through the prompts to reset their passwords.
Create a Password Rules Message
Optionally select the Password Rules Message check box and enter a description for your password policy that appears when end users change or reset their LDAP passwords. For example, the default message, Minimum eight characters including one numeral and one special character.
The System Log includes information about the duration of each Delegated Authentication (Del Auth) request to help admins identify bottlenecks in the Active Directory (AD) Del Auth pipeline. The Del Auth System Log events now include times in milliseconds for:
- delAuthTimeTotal: The total time spent for Del Auth in Okta. This time consists of the total time at the agent and the queue wait time in Okta before an agent starts processing the request. The queue wait times can be high if there are not enough agents to serve requests.
- delAuthTimeSpentAtAgent: The total time the agent spent processing the request. This includes the time spent at the DomainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). Controller.
- delAuthTimeSpentAtDomainController: The time spent at the Domain Controller.
Note: You must be using AD agent version 3.1.0 or higher to use this feature.
JIT ProvisioningWith Just-in-Time provisioning, you can use a SAML assertion to create regular and portal users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance. For example, if you recently added an employee to your organization, you don't need to manually create the user in Salesforce. When they log in with single sign-on, their account is automatically created for them, eliminating the time and effort with on-boarding the account. Just-in-Time provisioning works with your SAML identity provider to pass the correct user information to Salesforce in a SAML 2.0 assertion. You can both create and modify accounts this way. Because Just-in-Time provisioning uses SAML to communicate, your organization must have SAML-based single sign-on enabled.
For details about JIT with
Active Directory and LDAP, see JIT Provisioning.
Desktop SSO, see the Customization page.Top