panic: runtime error: index out of range, when using AD Explorer

[slemire]

ldapx runs fine with bloodhound-py and ldapsearch but crashes when I connect using AD Explorer

goroutine 19 [running]:
main.handleLDAPConnection.func3()
        C:/source/ldapx/proxy.go:139 +0x7aa
created by main.handleLDAPConnection in goroutine 18
        C:/source/ldapx/proxy.go:115 +0x7b6

To reproduce:

• Start ldapx without any middleware: ldapx -t x.x.x.x:389
• Connect to 127.0.0.1 with AD Explorer

[slemire]

Could be because ADExplorer uses GSS-API, based on some pcaps I took

[Macmod]

I'll look into this. Thanks for pointing it out!

[Macmod]

Apparently some messages sent by AD Explorer during SASL / GSSAPI establishment don't fit the "standard" expected format for LDAP messages. I'll try to check in the following days if we can just detect this condition somehow and get it working by just sending these "extra" packets back and forth between client and server.

[Macmod]

Seems liks this is a bigger issue than I first thought - even if we could make it not panic and forward the messages back and forth, SASL/GSS-API encrypts the messages, so ldapx would not actually do anything but sit in the middle of the connection. So we can either:
(1) Explicitly state that ldapx doesn't support SASL / GSSAPI (not ideal)
(2) Add a flag to try to "downgrade" the auth somehow by intercepting and changing the first BindResponse (theoretically possible?)
(3) Implement active decryption of SASL / GSSAPI in ldapx (impossible?)

I'll have to study which of (2) and (3) is the way out, but more testing is definitely needed to solve this one.

[16/12/2024] Update. I tried to intercept the BindResponse and reply an authMethodNotSupported (resultCode 7) to ADExplorer - it seems that it first tries to use SASL / GSSAPI (type 3), and if it gets an authMethodNotSupported back it tries again with NTLMSSP Negotiate (type 10). But then, if we reply code 7 again, it just sends an UnbindRequest and throws an alert saying that the server does not support the requested authentication method.

I also tried to remove the supportedSASLMechanisms attribute from the response of the initial search that ADExplorer does in the RootDSE (or change it to PLAIN only), but then ADExplorer tries with NTLMSSP Negotiate only. I'm not sure if there's any case in which ADExplorer is forced to do a simple bind / use an unencrypted channel.

If anyone has any ideas about this I'd appreciate it. It's possible that we can do (3) but then we would need to implement active decryption of SASL / GSSAPI and NTLMSSP Negotiate by explicitly requiring the user to specify the credentials via command-line arguments. For now I'll add a disclaimer mentioning this issue in the README to let users know about the issue.