Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Kerberos Auth still not working

Hi,

I have a pretty strange behaviour in my Lab Environment. Some time ago, I implemented Kerberos Auth at the customer's site - which was working after opening a support case and a lot of troubleshooting.

Now I wanted to implement it in my local lab environment, which consists of one Windows Server 2012 R2 Domain Controller and DNS Server/IIS with Windows Auth as well as one Windows 10 Client (domain-joined). Both machines are in their default config, no GPO's, no modifications, nada. F5 has the DC as DNS server set and A + PTR records for f5.test.local are set. Time is synchronized.

  • Flat /24 network with no firewalls etc.
  • BIG-IP Version 13.0.1.2
  • F5 Self-IP: 10.1.20.241
  • F5 VS: f5.test.local - 10.1.20.35
  • F5 Backend Pool Web Server: ad.test.local - 10.1.20.185
  • DC: ad.test.local - 10.1.20.185
  • Win10: win10.test.local - 10.1.20.180
  • Domain: test.local
  • NetBIOS: TEST
  • Kerberos User: f5krb

Kerberos user settings:

  • User Logon Name: f5krb
  • Account options: [+] This account supports Kerberos AES 256bit encryption.

The SPN was set using this command: setspn -U -A HTTP/f5.test.local f5krb

The keytab file was created using this command: ktpass -princ HTTP/f5.test.local@TEST.LOCAL -mapuser f5krb@TEST.LOCAL -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass Secret123! -out c:\f5krb.keytab

Importing the keytab, I used the following settings:

  • Auth Realm: TEST.LOCAL
  • Service Name: HTTP

The access policy: access_policy

Accessing the web server directly from the client (Internet Explorer), I see it successfully authenticates using Kerberos. When using the F5, I get this 401 popup window for authentication. The strange thing is that the client has fetched a valid Kerberos ticket for the SPN.

All I see in the APM log is:

/Common/test_kerberos:Common:acdc64ef: modules/Authentication/Kerberos/KerberosAuthModule.cpp: 'display_status_1()': 94: acdc64ef : GSS-API error gss_accept_sec_context: d0000 : Unspecified GSS failure. Minor code may provide more information

Wireshark Kerberos info when sending a GET /my.policy including the www-authenticate header:

[truncated]Authorization: Negotiate YIIGTgYGKwY...
    GSS-API Generic Security Service Application Program Interface
        OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
        Simple Protected Negotiation
            negTokenInit
                mechTypes: 4 items
                    MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                    MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                    MechType: 1.3.6.1.4.1.311.2.2.30 (NEGOEX - SPNEGO Extended Negotiation Security Mechanism)
                    MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                mechToken: 60820600...
                krb5_blob: 60820600...
                    KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                    krb5_tok_id: KRB5_AP_REQ (0x0001)
                    Kerberos
                        ap-req
                            pvno: 5
                            msg-type: krb-ap-req (14)
                            Padding: 0
                            ap-options: 20000000 (mutual-required)
                                0... .... = reserved: False
                                .0.. .... = use-session-key: False
                                ..1. .... = mutual-required: True
                            ticket
                                tkt-vno: 5
                                realm: TEST.LOCAL
                                sname
                                    name-type: kRB5-NT-SRV-INST (2)
                                    sname-string: 2 items
                                        SNameString: HTTP
                                        SNameString: f5.test.local
                                enc-part
                                    etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                    kvno: 8
                                    cipher: 964eef7e850...
                            authenticator
                                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                cipher: e8b3aa84...

Am I forgetting something? This has already worked the exact same way, the main problem at the customer was the wrong encryption type at keytab creation.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Seems about right. In my lab I use another crypto: rc4-hmac-nt.

You didn't mention anything about adding f5.local.test as a trusted site to IE. How about that?

0
Comments on this Answer
Comment made 11-Feb-2018 by Niels van Sluis 2744

I changed my crypto to AES256-SHA1 and it is still working in my lab. I compared your wireshark output with mine, and that looks very similar. Can you try the following on commands on your BIG-IP and see if these work?

[root@nielsvs-bigip:Active:Standalone] config # klist -ke 
WRFILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/\:Common\:kerberos-test-2_key_file_114455_1 
Keytab name: FILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/:Common:kerberos-test-2_key_file_114455_1
KVNO Principal
---- --------------------------------------------------------------------------
   5 HTTP/kerberos-test.vosko.nl@VOSKO.NL (aes256-cts-hmac-sha1-96) 
[root@nielsvs-bigip:Active:Standalone] config # 
[root@nielsvs-bigip:Active:Standalone] config # kinit HTTP/kerberos-test.vosko.nl@VOSKO.NL
Password for HTTP/kerberos-test.vosko.nl@VOSKO.NL: 
[root@nielsvs-bigip:Active:Standalone] config # 
[root@nielsvs-bigip:Active:Standalone] config # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/kerberos-test.vosko.nl@VOSKO.NL

Valid starting     Expires            Service principal
02/11/18 16:49:10  02/12/18 02:48:39  krbtgt/VOSKO.NL@VOSKO.NL
        renew until 02/18/18 16:49:10
[root@nielsvs-bigip:Active:Standalone] config # 
0
Comment made 11-Feb-2018 by Daniel Tremmel 247

I just removed and added the keytab file again and ran the commands:

[root@bigipA:Active:Standalone] config # klist -ke
Keytab name: FILE:/etc/krb5.keytab
klist: No such file or directory while starting keytab scan
[root@bigipA:Active:Standalone] config #
[root@bigipA:Active:Standalone] config # kinit HTTP/f5.test.local@TEST.LOCAL
Password for HTTP/f5.test.local@TEST.LOCAL:
[root@bigipA:Active:Standalone] config #
[root@bigipA:Active:Standalone] config # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/f5.test.local@TEST.LOCAL

Valid starting     Expires            Service principal
02/12/18 08:17:42  02/12/18 18:17:45  krbtgt/TEST.LOCAL@TEST.LOCAL
    renew until 02/19/18 08:17:42
[root@bigipA:Active:Standalone] config #

Although the keytab file in /config/filestore/files_d/Common_d/kerberos_keytab_file_d/ exists, there is no reference to it. Can this be the problem?

Btw, the content of /etc/krb5.conf

[root@bigipA:Active:Standalone] config # cat /etc/krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.COM

#F5mod
 dns_lookup_realm = true
 dns_lookup_kdc = true

 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 TEST.LOCAL = {
  default_tkt_enctypes = arcfour-hmac des-cbc-md5
 }
 EXAMPLE.COM = {
  kdc = kerberos.example.com
  admin_server = kerberos.example.com
 }

[domain_realm]
 test.local = TEST.LOCAL
 .test.local = TEST.LOCAL
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM
0
Comment made 11-Feb-2018 by Niels van Sluis 2744

No, it's not a reference problem. The command is:

klist -ke WRFILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/<key_file>

0
Comment made 12-Feb-2018 by Daniel Tremmel 247

The output:

[root@bigipA:Active:Standalone] config # klist -ke WRFILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/\:Common\:f5_key_file_74256_1
Keytab name: FILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/:Common:f5_key_file_74256_1
KVNO Principal
---- --------------------------------------------------------------------------
   8 HTTP/f5.test.local@TEST.LOCAL (aes256-cts-hmac-sha1-96)
[root@bigipA:Active:Standalone] config #

Everything's good so far. The strange thing is also that TGS-REQ and TGS-REP seems to work since I get a Kerberos ticket for the VS on the Win10 Client Machine. Any other hints?

0
Comment made 12-Feb-2018 by Niels van Sluis 2744

And how does the session show in under Active Sessions?

0
Comment made 12-Feb-2018 by Daniel Tremmel 247

There's the output of the APM log:

TL'DR:

Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/Authentication/Kerberos/KerberosAuthModule.cpp: 'display_status_1()': 94: 214cf0b0 : GSS-API error gss_accept_sec_context: d0000 : Unspecified GSS failure.  Minor code may provide more information
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/Authentication/Kerberos/KerberosAuthModule.cpp: 'display_status_1()': 94: 214cf0b0 : GSS-API error gss_accept_sec_context: 186a5 :

Full:

Feb 12 15:43:21 bigipA notice tmm[12813]: 01490506:5: /Common/test_kerberos:Common:214cf0b0: Received User-Agent header: Mozilla%2f4.0%20(compatible%3b%20MSIE%207.0%3b%20Windows%20NT%2010.0%3b%20WOW64%3b%20Trident%2f8.0%3b%20.NET4.0C%3b%20.NET4.0E%3b%20.NET%20CLR%202.0.50727%3b%20.NET%20CLR%203.0.30729%3b%20.NET%20CLR%203.5.30729).
Feb 12 15:43:21 bigipA notice tmm[12813]: 01490500:5: /Common/test_kerberos:Common:214cf0b0: New session from client IP 10.1.20.180 (ST=/CC=/C=) at VIP 10.1.20.35 Listener /Common/VS_Webserver (Reputation=)
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: 'execute()': 619: Let's evaluate rules, total number of rules for this action=1
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: 'execute()': 625: Rule to evaluate = ""
Feb 12 15:43:21 bigipA info apmd[7948]: 01490006:6: /Common/test_kerberos:Common:214cf0b0: Following rule 'fallback' from item 'Start' to item 'HTTP 401 Response'
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490011:7: /Common/test_kerberos:Common:214cf0b0: Logon agent: ENTER Function executeInstance
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/LogonPage/SimpleLogonPage/SimpleLogonPageAgent.cpp: 'SimpleLogonPageAgentexecuteInstance()': 1345: SCIM session state variables: Request Type : Request Domain : GroupName : UserName : ClearCache:0
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490012:7: /Common/test_kerberos:Common:214cf0b0: Logon agent: LEAVE Function executeInstance
Feb 12 15:43:21 bigipA info apmd[7948]: 01490004:6: /Common/test_kerberos:Common:214cf0b0: Executed agent '/Common/test_kerberos_act_http_401_response_ag', return value 3 ('Need User input')
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: '_executeOneAgent()': 199: user input is required
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'process_apd_request()': 1775: processing of access policy is done, result code=fffffff3
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'writeSessionVarToSessionDb()': 2364: syncing data with MEMCACHED
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon.page.customization.group' set to '/Common/test_kerberos_act_http_401_response_ag'
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ./AccessPolicyProcessor/Session.h: 'setSessionInactive()': 1134: 214cf0b0: done with request processing
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'sendAccessPolicyResponse()': 2697: send 'redirect to EUIE' code, redirect URL="/agent_logon_page_401.eui?401&2"
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'process_apd_request()': 1815:  ** done with the request processing **
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490011:7: /Common/test_kerberos:Common:214cf0b0: Logon agent: ENTER Function executeInstance
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/LogonPage/SimpleLogonPage/SimpleLogonPageAgent.cpp: 'SimpleLogonPageAgentexecuteInstance()': 1345: SCIM session state variables: Request Type : Request Domain : GroupName : UserName : ClearCache:0
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/LogonPage/SimpleLogonPage/SimpleLogonPageAgent.cpp: 'getLogUserName()': 749:  user input : Negotiate YIIGTQYGKwYBBQUCoIIGQTCCBj2gMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBgcEggYDYIIF/wYJKoZIhvcSAQICAQBuggXuMIIF6qADAgEFoQMCAQ6iBwMFACAAAACjggR/YYIEezCCBHegAwIBBaEMGwpURVNULkxPQ0FMoiAwHqADAgECoRcwFRsESFRUUBsNZjUudGVzdC5sb2NhbKOCBD4wggQ6oAMCARKhAwIBCKKCBCwEggQofHBOMWwG5ycfweZCoAc4A2LccGLqbMmFcsABMGEm+2B7ItYSqn8dzavG6Qwd+H3HfB51cLSioaPS6y1/Z2GaZqYdaxnKPM3ImAVEaTg7aB7SCGSFJdyg1srsDUqjfJ29kGdsDsAp/3EPcvHm1d1H+6+gKYk5KJbDVLGDqBdj6QB8dQhuw7rYRsONIlWiTSDT5c20DieO4NLICrCh7kcsfnW1kAHzqELOV3znESDuYliaeKv0cpIJaKqM+K95I4t8L6RO64RSkZ5pm/GDvbvs6Bk8rMDRw3cbOJk9SdM7yIm33gw8p7pyGlCumiWoweQyJ3rLEN0AlwdU8TWroLdUEtqCfhrqXzjDz1y56YDfKQ+KtqHQdDYO9N5E52lyVYR+EBO4PWGhmldMhPxRDTn6teedt6JbUb/GO3LWnjKoImq3SfJNs0ikGCXb15g9LOx9jYd9+hOCYxzojxd3aDbMLG4JxadKGKH4hwP980IGOJdD9fe8Xvp6h3qZK6zcCs3hIY/r6GTtuVrLR9uB4k45yNkpRjMligXoWs+aX9uexD8UO+uNZpcclawGvZw6TkY+0sJ0QQ6gqJbMlcX6dDN7eAhELXVqwl8y2tyjoY3i0CfEDvpUWqhAlT4VgqFUMO+R0SwBS+QJVpoQSAb86J+UfNWTqR23D/KJPw/q9dVW+0dNU1FnlS0QvWe+5MvoLaBozsLphrrSSTrOgCI2Hkg2vFuh8aQ9mo2qqeCaEPiHxCP+4UKMxTaCPohLszGkLQUE6wtzoCRa52R/ZWutHH+/fGQKmzo3nNWBDydAqIuiOToni6+KnNaqEcJfeAtEkj9Tu4yMlpYjDg3QzRHOpDypIPPtmyqNyh+EN4o11Q279l1oPo6c20QXgrUPuynu0Z7/3TlpS8JwYBV1PTQonimS2SNn3z/L1a+lG35mvSzCfb1D+pI7LiSGeY5eXkdny5Hhm8GLI41+MZDElPpgNSj3G+xhhO4CPyiW0XnPkCw3oTbKZlRzhHIlHfBQIa7g2ewe604S1GN4Un2BtOWws9ZtIpr835HGlZ+Fb/ThS5iB0CCU4dLHR4O3zGL86RFlwZHXwzXpsm3NiD6uKbX39wgvNJuaOdvdshmDjBQc2Jjf1+0NRcERp3tq/qErEH8Rh7IgCZzR7SXSfEcJL3k7qfOa9jSJm/IidMZ3c+UoJrE8xBoCvSu2fVXjE4sIMw7YkO1MSl+gJM5k9e41RkZ7c2hu5L+Zsab8bQHBV6MXFyrj2VpW2TnHXiyv2JPAa6RFUxZonnkcCKFVZlqR0nthZep9RIdxZh61iAjD4rD7WBdlSVzE6sB65DiOC+5zabe4M1SOdZuP6/vNY0RmfDVa3TSSdYFAKVilDlFhTBm5HJi6IGpq/Yuim2qemBoEdh12kpAOgi9bFBstbPCkggFQMIIBTKADAgESooIBQwSCAT9L8wPoLK+90CkR2PD9Zh0VCihVzWt+iVc5t9Y7l3Bp0C8TPhUKd8zNOuEifHjrDAtu9kelygmZtQ4hXOVFJqtwlRIHxnfc/MyjgvxhfAFDHb0c+Z/ya5rioWfZRgVWwVbOf7AG15s0Vesuxk8sk88xPDWBI5brO2jRFcvoc5SmGywtXjWJFIFhYELYPqctRsPLm+ecfHWWfTNsnsGx7DKeMRUGM0h4U4UGqM1t7SEB1pKGeBm4DhE8GQsakUpA240Zg6ECpfl4Z7MnS7fs9YwTGOg27xfmV4MEZUy
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490012:7: /Common/test_kerberos:Common:214cf0b0: Logon agent: LEAVE Function executeInstance
Feb 12 15:43:21 bigipA info apmd[7948]: 01490004:6: /Common/test_kerberos:Common:214cf0b0: Executed agent '/Common/test_kerberos_act_http_401_response_ag', return value 0 ('Execution Done')
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: 'execute()': 619: Let's evaluate rules, total number of rules for this action=3
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: 'execute()': 625: Rule to evaluate = "expr {[mcget {session.logon.last.authtype}] == "Basic"} "
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: 'execute()': 625: Rule to evaluate = "expr { [mcget {session.logon.last.authtype}] == "Negotiate" }"
Feb 12 15:43:21 bigipA info apmd[7948]: 01490006:6: /Common/test_kerberos:Common:214cf0b0: Following rule 'Negotiate' from item 'HTTP 401 Response' to item 'Kerberos Auth'
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490011:7: /Common/test_kerberos:Common:214cf0b0: KERBEROS agent: ENTER Function executeInstance
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ./AccessPolicyProcessor/Session.h: 'getSessionVar()': 587: variable "session.server.network.name" was not found in the local cache for session "214cf0b0"
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ./AccessPolicyProcessor/Session.h: 'getSessionVar()': 594: try to get it from MEMCACHED
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ./AccessPolicyProcessor/Session.h: 'getSessionVar()': 616: variable found, let's add it to the local cache "session.server.network.name"="f5.test.local"(length=13)
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490023:7: /Common/test_kerberos:Common:214cf0b0: KERBEROS module: ENTER Function authenticateUser
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/Authentication/Kerberos/KerberosAuthModule.cpp: 'display_status_1()': 94: 214cf0b0 : GSS-API error gss_accept_sec_context: d0000 : Unspecified GSS failure.  Minor code may provide more information
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/Authentication/Kerberos/KerberosAuthModule.cpp: 'display_status_1()': 94: 214cf0b0 : GSS-API error gss_accept_sec_context: 186a5 :
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490012:7: /Common/test_kerberos:Common:214cf0b0: KERBEROS agent: LEAVE Function executeInstance
Feb 12 15:43:21 bigipA info apmd[7948]: 01490004:6: /Common/test_kerberos:Common:214cf0b0: Executed agent '/Common/test_kerberos_act_kerberos_auth_ag', return value 4 ('Switch an agent')
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: '_executeOneAgent()': 199: user input is required
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490011:7: /Common/test_kerberos:Common:214cf0b0: Logon agent: ENTER Function executeInstance
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: modules/LogonPage/SimpleLogonPage/SimpleLogonPageAgent.cpp: 'SimpleLogonPageAgentexecuteInstance()': 1345: SCIM session state variables: Request Type : Request Domain : GroupName : UserName : ClearCache:0
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490012:7: /Common/test_kerberos:Common:214cf0b0: Logon agent: LEAVE Function executeInstance
Feb 12 15:43:21 bigipA info apmd[7948]: 01490004:6: /Common/test_kerberos:Common:214cf0b0: Executed agent '/Common/test_kerberos_act_http_401_response_ag', return value 3 ('Need User input')
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: AccessPolicyProcessor/AccessPolicy.cpp: '_executeOneAgent()': 199: user input is required
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'process_apd_request()': 1775: processing of access policy is done, result code=fffffff3
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'writeSessionVarToSessionDb()': 2364: syncing data with MEMCACHED
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon./Common/test_kerberos_act_http_401_response_ag.authparam' set to 'YIIGTQYGKwYBBQUCoIIGQTCCBj2gMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBgcEggYDYIIF/wYJKoZIhvcSAQICAQBuggXuMIIF6qADAgEFoQMCAQ6iBwMFACAAAACjggR/YYIEezCCBHegAwIBBaEMGwpURVNULkxPQ0FMoiAwHqADAgECoRcwFRsESFRUUBsNZjUudGVzdC5sb2NhbKOCBD4wggQ6oAMCARKhAwIBCKKCBCwEggQofHBOMWwG5ycfweZCoAc4A2LccGLqbMmFcsABMGEm+2B7ItYSqn8dzavG6Qwd+H3HfB51cLSioaPS6y1/Z2GaZqYdaxnKPM3ImAVEaTg7aB7SCGSFJdyg1srsDUqjfJ29kGdsDsAp/3EPcvHm1d1H+6+gKYk5KJbDVLGDqBdj6QB8dQhuw7rYRsONIlWiTSDT5c20DieO4NLICrCh7kcsfnW1kAHzqELOV3znESDuYliaeKv0cpIJaKqM+K95I4t8L6RO64RSkZ5pm/GDvbvs6Bk8rMDRw3cbOJk9SdM7yIm33gw8p7pyGlCumiWoweQyJ3rLEN0AlwdU8TWroLdUEtqCfhrqXzjDz1y56YDfKQ+KtqHQdDYO9N5E52lyVYR+EBO4PWGhmldMhPxRDTn6teedt6JbUb/GO3LWnjKoImq3SfJNs0ikGCXb15g9LOx9jYd9+hOCYxzojxd3aDbMLG4JxadKGKH4hwP980IGOJdD9fe8Xvp6h3qZK6zcCs3hIY/r6GTtuVrLR9uB4k45yNkpRjMligXoWs+aX9uexD8UO+uNZpcclawGvZw6TkY+0sJ0QQ6gqJbMlcX6dDN7eAhELXVqwl8y2tyjoY3i0CfEDvpUWqhAlT4VgqFUMO+R0SwBS+QJVpoQSAb86J+UfNWTqR23D/KJPw/q9dVW+0dNU1FnlS0QvWe+5MvoLaBozsLphrrSSTrOgCI2Hkg2vFuh8aQ9mo2qqeCaEPiHxCP+4UKMxTaCPohLszGkLQUE6wtzoCRa52R/ZWutHH+/fGQKmzo3nNWBDydAqIuiOToni6+KnNaqEcJfeAtEkj9Tu4yMlpYjDg3QzRHOpDypIPPtmyqNyh+EN4o11Q279l1oPo6c20QXgrUPuynu0Z7/3TlpS8JwYBV1PTQonimS2SNn3z/L1a+lG35mvSzCfb1D+pI7LiSGeY5eXkdny5Hhm8GLI41+MZDElPpgNSj3G+xhhO4CPyiW0XnPkCw3oTbKZlRzhHIlHfBQIa7g2ewe604S1GN4Un2BtOWws9ZtIpr835HGlZ+Fb/ThS5iB0CCU4dLHR4O3zGL86RFlwZHXwzXpsm3NiD6uKbX39wgvNJuaOdvdshmDjBQc2Jjf1+0NRcERp3tq/qErEH8Rh7IgCZzR7SXSfEcJL3k7qfOa9jSJm/IidMZ3c+UoJrE8xBoCvSu2fVXjE4sIMw7YkO1MSl+gJM5k9e41RkZ7c2hu5L+Zsab8bQHBV6MXFyrj2VpW2TnHXiyv2JPAa6RFUxZonnkcCKFVZlqR0nthZep9RIdxZh61iAjD4rD7WBdlSVzE6sB65DiOC+5zabe4M1SOdZuP6/vNY0RmfDVa3TSSdYFAKVilDlFhTBm5HJi6IGpq/Yuim2qemBoEdh12kpAOgi9bFBstbPCkggFQMIIBTKADAgESooIBQwSCAT9L8wPoLK+90CkR2PD9Zh0VCihVzWt+iVc5t9Y7l3Bp0C8TPhUKd8zNOuEifHjrDAtu9kelygmZtQ4hXOVFJqtwlRIHxnfc/MyjgvxhfAFDHb0c+Z/ya5rioWfZRgVWwVbOf7AG15s0Vesuxk8sk88xPDWBI5brO2jRFcvoc5SmGywtXjWJFIFhYELYPqctRsPLm+ecfHWWfTNsnsGx7DKeMRUGM0h4U4UGqM1t7SEB1pKGeBm4DhE8GQsakUpA240Zg6ECpfl4Z7MnS7fs9YwTGOg27xfmV4MEZUyVz0FZqcxY0qyHfcKnkNHrb9WV+/pxfai8GgLMLEku+zIdhdZqrRQwS5wVeuEVPE9TyCeXAVYOgkILj30NcGiCsgj37uh01nk5vqeNzBwppkqGERoxfEHl3VFMPOUFNuoWw4Uj'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon./Common/test_kerberos_act_http_401_response_ag.authtype' set to 'Negotiate'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon./Common/test_kerberos_act_http_401_response_ag.result' set to '1'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon.last.authparam' set to 'YIIGTQYGKwYBBQUCoIIGQTCCBj2gMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBgcEggYDYIIF/wYJKoZIhvcSAQICAQBuggXuMIIF6qADAgEFoQMCAQ6iBwMFACAAAACjggR/YYIEezCCBHegAwIBBaEMGwpURVNULkxPQ0FMoiAwHqADAgECoRcwFRsESFRUUBsNZjUudGVzdC5sb2NhbKOCBD4wggQ6oAMCARKhAwIBCKKCBCwEggQofHBOMWwG5ycfweZCoAc4A2LccGLqbMmFcsABMGEm+2B7ItYSqn8dzavG6Qwd+H3HfB51cLSioaPS6y1/Z2GaZqYdaxnKPM3ImAVEaTg7aB7SCGSFJdyg1srsDUqjfJ29kGdsDsAp/3EPcvHm1d1H+6+gKYk5KJbDVLGDqBdj6QB8dQhuw7rYRsONIlWiTSDT5c20DieO4NLICrCh7kcsfnW1kAHzqELOV3znESDuYliaeKv0cpIJaKqM+K95I4t8L6RO64RSkZ5pm/GDvbvs6Bk8rMDRw3cbOJk9SdM7yIm33gw8p7pyGlCumiWoweQyJ3rLEN0AlwdU8TWroLdUEtqCfhrqXzjDz1y56YDfKQ+KtqHQdDYO9N5E52lyVYR+EBO4PWGhmldMhPxRDTn6teedt6JbUb/GO3LWnjKoImq3SfJNs0ikGCXb15g9LOx9jYd9+hOCYxzojxd3aDbMLG4JxadKGKH4hwP980IGOJdD9fe8Xvp6h3qZK6zcCs3hIY/r6GTtuVrLR9uB4k45yNkpRjMligXoWs+aX9uexD8UO+uNZpcclawGvZw6TkY+0sJ0QQ6gqJbMlcX6dDN7eAhELXVqwl8y2tyjoY3i0CfEDvpUWqhAlT4VgqFUMO+R0SwBS+QJVpoQSAb86J+UfNWTqR23D/KJPw/q9dVW+0dNU1FnlS0QvWe+5MvoLaBozsLphrrSSTrOgCI2Hkg2vFuh8aQ9mo2qqeCaEPiHxCP+4UKMxTaCPohLszGkLQUE6wtzoCRa52R/ZWutHH+/fGQKmzo3nNWBDydAqIuiOToni6+KnNaqEcJfeAtEkj9Tu4yMlpYjDg3QzRHOpDypIPPtmyqNyh+EN4o11Q279l1oPo6c20QXgrUPuynu0Z7/3TlpS8JwYBV1PTQonimS2SNn3z/L1a+lG35mvSzCfb1D+pI7LiSGeY5eXkdny5Hhm8GLI41+MZDElPpgNSj3G+xhhO4CPyiW0XnPkCw3oTbKZlRzhHIlHfBQIa7g2ewe604S1GN4Un2BtOWws9ZtIpr835HGlZ+Fb/ThS5iB0CCU4dLHR4O3zGL86RFlwZHXwzXpsm3NiD6uKbX39wgvNJuaOdvdshmDjBQc2Jjf1+0NRcERp3tq/qErEH8Rh7IgCZzR7SXSfEcJL3k7qfOa9jSJm/IidMZ3c+UoJrE8xBoCvSu2fVXjE4sIMw7YkO1MSl+gJM5k9e41RkZ7c2hu5L+Zsab8bQHBV6MXFyrj2VpW2TnHXiyv2JPAa6RFUxZonnkcCKFVZlqR0nthZep9RIdxZh61iAjD4rD7WBdlSVzE6sB65DiOC+5zabe4M1SOdZuP6/vNY0RmfDVa3TSSdYFAKVilDlFhTBm5HJi6IGpq/Yuim2qemBoEdh12kpAOgi9bFBstbPCkggFQMIIBTKADAgESooIBQwSCAT9L8wPoLK+90CkR2PD9Zh0VCihVzWt+iVc5t9Y7l3Bp0C8TPhUKd8zNOuEifHjrDAtu9kelygmZtQ4hXOVFJqtwlRIHxnfc/MyjgvxhfAFDHb0c+Z/ya5rioWfZRgVWwVbOf7AG15s0Vesuxk8sk88xPDWBI5brO2jRFcvoc5SmGywtXjWJFIFhYELYPqctRsPLm+ecfHWWfTNsnsGx7DKeMRUGM0h4U4UGqM1t7SEB1pKGeBm4DhE8GQsakUpA240Zg6ECpfl4Z7MnS7fs9YwTGOg27xfmV4MEZUyVz0FZqcxY0qyHfcKnkNHrb9WV+/pxfai8GgLMLEku+zIdhdZqrRQwS5wVeuEVPE9TyCeXAVYOgkILj30NcGiCsgj37uh01nk5vqeNzBwppkqGERoxfEHl3VFMPOUFNuoWw4Uj'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon.last.authtype' set to 'Negotiate'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon.last.result' set to '1'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.logon.page.customization.group' set to '/Common/test_kerberos_act_http_401_response_ag'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.rest.clearcache' set to '0'
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.rest.groupname' set to ''
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.rest.requestdomain' set to ''
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.rest.requesttype' set to ''
Feb 12 15:43:21 bigipA info apmd[7948]: 01490007:6: /Common/test_kerberos:Common:214cf0b0: Session variable 'session.rest.username' set to ''
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ./AccessPolicyProcessor/Session.h: 'setSessionInactive()': 1134: 214cf0b0: done with request processing
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'sendAccessPolicyResponse()': 2697: send 'redirect to EUIE' code, redirect URL="/agent_logon_page_401.eui?401&2"
Feb 12 15:43:21 bigipA debug apmd[7948]: 01490266:7: /Common/test_kerberos:Common:214cf0b0: ApmD.cpp: 'process_apd_request()': 1815:  ** done with the request processing **
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Yep, I already tried that, unfortunately no change in behaviour.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I would check /etc/krb5.conf just in case there is something missing or restricting you ciphers options. A tcpdump on ports udp/tcp 88 has usually been useful to me when I had to troubleshoot kerberos.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I think the problem is in your krb5.conf file:

[realms]
 TEST.LOCAL = {
  default_tkt_enctypes = arcfour-hmac des-cbc-md5
 }

I think you should add there the encryption you are using (I think you can just remove that line).

0
Comments on this Answer
Comment made 12-Feb-2018 by Daniel Tremmel 247

I just added my encryption type (https://web.mit.edu/kerberos/krb5-1.15/doc/admin/enctypes.html) to the krb5.conf file and restarted all services (bigstart restart), but unfortunately no change in behaviour.

0
Comment made 12-Feb-2018 by Daniel Varela 711

Can you add this one as well? default_tgs_enctypes with your encryption.

0
Comment made 12-Feb-2018 by Daniel Tremmel 247

This way?

[realms]
 TEST.LOCAL = {
  default_tkt_enctypes = aes256-cts-hmac-sha1-96 arcfour-hmac des-cbc-md5
  default_tgs_enctypes = aes256-cts-hmac-sha1-96
 }

After restarting rba, no changes :-(

0
Comment made 12-Feb-2018 by Daniel Varela 711

It looks right. Have you tried to recreate the keytab file? There might be a mismatch in the kvno version.

I really recommend you to take a capture on the client and f5 on Kerberos protocol. There you will see all the details of why is failing.

0
Comment made 12-Feb-2018 by Daniel Varela 711

Btw, change in your Kerberos auth box the request based auth to disabled. I has given me some problems in the past I don’t know why (you don’t really need to authenticate every request anyway)

0
Comment made 12-Feb-2018 by Daniel Tremmel 247

I already did that (found it in another thread). I now recreated the keytab file, imported it and tested again running a tcpdump. Unfortunately still not working.

The dump shows me that the client sends a TGS-REQ to the domain controller and gets a valid response with TGS-REP. Using klist, I see that a ticket for f5.test.local was fetched and I also see in the dump that the client has sent this ticket to the F5.

0
Comment made 12-Feb-2018 by Daniel Varela 711

Man...I’m running out of ideas :)

Have you check the response to the client from the APM? It may contain a better description of the error, that would be the message I would check. I think the problem got to be there.

If dns, ntp, key tan are correct the only thing left I guess is to contact support.

0
Comment made 12-Feb-2018 by Niels van Sluis 2744

Yeah, doesn’t make sense... what version of the BIG-IP software are you using?

0
Comment made 13-Feb-2018 by Daniel Tremmel 247

I'm also running out of ideas, that was the reason I was writing this article :-)

Software version is 13.1.0.2, but I don't think this is a software-version-thing since I already downgraded to 12.1.3 and it had the same behaviour.

All I see at the client-side is that the client contacts the DC and fetches a Kerberos ticket. This ticket gets send to the APM after the 401 response, I correctly see the "YII..." last.auth.param variable.

I will now setup a completely new domain controller from scratch and test again. Thanks a lot for your help, I will keep you updated ;-)

0
Comment made 13-Feb-2018 by Daniel Varela 711

Good luck!

Just checking the APM log now, it is weird that the variable session.logon.last.result is set to 1 which I think it means success. Can you check in the Kerberos Auth branch configuration what is the result expectig to go on the successful branch?

This is my last try :)

0
Comment made 5 months ago by Brent J 232

@Daniel Tremmel did you resolve this? Thanks

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi,

I had the exact same issue as DAN, spent ages banging my head against the wall,

tickets granted , client request looking good, able to use kinit to get the ticket on the F5 itself, UPN and dns all the same etc.

Turned out it was the keytab encryption, is doesn't like using AES128,or 256. It only works with RC4 or DES* , I did try changing the config in krb5.conf but it didn't seem to make a difference.

thought its worth updating this thread incase someone finds it via google like I did.

cheers

  • I tried: DES-CBC-CRC DES-CBC-MD5 RC4-HMAC-NT AES256-SHA1 AES128-SHA1
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Same problem here. Any updates ?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

For any poor soul coming across this issue - to resolve the issue (only working in version 14)

Under Access > Authentication > Kerberos > (kerberos Server)

Instead of Host-Based server use Kerberos 5 NT Principal

HTTP/hostname-of-virutal-server.domain.name@DOMAIN.NAME eg HTTP/proxy.draven.local@DRAVEN.LOCAL

Hopefully this will save you a few days of wireshark captures.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

just to share, this helped me on my tshoot of kerberos end user authentication with APM

external reference for IIS configuration with Kerberos: https://blogs.msdn.microsoft.com/chiranth/2014/04/17/setting-up-kerberos-authentication-for-a-website-in-iis/

F5 manual: https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-11-5-0/9.html

my setup from scratch:

note: as usual, ensure dns - fwd and reverse records are configured correctly for the F5 VS with the APM access policy doing kerberos end user authentication. ensure the KDC is reachable from the client and is able to get kerberos tickets. enable port 88, 53 for kerberos and dns traffic. bigip and client needs to properly resolve dns records for the protected site.

a) here is my working setspn command: setspn -a HTTP/ww1.domain.dom user output:

Registering ServicePrincipalNames for CN=user,CN=Users,DC=domain,DC=dom HTTP/ww1.domain.dom Updated object

b) ktpass command: ktpass -princ HTTP/ww1.domain.dom@DOMAIN.DOM -mapuser user@DOMAIN.DOM -crypto rc4-hmac-nt -ptype KRB5_NT_PRINCIPAL -pass xxxxxxx -out c:\kerb.keytab

output: Targeting domain controller: ad.domain.dom Using legacy password setting method Successfully mapped HTTP/ww1.domain.dom to user. Key created. Output keytab to c:\kerb.keytab: Keytab version: 0xxxx keysize xx HTTP/ww1.domain.dom@DOMAIN.DOM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0xxx (RC4-HMAC) keylength 16 (0xxxxxxxxx)

notice the vno value = 3

c) import the keytab file in APM kerberos AAA and run the verification to confirm the same kvno value as when it was generated in AD

command: klist -ekt /config/filestore/files_d/Common_d/kerberos_keytab_file_d/:Common:keytabfile

output:

Keytab name: FILE:/config/filestore/files_d/Common_d/kerberos_keytab_file_d/:Common:keytabfile KVNO Timestamp Principal


3 01/01/70 07:30:00 HTTP/ww1.domain.dom@DOMAIN.DOM (arcfour-hmac) >>>>>>>>>!!!!!!!! KVNO 3

d) for the user mapped with the SPN in AD, enable 'trust this user for delegation to any service Kerberos only'

note: for d), this is how it worked for me following the external MS resource reference. configure as needed on your environment.

e) the AD user mapped for the SPN is also used in my IIS site for the application pool identity - something to do with decrypting the kerberos ticket

f) APM krb5.conf - v12.1.3

====== Initially added under realms per K13399

DOMAIN.DOM = { master_kdc = ad.domain.dom kdc = ad.domain.dom admin_server = ad.domain.dom

}

After a few bigstart restart rba, here is the resulting krb5.conf

[root@apm] config # cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log

[libdefaults] default_realm = EXAMPLE.COM

F5mod

dns_lookup_realm = true dns_lookup_kdc = true

ticket_lifetime = 24h renew_lifetime = 7d forwardable = true

[realms] EXAMPLE.COM = { kdc = kerberos.example.com admin_server = kerberos.example.com } DOMAIN.DOM = { default_tkt_enctypes = arcfour-hmac des-cbc-md5 }

[domain_realm] domain.dom = DOMAIN.DOM .domain.dom = DOMAIN.DOM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [root@apm] config #

============== K13399: Configuring the BIG-IP system to use multiple Kerberos KDCs

g) here is how tickets look like from the client device for the SPN - see "#2>"

C:\Users\user1>klist tickets

Current LogonId is 0:0xxxxxx

Cached Tickets: (3)

0> Client: user1 @ DOMAIN.DOM

    Server: krbtgt/DOMAIN.DOM @ DOMAIN.DOM
    KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
    Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
    Start Time: 11/26/2018 14:09:49 (local)
    End Time:   11/27/2018 0:09:49 (local)
    Renew Time: 12/3/2018 14:09:49 (local)
    Session Key Type: RSADSI RC4-HMAC(NT)

1> Client: user1 @ DOMAIN.DOM

    Server: krbtgt/DOMAIN.DOM @ DOMAIN.DOM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
    Start Time: 11/26/2018 14:09:49 (local)
    End Time:   11/27/2018 0:09:49 (local)
    Renew Time: 12/3/2018 14:09:49 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96

2> Client: user1 @ DOMAIN.DOM

    Server: HTTP/ww1.DOMAIN.DOM @ DOMAIN.DOM
    KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
    Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_deleg

ate Start Time: 11/26/2018 14:09:49 (local) End Time: 11/27/2018 0:09:49 (local) Renew Time: 12/3/2018 14:09:49 (local) Session Key Type: RSADSI RC4-HMAC(NT)

g) working kerberos auth logs - /var/log/apm when rba debug (tmsh modify sys db log.rba.level value debug) is enabled

Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:688 Received Response Key: session.logon.last.authparam Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:689 Received Response Val: YII<... long encoded string...>9EA= Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:688 Received Response Key: session.logon.last.authtype Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:689 Received Response Val: Negotiate Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:688 Received Response Key: session.logon.last.username Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:689 Received Response Val: user1@DOMAIN.DOM Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:688 Received Response Key: session.logon.page.challenge Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:689 Received Response Val: Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:688 Received Response Key: session.logon.page.errorcode Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:689 Received Response Val: Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:688 Received Response Key: session.server.network.name Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:689 Received Response Val: ww1.domain.dom Nov 26 14:10:11 apm debug rba[16259]: 01490000:7: RBA:rba.cpp:402 rbaClientHandler auth successfully!

hopefully this also help someone trying this config.

0