Add CRUD methods to ldap

[NeffIsBack]

Until now for all modification operations ldap3 must be used, due to the lack of CRUD methods in ldap (yeah R=read exists, but w/e).

This is now supported!
The implementation is very close to the syntax of the corresponding ldap3 calls in order to be a drop-in-place. Therefore, all existing calls should be able to be replaced by simply switching to impackets ldap. Keep in mind that ldap3 returns False together with populating connection.last_error, while impackets implementation raises an error. Therefore, error handling must be adjusted. If there are issues (now or in the future) where impackets ldap does not behave similar to ldap3 please hit me up.

Subsequently, all existing ldap3 adaptations inside of impacket and NetExec can gradually be replaced by impackets ldap implementation.
Example of adding, modifying and deleting a computer object from NetExec:

Note that i have not tested the modify_dn() function because i had no proper use-case (at least that worked). Since it is pretty simple, i don't think i have messed it up.

[Dfte]

So great :D!!

[mpgn]

Nice one 🎉

[NeffIsBack]

@anadrianmanrique i don't want to mess with your priority list too much, but i think it would be nice to have this one merged some time soon so we (in NetExec) can start replacing all manually established ldap3 connections in NetExec with impacket.

[anadrianmanrique]

hello, @NeffIsBack I'll be reviewing these changes next week. I'll be discussing with the team also this PR, as it duplicates functionality with ldap3, which is intended to be potentially, as you mention, replaced.
ldap3 was, I understand, added as dependency in order to gradually delegate ldap operations to an external lib. I understand also the issues related to how this project it's being maintained these last years.
So please, let me put in sync the team with this, as this implies not only changes in our ldap implementation.
Thanks!

[NeffIsBack]

Sounds good👍🏼

Besides that ldap3 had some maintenance issues, there are two core issues that arises with the use in NetExec:

• NetExec has a lot of logic that ensures that a connection to ldap is established, checking TLS availability, managing the requirement of signing/channel binding, deciding between password/hash/ticket auth etc. Therefore, the need to reestablish connections using ldap3 bypasses all of these checks and can easily break the connection (e.g. the use of hashes with impacket, but missing in the ldap3 object). Being able to just use the already established impacket ldap connection would be a huge win.
• Ldap3 does not support signing capabilities without TLS afaik. Therefore, in situations where signing is required, but no TLS cert is available ldap3 can't be used, but impackets ldap must be used. As far as I can tell, impackets ldap implementation is with this PR more feature complete (at least more complete with features relevant to us) than the ldap3 implementation.

TLDR; I don't want to discourage the use of ldap3 which is by all means a good lib, but rather simplify NetExec (and impacket) development by being able to rely on just one ldap implementation instead of having two intertwined in the project.

A few PRs and features of NetExec that reestablish the connection using ldap3 just because of the lack of CRUD functions:

• add-computer module
• New Module add-group Pennyw0rth/NetExec#688
• Create tombstone module Pennyw0rth/NetExec#736
• Add DNS Module Pennyw0rth/NetExec#761
• Add targeted Kerberoasting by injecting/removing temporary SPNs Pennyw0rth/NetExec#840
• Add Shadow credentials module ! Pennyw0rth/NetExec#936 (implicitly)
• Add user ldaps Pennyw0rth/NetExec#966

[anadrianmanrique]

ok, I created ldap_examples_update branch in order to port there examples from ldap3 to impacket.ldap .
I'll merge this one, as I tested successfully changes in addcomputer.py

Thanks!

[NeffIsBack]

Awesome! Glad to hear, we'll get things moving in NetExec as well.

Keep in mind that the syntax works as before, but ldap3 did not raise exceptions when it received errors, while impacket does. Can happen for example if you try to add an object that already exists.

[Neustradamus]

Dear @fortra team, @gabrielg5, @anadrianmanrique,

LDAP Channel Binding support will be added with your recent changes?

@dadevel has done a good work here:

• Support channel binding in init_ldap_session() #2120
• Support channel binding in rbcd.py, dacledit.py and owneredit.py #1657

[NeffIsBack]

Dear @fortra team, @gabrielg5, @anadrianmanrique,

LDAP Channel Binding support will be added with your recent changes?

@dadevel has done a good work here:

• Support channel binding in init_ldap_session() #2120

• Support channel binding in rbcd.py, dacledit.py and owneredit.py #1657

LDAP channel binding is supported by default with impackets LDAP implementation. Once example scripts etc are migrated every script will support channel binding by default.