-
Notifications
You must be signed in to change notification settings - Fork 287
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
Comments
@MarioSpenc did you check the hostname you used to attach the vm?
But when I registered (joined) my vm on the AD, I changed the "This server's name" from %h to something like "zammitfriend". |
Hi, @MarioSpenc
But no errors were found. Thanks! |
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 ... |
Hi, thanks for your help! My steps for reproducing the problem:
|
OK, the 2nd question, are you upgrading from an old PF installation ? what was the version 13.1 for ? |
Hi, In my example the machine account is already created, but resetted. Is this a problem? Can you explain yourself this MD4 error? |
Hi, what I found is that the problem could be a problem in openssl/ldap3 implementation: |
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. |
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.
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 please backport to |
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!!).
The text was updated successfully, but these errors were encountered: