Validate Service ticket by using another Computer account and Keytab

[minli1]

Hi, I am asking how to validate the service ticket with another account(machine account) + keytab file. Any insights appreciated!

What I got now:

1. get the local user service ticket(AP-REQ) by SSPI, like below, say the current logged on user is UserA, this user can get a service ticket to the current Host with a success.

var hostName = Environment.MachineName.ToLowerInvariant();
var context = new SspiContext(spn: hostName);
byte[] tokenBytes = context.RequestToken();

2. I have another machine account say ComputerB and it's a valid keytab file.

My question is how to validate the service ticket got from step 1 by using the ComputerB the keytab. Is there any S4U way for validating this? @SteveSyfuhs

[SteveSyfuhs]

It's not entirely clear what you're trying to accomplish. You're requesting a ticket to the current host. Is ComputerB the current host? If the current host is not ComputerB then the keytab isn't going to do anything because the ticket is encrypted to that host's own key. You need to request a ticket to ComputerB. Only then can you validate the ticket using ComputerB's keytab.

[minli1]

Appreciated your quick response. @SteveSyfuhs The ComputerB is not the current host so like you said I cannot use the keytab from the ComputerB to validate the ticket for the current host. I will try to get the service ticket to ComputerB and then use the ComputerB's keytab for the validation. Thanks!

[minli1]

Hi @SteveSyfuhs Thanks a lot for the hint. I managed to validate the ticket now. One more question, I am wondering whether there is a way that can leverage from this repo to encrypt the arbitrary message by the service ticket and decrypt the message when validating the service ticket.

[SteveSyfuhs]

There are two mechanisms built into the Kerberos protocol for that.

First is the session key. Both the client and server know the key, so you can use it as a symmetric key for any form of encryption that you want. That's something defined by you.

Second, you can pass in additional authorization data via the ticket or the authenticator. Passing via the ticket requires sending the data to the KDC beforehand, and passing via the authenticator requires just passing it during the AP-REQ. Both require the client to be aware of this data. SSPI doesn't allow you to pass in arbitrary authz data. KerberosClient here also doesn't support that, but it could be modified to do so.

[minli1]

Hi Steve, thanks a lot for your kind response so far. @SteveSyfuhs I do have another question about the kdecode in bruce, after I click request for <local-host> , it successfully gave me a ticket for accessing the local host, I assume to validate the local host ticket, I need the host's credential which can get from the LSA, can you confirm that? When I click the Decode with LSA Secret, it failed with below, maybe you could give some insights about this? Thanks in advance!

[SteveSyfuhs]

Yes, you need local admin rights to read the machine secret.

[minli1]

Thanks, @SteveSyfuhs While I used the below code to get a ticket for accessing the local machine,

var localHost = Environment.MachineName.ToLowerInvariant();
var context = new SspiContext(spn: localHost);
byte[] tokenBytes = context.RequestToken()
var ticket = Convert.ToBase64String(tokenBytes);
Console.WriteLine("the ticket is: " + ticket);

But when I pasted the ticket string into the kdecode console app and click Decode with LSA secret(this time I have the admin rights), the decode failed. It seems like the LSA secret was fetched with a success but still got a decode failure. I am guessing it may due to the SPN was not matched so the local machine secret cannot decode the ticket, I read from the kdecode code, and it also gets a ticket with spn=machineName. Did I get some wrong here? Thanks.

[SteveSyfuhs]

No, the issue is that the secret coming out of LSA Secrets is encrypted to non-system components. There is also an undocumented registry key you have to set to tell Windows to give you the secret in clear text. I have left it undocumented because I don't want people abusing it. You will have to search online to find it.

---

From: min li @.> Sent: Friday, September 16, 2022 9:34:22 PM To: dotnet/Kerberos.NET @.> Cc: Steve Syfuhs @.>; Mention @.> Subject: Re: [dotnet/Kerberos.NET] Validate Service ticket by using another Computer account and Keytab (Issue #315)

Thanks, @SteveSyfuhshttps://github.com/SteveSyfuhs While I used the below code to get a ticket for accessing the local machine,

var localHost = Environment.MachineName.ToLowerInvariant(); var context = new SspiContext(spn: localHost); byte[] tokenBytes = context.RequestToken() var ticket = Convert.ToBase64String(tokenBytes); Console.WriteLine("the ticket is: " + ticket);

But when I pasted the ticket into the kdecode console app and click Decode with LSA secret(this time I have the admin rights), the decode failed. It seems like the LSA secret was fetched with a success but still got a decode failure. I am guessing it may due to the SPN was not matched so the local machine secret cannot decode the ticket, I read from the kdecode code, and it also gets a ticket with spn=machineName. Did I get some wrong here? Thanks. [image]https://user-images.githubusercontent.com/26323691/190840334-6ac173b8-b160-4e2f-a7ee-4032a4bb76a9.png

— Reply to this email directly, view it on GitHubhttps://github.com/dotnet/Kerberos.NET/issues/315#issuecomment-1249997745, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJHTYOJWFLD5WZQ5JBVF5LV6VC45ANCNFSM6AAAAAAQJ3FOWA. You are receiving this because you were mentioned.Message ID: @.***>

[minli1]

the issue is that the secret coming out of LSA Secrets is encrypted to non-system components

@SteveSyfuhs Hi Steve, if the LSA secrets are encrypted to non-system components then I guess they cannot be used to validate the service ticket for the current host, is that true? if so, why did the kdecode add this option since it actually cannot be used for decoding? Thanks.

[SteveSyfuhs]

Because it's a developer tool used for troubleshooting issues, not for general purpose use. If you run it as system then it'll decode things correctly, or if you set the undocumented Windows reg key value it will also decode things correctly.