Unable to authenticate

[AhmedAA]

When running adalanche from a kali against a DC (remotely), it seems to throw authentication errors, although the credentials are correct.

See below output:

This is from the hackthebox machine "pivotapi" (which is retired, so don't worry about the spoilers).
As you can see, bloodhound works fine, but for some reason adalanche gives authentication errors.

I am not entirely sure what goes wrong here. I know when using bloodhound on hackthebox, it is important to use the nameserver flag, but adalanche does not seem to have this option/flag (or I am too stupid to find it).

EDIT
Running the Windows binary locally on the target worked, but produced another error, which I will open a new issue for.

EDIT 2
Testing information:

• HOST: kali linux
• ADALANCHE VERSION: Latest release (downloaded pre-compiled binaries)

[lkarlslund]

Hmm ... good question. It this a public HTB lab?

No, adalanche does not implement its own DNS client, but if I get enough requests for it I'll put it on the TODO list. Testing is done on Windows in a "blue" environment ;)

[AhmedAA]

I think retired machines require a VIP subscription, unfortunately.

Well, I guess another thing I could do is try to manually see if I can set the DNS server, just for that one request and see if it works. If it isn't the DNS, then it would be interesting to see what is going on, I guess?

[AhmedAA]

Even with the DNS server explicitly set, it still gives an error with invalid credentials.

This seems quite weird..
Do you have any ideas on what might cause this?

[m8r1us]

Same finding with debian.
Tried LDAP and LDAPS. PW is correct.

[lkarlslund]

I've added a warning about this to the readme, and a workaround for it. I'm not sure what's causing it.

[bill-e-ghote]

I haven't looked at the adalanche source yet, but reading this, description sounds similar: ruby-ldap/ruby-net-ldap#339

Maybe tweak LDAPServerIntegrity and LdapEnforceChannelBinding settings?

[lkarlslund]

adalanche is just a LDAP consumer, so it's not really directly an adalanche problem.

It uses my own fork of the Go LDAP library, located at https://github.com/lkarlslund/ldap.

The difference between the stock Go LDAP library and mine is that I implemented integrated NTLM authentication support when on the Windows platform.

Any help on fixing this would be welcome.

[lkarlslund]

I've implemented a feature that lets you dump the Active Directory with SysInternal ADExplorer (save snapshot). You then proceed to do a normal "collect activedirectory" but use the snapshot as the source instead of a direct LDAP connection to a DC.

Procedure:

1. Start AD Explorer, connect to default server (just press connect), or use custom settings
2. Save snapshot file
3. Run "adalanche collect activedirectory --adexplorerfile=your-snapshot-file"

It will then do an on-the-fly conversion (a bit slow, but it works), and save the normal compressed data file. After that it will collect GPOs as normal and save them.

The result is more or less the same as you would expect from the LDAP source. As this solves the above problems, I consider this solved, as implementing "channel binding" and "signing" in LDAP is beyond this project.

[lkarlslund]

Closing this as a wontfix - there's an alternative solution, and the problem lies within a third party library.