[Samba] Various AD issues; summary

Wed May 22 10:42:09 UTC 2019

Alright, I managed to jury-rig LDAP-authenticated FTP access to the file
shares, which works well enough that I no longer have the whole company
breathing down my neck. Sorry for being so cranky yesterday.

From what we've established, it seems that there are a bunch of
replication issues, maybe others:

• Authentication on one member server fails for some users, but not all.
There doesn't seem to be any pattern to who is and isn't affected.

• Trust between PCs and the domain is randomly lost. That was handled by
L1 support without telling me (they just re-joined the PCs every other
week), so I wasn't aware of that yesterday

• All sorts of replication issues between the various DCs:

> https://up.tao.at/u/samba/graz-dc-sem.txt (FSMO role holder)
> https://up.tao.at/u/samba/graz-dc-1b.txt
> https://up.tao.at/u/samba/villach-dc-1a.txt
> https://up.tao.at/u/samba/villach-dc-bis.txt

(Unchanged from yesterday)

• Some DB issues:

> https://up.tao.at/u/samba/graz-dc-sem-dbcheck.txt
> https://up.tao.at/u/samba/graz-dc-1b-dbcheck.txt
> https://up.tao.at/u/samba/villach-dc-1a-dbcheck.txt
> https://up.tao.at/u/samba/villach-dc-bis-dbcheck.txt

(Unchanged from yesterday)

And since we now actually have time for this, all collected info for all
domain-joined servers:

https://up.tao.at/u/samba/graz-dc-1b.info.txt
https://up.tao.at/u/samba/graz-dc-sem.info.txt
https://up.tao.at/u/samba/graz-file.info.txt
https://up.tao.at/u/samba/graz-mail.info.txt
https://up.tao.at/u/samba/villach-dc-1a.info.txt
https://up.tao.at/u/samba/villach-dc-bis.info.txt
https://up.tao.at/u/samba/villach-file.info.txt
https://up.tao.at/u/samba/villach-mail.info.txt

I have no idea how villach-dc-bis worked so far with that krb5.conf
setup, but I guess that needs fixing.

For general smb.conf stuff, the features we now still need are

• rfc2307-based Unix attributes (it's where we get all UIDs/GIDs from)
• ACLs are set programmatically with a script (management wants that
locked down), so if there's a better way to handle those, we can just
nuke the current setup and reset them all
• ACLs still need to work for people SSHing (or now FTPing) into the
servers with their domain accounts, not just from Windows
• New features (like SePrivileges support) aren't interesting, file
shares will be deprecated in favour of Cloud™ Stuff™ soon-ish anyway
(let's see for how long)
• Mail servers need winbind expansion and enumeration to support legacy
stuff that we won't get around to fix for a while yet (the domain has
like 50 users and a maximum nesting depth of 1, so performance is fine
for now)

With these constraints, what are the minimal smb.conf setups I need?

Other todos for now:

• Fix krb5.conf everywhere (remove dns_lookup_realm?)
• Improve nsswitch setup

I'll get to that when I know what all the smb.confs need to look like.

And going back to Louis' email:

On 22.05.19 10:29, L.P.H. van Belle wrote:
> Yes, then it does take the hostname. Just be warned, that in such
> cases the hostname max lenght is 15 chars.

That used to be a problem a while back when we had longer hostnames, but
shouldn't apply with the current setup. So I guess we can get rid of
that too.

> You need to verify all GUID of the DC's. ( and A/PTR/CNAME records ) 
> ldbsearch -H /var/lib/samba/private/sam.ldb '(fromServer=*CN=Windows-DC*)' --cross-ncs dn

That gives me no results on all DCs. The wiki suggests using "ldbsearch
-H /var/lib/samba/private/sam.ldb '(invocationId=*)' --cross-ncs
objectguid" for GUIDs, which does give me results.

> Samba INTERNAL_DNS Back End - Troubleshooting

That seems to work fine, there's nothing blocking samba's internal DNS
from listening on :53, and I can query it just fine.

> https://wiki.samba.org/index.php/Verifying_and_Creating_a_DC_DNS_Record

villach-dc-bis doesn't have its _msdcs record set on /any/ server. All
other records are fine on all servers.

I set it on graz-dc-sem as detailed in the wiki, and it replicated fine
to all servers except graz-dc-1b. I restarted samba-ad-dc on that to
increase the log level, and that restart alone seems to have done the
trick, it now has the record as well.

I also fixed villach-dc-bis Kerberos to
> [libdefaults]
> 	default_realm = AD.TAO.AT
> 	dns_lookup_kdc = true
> 	default_keytab_name = FILE:/etc/krb5.keytab
> 
> [domain_realm]
> 	.ad.tao.at = AD.TAO.AT
> 	ad.tao.at = AD.TAO.AT
> 	.tao.at = AD.TAO.AT
> 	tao.at = AD.TAO.AT

and restarted samba-ad-dc on it.

Now, trying to full sync replicate works fine for the base partition and
Configuration, but replicating ForestDnsZones or DomainDnsZones both
fail with:

> ERROR(<class 'samba.drs_utils.drsException'>): DsReplicaSync failed - drsException: DsReplicaSync failed (8440, 'WERR_DS_DRA_BAD_NC')
>   File "/usr/lib/python2.7/dist-packages/samba/netcmd/drs.py", line 368, in run
>     drs_utils.sendDsReplicaSync(server_bind, server_bind_handle, source_dsa_guid, NC, req_options)
>   File "/usr/lib/python2.7/dist-packages/samba/drs_utils.py", line 83, in sendDsReplicaSync
>     raise drsException("DsReplicaSync failed %s" % estr)

Replicating Schema still runs to a timeout on the sending server and a
PANIC on villach-dc-bis.

Log file on villach-dc-bis: https://up.tao.at/u/samba/log.samba.txt

Relevant time stamps 2019/05/22 12:26:26.456202 (ForestDnsZones
failure), 2019/05/22 12:26:49.027595 (DomainDnsZones failure) and
2019/05/22 12:27:03.755312 (Schema panic)

-- 
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
✉ sven.schwedas at tao.at | ☎ +43 680 301 7167
TAO Digital   | Teil der TAO Beratungs- & Management GmbH
Lendplatz 45  | FN 213999f/Klagenfurt, FB-Gericht Villach
A8020 Graz    | https://www.tao-digital.at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba/attachments/20190522/05e97fb7/signature.sig>