KDC validation from TGS-REP

Question

I have a question on validating the KDC from TGS-REP.

I have a legacy test tool written in c++ that validates the user's AD credentials. This test-tool invokes krb5 library methods for performing the authentication and runs on client (linux machine). I could see in the packet capture that the test-tool is validating the user from AS-REP.

test-tool on client <-------> AD Server

-———----——— AS-REQ—————>

<-———----——— AS-REP—————

(user will be validated by now)

The test-tool is validating the user from AS-REP.

It is not sending/receiving TGS-REQ/TGS-REP. ***I learned that from TGS-REP, we can validate the KDC as well. *** So am extending that tool to do the below:

test-tool on client <-------> AD Server

 -———----——— AS-REQ—————>

 <----——— AS-REP —————


      
    —————— TGS-REQ (with sname: host/[email protected])—————>

     <——— TGS-REP—————

....... my test-toold will validate the KDC by comparing the secret key for the KDC with a pre-configured keytab. I have created a keytab for the above SPN.

Q: From some online readings, I could read that this can be done by comparing the secret key for the KDC with a pre-configured keytab file. Am sure that I do not get this completely. Please help me to understand this part. Why can not we get this validation from AS-REP?

Answer 1

I am not really getting what you meant by validating KDC. Usually an incoming kerberos ticket is validated. When validating the incoming token, there is no need to make a round trip to KDC.
The incoming kerberos token is encrypted using SPN's password (key). This key to decrypt the token is present in keytab only.

Check this link to understand how its done.

Further, there are two main parts to consider - Acceptor and Initiator.

The service where the token is validated, can be

• Acceptor - Accept and validate the ticket using keytab or username/password provided in configuration
• Initiator - Application can demand token for self/other service
• Acceptor + Initiator - where you validate the incoming token and based on that, request new token to KDC - these are the cases such as delegation and impersonation.

The Kerberos flavor I use has a configuration to make the application as Initiator or Acceptor. Based on that GSS-API decide whether to communicate with KDC or not.

Answer 2

Okay, here is what I done to get my requirement.

krb5_context  krb5Context;

 krb5_init_context(&krb5Context);

…

// get initial tkts (AS-REQ/AS-REP) for user [email protected]

krb5_get_init_creds_password(krb5Context,... )

…

// store the tkt in cache
krb5_cc_default()
krb5_cc_initialize()
krb5_cc_store_cred()
…

krb5_creds in_creds, out_creds;
memset(&in_creds, 0, sizeof(in_creds));

err = krb5_parse_name(krb5ctx, user, &user_princ); // user = “[email protected]” 

 err = krb5_parse_name(krb5ctx, spn, &server_princ); // spn = “HOST/[email protected]”

 in_creds.client = user_princ; 
 in_creds.server = server_princ; 

…
// send TGS-REQ if srv tkt not there in cache,
// receive a session tkt for above srvc in TGS-REP

krb5_get_credentials()

// decrypt the srvc tkt using the key in keytab file

krb5_decode_ticket()

krb5_kt_default()

krb5_kt_get_entry()
krb5_decrypt_tkt_part()

...
krb5_free...

---

This is working for me but am facing two problems here.

1. My test-tool is failed with "error: Cannot contact any KDC for realm 'MY.DOMAIN.COM'" upon every alternative execution. It passes the test alternatively. I have verified my krb5.conf and it has required entries for realm.

2. When the test succeeds (no krb5 errors while decoding the tkt, reading keytab, decrypting the srvc tkt), I did not see TGS-REQ/TGS-REP in the packet traces captured on my domain controller. But at the same time, there were "TGS-REQ" UDP packets on my linux box where the test-tool ran.

What can be the reason for the above observations ?