Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PF 14.0 ISO - Active Directory Integration broken #8301

Closed
MarioSpenc opened this issue Sep 12, 2024 · 10 comments
Closed

PF 14.0 ISO - Active Directory Integration broken #8301

MarioSpenc opened this issue Sep 12, 2024 · 10 comments
Assignees

Comments

@MarioSpenc
Copy link

MarioSpenc commented Sep 12, 2024

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

  • fresh Installation with "PacketFence-ISO-v14.0.0.iso" downloaded 2024-09-12
  • OS: Debian 12; PF 14.0
@stgmsa stgmsa self-assigned this Sep 12, 2024
@JeGoi
Copy link
Contributor

JeGoi commented Sep 12, 2024

@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
Copy link
Contributor

stgmsa commented Sep 16, 2024

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!

@MarioSpenc
Copy link
Author

@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
Copy link
Author

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:

  • Install on VM from ISO
  • start the configuration wizard from web
  • Log in
  • Policies and Access Control --> Domains --> Active Directory Domains --> New Domain
  • Fill out fields according to working, running version 13.1 but ...
  • Fill out OU --> here starts 1st problem:
  • -- we have alternate OU: PF says: "Non-default OU is define. LDAPS service on port 636 is required in Domain Controller."
  • -- there could be some bug behind?
  • Fill out machine account password --> here starts 2nd problem:
  • -- Machine account password: if you type a for example a 12 character long random password
  • Click create -->
    --> Errormessage:
    image

@stgmsa
Copy link
Contributor

stgmsa commented Sep 17, 2024

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
Copy link
Author

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
Copy link
Author

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

dfir-iris/iris-web#571
cannatag/ldap3#1051

@E-ThanG
Copy link
Contributor

E-ThanG commented Oct 5, 2024

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 cannatag/ldap3#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
Copy link
Contributor

E-ThanG commented Oct 6, 2024

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.

@stgmsa stgmsa closed this as completed in 341b0d6 Oct 7, 2024
@satkunas
Copy link
Contributor

satkunas commented Oct 7, 2024

@stgmsa please backport to maintenance/14.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants