Okta : Password Sync Agent Requirements

For Secure Web Applications (SWA) which leverage AD Passwords and in turn SWA Apps in Okta store the username and password, we can leverage Password Sync Agent to make sure that AD passwords changed outside of Okta are pushed to the SWA Apps within Okta, so that no manual updates are needed.

Requirements for Password Sync Agent (PSA)

• The org must be AD-mastered.
• The Active Directory Agent must be installed and configured on at least one domain controller in each domain in your forest.
• The Active Directory Password Sync Agent must be installed and configured on all domain controllers in each domain in your forest.
• Delegated Authentication must be enabled.
• Okta username format must be UPN
•  If Inbound SAML is set up, PSA will not work

More requirements here

https://support.okta.com/help/Documentation/Knowledge_Article/Password-Synchronization-Overview#PasswordSyncAgent

This will push AD Passwords to the provisioning-enabled SWA App during initial setup or whenever password changes. The Okta AD Password Sync Agent automatically pushes users' AD passwords from your Domain Controllers to the Okta service.

Passwords are synced from your Domain Controller to Okta whenever a user's password is changed. The agent must be installed on all Domain Controllers and Delegated Authentication must be enabled on your Okta organization.

Other useful Links

https://support.okta.com/help/Documentation/Knowledge_Article/Using-Password-Sync-410642235

https://support.okta.com/help/Documentation/Knowledge_Article/Password-Synchronization-Overview

Okta Session : How to Set Maximum Session Timeout using APIs

Quite often, an application developer would need a maximum time after which a session should be destroyed irrespective of activity. This is also called the Maximum Session Timeout.

Okta is a popular cloud based Identity and Access Management Platform used as an Identity Provider enabling secure and seamless access to all applications via any device.

As of today, there’s NO setting in the Okta UI to set Maximum Session Time. 

The Session Lifetime setting in the Okta GUI is for Maximum Idle Session Time.

However, there’s an option to do this via APIs using SignOn Policy APIs. 

We can create Policies via APIs or from GUI .. Admin -> Security -> Authentication -> SignOn Policies-> Create Policy -> Create Rules and then update the maxSessionTimeoutInMinutes using API calls as shown in the screenshot.

If you are unaware of how to get started with Okta APIs and/or to setup Postman, please check this link.

Okta SAML SSO with Zoom : Error 1021 : You are not entitled to meeting service

Use Case : Setup SAML based SSO for Zoom using Okta as the IDP

Documents referred :

https://support.zoom.us/hc/en-us/articles/115005719946-Configuring-Okta-with-Zoom

Pre-requisites :

• Zoom owner or admin privileges

• Business or Education account with approved Vanity URL

• Okta admin privileges

Note :

Zoom is a Big Bang App (account needs to exist in SAML IDP) when using the vanity URL
A backdoor URL can be used : https://zoom.us/signin where users can login with their username and password

Issue : When doing SP-init (using vanity URL) or doing IDP-init (using Okta chiclet), we get the following error -

Troubleshooting Steps :

• Checked SAML response was valid using SAML Tracer in Firefox
• No errors in Okta Logs
• Verified that Username being passed in SAML assertion from Okta to Zoom existed in Zoom
• Created a custom SAML template App in Okta instead of using the App in Okta Integration Network (OIN) 

Solution :

Issue was in the Zoom SSO Configuration.

We need to change the "Default user type:" from None to either Basic or Pro on the SSO configuration page (SAML Response mapping). The SSO service is currently passing the user over but since "None" was selected, it was not assigning a user type and resulted in them not being authorized