0

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/test.machine.examaple.com@EXAMPLE.COM)—————>

     <——— 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?

kee
  • 46
  • 2
  • 10
  • 1
    You are confused. The application server *never* contacts the KDC. The GSS-API mechanism on UNIX/LINUX as part of AP-REQ validates the user after decrypting the inbound credentials using a keytab deployed on that UNIX/LINUX server. On Windows, SSPI handles all of this by itself no keytab needed during AP-REQ. You are going on about AS-REQ which is between the client and the KDC. The app server is not part of this exchange to this point yet. – T-Heron Aug 23 '20 at 23:34
  • I could not articulate correctly, my bad. My test application is not a service. It is just a test tool that can run on client to validate a user's AD credentials. I would liek to extend this test-tool's capability so that It can send TGS-REQ after validating the user from AS-REP. I did rephrase my question. Thanks. – kee Aug 24 '20 at 09:13
  • @T-Heron I think in case of Delegation (S4U2Self/Proxy), GSS-API does contact the KDC. – Bhushan Karmarkar Aug 24 '20 at 09:14
  • sorry for editing the question again, but this captures my ask now. – kee Aug 24 '20 at 09:38
  • @BhushanKarmarkar - he wasn't talking about delegation in this case. – T-Heron Aug 24 '20 at 10:49

2 Answers2

0

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.

Dharman
  • 30,962
  • 25
  • 85
  • 135
Bhushan Karmarkar
  • 625
  • 7
  • 22
  • By validating KDC, am trying to address kdc spoofing vulnerability https://www.securityfocus.com/bid/1616/discuss. My test-client validates the user just by AS_REP and ignore further TGS_REQ/TGS-REP. This (https://www.silverfort.com/blog/silverfort-researchers-panw-pan-os-cve-2020-2002/) gives a great amount of info on this vulnerability – kee Aug 26 '20 at 18:41
  • Sorry I did not get where to add these options? Please see my new comment. – kee Sep 01 '20 at 13:09
0

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 userone@my.domain.com

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 = “userone@my.domain.com” 

 err = krb5_parse_name(krb5ctx, spn, &server_princ); // spn = “HOST/test-host.my.domain.com@MY.DOMAIN.COM”

 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 ?

kee
  • 46
  • 2
  • 10
  • do you use Krb5 Conf file? if yes, please paste it here. UDP will used by default instead of TCP if the packet size is smaller than a certain size (it configurable with Krb conf, it has some default value). Usually UDP is blocked at DC level. You can check firewall settings. If Linux machine is sending UDP packets,then definitely they are filtered at DC. – Bhushan Karmarkar Sep 02 '20 at 05:12