Rick Hollinbeck
2020-Feb-14 19:47 UTC
[Samba] Samba 4.11.6 cannot JOIN - 'Could not find machine account'
Dug deeper (i.e. into the source code)... no answer yet.
The samba join process is failing when fetching the domain's machine
password
from the secrets.tdb database, which presumably it has just built as part of the
JOIN..
Specifically, it is looking for an entry:
"SECRETS/$MACHINE.ACC/OFFICE" in secrets.tdb.
When that fails, samba looks in secrets.ldb in "cn=Primary Domains".
That cn does not exist in my Windows DNS (this is not a legacy NT4 style
domain).
So, this search fails also and the whole JOIN then fails.
So the question is: Why isn't "SECRETS/$MACHINE.ACC/OFFICE" found
in secrets.tdb?
Grepping the samba source code only shows two places where this key is
referenced:
files: machine_account_secrets.c and samba3/_init_.py.
Both uses are READ accesses.
So, who WRITES this key - somewhere in the code, I would think.
Or, does it come from the Windows side during the join and replication?
Here's the relevant log entries in log.winbindd...
[2020/02/14 16:59:37.564101, 3]
../../source3/winbindd/winbindd_util.c:297(add_trusted_domain)
add_trusted_domain: Added domain [BUILTIN] [(null)] [S-1-5-32]
[2020/02/14 16:59:37.564782, 3]
../../source3/winbindd/winbindd_util.c:297(add_trusted_domain)
add_trusted_domain: Added domain [OFFICE] [office.example.com]
[S-1-5-21-3876585788-2465688680-3807591480]
--- HERE'S WHERE THE TROUBLE STARTS ---
[2020/02/14 16:59:37.564842, 5]
../../source3/passdb/passdb.c:2396(get_trust_pw_clear2)
get_trust_pw_clear2: could not fetch clear text trust account password for
domain OFFICE
[2020/02/14 16:59:37.564857, 5]
../../source3/passdb/machine_account_secrets.c:343(secrets_fetch_trust_account_password
_legacy)
secrets_fetch failed!
[2020/02/14 16:59:37.564866, 5]
../../source3/passdb/passdb.c:2475(get_trust_pw_hash2)
get_trust_pw_hash: could not fetch trust account password for domain OFFICE
[2020/02/14 16:59:37.566881, 3]
../../lib/ldb-samba/ldb_wrap.c:332(ldb_wrap_connect)
ldb_wrap open of secrets.ldb
[2020/02/14 16:59:37.566960, 1]
../../auth/credentials/credentials_secrets.c:426(cli_credentials_set_machine_account_db_ctx)
Could not find machine account in secrets database: Failed to fetch machine
account
password for OFFICE
from both secrets.ldb
(Could not find entry to match filter:
'(&(flatname=OFFICE)(objectclass=primaryDomain))'
base: 'cn=Primary Domains':
No such object: dsdb_search at ../../source4/dsdb/common/util.c:4733)
and from /var/lib/samba/private/secrets.tdb:
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2020/02/14 16:59:37.566995, 0]
../../source3/winbindd/winbindd_util.c:878(migrate_secrets_tdb_to_ldb)
Failed to fetch our own, local AD domain join password for winbindd's
internal use,
both from secrets.tdb and secrets.ldb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2020/02/14 16:59:37.567595, 0]
../../source3/winbindd/winbindd_util.c:1217(init_domain_list)
Failed to migrate our own, local AD domain join password for winbindd's
internal use into
secrets.tdb
[2020/02/14 16:59:37.567761, 0]
../../source3/winbindd/winbindd.c:1462(winbindd_register_handlers)
unable to initialize domain list
----
secrets.ldb does show a record for "Primary Domains":
# record 2
dn: CN=Primary Domains
cn: Primary Domains
objectClass: top
objectClass: container
objectGUID: 8ca0a56e-d...e5524c75
whenCreated: 20200213164429.0Z
whenChanged: 20200213164429.0Z
uSNCreated: 6
uSNChanged: 6
name: Primary Domains
distinguishedName: CN=Primary Domains
---
I tried running:
sudo samba_upgradedns --dns-backend=BIND9_DLZ
to see what it reports:
...
Processing section "[sysvol]"
Processing section "[netlogon]"
pm_process() returned Yes
schema_fsmo_init: we are master[no] updates allowed[no]
Traceback (most recent call last):
File "/usr/sbin/samba_upgradedns", line 292, in <module>
paths, lp.configfile, lp)
File "/usr/lib/python3/dist-packages/samba/provision/__init__.py",
line 209, in
find_provision_key_parameters
names.netbiosname =
str(res[0]["sAMAccountName"]).replace("$", "")
IndexError: list index out of range
----
I am wondering if the Windows server's DNS SHOULD have a Primary Domains CN
partition...
It is missing on the Windows side.
Is this what my problem is?
If so, how can I recreate it on the Windows Server?
Andrew Bartlett
2020-Feb-14 20:03 UTC
[Samba] Samba 4.11.6 cannot JOIN - 'Could not find machine account'
On Fri, 2020-02-14 at 12:47 -0700, Rick Hollinbeck via samba wrote:> Dug deeper (i.e. into the source code)... no answer yet. > > The samba join process is failing when fetching the domain's machine password > from the secrets.tdb database, which presumably it has just built as part of the JOIN.. > > Specifically, it is looking for an entry: "SECRETS/$MACHINE.ACC/OFFICE" in secrets.tdb.I'm really sorry for this red herring. We are actually hoping for the reverse. The hope is that this fails, because this means we are not successfully joined to this domain already (we use the password to connect, if we connect successfully we fail). This was added to prevent administrators accidentally re-joining existing, fully functional DCs to the domain, and so triggering a replication flush around a potentially quite large domain. Sadly it triggers debug messages because it is using the code 'backwards' and this would normally be a problem. Your error is later than this. Sorry, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Rowland penny
2020-Feb-14 20:27 UTC
[Samba] Samba 4.11.6 cannot JOIN - 'Could not find machine account'
On 14/02/2020 20:03, Andrew Bartlett via samba wrote:> On Fri, 2020-02-14 at 12:47 -0700, Rick Hollinbeck via samba wrote: >> Dug deeper (i.e. into the source code)... no answer yet. >> >> The samba join process is failing when fetching the domain's machine password >> from the secrets.tdb database, which presumably it has just built as part of the JOIN.. >> >> Specifically, it is looking for an entry: "SECRETS/$MACHINE.ACC/OFFICE" in secrets.tdb. > I'm really sorry for this red herring. We are actually hoping for the > reverse. > > The hope is that this fails, because this means we are not successfully > joined to this domain already (we use the password to connect, if we > connect successfully we fail). > > This was added to prevent administrators accidentally re-joining > existing, fully functional DCs to the domain, and so triggering a > replication flush around a potentially quite large domain. > > Sadly it triggers debug messages because it is using the code > 'backwards' and this would normally be a problem. > > Your error is later than this. > > Sorry, > > Andrew Bartlett >Andrew, has the code change ? (if so, I must have missed it and cannot find where), it used to print 'Join failed - cleaning up', then go on about the password. I feel sure this is because the Windows domain was based on the pre 2008 DNS Could the entire DomainDnsZones & ForestDnsZones objects be removed and then recreated (correctly) with samba_upgradedns ???? Rowland