1. For troubleshooting purposes, you might have to enable additional verbose logging for Virtual Services using ESP/SSO.

 To enable SSOMGR Debug Traces, navigate to:

System Configuration > Logging Options > System Log Files > Debug Options > Enable SSOMGR Debug Traces

• Click Enable Traces

Figure 1.1 - Enable SSOMGR Debug Traces

 

To view the log data, navigate to (on firmware 7.2.42 and newer): 

System Configuration > Logging Options > System Log Files > System Message File

For firmware older than 7.2.41, navigate to:

System Configuration >Logging Options > Extended Log Files  > SSOMGR Audit Logs >  SSOMGR > View

Note: Ensure you disable the SSOMGR Debug Traces after the required amount of logging has been gathered for troubleshooting. Failing to do so causes the LoadMaster log storage to quickly fill up.

Sample SSO Debug Logs (user authentication succeeds):

Aug 22 16:38:33 USHA1 ssomgr: #846# auth_form: Auth_form user administrator
Aug 22 16:38:33 USHA1 ssomgr: #846# >>>get_domain
Aug 22 16:38:33 USHA1 ssomgr: #846# >>>get_domain_from_user
Aug 22 16:38:33 USHA1 ssomgr: #846# get_domain_from_user: no domain to extract from [administrator]
Aug 22 16:38:33 USHA1 ssomgr: #846# get_domain: client domain not provided, proceed with default domain [KEMPTEST.COM] for VS[114]
Aug 22 16:38:33 USHA1 ssomgr: #846# >>>get_domain
Aug 22 16:38:33 USHA1 ssomgr: #846# >>>get_domain_from_user
Aug 22 16:38:33 USHA1 ssomgr: #846# get_domain_from_user: no domain to extract from [administrator]
Aug 22 16:38:33 USHA1 ssomgr: #846# get_domain: client domain not provided, proceed with default domain [KEMPTEST.COM] for VS[114]
Aug 22 16:38:33 USHA1 ssomgr: #846# normalize_user: user:|administrator|; nd1:|(null)|; nd2:|(null)|; logonfmt:1 phase:1
Aug 22 16:38:33 USHA1 ssomgr: #846# normalize_user: Logon Format : Principalname
Aug 22 16:38:33 USHA1 ssomgr: #846# normalize_user: normalized user: |administrator@kemptest.com|
Aug 22 16:38:33 USHA1 ssomgr: >>find_user_by_user(administrator@kemptest.com,10.0.30.105) 
Aug 22 16:38:33 USHA1 ssomgr: #846# >>find_user_by_user():  up==NULL 
Aug 22 16:38:33 USHA1 ssomgr: >>find_user_by_user(administrator@kemptest.com,) 
 
Aug 22 16:38:33 USHA1 ssomgr: #16358# baseUserName: basename=|administrator|
Aug 22 16:38:33 USHA1 ssomgr: #16358# >> do_sso_ldap_check(kemptest.com,administrator@kemptest.com(administrator)[1])
Aug 22 16:38:33 USHA1 ssomgr: #16358# sso_cfg: [Domain:kemptest.com] [Server:10.1.162.50] [METH:128] [auth_type:0]
Aug 22 16:38:33 USHA1 ssomgr: #16358# >>> ldap_map_auth_for_dual_factor: auth_type in: 0
Aug 22 16:38:33 USHA1 ssomgr: #16358# <<< ldap_map_auth_for_dual_factor: auth_type out: 0, server: 10.1.162.50
Aug 22 16:38:33 USHA1 ssomgr: #16358# do_sso_ldap_check: ldap_urls=|ldap://10.1.162.50|
Aug 22 16:38:33 USHA1 ssomgr: #16358# do_sso_ldap_check: ldap timeout is 5
Aug 22 16:38:33 USHA1 ssomgr: #16358# >>> ldap_need_steering_groups: vid=114
Aug 22 16:38:33 USHA1 ssomgr: #16358# baseUserName: basename=|administrator|
Aug 22 16:38:33 USHA1 ssomgr: #16358# do_sso_ldap_check: bind(administrator@kemptest.com): rc=0,msgid=1
Aug 22 16:38:33 USHA1 ssomgr: #16358# domain=|kemptest.com|	baseDN=|dc=kemptest,dc=com|
Aug 22 16:38:33 USHA1 ssomgr: #16358# do_sso_ldap_check: Attempt attribute retrieval for [administrator@kemptest.com]
Aug 22 16:38:33 USHA1 ssomgr: #16358# do_sso_ldap_check: ldap_search_ext(ld,dc=kemptest,dc=com,,(userprincipalname=administrator@kemptest.com)): rc=0

With SSO Debug Traces enabled, it is now possible to view the full authentication between the client and the LDAP/Active Directory from the LoadMaster logs. The above sample SSO debug logs shows that the client entered their Username only, without any domain attached. Therefore, the LoadMaster normalized the user to Principalname Logon Format using the pre-set Logon Format and the pre-assigned domain/realm set in the Client Side SSO configuration. This normalized user string (administrator@kemptest.com) is then sent to the Active Directory for authentication.

Once the LDAP bind check returns an rc=0, this means that the check is complete, the user's credentials are valid, and the user is now successfully authenticated.

For example, if the LDAP bind returns an rc=49, this means that the user's inputted credentials do not match the credentials on the active directory.

Sample SSO Debug Logs (user authentication fails):

Aug 23 11:08:28 USHA1 ssomgr: #27896# baseUserName: basename=|Aadministrator|
Aug 23 11:08:28 USHA1 ssomgr: #27896# do_sso_ldap_check: bind(,Aadministrator@kemptest.com,...): rc=49
Aug 23 11:08:28 USHA1 ssomgr: #27896# << do_sso_ldap_check: bindrc:49 groupOK:1
Aug 23 11:08:28 USHA1 ssomgr: #27896# Couldn't bind: [KEMPTEST.COM] [10.1.162.50]: 49, Invalid credentials

 See these Knowledge Base articles for examples of troubleshooting Kerberos Constrained Delegation (KCD) and Security Assertion Markup Language (SAML) ESP SSO Logs.