Offer multiple etype for TGS-REQ

[CravateRouge]

Before change using a krb ticket generated with impacket getTGT.py gives the following error:

$ getTGT.py -dc-ip 192.168.100.3 'bloody.corp/john:Password123!'         
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

[*] Saving ticket in john.ccache

$ msldap -v 'ldap+kerberos-ccache://bloody.corp\john:john.ccache@dc1.outsider.lab/?serverip=192.168.100.10&dc=192.168.100.3&dcc=192.168.100.10&realmc=outsider.lab' 'login'
2024-11-29 12:24:11,843 msldap       DEBUG    ==== UniCredential ====
domain: bloody.corp
username: john
secret: john.ccache
stype: CCACHE
protocol: KERBEROS
subprotocol: <asyauth.common.subprotocols.native.SubProtocolNative object at 0x7fd3aa3f1c90>
etypes: [23, 17, 18]
altname: None
altdomain: None
target: ==== UniTarget ====
hostname: None
port: 88
protocol: UniProto.CLIENT_TCP
timeout: 5
ssl_ctx: None
dc_ip: 192.168.100.3
domain: None
dns: None
use_privileged_source_port: False
proxies: []
ip: 192.168.100.3

certdata: None
keydata: None
cross_target: ==== UniTarget ====
hostname: None
port: 88
protocol: UniProto.CLIENT_TCP
timeout: 5
ssl_ctx: None
dc_ip: 192.168.100.10
domain: None
dns: None
use_privileged_source_port: False
proxies: []
ip: 192.168.100.10

cross_realm: outsider.lab
dh_params: {'p': 179769313486231590770839156793787453197860296048756011706444423684197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007, 'g': 2}

DEBUG:msldap:==== UniCredential ====
domain: bloody.corp
username: john
secret: john.ccache
stype: CCACHE
protocol: KERBEROS
subprotocol: <asyauth.common.subprotocols.native.SubProtocolNative object at 0x7fd3aa3f1c90>
etypes: [23, 17, 18]
altname: None
altdomain: None
target: ==== UniTarget ====
hostname: None
port: 88
protocol: UniProto.CLIENT_TCP
timeout: 5
ssl_ctx: None
dc_ip: 192.168.100.3
domain: None
dns: None
use_privileged_source_port: False
proxies: []
ip: 192.168.100.3

certdata: None
keydata: None
cross_target: ==== UniTarget ====
hostname: None
port: 88
protocol: UniProto.CLIENT_TCP
timeout: 5
ssl_ctx: None
dc_ip: 192.168.100.10
domain: None
dns: None
use_privileged_source_port: False
proxies: []
ip: 192.168.100.10

cross_realm: outsider.lab
dh_params: {'p': 179769313486231590770839156793787453197860296048756011706444423684197180216158519368947833795864925541502180565485980503646440548199239100050792877003355816639229553136239076508735759914822574862575007425302077447712589550957937778424442426617334727629299387668709205606050270810842907692932019128194467627007, 'g': 2}

2024-11-29 12:24:11,843 msldap       DEBUG    ==== MSLDAPTarget ====
hostname: dc1.outsider.lab
port: 389
protocol: UniProto.CLIENT_TCP
timeout: 5
ssl_ctx: None
dc_ip: 192.168.100.3
domain: bloody.corp
dns: None
use_privileged_source_port: False
proxies: []
ip: 192.168.100.10
tree: None
ldap_query_page_size: 1000
ldap_query_ratelimit: 0

DEBUG:msldap:==== MSLDAPTarget ====
hostname: dc1.outsider.lab
port: 389
protocol: UniProto.CLIENT_TCP
timeout: 5
ssl_ctx: None
dc_ip: 192.168.100.3
domain: bloody.corp
dns: None
use_privileged_source_port: False
proxies: []
ip: 192.168.100.10
tree: None
ldap_query_page_size: 1000
ldap_query_ratelimit: 0

2024-11-29 12:24:11,858 msldap       DEBUG    Connecting!
DEBUG:msldap:Connecting!
2024-11-29 12:24:11,861 msldap       DEBUG    Connection succsessful!
DEBUG:msldap:Connection succsessful!
2024-11-29 12:24:11,861 msldap       DEBUG    BIND in progress...
DEBUG:msldap:BIND in progress...
2024-11-29 12:24:11,862 asyauth.kerberos DEBUG    Flags: 48
2024-11-29 12:24:11,862 asyauth.kerberos DEBUG    SPN: ldap/dc1.outsider.lab@bloody.corp
2024-11-29 12:24:11,862 asyauth.kerberos DEBUG    CCACHE SPN record: krbtgt/BLOODY.CORP@BLOODY.CORP
Traceback (most recent call last):
  File "/home/silver/.local/lib/python3.11/site-packages/asyauth/protocols/kerberos/client/native.py", line 144, in authenticate
    raise err
  File "/home/silver/.local/lib/python3.11/site-packages/minikerberos/aioclient.py", line 353, in tgs_from_ccache
    tgs, keystruct, err = self.ccache.get_tgs(spn_user)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/silver/.local/lib/python3.11/site-packages/minikerberos/common/ccache.py", line 657, in get_tgs
    return tgss[0][0], tgss[0][1], None
           ~~~~^^^
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/silver/.local/lib/python3.11/site-packages/msldap/examples/msldapclient.py", line 90, in do_login
    raise err
  File "/home/silver/.local/lib/python3.11/site-packages/msldap/connection.py", line 408, in bind
    raise err
  File "/home/silver/.local/lib/python3.11/site-packages/asyauth/protocols/kerberos/client/native.py", line 154, in authenticate
    ref_tgs, ref_encpart, ref_key, new_factory = await self.kc.get_referral_ticket(self.credential.cross_realm, self.credential.cross_target.get_ip_or_hostname())
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/silver/.local/lib/python3.11/site-packages/minikerberos/aioclient.py", line 801, in get_referral_ticket
    tgs, encpart, key = await self.get_TGS(crossrealm_spn)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/silver/.local/lib/python3.11/site-packages/minikerberos/aioclient.py", line 447, in get_TGS
    raise KerberosError(rep, 'get_TGS failed!')
minikerberos.protocol.errors.KerberosError: get_TGS failed! Error Name: KDC_ERR_ETYPE_NOTSUPP Detail: "KDC has no support for encryption type" 

Because minikerberos only offers ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) when it offers ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23) when using a TGT generated by minikerberos. To compare impacket getST.py always offers the following:

etype: 4 items
    ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
    ENCTYPE: eTYPE-DES3-CBC-SHA1 (16)
    ENCTYPE: eTYPE-DES-CBC-MD5 (3)
    ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)

This change will always offers the ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23) encryption mode as second option so DC can fallback to it if it doesn't support others.

There is a Microsoft article to explain this issue with referral tickets: https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/unsupported-etype-error-accessing-trusted-domain#kerberos-encryption-types

[skelsec]

huh, interesting. I haven't encountered this issue myself, but it looks good to me.
thank you for the PR!