Also impacts net/samba43 net/samba44 This one has been causing me headaches for a while and definitely needs some discussion around the implications. It appears to have been previously attempted (net/samba42/Makefile at 349) but commented out. So currently it obeys make.conf settings. However, in an actual modern AD environment, LDAP queries should implicitly use KRB5 which requires GSSAPI. This means the port is more or less 'broken by default' for properly configured AD environments. It also impacts security/sssd which currently does not have an explicit requirement for openldap24-sasl-client defined, but absolutely requires it. This obviously has implications since it is a change to defaults which could impact dependent ports and pkg builds. However, as it is essentially incompatible with the current AD security model, are there specific reasons to not switch Samba ports to require OPENLDAP_SASL?
Maintainer timeout (> 2 weeks) Open to take
As suggested by Kubilay, here is a (hopefully) better explanation of the problem and compatibility matrix. For Windows 2k8R2 and later domains, GSSAPI is essentially a requirement for domain join as they use Kerberos 5 as a key part of authentication. That includes for authenticated LDAP queries. Because of that, WANT_OPENLDAP_SASL should be enforced by the Samba ports when the ADS option is set. This is because 2k8R2 functional level and above domains should require Kerberos 5 capability in clients. LDAP queries without GSSAPI authentication should fail for machines joined to the domain. Therefore, the current default will not function as desired on currently supported versions of Active Directory. For forest roots running below the 2k8R2 functional level, the presence of GSSAPI in the client will not present any problems. So it stands to reason that the Samba ports should at this point require openldap-sasl-client to align with current supported versions of Active Directory rather than following /etc/make.conf settings as they do now. Patches have been prepared for security/sssd to address deficiencies in that port, including resolving the openldap-sasl-client requirement, but they depend on answering this question one way or the other first. The TL,DR being: Windows 2k8R2 Domains and above: minimum supported version, require GSSAPI Windows 2k8 Domains and below: unsupported, GSSAPI does not interfere
Created attachment 173359 [details] patch-sasl-samba42 Changes behavior to WANT_OPENLDAP_SASL only for ADS; LDAP option still follows /etc/make.conf
Created attachment 173360 [details] patch-sasl-samba43 Changes behavior to WANT_OPENLDAP_SASL only for ADS; LDAP option still follows /etc/make.conf
Created attachment 173361 [details] patch-sasl-samba44 Changes behavior to WANT_OPENLDAP_SASL only for ADS; LDAP option still follows /etc/make.conf
Proposed patches attached. Obviously not the greatest of solutions, but it is passing internal testing with the desired result of requiring openldap-sasl-client. This will definitely need to be run through proper evaluation as ADS is a DEFAULT option and it may have wider impacts for quarterlies and other scenarios.
I opened this review for samba42 https://reviews.freebsd.org/D7439
There's something wrong going on with the openldap / sasl support in the ports tree because it keeps picking up openldap without sasl and then complaining. I think we need a cleaner approach perhaps with USES
(In reply to Mark Felder from comment #8) This is what I suggested on IRC, as this and support for default versions makes it a ton easier to not shoot yourself in the foot, and puts the burden (choice) on the user to select a default, not the framework, AND brings bsd.ldap.mk into USES/DEFAULT_VERSIONS fray for bonus consistency points
(In reply to Mark Felder from comment #8) Yep. I was hoping to stop-gap (this is blocking security/sssd improvements) but the same issue seen here was not reproducing in clean tree for me. I'm confident saying there is definitely something misbehaving in bsd.ldap.mk and the current state of it is now actively blocking multiple items. The 'easy' fix is for ADS to be removed from the samba4{2,3,4} OPTIONS_DEFAULT. But removing ADS from OPTIONS_DEFAULT has extreme impacts - not only does it affect any port making use of samba4*, but it will completely cripple expected default functionality of samba itself. DEFAULT_VERSIONS is obviously preferable, but unless it can reliably force WANT_OPENLDAP_SASL, it would not address the issue here. Not only that, but frankly, I don't see a sound reason for it. bsd.ldap.mk still allows 2.3, but all of those ports expired in 2013 it turns out. So as it is bsd.ldap.mk should be considered broken. At current, it looks like there are 92 ports (including expired ports) which depend on openldap24-client, and zero conflicts with either port. Since SASL extends functionality, rather than changes, is there any reason to not remove bsd.ldap.mk, combine openldap24-client and openldap24-sasl-client, and make SASL OPTIONS_DEFAULT for the openldap port? (I'm sure there probably was, but it seems far less likely now.)
Closing as Overcome; samba4[2,3] EOL'd upstream, samba44 on security only. Additionally see https://reviews.freebsd.org/D9083 regarding use of WANT_OPENLDAP_SASL. Further discussion would need to go under use of OPENLDAP rather than samba.