AWS loadmaster | NTLM authentication not working

0

Hi Kemp Team, 

I have configured an virtuell service (HTTPS / L7) with NTLM (Client Authentication Mode) and KCD (Server Authentication Mode). 

KCD authentication is working when I change the Client Authentication Mode from NTLM to Form Based. But NTLM is not working. I cann´t see anthing in the system log (Debug logging is enabled)

Here you can find the informations from system log (LDAP Healthcheck is working) 

Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: maybe got alpn 0
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: SSL accept on 10.248.1.112:443 from 10.248.1.241:58934 (0)
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: Parse_http_header
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: Parse_http_header: finished
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: request: POST /innovatorserver/NotificationServer/UserNotifications/ProxyPage.aspx
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: find persist returns (null)
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: RS 10.248.1.104:443 aconns 0 refcnt 2 weight 1000
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: Send error(401) HTTP/1.1 401 Authorization Required^M
Feb 3 09:40:11 seu03cg9999 kernel: Date: Mon, 03 Feb 2020 09:40:11 GMT^M
Feb 3 09:40:11 seu03cg9999 kernel: X-Frame-Options: SAMEORIGIN^M
Feb 3 09:40:11 seu03cg9999 kernel: X-XSS-Protection: 1; mode=block^M
Feb 3 09:40:11 seu03cg9999 kernel: X-Content-Type-Options: nosniff^M
Feb 3 09:40:11 seu03cg9999 kernel: Connection: close^M
Feb 3 09:40:11 seu03cg9999 kernel: Content-Length: 139^M
Feb 3 09:40:11 seu03cg9999 kernel: WWW-Authenticate: NTLM^M
Feb 3 09:40:11 seu03cg9999 kernel: Content-Type: text/html^M
Feb 3 09:40:11 seu03cg9999 kernel: ^M
Feb 3 09:40:11 seu03cg9999 kernel: <html><head><title>401 Authorization Required</title></head><body>You do not have authorization to perform the requested operation</body>^M
Feb 3 09:40:11 seu03cg9999 kernel:
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: conn release 7
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: maybe got alpn 0
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: SSL accept on 10.248.1.112:443 from 10.248.1.241:58935 (0)
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: Parse_http_header
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: Parse_http_header: finished
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: request: POST /innovatorserver/NotificationServer/UserNotifications/ProxyPage.aspx
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: find persist returns (null)
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: RS 10.248.1.104:443 aconns 0 refcnt 2 weight 1000
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: Got NTLM message '1' flags 0xa2088207
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: Send error(401) HTTP/1.1 401 Authorization Required^M
Feb 3 09:40:11 seu03cg9999 kernel: Date: Mon, 03 Feb 2020 09:40:11 GMT^M
Feb 3 09:40:11 seu03cg9999 kernel: X-Frame-Options: SAMEORIGIN^M
Feb 3 09:40:11 seu03cg9999 kernel: X-XSS-Protection: 1; mode=block^M
Feb 3 09:40:11 seu03cg9999 kernel: X-Content-Type-Options: nosniff^M
Feb 3 09:40:11 seu03cg9999 kernel: Connection: keep-alive^M
Feb 3 09:40:11 seu03cg9999 kernel: Content-Length: 139^M
Feb 3 09:40:11 seu03cg9999 kernel: WWW-Authenticate: NTLM TlRMTVNTUAACAAAACAAIADAAAAABEoCgBO/pJl2HFZ0AAAAAAAAAABAAEAA4AAAAQwBPAFIAUAACAAgAQwBPAFIAUAAAAAAA^M
Feb 3 09:40:11 seu03cg9999 kernel: Content-Type: text/html^M
Feb 3 09:40:11 seu03cg9999 kernel: ^M
Feb 3 09:40:11 seu03cg9999 kernel: <html><head><title>401 Authorization Required</title></head><body>You do not have authorization to perform the requested operation</body>^M
Feb 3 09:40:11 seu03cg9999 kernel:
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: client closed
Feb 3 09:40:11 seu03cg9999 kernel: L7: ffff8881fbd79c08: conn release 7
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# baseUserName: basename=|svc-cde-cg-LoadBala|
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# >> do_sso_ldap_check(corp,svc-cde-cg-LoadBala@domain(svc-cde-cg-LoadBala)[1])
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# sso_cfg: [Domain:corp] [Server:10.246.3.62] [METH:128] [auth_type:0]
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# >>> ldap_map_auth_for_dual_factor: auth_type in: 0
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# <<< ldap_map_auth_for_dual_factor: auth_type out: 0, server: 10.246.3.62
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# do_sso_ldap_check: ldap_urls=|ldap://10.246.3.62|
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# do_sso_ldap_check: ldap timeout is 5
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# do_sso_ldap_check: LDAP_AUTH_SIMPLE: vid:(null),domain:corp,adminuser:svc-cde-cg-LoadBala@domain
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# baseUserName: basename=|svc-cde-cg-LoadBala|
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# do_sso_ldap_check: bind(,svc-cde-cg-LoadBala@domain,...): rc=0
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# >>>group_processing: started group processing for do_sso_ldap_check, vid=(null)
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# >>> ldap_need_steering_groups: vid=(null)
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# group_processing: chk_sids = 0, chk_allowed_groups = 0, chk_steering_groups = 0
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# <<<group_processing: completed group processing for do_sso_ldap_check, groupOK=1
Feb 3 09:40:12 seu03cg9999 ssomgr: SM: #1171# << do_sso_ldap_check: bindrc:0 groupOK:1 ecpexpwdays:0 maxPwdAge:0

 

3 comments

Avatar
0
Michael Starr

Hello Sebastian,

Do you find that basic Client Authentication works as well or only forms-based?

 

Unfortunately, that log does not provide much info on the SSO process. In the debug options found in System Configuration -> logging options -> System log files -> debug options.  There's a setting "Enable SSOMGR Debug Traces" which can provide logs specifically on the SSO process. The logs will appear in the message file as well. Make sure to clear the logs before your test to help with the troubleshooting process. 

Also before the test make sure to Flush SSO Authentication Cache which is the button below "Enable SSOMGR Debug Traces"

Sharing those logs on the post may give more information on what the problem is

 

Avatar
0
sebastian.hassel

Hello Michael,

thanks for you Reply.

The setting "Enable SSOMGR Debug Traces" is already activated and the log informations which I posted were from System log as well. I have flushed SSO Authentication Cache now but still the same log entries.

When I use "Form Based" as Client Authentication Mode then authentication is working. Basic Authentication is not working because we want to use KCD for Server authentication.

Regards

Sebastian

Avatar
0
Michael Starr

Sebastian,

I see, unfortunately, it looks like the logs relating to the Kerberos was cut off from your post as there should be some relating to the actually Kerberos authentication attempt. You could disable the L7 debug traces as this mostly gives info on the connection itself not the authentication attempt.

Another option to get some more information would be to take a TCP.dump between the loadmaster and the server handling Kerberos to confirm the loadmaster can reach the server.

Info on how that can be done is at the article I posted below.

 

https://support.kemptechnologies.com/hc/en-us/articles/360030802632-Performing-a-TCPDump