Re: [Samba] dsdb_access Access check failed on CN=Configuration
- Date: Wed, 22 May 2019 14:09:33 -0500 (CDT)
- From: Mike Ray via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] dsdb_access Access check failed on CN=Configuration
----- On May 22, 2019, at 1:00 PM, samba samba@xxxxxxxxxxxxxxx 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@xxxxxxxxxxx wrote:
>>> Setting the log level to 10 shows this blurp in the output of the ldapcmp
>>> resolve_lmhosts: Attempting lmhosts lookup for name
>>> 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
> 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:
> 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.
> 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.
To unsubscribe from this list go to the following URL and read the