Increased authentication times, with LDAP queries
search cancel

Increased authentication times, with LDAP queries

book

Article ID: 272919

calendar_today

Updated On:

Products

ISG Proxy

Issue/Introduction

Increased authentication times, with LDAP queries

Environment

Release :

Resolution

From LSA Debug:
3854.891 4003CC Exiting Select_impl::Select(0)
3854.891 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.891 4003CC Select_impl::Check_async_complete(IO_READ, 30FB5BC8F40, 140)
3854.891 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.891 4003CC Select_impl::Check_async_complete(IO_READ, 30FBAE7CC40, 140)
3854.891 4003CC Select_impl::Check_async_complete(IO_READ, 111E7311244)
3854.891 4003CC Select_impl::Select CK_Receive returned signal for complete 2000000
3854.891 4003CC FD_Socket<30FB5BC8F40>::Perform_IO() return=140
3854.891 4003CC FD_Socket<30FB5BC8F40>::Perform_IO(IO_WRITE, 30FB59630F4, 140, 0)
3854.891 TRACE: lwio - [RdrSocketReceivePacket() socket.c:732] Status: STATUS_PENDING = 0x00000103 (259)
3854.891 TRACE: lwio - [RdrSocketRead() socket.c:1991] Status: STATUS_PENDING = 0x00000103 (259)
3854.891 4003CC FD_Socket<30FB5BC8F40>::Perform_IO() return=-1
3854.891 4003CC FD_Socket<30FB5BC8F40>::Perform_IO(IO_READ, 40FB1A5F024, 4, 0)
3854.890 4003CC FD_Socket<30FBAE7CC40>::Perform_IO() return=1
3854.890 4003CC FD_Socket<30FBAE7CC40>::Perform_IO(IO_READ, 30FBEBBB380, 1, 0)
3854.890 4003CC Exiting Select_impl::Select(1)
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 111E7311244)
3854.890 4003CC Select_impl::Finish_async_select(1, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ)
3854.890 4003CC Select_impl::Start_async_select(1, 30FBEBBB0B0, 30FBEBBB5F0, 1, IO_WRITE, 0)
3854.890 4003CC FD_Socket<30FBAE7CC40>::Select_read_async() return=1
3854.890 4003CC Select_impl::Start_async_select(1, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ, 111E7311244)
3854.890 4003CC Select_impl::Select(1, 30FBEBBB3F0, 30FBEBBB5F0, 30FBEBBB7F0, {0, 0})
3854.890 TRACE: lwio - [RdrFreeContext() driver.c:603] Freed op context 20FB57BE544
3854.890 KRB5-TRACE keytab file:  krb5_ktfile_close() at kt_file.c:259: 
3854.890 KRB5-TRACE keytab file:  krb5_ktfile_close() at kt_file.c:259: 
3854.890 KRB5-TRACE:  [4195276] 1691349220.15016: Destroying ccache MEMORY:2266492560876
3854.890 KRB5-TRACE:  krb5_cc_destroy() at ccfns.c:69: 
3854.890 TRACE: lwio - [RdrFreeContext() driver.c:603] Freed op context 20FB57BE404
3854.890 TRACE: lwio - [RdrCreateTreeConnect2Complete() create2.c:143] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 TRACE: lwio - [RdrTransceiveCreate2() create2.c:231] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 4003CC FD_Socket<30FBAE7C9C0>::Perform_IO() return=1
3854.890 4003CC FD_Socket<30FB5BC8F40>::Perform_IO(IO_READ, 40FB1A5F024, 4, 0)
3854.890 4003CC Exiting Select_impl::Select(1)
3854.890 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 30FBAE7CC40, 140)
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 111E7311244)
3854.890 4003CC Select_impl::Select CK_Receive returned signal for complete 2000000
3854.890 4003CC Select_impl::Select calling CK_Receive with signal mask for complete 2000000
3854.890 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=0
3854.890 4003CC Select_impl::Finish_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ)
3854.890 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Capture_async_select(IO_READ, 30FB5BC8F40, 0)
3854.890 4003CC Select_impl::Start_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ, 111E7311244)
3854.890 4003CC Select_impl::Select(3, 30FBEBBB3F0, 30FBEBBB5F0, 30FBEBBB7F0, {19, 999920})
3854.890 4003CC Exiting Select_impl::Select(0)
3854.890 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 30FB5BC8F40, 140)
3854.890 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 30FBAE7CC40, 140)
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 111E7311244)
3854.890 4003CC Exiting Select_impl::Select(1)
3854.890 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 30FB5BC8F40, 140)
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 111E7311244)
3854.890 4003CC Select_impl::Select CK_Receive returned signal for complete 2000000
3854.890 4003CC Select_impl::Select calling CK_Receive with signal mask for complete 2000000
3854.890 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=0
3854.890 4003CC Select_impl::Finish_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ)
3854.890 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Capture_async_select(IO_READ, 30FBAE7CC40, 0)
3854.890 TRACE: lwio - [RdrNegotiateGssContextWorkItem2() connect2.c:525] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 4003CC Select_impl::Capture_async_select(IO_READ, 111E7311244)
3854.890 TRACE: lwio - [RdrSessionSetupComplete2() connect2.c:715] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 4003CC Select_impl::Select CK_Receive returned signal 2000000
3854.890 TRACE: lwio - [RdrTransceiveTreeConnect2() connect2.c:850] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 C48005CC FD_Socket<30FBAE7C9C0>::Perform_IO() return=1
3854.890 C48005CC FD_Socket<30FBAE7C9C0>::Perform_IO(IO_WRITE, 20FB28AE7B0, 1, 0)
3854.890 TRACE: lwio - [RdrCreateContext() driver.c:555] Created op context 20FB57BE2C4
3854.890 GSSAPI:  gss_inquire_sec_context_by_oid() at g_inq_context_oid.c:60 [Minor: 22]
3854.890 KRB5-TRACE:  [-998242868] 1691349220.15013: Read AP-REP, time 1691349220.15009, subkey rc4-hmac/0635, seqnum 299587167
3854.890 4003CC Select_impl::Select calling CK_Receive with signal mask A000000
3854.890 4003CC Select_impl::Start_async_select(3, 30FBEBBB0B0, 30FBEBBB5F0, 0, IO_WRITE, 0)
3854.890 4003CC FD_Socket<30FB5BC8F40>::Select_read_async() returned EASYNC_WILL_SIGNAL
3854.890 4003CC FD_Socket<30FBAE7CC40>::Select_read_async() returned EASYNC_WILL_SIGNAL
3854.890 4003CC Select_impl::Start_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ, 111E7311244)
3854.890 KRB5-TRACE:  krb5_rd_rep() at rd_rep.c:133: 
3854.890 4003CC Select_impl::Select(3, 30FBEBBB3F0, 30FBEBBB5F0, 30FBEBBB7F0, {29, 999940})
3854.890 TRACE: lwio - [RdrSocketTask() socket.c:1365] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 TRACE: lwio - [RdrSocketReceivePacket() socket.c:732] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 TRACE: lwio - [RdrSocketRead() socket.c:1991] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 4003CC FD_Socket<30FB5BC8F40>::Perform_IO() return=-1
3854.890 4003CC FD_Socket<30FB5BC8F40>::Perform_IO(IO_READ, 40FB1A5F024, 4, 0)
3854.890 4003CC Exiting Select_impl::Select(0)
3854.890 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Select(1, 30FBEBBB3F0, 30FBEBBB5F0, 30FBEBBB7F0, {0, 0})
3854.890 TRACE: lwio - [RdrProcessSessionSetupResponse2() connect2.c:368] Status: STATUS_PENDING = 0x00000103 (259)
3854.890 TRACE: lwio - [RdrContinueContext() driver.c:637] Continuing context 20FB57BE544
3854.890 4003CC FD_Socket<30FB5BC8F40>::Perform_IO() return=235
3854.890 4003CC FD_Socket<30FB5BC8F40>::Perform_IO(IO_READ, 40FA2C87028, 235, 0)
3854.890 4003CC FD_Socket<30FB5BC8F40>::Perform_IO() return=4
3854.890 4003CC FD_Socket<30FB5BC8F40>::Perform_IO(IO_READ, 40FA2C87024, 4, 0)
3854.890 4003CC Exiting Select_impl::Select(1)
3854.890 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 30FBAE7CC40, 140)
3854.890 4003CC Select_impl::Check_async_complete(IO_READ, 111E7311244)
3854.890 4003CC Select_impl::Select CK_Receive returned signal for complete 2000000
3854.890 4003CC Select_impl::Select calling CK_Receive with signal mask for complete 2000000
3854.890 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=0
3854.890 4003CC Select_impl::Finish_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ)
3854.890 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.890 4003CC Select_impl::Capture_async_select(IO_READ, 30FB5BC8F40, 0)
3854.890 4003CC Select_impl::Capture_async_select(IO_READ, 111E7311244)
3854.890 4003CC Select_impl::Select CK_Receive returned signal 2000000
3854.888 4003CC Select_impl::Select calling CK_Receive with signal mask A000000
3854.888 4003CC Select_impl::Start_async_select(3, 30FBEBBB0B0, 30FBEBBB5F0, 0, IO_WRITE, 0)
3854.888 4003CC FD_Socket<30FB5BC8F40>::Select_read_async() returned EASYNC_WILL_SIGNAL
3854.888 4003CC FD_Socket<30FBAE7CC40>::Select_read_async() returned EASYNC_WILL_SIGNAL
3854.888 4003CC Select_impl::Start_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ, 111E7311244)
3854.888 4003CC Select_impl::Select(3, 30FBEBBB3F0, 30FBEBBB5F0, 30FBEBBB7F0, {19, 999935})
3854.888 4003CC Exiting Select_impl::Select(0)
3854.888 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.888 4003CC Select_impl::Check_async_complete(IO_READ, 30FB5BC8F40, 140)
3854.888 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.888 4003CC Select_impl::Check_async_complete(IO_READ, 30FBAE7CC40, 140)
3854.888 4003CC Select_impl::Check_async_complete(IO_READ, 111E7311244)
3854.888 4003CC Select_impl::Select CK_Receive returned signal for complete 2000000
3854.888 4003CC Select_impl::Select calling CK_Receive with signal mask for complete 2000000
3854.888 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=0
3854.888 4003CC FD_Socket<30FBAE7CC40>::Cancel_select_read_async() return=0
3854.888 4003CC Select_impl::Finish_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ)
3854.888 4003CC Select_impl::Select CK_Receive returned signal 8000000
3854.888 4003CC Select_impl::Select calling CK_Receive with signal mask A000000
3854.888 4003CC Select_impl::Start_async_select(3, 30FBEBBB0B0, 30FBEBBB5F0, 0, IO_WRITE, 0)
3854.888 4003CC FD_Socket<30FB5BC8F40>::Select_read_async() returned EASYNC_WILL_SIGNAL
3854.888 4003CC FD_Socket<30FBAE7CC40>::Select_read_async() returned EASYNC_WILL_SIGNAL
3854.888 4003CC Select_impl::Start_async_select(3, 30FBEBBAEB0, 30FBEBBB3F0, 0, IO_READ, 111E7311244)
3854.888 4003CC Select_impl::Select(3, 30FBEBBB3F0, 30FBEBBB5F0, 30FBEBBB7F0, {0, 0})
3854.888 4003CC FD_Socket<30FB5BC8F40>::Perform_IO() return=1708
3854.888 4003CC FD_Socket<30FB5BC8F40>::Perform_IO(IO_WRITE, 111E6B1C044, 1708, 0)
3854.888 4003CC FD_Socket<30FBAE7CC40>::Perform_IO() return=1
3854.888 4003CC FD_Socket<30FBAE7CC40>::Perform_IO(IO_READ, 30FBEBBB380, 1, 0)
3854.888 4003CC Exiting Select_impl::Select(1)
3854.888 4003CC FD_Socket<30FB5BC8F40>::Cancel_select_read_async() return=SOCKET_ERROR errno=22
3854.888 4003CC Select_impl::Check_async_complete(IO_READ, 30FB5BC8F40, 140)

From the LSA debug, It can be seen that the Kerberos authentication process is largely incomplete, and with lots of socket (communication) errors, and with the negotiation status never determined, remained in the "PENDING" state.

With the failure of the Kerberos authentication, expectedly, by design, the appliance falls back to use NTLM for authentication, and investigating the auth. debug log, you would see the log lines for the NTLM authentication process, as shown below.

3857.473 User_auth::Authenticate
3857.473 DD-AUTH:authenticate() at user_auth_admin.cpp:1411: User_auth_admin::authenticate(transaction=683053, realm=admin, username=)
3857.473 TT 50FAE0774A0 Start_auth 0 0 0 683053 - tcp://a1.xxx.xxx.xx.xx:443/ tenancy - trans: - cookie: - rcp: -
3857.450 TT 50FAE0774A0 End_auth 0 0 0 683052 - tcp://a1.xxx.xxx.xx.xx:443/ tenancy - trans: - cookie: - rcp: -
3857.450 DD-AUTH:authenticate() at user_auth_admin.cpp:2200: User_auth_admin::authenticate(transaction=683052) returning 2425292
3857.450 Realm admin, authenticate result 2425292
3857.450 Sending NTLM challenge with context ID: 0x3A
3857.450 B64 Cred: TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAKAGFKAAAADw==
3857.450 DD-AUTH:authenticate_surrogate() at user_auth_admin.cpp:1023: authenticate_surrogate(transaction=683052) returning 2425098
3857.450 DD-AUTH:Reset_encoded_cookie() at user_cookie.cpp:727: User_cookie::Reset_encoded_cookie()
3857.450 DD-AUTH:Reset_logged_out_cookie() at user_cookie.cpp:654: User_cookie::Reset_logged_out_cookie() calling Reset_cookies()
3857.450 DD-AUTH:Resolve_surrogate() at user_credentials.cpp:161:     [683052] realm=40FB308C360, cookie=111B626A050, ignore_x_header=false
3857.450 DD-AUTH:Resolve_surrogate() at user_credentials.cpp:160: User_credentials::Resolve_surrogate(transaction=683052)
3857.450 DD-AUTH:authenticate_surrogate() at user_auth_admin.cpp:949: User_auth_admin::authenticate_surrogate(transaction=683052, user=, realm=admin)
3857.450 DD-AUTH:update_realm_info() at user_auth_session.cpp:1297: User_auth_session::update_realm_info(transaction=683052) returning
3857.450 DD-AUTH:update_realm_info() at user_auth_session.cpp:1287:     [683052] realm_use_persistent_cookies: false
3857.450 DD-AUTH:update_realm_info() at user_auth_session.cpp:1264:     [683052] realm->Use_persistent_cookies(): false
3857.450 DD-AUTH:update_realm_info() at user_auth_session.cpp:1259: User_auth_session::update_realm_info(transaction=683052)
3857.450 Not authenticated.
3857.450 User_auth::Authenticate
3857.450 DD-AUTH:authenticate() at user_auth_admin.cpp:1411: User_auth_admin::authenticate(transaction=683052, realm=admin, username=)
3857.450 TT 50FAE0774A0 Start_auth 0 0 0 683052 - tcp://a1.xxx.xxx.xx.xx:443/ tenancy - trans: - cookie: - rcp: -
3857.391 TT 50FAE0934A0 Release 0 0 0 0 -  tenancy - trans: default cookie: - rcp: -
3857.391 User_auth_admin: Message 8  4DC005D1
3857.390 TT 50FAE0934A0 End_auth 0 0 0 683051 - tcp://a1.xxx.xxx.xx.xx:443/ tenancy - trans: - cookie: - rcp: -
3857.390 DD-AUTH:authenticate() at user_auth_admin.cpp:2200: User_auth_admin::authenticate(transaction=683051) returning 2425098
3857.390 Realm admin, authenticate result 2425098
3857.390 DD-AUTH:authenticate_surrogate() at user_auth_admin.cpp:1023: authenticate_surrogate(transaction=683051) returning 2425098
3857.390 DD-AUTH:Reset_encoded_cookie() at user_cookie.cpp:727: User_cookie::Reset_encoded_cookie()
3857.390 DD-AUTH:Reset_logged_out_cookie() at user_cookie.cpp:654: User_cookie::Reset_logged_out_cookie() calling Reset_cookies()
3857.390 DD-AUTH:Resolve_surrogate() at user_credentials.cpp:161:     [683051] realm=40FB308C360, cookie=111B626A050, ignore_x_header=false
3857.390 DD-AUTH:Resolve_surrogate() at user_credentials.cpp:160: User_credentials::Resolve_surrogate(transaction=683051)
3857.390 DD-AUTH:authenticate_surrogate() at user_auth_admin.cpp:949: User_auth_admin::authenticate_surrogate(transaction=683051, user=, realm=admin)
3857.390 DD-AUTH:update_realm_info() at user_auth_session.cpp:1297: User_auth_session::update_realm_info(transaction=683051) returning
3857.390 DD-AUTH:update_realm_info() at user_auth_session.cpp:1287:     [683051] realm_use_persistent_cookies: false
3857.390 DD-AUTH:update_realm_info() at user_auth_session.cpp:1264:     [683051] realm->Use_persistent_cookies(): false
3857.390 DD-AUTH:update_realm_info() at user_auth_session.cpp:1259: User_auth_session::update_realm_info(transaction=683051)

So, with NTLM, and by design, you should expect a much longer authentication time.

Note 1:

Amongst the many dissimilarities between NTLM and Kerberos is the speed of the end-to-end authentication process.

  • Kerberos is faster than NTLM in authentication operations. NTLM slows down domain controllers. This is because Kerberos uses a ticket-based authentication system, which reduces the need for continuous back-and-forth communication with the domain controller (DC). Once a user is authenticated, Kerberos provides the user with a time-limited ticket that can be used to access multiple network resources without the need to reauthenticate for each resource. This reduces the load on domain controllers and network traffic, resulting in better performance.
  • NTLM, on the other hand, involves a challenge-response mechanism, where the client must respond to a series of authentication challenges from the server (or domain controller) for each resource access. This can lead to more frequent interactions with the domain controller and potentially slower performance, especially in multi-resource scenarios.

Note 2:

Even if you configure IWA to allow Kerberos, Kerberos will only be used if configured properly. If the ProxySG appliance appliance cannot successfully negotiate Kerberos with a client, it will silently downgrade to use NTLM authentication. Because this happens behind the scenes, you may not know whether you are using Kerberos or NTLM.

So, after the upgrade to SGOS 7.3.x.x, it's important to check to verify that Kerberos authentication still works. If it doesn't, you may need to check the implementation, to fix that. To troubleshoot Kerberos authentication, please refer to the guidance provided in the Tech. Doc. with the URL below.

https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/edge-swg/7-3/authentication_co/IWA_configure_st/IWA_Direct_st/IWA_verify_Kerberos_auth_ta.html 

For configuring Kerberos authentication on ProxySG, please refer to the guidance detailed in the Tech. Article with the URL below.

https://knowledge.broadcom.com/external/article/168161/configure-kerberos-authentication-for-ed.html

Note 3: Authenticating with NTLM does not imply performance issues. The response time for NTLM authentication would be much higher than with Kerberos. This is expected and usually wouldn't be significant enough to impact web access in a noticeably negative way.

Note 4: Should the customer required help with troubleshooting/fixing Kerberos authentication configuration, from ProxySG perspective, this will be considered as a new, and separate, request and will require a new/separate Technical Support ticket, in line with Broadcom's "one issue, one ticket" guidance.

For Kerberos Authentication steps, please refer to the snippet below, to help describe the end-to-end flow, with Kerberos, and to further help show that the Kerberos authentication investigated in this case simply did not complete and wasn't successful, explaining why the fallback to NTLM happened, hence the clear reason why the authentication time reported was indeed much higher. 

KRB_AS_REQ: Request TGT from Authentication Service (AS)

The client’s request includes the user’s User Principal Name (UPN) and a timestamp. It is encrypted using the user’s password hash.

KRB_AS_REP: TGT Received from Authentication Service

The KDC uses the UPN to look up the client in its database and uses the user’s password hash to attempt to decrypt the message.

AS generates a TGT containing the client ID, client network address, timestamp, lifetime and a session key (SK1).

If the KDC successfully decrypts the TGT request and if the timestamp is within the KDC’s configured time skew, the authentication is successful.

A TGT and a TGS session key are sent back to the client. The TGS session key is used to encrypt subsequent requests.

KRB_TGS_REQ: Present TGT and TGS request

The client presents its TGT along with a request that includes the SPN for the service it wants to access.  The TGS request is encrypted with the TGS session key.

KRB_TGS_REP: Receive TGS from KDC

The KDC attempt to validate the TGT; if successful, it generates a TGS that contains information about the requestor, such as their SID and group memberships, and is encrypted with the service’s password hash.

The TGS and the service session keys are encrypted with the TGS session key and sent back to the client.

KRB_AP_REQ: Present TGS to Application Server for Authorization

The client sends the TGS that it received from the KDC to the application server, along with an authenticator message that is encrypted with the service session key.

KRB_AP_REP: Grant Client Access to the Service

The client receives the message and decrypts it with the service session key.

The Application Server extracts the Privilege Attribute Certificate (PAC) from the service ticket to verify its contents with a domain controller.

Validation of the ticket and PAC happens only when the TGT is older than 20 minutes.

Factors Affecting Kerberos Operation

There are a handful of factors that problems if not sufficiently provided for.

  • Replication is required between domain controllers.
    • If multiple domain controllers (and therefore multiple KDCs) are deployed, then replication must be enabled and happen in a timely manner. Should replication fail or be delayed, authentication failures are possible when a user changes their password.
  • Clients and KDCs must use NetBIOS and DNS name resolution.
    • Kerberos Service Principal Names normally include NetBIOS and DNS addresses, which means both the KDC and client must be able to resolve those names the same way. In certain situations, IP addresses may also be used in Service Principal Names.
  • Clients and KDCs must have their clocks synchronized.
    • Accurate measurement of time is important to prevent replay attacks. Kerberos supports a configurable time skew (5 minutes by default), outside of which client authentication will fail.
  • Clients and KDCs must be able to communicate on the network.
    • Kerberos traffic occurs on TCP and UDP port 88, which must be accessible from all clients to at least one KDC.
  • Clients, users and services must have unique names.
    • Duplicate credentials for computers, users or Service Principal Names can cause unexpected Kerberos authentication
Powered by Wolken Software