The Basics

Community has four login methods:

1. Application login
2. Windows login
3. Third party passthrough
4. Single sign on (SSO)

Application Login

Application Login is the default login method for Community and is the most popular option.

The login page uses a username & password combination that is stored in the Community3 Database.

How is it interfaced?

0 – Digit in Authentication Mode in the “t_almanac_params” table

• User IDs are located in the “login_id” field in t_agent table
• Can use either a text login ID or a text email address
• Verifies the login ID against the t_agent table, resolves the password, and serves the agent profile

How do we troubleshoot?

• Username and Password used with Application Login works with Community Android/IOS Apps (if licensed).
• Password resets can be done by those with accounts at the same privilege level or above.
• Recommended password reset process:
  1. Navigate to the agent profile
  2. Click “Generate password”
  3. Copy & paste the password into the “Confirm password” field
  4. Click “Save”
  5. Verify the new credentials by logging in
  6. Send the new credentials to the user

Windows Active Directory Login

• Windows Active Directory Login (or “Windows Login”), is a method most popular with On-Prem customers.
• 1 – Authentication Mode
• Instead of the request being processed by Community, a login request is passed through the Active Directory server for the agents' Windows profile and is then matched in the t_agent table.

• Logins use a specific format:
  • Domain\User
    • Community\jturner
• The User ID needs to match in the login_id field in the t_agent table.

How do we Troubleshoot?

• Check the login ID and Agent Profile.
  • User credentials can be found by using “whoami” command in the command prompt of the client PC.
  • Check Agent Profile Employment
  • Make sure the agent is “Active” and not “Inactive”
• If confirmed that it’s the same login, check for leading or trailing spaces.
• If that does not work, Send a request to the customer for a meeting, cc Community Support.
  • The meeting should involve the support agent, support supervisor, Community Support, and Community Systems Engineer.

Third Party Passthrough

• Community is wrapped and served inside another web page.
• Most common occurrence is Five9/CSI with their Virtual Observer Suite.
  • Five9 manages the user accounts and passwords.

• 2 - Authentication Mode
• Authentication is handled by Five9/CSI profiles
• Matches the User ID in Virtual Observer and Community to serve the Agent Profile
• Community is wrapped in the Virtual Observer window
• Community is inaccessible through the normal /communityweb/ extension
  • It uses the extension /VirtualObserver/vo.voml?

How do we Troubleshoot?

• Check URL extensions if you can’t access a site.

• Try changing the URL from /communityweb/ to /virtualobserver/vo.voml? to see if the page will resolve.
• Confirm that there is a Virtual Observer Profile for the specific agent (e.g., tcotharin).

• Confirm that there is a Community Profile for the specific agent (e.g., tcotharin).

• Confirm that the User ID is the same between the two profiles.
• When all accounts match in Virtual Observer and Community you will see a profile served like this:

• If that does not work, send a request to the customer for a meeting, cc Community Support.
  • The meeting should involve the support agent, support supervisor, Community Support, and Community Systems Engineer.

Single Sign-on

SSO Login allows for one login and passthrough for all programs.

Authentication is handled by an SSO provider like Azure (Microsoft), Okta, OneLogin, or JumpCloud.

When a site uses SSO login, the webpage will redirect from the homepage to the SSO login page.

• We are not provided with an SSO account by the customer.
• The site uses an attribute that is determined by the customer.
• Most common practice is to use email address for the attribute.

How do we Troubleshoot?

• Community does not pull down accounts from SSO providers.
• Create Agent accounts in Community first and then setup in the SSO.
• Populate the user login entry in the Agent profile with the unique attribute.
  • E.g., username@communitywfm.com
• Confirm that it matches the email address in the SSO profile.

[/SAML/consumer.aspx] SAML consumer called at 4/29/2022 2:42:39 PM.

[/SAML/consumer.aspx] Attempting to read Community's SAML configuration...

[/SAML/consumer.aspx] Community's SAML configuration was successfully read.

[/SAML/consumer.aspx] HTTP POST binding detected.

[/SAML/consumer.aspx] POST data successfully read. (Length: 7103)

[/SAML/consumer.aspx] SAMLResponse was successfully read. (Length: 7012)

[/SAML/consumer.aspx] Decode was successful.

[/SAML/consumer.aspx] Creating Response object...

[/SAML/consumer.aspx] Response object created.

[/SAML/consumer.aspx] StatusCode evaluation...<PASS>

[/SAML/consumer.aspx] IssueInstant evaluation...<PASS>

[/SAML/consumer.aspx] Reading Community username from attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress...

[/SAML/consumer.aspx] Username = reyesl@nsmg.com

[/SAML/consumer.aspx] X.509 Certificate evaluation...<PASS>

[/SAML/consumer.aspx] Issuer evaluation...<PASS>

[/SAML/consumer.aspx] Authentication failed...user 'reyesl@nsmg.com' was not found in Community.

Using this login we find:

• Ask: Is the issue with all agents or only some agents?
  • If all agents: suggests a problem with the SSO settings and configuration.
    • Contact customer’s SSO engineers to diagnosis the issue.
  • If only some agents: suggests a problem with the individual agent profiles.
• If that does not work, send a request to the customer for a meeting, cc Community Support.
• The meeting should involve the support agent, customer’s SSO engineer, affected customer agent, & Community Systems Engineer.