samba - Oct 2022 - samba-tool domain join: Unable to open tdb '/var/lib/samba/private/secrets.ldb': No such file or directory

31.10.2022 16:27, Rowland Penny via samba wrote:
> On 31/10/2022 13:07, Michael Tokarev via samba wrote:
..
>> ldb: Failed to connect to '/var/lib/samba/private/secrets.ldb'
with backend 'tdb': Unable to open tdb
'/var/lib/samba/private/secrets.ldb': No such
>> file or directory
>> Joined domain tls.msk.ru (S-1-5-21-411424318-379842365-2075518510)
>> # _
>>
>> So it looks like it joined successfully (tho it does not
>> add an uid to the machine account), despite these error
>> messages.
> 
> The join doesn't add a Unix ID to a computers object:
> 1) it is only used by the 'ad' idmap backend
> 2) there is nowhere to find the next ID to use.
Yeah it doesn't, and I remember coming across that already in the past
debugging
this issue, - I had to manually add uidNumber & gidNumber to the computer
object.
But I didn't add these attributes to all of them, - eg, another (non-test)
server
here (which also logs this very error message *alot*, btw) does not have it too,
while some windows machines have it.

If it can not be added automatically but is required, maybe it is a good idea
to add a warning somewhere at the end of `samba-tool domain join' output
about
that?
>> [2022/10/31 16:02:43.961859,? 1]
../../lib/ldb-samba/ldb_wrap.c:79(ldb_wrap_debug)
>> ?? ldb: Failed to connect to
'/var/lib/samba/private/secrets.ldb' with backend 'tdb': Unable
to open tdb '/var/lib/samba/private/secrets.ldb': No
>> such file or directory
> 
> At one time, on a Unix domain member, just doing something that would ask
for secrets.ldb would result in an empty file being created. This was
> stopped sometime ago.
It seems there's any sort of activity which result in that.. :)

>> # Global parameters
>> [global]
>> ???????? dedicated keytab file = /etc/krb5.keytab
>> ???????? disable spoolss = Yes
>> ???????? kerberos method = secrets and keytab
>> ???????? log file = /var/log/samba/log.%m
>> ???????? log level = 1
>> ???????? max log size = 1000
>> ???????? netbios name = WH
>> ???????? realm = TLS.MSK.RU
>> ???????? workgroup = TLS
>> ???????? security = ADS
>> ???????? server role = member server
>> ???????? winbind use default domain = Yes
>> ???????? idmap config tls : backend = ad
>> ???????? idmap config tls : range = 1000-4999
> 
> Have you added uidNumber & gidNumber attributes to your AD ?
> They are not added automatically.
I've added uidNumber now.  The error message in $subj, obviously, is still
being logged.
> Also why are you using such a low range ?
Well, this is because you said many months ago that having local users with
the same names as in AD is wrong.  So I had to remove local users, but changing
their UIDs is too problematic as it will result in *lots* of chown'ing. So I
kept
their UIDs the same as before.
> By starting at 1000, you cannot have any local Unix users or groups.
This is incorrect because of two reasons.

1. Local unix users can have any UIDs too, not only 1000 and up.  Yes, *by
default*,
adduser will start at 1000 and find the next unused UID. But a) adduser is not
the
only tool to manage /etc/passwd, even echo "user:pw:uid:gid:..."
>> /etc/passwd will
do, and b) these are just the defaults, one can fix them in /etc/adduser.conf.
And second, nss_winbind is listed *second* in nsswitch.conf, with first being
nss_files. So any getpwuid() lookup will first look up a local uid, and only if
that fails, nss_winbind will do its work, - and if you're accurate, there
will
be no conflicts in there.  idmap config range is just a quick filter for
winbindd
to route this uid to the right domain, at least as far as I see.
>> ???????? idmap config tls : schema_mode = rfc2307
>> ???????? idmap config tls : unix_primary_group = yes
>> ???????? idmap config * : backend = tdb
>> ???????? idmap config * : range = 5000-5099
> 
> You are going to need more than '99' for the default domain.
This is interesting. So far I don't see any uids used in there. At least
getent passwd 5000..50099 return nothing (while getent passwd 1006 does
return mjt-adm info).  What these user IDS are used for, and when?

Thank you!

/mjt

On 31/10/2022 14:03, Michael Tokarev wrote:
> 31.10.2022 16:27, Rowland Penny via samba wrote:
>> On 31/10/2022 13:07, Michael Tokarev via samba wrote:
> ..
>>> ldb: Failed to connect to
'/var/lib/samba/private/secrets.ldb' with
>>> backend 'tdb': Unable to open tdb 
>>> '/var/lib/samba/private/secrets.ldb': No such file or
directory
>>> Joined domain tls.msk.ru (S-1-5-21-411424318-379842365-2075518510)
>>> # _
>>>
>>> So it looks like it joined successfully (tho it does not
>>> add an uid to the machine account), despite these error
>>> messages.
>>
>> The join doesn't add a Unix ID to a computers object:
>> 1) it is only used by the 'ad' idmap backend
>> 2) there is nowhere to find the next ID to use.
> 
> Yeah it doesn't, and I remember coming across that already in the past 
> debugging
> this issue, - I had to manually add uidNumber & gidNumber to the 
> computer object.
> But I didn't add these attributes to all of them, - eg, another 
> (non-test) server
> here (which also logs this very error message *alot*, btw) does not have 
> it too,
> while some windows machines have it.
> 
> If it can not be added automatically but is required, maybe it is a good 
> idea
> to add a warning somewhere at the end of `samba-tool domain join'
output
> about
> that?
Sorry, but I am not going to try and fight that battle again.

> 
>> Also why are you using such a low range ?
> 
> Well, this is because you said many months ago that having local users with
> the same names as in AD is wrong.? So I had to remove local users, but 
> changing
> their UIDs is too problematic as it will result in *lots* of chown'ing.
> So I kept
> their UIDs the same as before.
> 
>> By starting at 1000, you cannot have any local Unix users or groups.
> 
> This is incorrect because of two reasons.
> 
> 1. Local unix users can have any UIDs too, not only 1000 and up.
I accept this, but a normal user doesn't want to jump through hoops to 
create users, best to stick to standard practices.
>> You are going to need more than '99' for the default domain.
> 
> This is interesting. So far I don't see any uids used in there. At
least
> getent passwd 5000..50099 return nothing (while getent passwd 1006 does
> return mjt-adm info).? What these user IDS are used for, and when?

Microsoft has the concept of Well Known SIDs and there are nearly 200 of 
these, they are mapped on a first come basis in the default '*' domain 
.tdb file, there also need to to be space for anything outside your main 
domain e.g. another domain.

Rowland