0

I have a client on windows which is sending a kerberos token obtained from windows using sspi. When I pass in client's token to gss_accept_sec_context on server (Linux Redhat 8) , I get "An unsupported mechanism was requested"

I am calling the gss_accept_sec_context as below:

j_stat = gss_accept_sec_context(&min_stat, context,
                                            *server_creds, &recv_tok,
                                            GSS_C_NO_CHANNEL_BINDINGS,
                                            &client, &doid, &send_tok,
                                            NULL,
                                            NULL,  /* time_rec */
                                            NULL); /* del_cred_handle */

I acquire the credentials as :

OM_uint32 maj_stat, min_stat;

  maj_stat = gss_acquire_cred(&min_stat, GSS_C_NO_NAME,
                             GSS_C_INDEFINITE , 
                             GSS_C_NO_OID_SET, 
                             GSS_C_ACCEPT,
                             server_creds,
                             NULL, NULL);

What could be the problem?

ekhanad
  • 154
  • 2
  • 8
  • 1
    you can check the network logs to confirm it is kerberos token and not NTLM. Kerberos token has size of around 1600-1700 bytes, while the NTLM toke is much shorter. – Bhushan Karmarkar Aug 18 '20 at 04:58
  • @BhushanKarmarkar You haven't seen real token with PAC data inside. – Michael-O Aug 19 '20 at 07:06
  • Is there a way to check the type of the token? – ekhanad Aug 19 '20 at 07:54
  • @Michael-O thanks, I just read about PAC data. The products i worked on has their own authorization such as roles and groups. They rely on kerberos solely for authentication. – Bhushan Karmarkar Aug 19 '20 at 08:17
  • @BhushanKarmarkar Regardless of that. You ticket issued from AD WILL include PAC data. – Michael-O Aug 19 '20 at 08:46
  • @Michael-O Could one check the type of the token or see its contents by using some tool? – ekhanad Aug 19 '20 at 09:43
  • 1
    [This](https://lapo.it/asn1js/) is generally a good tool. Wireshark gives more context if you have the keytab at hand. – Michael-O Aug 19 '20 at 10:21
  • @Michael-O okay. Our applications only checks whether the token can be accepted. If yes, the principal has userid which we need. Authorization is taken care by the application – Bhushan Karmarkar Aug 19 '20 at 11:13

1 Answers1

1

I hightly doubt that. It is likely an NTLM or SPNEGO token.

Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • The client is sending me a 66 bytes long token! – ekhanad Aug 27 '20 at 12:42
  • NTLM Type 1 message? – Michael-O Aug 27 '20 at 21:18
  • No it does not contain the string "ASCII string 'NTLMSSP" but contains my user name (at offset 41) and domain (offset 52) at the end of the token. It contains the following object identifier: 1.2.840.113554.1.2.2.3 – ekhanad Aug 28 '20 at 09:07
  • Interesting that is performs Kerberos U2U. Can you provide a token in Base64? What SPN do you pass to the `InitializeSecurityContext` function? – Michael-O Aug 28 '20 at 09:50
  • https://tools.ietf.org/html/draft-ietf-cat-user2user-02. It seems that your setup on the server is incorrect. – Michael-O Aug 28 '20 at 09:52
  • I get the following error in the windows event log on the client side when obtaining a token: ` A Kerberos error message was received: on logon session Client Time: Server Time: 9:48:40.0000 8/28/2020 Z Error Code: 0x1b Unknown Error Extended Error: Client Realm: Client Name: ** Server Realm: MYORG.ORG** **Server Name: MYUSERNAME** **Target Name: MYUSERNAME@MYORG.ORG** Error Text: File: onecore\ds\security\protocols\kerberos\client2\kerbtick.cxx Line: 128d Error Data is in record data. ` – ekhanad Aug 28 '20 at 10:01
  • 1
    I highly recommend to use Wiresharl now. Especially the `TGS-REQ`. – Michael-O Aug 28 '20 at 12:22
  • I have used wireshark and I get following error on the client side when calling `InitializeSecurityContext()`: **KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN ** i am using username@MyDomain.ORG? What could be wrong? – ekhanad Sep 01 '20 at 16:21
  • 1
    And that's the whole point. You are requesting a service ticket for a UPN therefore you get Kerberos U2U. You must request a service ticket for a SPN! – Michael-O Sep 01 '20 at 17:16
  • Actully UPN is working! I was running as admin on server and trying to get the token for the user. It is possible for admin to get token for a user without using the password? only thing i get from the client is a user name and a token. – ekhanad Sep 04 '20 at 06:33