On 09/29/2016 01:13 PM, Alan DeKok wrote:
On 09/29/2016 12:39 PM, Alan DeKok wrote: Fix your LDAP server so that FreeRADIUS is allowed to search it. Typically this is done by making a read-only admin account in LDAP, and using that with FreeRADIUS.
That doesn't explain it. Why does the server successfully bind and search for to find user DN, than fails to bind when searching for group DNs? See below.
Ask your LDAP server. FreeRADIUS doesn't produce this message. Your LDAP server produces it.
So... If you want to fix the problem, fix your LDAP server
Okay, progress made. I've demonstrated the problem is the interaction between rlm_ldap, SASL GSSAPI, and Samba 4.3.x, 4.4.x, and 4.5.0 ldap_server. If ldap_server negotiates encryption via SASL, it will not allow subsequent SASL binds. After patching ldap_server, adjusting for logic flow, the server returns LDAP_UNWILLING_TO_PERFORM and reports SASL:[GSSAPI]: Sign or Seal are not allowed if SASL encryption has already been set up
Re-including freeradius -X output:
Please don't waste my time. I read that in the first message. There is no need to include it again.
As a hint for future questions, if you're asking questions here, it means you don't have the answer. So it's rude to question the people who do know the answer, and are kind enough to help you.
Alan, I didn't mean to offend your constitution. The supplied answer didn't agree with the runtime log artifacts and I was fishing for a different answer or to anchor a thoughtful discussion. I appreciated your help as it allowed me to quickly exclude possibilities and to demonstrate the real problem. ~ Tom