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

----- On May 22, 2019, at 1:00 PM, samba samba at lists.samba.org wrote:
> On 22/05/2019 18:24, Mike Ray wrote:
>> Poking around on this further, I believe the LMHOSTS error does not
matter.
>>
>> The smb directive "name resolve order" defaults to
"lmhosts wins host bcast" --
>> so I believe the file no found error is just because it's trying
lmhosts first,
>> not finding the file and then moving on.
>>
>> Eventually it hits "host" resolution and uses /etc/hosts to
resolve the name.
>>
>> Changing the directive so that "host" is first and then
re-running the command
>> just removes the lmhosts errors; however the "ERROR(ldb): uncaught
exception -
>> LDAP error 32 LDAP_NO_SUCH_OBJECT - <dsdb_access: Access check
failed ..." is
>> still present.
>>
>> ----- On May 22, 2019, at 11:52 AM, Mike Ray mray at xes-inc.com wrote:
>>
>>> Setting the log level to 10 shows this blurp in the output of the
ldapcmp
>>> command:
>>>
>>> resolve_lmhosts: Attempting lmhosts lookup for name
>>> dc3.otherinternaldomain.local<0x20>
>>> startlmhosts: Can't open lmhosts file /etc/samba/lmhosts. Error
was No such file
>>> or directory
>>> ERROR(ldb): uncaught exception - LDAP error 32 LDAP_NO_SUCH_OBJECT
-
>>> <dsdb_access: Access check failed on
CN=Configuration,DC=domain,DC=local> <>
>>>
>>>
>>> I can confirm that file does not exist.
>>>
>>> It is interesting that it is looking for the
'otherinternaldomain.local' instead
>>> of just 'domain.local'.
>>>
>>> However, removing that entry from /etc/hosts does not change the
output of the
>>> command.
> 
> Your Samba AD DC's are all authoritative for the AD dns domain and they
> should only know about computers etc that are in their domain. The
> computer 'dc3.otherinternaldomain.local' is not the same computer
as
> 'dc3.domain.local', anything outside the 'domain.local'
domain, which
> 'dc3.otherinternaldomain.local' is, should be forwarded to a dns
server
> outside the AD domain, but I fear this will not work in this case,
> because 'dc3.otherinternaldomain.local' probably doesn't really
exist.
I want 'dc3.otherinternaldomain.local' and 'dc3.domain.local' to
resolve to the same computer so computers outside the domain can do things like
ldapsearch. As I thought about it though, we have separate DNS servers that
handle 'otherinternaldomain.local' and so I have removed the local
/etc/hosts record as the DC doesn't need to self-resolve it.

> 
> You have confirmed (by the ldapsearch) that the record exists, so the
> problem is possibly dns related.
> 
> You shouldn't need those GUID records in /etc/hosts, so have you read
> this wikipage:
> 
> https://wiki.samba.org/index.php/Verifying_and_Creating_a_DC_DNS_Record
> 
> If dns is correct, when you join a DC, all the required dns records
> should be created by samba_dnsupdate, but if the GUID record isn't
> created (and it wasn't at one time) then it fails.
I have read that wiki page before -- but I went ahead and verified all the HOST
and CNAME records just to be paranoid; they are all there.
> 
> Rowland
> 
> 
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

I removed the CNAMES from /etc/hosts just to see what would happen and in the
~30 minutes since I have made that change, replication is still functional.
Perhaps my original replication errors were caused by something else and adding
those records to /etc/hosts was a red herring.

However, even after correcting these things, the ldapcmp command is still
returning the same error as before.

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.

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