ian351c
Patron
- Joined
- Oct 20, 2011
- Messages
- 219
Hopefully this helps anyone who comes looking...
I'm running FreeNAS-9.3-STABLE-201512121950. I am connecting to Samba 4.2.11 AD Controller in a FreeNAS 9.3 jail. I had to reboot today and when FreeNAS came back up, the CIFS service started in "workgroup" mode rather than "domain member" mode. No matter what I did, FreeNAS could not bind to the AD controller. The errors I was getting while setting up the AD service in FreenAS said that I needed "Strong(er)" authentication to bind to the Samba server in the jail, similar to bug 7080.
In my research , I have found what appears to be an uncorrected bug: you cannot enable SASL and have it work when configuring the AD Directory Service in FreeNAS 9.3. See bug 7421, which was "resolved" by enabling TLS, which is more of a work around than a solution as Samba 4, by default, requires either SASL or TLS. So, I decided to try TLS. Where I ran into this issue, where for some reason, Samba either can't find the CA cert or won't negotiate encryption on port 389 and FreeNAS won't connect on port 636 for ldaps (another possible GUI bug in FreeNAS).
Just when I was about to really start pulling my hair out, I came upon this little gem: Samba 4.2 release notes. Buried in there is what I was looking for (and isn't documented ANYWHERE else on the internets):
This is exactly what I was looking for. Set this value to "no" in the [global] section of smb4.conf on the Samba server and enjoy the bliss of unencrypted ldap!
I'm running FreeNAS-9.3-STABLE-201512121950. I am connecting to Samba 4.2.11 AD Controller in a FreeNAS 9.3 jail. I had to reboot today and when FreeNAS came back up, the CIFS service started in "workgroup" mode rather than "domain member" mode. No matter what I did, FreeNAS could not bind to the AD controller. The errors I was getting while setting up the AD service in FreenAS said that I needed "Strong(er)" authentication to bind to the Samba server in the jail, similar to bug 7080.
In my research , I have found what appears to be an uncorrected bug: you cannot enable SASL and have it work when configuring the AD Directory Service in FreeNAS 9.3. See bug 7421, which was "resolved" by enabling TLS, which is more of a work around than a solution as Samba 4, by default, requires either SASL or TLS. So, I decided to try TLS. Where I ran into this issue, where for some reason, Samba either can't find the CA cert or won't negotiate encryption on port 389 and FreeNAS won't connect on port 636 for ldaps (another possible GUI bug in FreeNAS).
Just when I was about to really start pulling my hair out, I came upon this little gem: Samba 4.2 release notes. Buried in there is what I was looking for (and isn't documented ANYWHERE else on the internets):
ldap server require strong auth (G)
The ldap server require strong auth defines whether the ldap server requires ldap traffic to be signed or signed and encrypted (sealed). Possible values are no, allow_sasl_over_tls and yes.
A value of no allows simple and sasl binds over all transports.
A value of allow_sasl_over_tls allows simple and sasl binds (without sign or seal) over TLS encrypted connections. Unencrypted connections only allow sasl binds with sign or seal.
A value of yes allows only simple binds over TLS encrypted connections. Unencrypted connections only allow sasl binds with sign or seal.
The ldap server require strong auth defines whether the ldap server requires ldap traffic to be signed or signed and encrypted (sealed). Possible values are no, allow_sasl_over_tls and yes.
A value of no allows simple and sasl binds over all transports.
A value of allow_sasl_over_tls allows simple and sasl binds (without sign or seal) over TLS encrypted connections. Unencrypted connections only allow sasl binds with sign or seal.
A value of yes allows only simple binds over TLS encrypted connections. Unencrypted connections only allow sasl binds with sign or seal.
This is exactly what I was looking for. Set this value to "no" in the [global] section of smb4.conf on the Samba server and enjoy the bliss of unencrypted ldap!