samba - May 2019 - dsdb_access Access check failed on CN=Configuration

On 23/05/2019 20:45, Mike Ray wrote:
> OK -- I fixed this issue.
>
> The fix also fixed the issue where the following ldapsearch command use to
return but no longer did:
> # ldapsearch -x -H ldap://DC -b dc=domain,dc=local
"(&(gidNumber=xxxx)(!(uidNumber=*)))"
>
> The answer is that I needed to re-add "acl:search = no" to the
smb.conf to all DCs.
>
> The question is why?
>
> I upgraded from a custom compiled Samba ~4.0 to Samba 4.9 about a little
over a month ago.
>
> Shortly after upgrading, I noted strange behavior with seemingly high
CPU/RAM usage on DCs causing logon issues. Additionally, I was seeing errors in
the output of "samba-tool drs kcc <DC>". That discussion is
here: https://lists.samba.org/archive/samba/2019-April/222643.html
>
> The first problem of high load seemed to resolve itself after we increased
resources on the system and tweaked AV settings on the box.
>
> The second problem was resolved by off-setting CRONs so that
"samba-tool drs kcc <DC>" did not run at the same time.
>
> However, while debugging with the list, several smb.conf edits were
suggested. One suggestion was the removal of "acl:search = no". It was
noted that it was a very old fix and unlikely to be needed now. However, it
seems I do need it.
>
> Does anyone have any information on that directive? I'm having issues
finding it in the man page.
Did you classicupgrade originally ?

try reading this bug:

https://bugzilla.samba.org/show_bug.cgi?id=9481

Rowland

No -- we never ran classicupgrade.

We created the original DCs with a custom package (that should be close, but not
exactly the same as 4.0.6).

We then took a fresh 4.9 DC, joined it to the old domain, removed the old DCs
and transferred the FSMO roles.

As our original DCs should be close to 4.0.6, I would think this bug doesn't
quite apply as it was supposedly fixed by 4.0.1.

----- On May 23, 2019, at 3:08 PM, samba samba at lists.samba.org wrote:
> On 23/05/2019 20:45, Mike Ray wrote:
>> OK -- I fixed this issue.
>>
>> The fix also fixed the issue where the following ldapsearch command use
to
>> return but no longer did:
>> # ldapsearch -x -H ldap://DC -b dc=domain,dc=local
>> "(&(gidNumber=xxxx)(!(uidNumber=*)))"
>>
>> The answer is that I needed to re-add "acl:search = no" to
the smb.conf to all
>> DCs.
>>
>> The question is why?
>>
>> I upgraded from a custom compiled Samba ~4.0 to Samba 4.9 about a
little over a
>> month ago.
>>
>> Shortly after upgrading, I noted strange behavior with seemingly high
CPU/RAM
>> usage on DCs causing logon issues. Additionally, I was seeing errors in
the
>> output of "samba-tool drs kcc <DC>". That discussion is
here:
>> https://lists.samba.org/archive/samba/2019-April/222643.html
>>
>> The first problem of high load seemed to resolve itself after we
increased
>> resources on the system and tweaked AV settings on the box.
>>
>> The second problem was resolved by off-setting CRONs so that
"samba-tool drs kcc
>> <DC>" did not run at the same time.
>>
>> However, while debugging with the list, several smb.conf edits were
suggested.
>> One suggestion was the removal of "acl:search = no". It was
noted that it was a
>> very old fix and unlikely to be needed now. However, it seems I do need
it.
>>
>> Does anyone have any information on that directive? I'm having
issues finding it
>> in the man page.
> 
> Did you classicupgrade originally ?
> 
> try reading this bug:
> 
> https://bugzilla.samba.org/show_bug.cgi?id=9481
> 
> Rowland
> 
> 
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

On 23/05/2019 22:39, Mike Ray wrote:
> No -- we never ran classicupgrade.
>
> We created the original DCs with a custom package (that should be close,
but not exactly the same as 4.0.6).
>
> We then took a fresh 4.9 DC, joined it to the old domain, removed the old
DCs and transferred the FSMO roles.
>
> As our original DCs should be close to 4.0.6, I would think this bug
doesn't quite apply as it was supposedly fixed by 4.0.1.
>
Well yes, but it comes pretty damn close ;-)

Rowland