SSO-Manager Logs for LDAP (Lightweight Directory Access Protocol) Authentication

Scope

This Article explains some examples of the Ldap SSO Logs when using ESP.

 

1. Enable SSO debug traces

2. SSO Domain Health-check

3. Authentication Form fill out

4. LDAP Authentication with Permitted Group check

 

1. Enable SSO debug traces

To enable the SSO debug traces you need to go to 'Logging Options > System Logs Files > Debug Options > Enable SSOMGR Debug Traces'

 

2. SSO Domain Health-check

The LoadMaster performs regular health-checks to the LDAP Endpoint. If these Fail, the virtual Service alarms with a Security down error.

The User that is set on the LDAP Endpoint setup will be used to perform a bind request to the LDAP Servers that have been set. In this example the LDAP Server was 10.1.155.10 and the user administrator@foxworld.loc. 

The Servers responds (highlighted below) rc=0 means the credentials used are correct and the bind request was successful. rc=49 would mean the credentials used are wrong.


Jun 22 10:42:28 LB100 ssomgr: #12849# baseUserName: basename=|administrator|
Jun 22 10:42:28 LB100 ssomgr: #12849# >> do_sso_ldap_check(Foxworld.loc,administrator@foxworld.loc(administrator)[1])
Jun 22 10:42:28 LB100 ssomgr: #12849# sso_cfg: [Domain:Foxworld.loc] [Server:10.1.155.10] [METH:128] [auth_type:0]
Jun 22 10:42:28 LB100 ssomgr: #12849# >>> ldap_map_auth_for_dual_factor: auth_type in: 0
Jun 22 10:42:28 LB100 ssomgr: #12849# <<< ldap_map_auth_for_dual_factor: auth_type out: 0, server: 10.1.155.10
Jun 22 10:42:28 LB100 ssomgr: #12849# do_sso_ldap_check: ldap_urls=|ldap://10.1.155.10|
Jun 22 10:42:28 LB100 ssomgr: #12849# do_sso_ldap_check: ldap timeout is 5
Jun 22 10:42:28 LB100 ssomgr: #12849# baseUserName: basename=|administrator|
Jun 22 10:42:28 LB100 ssomgr: #12849# do_sso_ldap_check: bind(,administrator@foxworld.loc,...): rc=0
Jun 22 10:42:28 LB100 ssomgr: #12849# >>>group_processing: started group processing for do_sso_ldap_check
Jun 22 10:42:28 LB100 ssomgr: #12849# >>> ldap_need_steering_groups: vid=(null)
Jun 22 10:42:28 LB100 ssomgr: #12849# group_processing: chk_sids = 0, chk_allowed_groups = 0, chk_steering_groups = 0
Jun 22 10:42:28 LB100 ssomgr: #12849# <<<group_processing: completed group processing for do_sso_ldap_check, groupOK=1
Jun 22 10:42:28 LB100 ssomgr: #12849# << do_sso_ldap_check: bindrc:0 groupOK:1

 

3. Authform fill out

The LoadMaster detects the username that has been entered.

It then tries to extract a domain to match on the set SSO domains (if alternative SSO Domains are assigned). If the user did not enter a Domain the LoadMaster will revert to the default set SSO Domain. In this example 'Foxworld.loc'

Then the LoadMaster checks if the username need to be normalized. The SSO Domain in our example has the Setting 'Principalname' set so the LoadMaster turns the username (rschoepfel) into rschoepfel@foxworld.loc

For more information on normalization please review our Article: Logon Format Normalization

Jun 22 11:02:22 LB100 ssomgr: #853# 0000 00000000 00000000 ........
Jun 22 11:02:22 LB100 ssomgr: #853# Auth_form user rschoepfel
Jun 22 11:02:22 LB100 ssomgr: #853# >>>get_domain
Jun 22 11:02:22 LB100 ssomgr: #853# >>>get_domain_from_user
Jun 22 11:02:22 LB100 ssomgr: #853# get_domain_from_user: no domain to extract from [rschoepfel]
Jun 22 11:02:22 LB100 ssomgr: #853# get_domain: client domain not provided, proceed with default domain [FOXWORLD.LOC] for VS[20]
Jun 22 11:02:22 LB100 ssomgr: #853# >>>get_domain
Jun 22 11:02:22 LB100 ssomgr: #853# >>>get_domain_from_user
Jun 22 11:02:22 LB100 ssomgr: #853# get_domain_from_user: no domain to extract from [rschoepfel]
Jun 22 11:02:22 LB100 ssomgr: #853# get_domain: client domain not provided, proceed with default domain [FOXWORLD.LOC] for VS[20]
Jun 22 11:02:22 LB100 ssomgr: #853# normalize_user: user:|rschoepfel|; nd1:|(null)|; nd2:|(null)|; logonfmt:1 phase:1
Jun 22 11:02:22 LB100 ssomgr: #853# normalize_user: Logon Format : Principalname
Jun 22 11:02:22 LB100 ssomgr: #853# normalize_user: normalized user: |rschoepfel@Foxworld.loc|

 

4. Ldap Auth with Permitted Group check

The Authorization for a user works in the same principle as the Health-Check mentioned above. A bind request with the credentials and when it is successful the rc=0 will be returned.

Jun 22 11:02:22 LB100 ssomgr: #13353# >> do_sso_ldap_check(Foxworld.loc,rschoepfel@Foxworld.loc(rschoepfel)[1])

In combination with Permitted Groups, a group check is performed before the credentials bind request is done. The User entered in the LDAP Endpoint Setting need to have enough Permission to request a group Membership for a different user (we request an Admin User)

For each group-check an additional LDAP Endpoint Healthcheck is performed.

Jun 22 11:02:22 LB100 ssomgr: #13353# sso_cfg: [Domain:Foxworld.loc] [Server:10.1.155.10] [METH:128] [auth_type:0]
Jun 22 11:02:22 LB100 ssomgr: #13353# >>> ldap_map_auth_for_dual_factor: auth_type in: 0
Jun 22 11:02:22 LB100 ssomgr: #13353# <<< ldap_map_auth_for_dual_factor: auth_type out: 0, server: 10.1.155.10
Jun 22 11:02:22 LB100 ssomgr: #13353# do_sso_ldap_check: ldap_urls=|ldap://10.1.155.10|
Jun 22 11:02:22 LB100 ssomgr: #13353# do_sso_ldap_check: ldap timeout is 5
Jun 22 11:02:22 LB100 ssomgr: #13353# baseUserName: basename=|administrator|
Jun 22 11:02:22 LB100 ssomgr: #13353# do_sso_ldap_check: bind(,administrator@foxworld.loc,...): rc=0

In this example there are two Groups set on the Virtual Service (EMEAteam;APACteam).

First the LoadMaster will check with the LDAP Server if the listed Groups exist on the Server.

Jun 22 11:02:22 LB100 ssomgr: #13353# >>>group_processing: started group processing for do_sso_ldap_check
Jun 22 11:02:22 LB100 ssomgr: #13353# >>> ldap_need_steering_groups: vid=20
Jun 22 11:02:22 LB100 ssomgr: #13353# group_processing: chk_sids = 0, chk_allowed_groups = 1, chk_steering_groups = 0
Jun 22 11:02:22 LB100 ssomgr: #13353# domain=|Foxworld.loc| baseDN=|dc=Foxworld,dc=loc|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupFilter: >> basedn=|dc=Foxworld,dc=loc| vid=|20|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: >> basedn=|dc=Foxworld,dc=loc| groupname=|APACteam|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: filter=|(&(objectClass=group)(cn=APACteam))|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: ldap_result(): rc2=100 (search-entry)
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: groupdn=|CN=APACteam,CN=Users,DC=foxworld,DC=loc|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: ldap_result(): rc=0
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: <<< - rc=0
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: >> basedn=|dc=Foxworld,dc=loc| groupname=|EMEAteam|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: filter=|(&(objectClass=group)(cn=EMEAteam))|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: ldap_result(): rc2=100 (search-entry)
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: groupdn=|CN=EMEAteam,CN=Users,DC=foxworld,DC=loc|
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: ldap_result(): rc=0
Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupDN: <<< - rc=0

Based on this Information the membership request will be done, determining if the user is part of any of the groups the LDAP has confirmed exist on its database.

Jun 22 11:02:22 LB100 ssomgr: #13353# getGroupFilter: << vid=|20| groupfilter=|(|(memberOf=CN=APACteam,CN=Users,DC=foxworld,DC=loc)(memberOf=CN=EMEAteam,CN=Users,DC=foxworld,DC=loc))|
Jun 22 11:02:22 LB100 ssomgr: #13353# do_check_group: attrs[0]=|userprincipalname| filter=|(&(samAccountType=805306368)(|(memberOf=CN=APACteam,CN=Users,DC=foxworld,DC=loc)(memberOf=CN=EMEAteam,CN=Users,DC=foxworld,DC=loc))(userprincipalname=rschoepfel@Foxworld.loc))| tout:5
Jun 22 11:02:22 LB100 ssomgr: #13353# do_check_group: ldap_search_ext(): rc=0
Jun 22 11:02:22 LB100 ssomgr: #13353# do_check_group: ldap_result(): rc2=101 (search-result)
Jun 22 11:02:22 LB100 ssomgr: #13353# do_check_group: ldap_msg: msgid=4 type=100 (search-entry)
Jun 22 11:02:22 LB100 ssomgr: #13353# do_check_group: userPrincipalName=|rschoepfel@foxworld.loc|
Jun 22 11:02:22 LB100 ssomgr: #13353# do_check_group: user in group(s)
Jun 22 11:02:22 LB100 ssomgr: #13353# group_processing: Granted access - user in approved groups for VS [20]
Jun 22 11:02:22 LB100 ssomgr: #13353# <<<group_processing: completed group processing for do_sso_ldap_check, groupOK=1

Logs like is are also possible, deny the Access if the user is not part of the group or the LDAP Endpoint user has not enough rights.

Jun 22 11:35:46 LB100 ssomgr: #2859# group_processing: Blocked access - user not in approved groups for VS [20]
Jun 22 11:35:46 LB100 ssomgr: #2859# <<<group_processing: completed group processing for do_sso_ldap_check, groupOK=0
Jun 22 11:35:46 LB100 ssomgr: #2859# << do_sso_ldap_check: bindrc:50 groupOK:0
Jun 22 11:35:46 LB100 ssomgr: #2859# Couldn't bind: [FOXWORLD.LOC] [10.1.155.10]: 50, Insufficient access

Granted Access means the Membership of the user has been confirmed.

Jun 22 11:02:22 LB100 ssomgr: #13353# baseUserName: basename=|rschoepfel|
Jun 22 11:02:22 LB100 ssomgr: #13353# do_sso_ldap_check: bind(rschoepfel@Foxworld.loc): rc=0,msgid=5
Jun 22 11:02:22 LB100 ssomgr: #13353# domain=|Foxworld.loc| baseDN=|dc=Foxworld,dc=loc|
Jun 22 11:02:22 LB100 ssomgr: #13353# do_sso_ldap_check: Attempt attribute retrieval for [rschoepfel@Foxworld.loc]
Jun 22 11:02:22 LB100 ssomgr: #13353# do_sso_ldap_check: ldap_search_ext(ld,dc=Foxworld,dc=loc,,(userprincipalname=rschoepfel@Foxworld.loc)): rc=0
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_count_messages(): 1
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_count_entries(): 1
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_result(): rc=100
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_first_message(): msg=0x7fc7b800a270 msgtype=100
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: samAccountName=|rschoepfel|
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: userPrincipalName=|rschoepfel@foxworld.loc|
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_result(): rc=0
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_count_messages(): 1
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_count_entries(): 0
Jun 22 11:02:22 LB100 ssomgr: #13353# get_attributes: ldap_result(): rc=101
Jun 22 11:02:22 LB100 ssomgr: #13353# do_sso_ldap_check: attributes retrieved userPrincipleName:rschoepfel@foxworld.loc, samAccountName:rschoepfel
Jun 22 11:02:22 LB100 ssomgr: #13353# << do_sso_ldap_check: bindrc:0 groupOK:1

The provided username and password matched on the LDAP Server so the authentication was successful.

As mentioned before rc=49 would mean the credentials were wrong or on older firmware before 7.2.x that the password might has been expired.

 

Was this article helpful?

0 out of 0 found this helpful

Comments