`AttributeError: module 'ldap3' has no attribute 'TLS_CHANNEL_BINDING' after installing to PacketFence 14.1 on Debian 12`

[bahamut45]

🐛 Bug Report

Title: AttributeError: module 'ldap3' has no attribute 'TLS_CHANNEL_BINDING' after installing to PacketFence 14.1 on Debian 12

---

Description

After upgrading to PacketFence 14.1 (package packetfence_14.1.0+20251008182116+2097477396+0012+maintenance~14~1+bookworm1 from the official Debian repository), running the impacket_addcomputer.py script fails with the following error:

Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

Traceback (most recent call last):
  File "/usr/local/pf/bin/impacket/impacket_addcomputer.py", line 611, in <module>
    group.add_argument('-channel-binding', action='store_const', const = ldap3.TLS_CHANNEL_BINDING, help='enable TLS Channel Binding')
                                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'ldap3' has no attribute 'TLS_CHANNEL_BINDING'

It seems that the installed ldap3 library version (2.9.1) does not define the TLS_CHANNEL_BINDING constant that the script expects.

---

Steps to Reproduce

1. Install PacketFence 14.1 from the official Debian repositories on Debian 12 (bookworm)
   (package: packetfence_14.1.0+20251008182116+2097477396+0012+maintenance~14~1+bookworm1)
2. Run the following command:

   /usr/local/pf/bin/impacket/impacket_addcomputer.py

3. Observe the AttributeError: module 'ldap3' has no attribute 'TLS_CHANNEL_BINDING' error message.

---

Expected Behavior

The script should:

• Check for the presence of ldap3.TLS_CHANNEL_BINDING before using it, or
• Be compatible with the current versions of ldap3 (≥2.9.1) that no longer expose this constant.

---

System Information

Component	Version
OS	Debian 12 (bookworm)
PacketFence package	packetfence_14.1.0+20251008182116+2097477396+0012+maintenance~14~1+bookworm1
Impacket	0.10.0
ldap3	2.9.1
Installation method	Official PacketFence Debian repository
Script path	/usr/local/pf/bin/impacket/impacket_addcomputer.py

---

Analysis / Possible Fix

• In recent versions of ldap3, the TLS Channel Binding support has changed, and the constant TLS_CHANNEL_BINDING is no longer directly exposed.
• The code could be adjusted to handle this gracefully, for example:

if hasattr(ldap3, "TLS_CHANNEL_BINDING"):
    const = ldap3.TLS_CHANNEL_BINDING
else:
    const = None

• Alternatively, the dependency on ldap3 could be pinned to a version that still provides TLS_CHANNEL_BINDING, or the impacket integration updated accordingly.

---

Impact

This issue prevents certain Active Directory integrations (via Impacket) from functioning properly, especially scripts like impacket_addcomputer.py used for automated computer account creation.

---

Additional Notes

It may be useful to review compatibility between PacketFence’s bundled Impacket and the currently shipped ldap3 version.

[jrouzierinverse]

Do you call impacket_addcomputer.py directly?

[bahamut45]

Yes, we are calling the script directly:

/usr/local/pf/bin/impacket/impacket_addcomputer.py

It fails immediately with the following error:

AttributeError: module 'ldap3' has no attribute 'TLS_CHANNEL_BINDING'

Also, I noticed that the shebang has changed between versions — previously it was:

#!/usr/bin/env python

and now it is:

#!/usr/local/pf/python/bin/python

I was a bit surprised by this change.
Does this mean that future PacketFence releases will use a dedicated Python environment or virtual environment for internal scripts?

[jrouzierinverse]

We use the script in the pfperl-api container where we have the virtual environment.

You can change how you call it by doing the following.

docker exec pfperl-api /usr/local/pf/bin/impacket-addcomputer <args>

[bahamut45]

Thanks for the clarification — your suggested command works perfectly:

docker exec pfperl-api /usr/local/pf/bin/impacket-addcomputer <args>

However, I just wanted to better understand the reasoning behind this change.

In previous versions, the Python scripts under /usr/local/pf/bin/impacket/ could be executed directly (using the system Python), for example:

/usr/local/pf/bin/impacket/impacket_addcomputer.py

But now the shebang has changed from:

#!/usr/bin/env python

to:

#!/usr/local/pf/python/bin/python

I understand that this points to a dedicated Python environment, but I was surprised that the scripts are no longer meant to be run directly on the host — especially since they are still distributed under /usr/local/pf/bin/impacket/.

Is the idea that, going forward, all Python scripts should always be executed within the pfperl-api container (or a similar dedicated container environment)?

Just trying to understand the new intended usage and best practice for these internal Python tools.