search

inverse-inc / packetfence

PacketFence is a fully supported, trusted, Free and Open Source network access control (NAC) solution. Boasting an impressive feature set including a captive-portal for registration and remediation, centralized wired and wireless management, powerful BYOD management options, 802.1X support, layer-2 isolation of problematic devices; PacketFence can be used to effectively secure networks small to very large heterogeneous networks.
https://packetfence.org
GNU General Public License v2.0
1.37k stars 287 forks source link

PF 14.0 ISO - Active Directory Integration broken #8301

Closed MarioSpenc closed 3 weeks ago

MarioSpenc commented 1 month ago

Normally you add a AD Domain in "Policies and Access Control" --> Domains --> AD Domains --> New Domains. You fill out all missing fields, click on "Save" and PF go to AD Server and update the machine account password so you are joined with AD. This does not work. Instead we get some MD4 error (screenshot!!).

image

JeGoi commented 1 month ago

@MarioSpenc did you check the hostname you used to attach the vm? Could it be something that you are currently using? mine was that:

root@packetfence:/usr/local/pf# hostnamectl
 Static hostname: packetfence
       Icon name: computer-vm
         Chassis: vm 🖴
      Machine ID: bf469408740e48ed8c4927e507408752
         Boot ID: cb64abbafa7c4e2f9fde7f49fedde186
  Virtualization: vmware
Operating System: Debian GNU/Linux 12 (bookworm)  
          Kernel: Linux 6.1.0-25-amd64
    Architecture: x86-64
 Hardware Vendor: VMware, Inc.
  Hardware Model: VMware Virtual Platform
Firmware Version: 6.00

But when I registered (joined) my vm on the AD, I changed the "This server's name" from %h to something like "zammitfriend". Then, no issue.

stgmsa commented 1 month ago

Hi, @MarioSpenc I’ve checked with a fresh installation of PacketFence v14.0 from an ISO image downloaded right after this issue was raised, checked with:

But no errors were found. Could you please provide some details so we can reproduce?

Thanks!

MarioSpenc commented 1 month ago

@MarioSpenc did you check the hostname you used to attach the vm? Could it be something that you are currently using? mine was that:

root@packetfence:/usr/local/pf# hostnamectl
 Static hostname: packetfence
       Icon name: computer-vm
         Chassis: vm 🖴
      Machine ID: bf469408740e48ed8c4927e507408752
         Boot ID: cb64abbafa7c4e2f9fde7f49fedde186
  Virtualization: vmware
Operating System: Debian GNU/Linux 12 (bookworm)  
          Kernel: Linux 6.1.0-25-amd64
    Architecture: x86-64
 Hardware Vendor: VMware, Inc.
  Hardware Model: VMware Virtual Platform
Firmware Version: 6.00

But when I registered (joined) my vm on the AD, I changed the "This server's name" from %h to something like "zammitfriend". Then, no issue.

Hi,

thanks for answer. I added new, unused machine in AD and used exactly same name everywhere from beginning of installation.

Should be no problem ...

MarioSpenc commented 1 month ago

Hi, @MarioSpenc I’ve checked with a fresh installation of PacketFence v14.0 from an ISO image downloaded right after this issue was raised, checked with:

  • create a domain profile
  • update domain profile settings, such as changing machine account password.

But no errors were found. Could you please provide some details so we can reproduce?

Thanks!

Hi,

thanks for your help! My steps for reproducing the problem:

stgmsa commented 1 month ago

OK, For your first question, LDAPS is required is a hint in frontend whenever you specific an OU except using Computers (by default, the machine account will be created under domain -> Computers), Thus, a LDAPS service is required because SAMR can only make it to the default place. It's not an error, but just a hint that reminds you to have LDAPS configured and running properly.

the 2nd question, are you upgrading from an old PF installation ? what was the version 13.1 for ?

MarioSpenc commented 1 month ago

Hi, Version 13.1 is the running packetfence installation which is in production environment. My first attempts were exports/imports from 13.1 to 14.0 but that didn't worked (because of the errors I described here). So we are talking about absolutely new installation of pf 14.0 with ISO and with new hostname so I don't crash my production box.

In my example the machine account is already created, but resetted. Is this a problem?

Can you explain yourself this MD4 error?

MarioSpenc commented 1 month ago

Hi, what I found is that the problem could be a problem in openssl/ldap3 implementation:

https://github.com/dfir-iris/iris-web/issues/571 https://github.com/cannatag/ldap3/issues/1051

E-ThanG commented 4 weeks ago

New PF 14 ZEN VM, no data imported. Happens immediately after trying to add a domain.

I think that the issue is with one of the docker builds, that's not saying much though, it's all docker. From what I can see, the pieces are all there externally for MD4 to be supported in the VM. Openssl configuration has legacy enabled, Many of the Python functions are using hashlib MD4, Perl Digest::MD4 isn't installed globally, but it is in: /usr/local/pf/lib_perl/lib/perl5/ As long as the docker container has that in its libraries, then it seems like it should work.

The message that we are seeing is from /usr/local/pf/lib/pf/UnifiedApi/Controller/Config/Domains.pm. It is a Perl module and uses Digest::MD4", however, the point where we are failing is just before the hash function is actually used in the code. Domains.pm calls add_computer in /usr/local/pf/lib/pf/domain.pm, another Perl file, also importing Digest::MD4. Nothing in domain.pm actually uses the MD4 hash though. In domain.pm I see that if a machine's OU is "Computers" it is added with SAMR method, if it's somewhere else, it uses LADPS, that's interesting... You mentioned this already.

Adding the computer in domain.pm is a call to '/usr/local/pf/bin/impacket-addcomputer', which doesn't exist in the source tree. However, in the dockers it is a symlink created by the pfperl-api Dockerfile to /usr/share/doc/python3-impacket/examples/addcomputer.py. When I try to add a new domain I see /usr/local/pf/bin/impacket-addcomputer being executed, which backs up the notion that this module is related.

It's worth noting that addcomputer.py doesn't exist in the PF source tree, it's an example from python3-impacket. I'm not sure if there are any guarantees that examples are maintained, nor even if they will continue to exist. it may be worth moving that into the PF source tree?

That said, in addcomputer.py I see that there is quite a bit of difference between SAMR and LDAPS add. Recalling what we said earlier, I deleted my machine from the domain in AD, deleted the domain from PF. Then used PF re-join the domain with it bound in Computers instead, it adds with no issues.

Thus, SAMR good, LDAPS broken. The required port is open for LDAPS (SSL), it works for LDAPS authentication sources and AD binding worked in earlier versions of PF.

The LDAPS functions in addcomputer.py use the ldap3 library. The link that MarioSpenc provided may actually be the problem https://github.com/cannatag/ldap3/issues/1051 In their latest released version the ntlm.py module tries using hashlib, if that fails it tries Crypto.Hash. But the devel branch abandons both modules and uses the Cryptodome.Hash library instead. Maybe try rebuilding the docker with that branch of ldap3 library?

@stgmsa Try binding your machine to some non-default location other than Computers.

I have a second VM that I left at 13.2, I can perform any testing you'd like on either VM. I upgraded the 14.0 VM to the latest 14.1 devel version, same problem there.

E-ThanG commented 3 weeks ago

That is the issue. The OpenSSL configuration inside pfperl-api doesn't have legacy enabled.

I was able to get it working by using the same openssl configuration file as was used in the ntlm-auth-api.

  1. Add COPY addons/ntlm-auth-api/openssl.cnf /usr/lib/ssl/openssl.cnf to containers/pfperl-api/Dockerfile
  2. Build new docker with /usr/local/pf/addons/dev-helpers/build-local-container.sh pfperl-api
  3. Restart pfperl-api
  4. Add new domain in any OU

I also fixed it a different way by installing pycrypto in the container using docker exec to obtain a bash shell, but that required installing pip as well. It worked, but I didn't like the idea of editing an already built docker container.

I confirmed that it works in 14.0 and 14.1 devel.

The container has pycroptodomex installed already, so when the new ldap3 library is released the issue may go away on its own.

satkunas commented 3 weeks ago

@stgmsa please backport to maintenance/14.0