[Samba] Various AD issues; summary

Wed May 22 13:31:11 UTC 2019

Hai, 

Well, good that your more relax and releaved in pressure.. 
Apoligies accepted. ;-), i know the fealing but do understand, we are trying to help out.. 

As you know, it very frustration to ask the same things again, and you showing them again
But now as you showed with all the configs. It is needed.. (sorry) 

So I had a quick look, and you up to some changes. All are fixable, no worries,
but it takes a bit of time and you need to be precise/accurate. 

For example, 

https://up.tao.at/u/samba/graz-dc-1b.info.txt 
Hostname: graz-dc-1b
DNS Domain:	
FQDN: graz-dc-1b
ipaddress: 169.254.93.226 192.168.17.66
- Where is the DNS domain?  ( i'll add warning in the script there if its missing.) 
Cause:  Checking file: /etc/hosts

127.0.0.1 graz-dc-1b localhost
- Which is wrong. 

- I would have expected to see: 
127.0.0.1 localhost

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

192.168.17.66	graz-dc-1b.ad.tao.at graz-dc-1b

And this one, i should not see that, execpt if its a dhcp thats failing. 
169.254.93.226 NetName: LINKLOCAL-RFC3927-IANA-RESERVED

And if you did disable IPv6, which you attempted, at least looks like it. 
 inet6 fe80::b8de:f4ff:fe1e:11e5/64 scope link is on the interface, but the ipv6 parts where missing in /etc/hosts. 

/etc/resolv.conf
nameserver 192.168.17.1
Only one DC? And you have 4.. 

For every DC and per site, you have 2 sites correct? 
I suggest, per site, 2 DC of the same site, 1 DC of the remote as backup. 
Look at this, explanation is below it. The DC1 with fsmo. 
/etc/resolv.conf ( by example )
domain ad.tao.at
nameserver IP_DC1_WITH_FSMO
nameserver IP_DC2
nameserver IP_DC3_S2

DC2. 
/etc/resolv.conf ( by example ) 
domain ad.tao.at
nameserver IP_DC1_WITH_FSMO
nameserver IP_DC2
nameserver IP_DC4_S2
# Before reboot and after reboot and wait time and db replication check. 
#nameserver IP_DC2
#nameserver IP_DC1_WITH_FSMO
#nameserver IP_DC4_S2

# one example site 2.
# Before.. DC2.
/etc/resolv.conf
# depending on how your site is defined in AD. 
# search site2.tao.at ad.tao.at 
# search site2.tao.at
# if all in same domain: 
search ad.tao.at
nameserver IP_DC1_WITH_FSMO
nameserver IP_DC1_SITE2
nameserver IP_DC2_SITE2
# After reboot and after checking the resolving. 
/etc/resolv.conf
nameserver IP_DC1_SITE2
nameserver IP_DC2_SITE2
nameserver IP_DC1_WITH_FSMO

# some options you can play with, put them in the resolv.conf but do not enable them yet. 
# I use bind, you are using internal DNS. 
#options timeout:2
#options attempts:2
#options edns0
#options single-request
#options single-request-reopen

Now the 2 resolv.conf examples and /etc/hosts file, should make sure your hostname and dnsdomain is correct. 
As shown per example this needs to be correct before we do anything else, and yes, fix this for every server. 

For the replication. 
You see, i've kept in both resolv.conf files DC1 as first, you need this for the first replication. 
After a reboot and at least 15 min-30 main waiting, on DC2, switch the DC1 and DC2 lines and set DC2 first. 
And this is for every server needed. I wont hurt if DC1 stays first, but that could overload DC1 on DNS requests.

For all DC's and members, all you need: ( i install krb5-user, define the REALM and keep everythings default. 
So this is sufficient.  ( yes only that one default_realm line, others are defaults ) 

/etc/krb5.conf
[libdefaults]
        default_realm = AD.TAO.AT

Except, i noticed, 
	.tao.at = AD.TAO.AT
	tao.at = AD.TAO.AT
That might need some more explanation why you added it.
That helps me understanding your setup. SSO login with users email adresses maybe? 

/etc/nsswitch.conf
passwd:         files winbind
group:          files winbind
shadow:         files 			< winbind removed here. 

/etc/samba/smb.conf
	ldap ssl = start tls
	ldap ssl ads = yes
These are not supported in the AD setup. These are for an NT4DOM/ PDC/BDC setup with ldap. 

And i like how you did split up the global part and the "real" server config part. 
One im going to use also..  So noo, not only bad thin, also good things.. 

I noticed also: 
	#FIXME: Temporary to fix PHP shit
	ldap server require strong auth = no

# explain this to me, can offlist if needed. 
Because here, i think you forgot to also define /etc/ldap/ldap.conf 
.. And i missed this in the script, i'll add this ..

# /etc/ldap/ldap.conf 
# example, change the hostnames.. ( saved me typing ) ;-) 
BASE    dc=ad,dc=tao,dc=at
URI     ldaps://dc1.ad.tao.at ldaps://rtd-dc2....  ldaps://dc3...  ldaps://dc4... 
# and here again, first the 2 within the same site, then the 2 others. 
# Note, all my servers use ldaps (ssl), you can use ldap with TLS also. 

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

# and minimal 
TLS_REQCERT allow

# i did see you added the certificates also with update-ca-certificates correct, if yes. 
# then the company cert is in : /etc/ssl/certs/ca-certificates.crt 
# if no, then you need to define it. 

Last one, 
[homes]
	msdfs root = yes
	msdfs proxy = \\graz-file\homes

	As per MS advice, \\graz-file.ad.tao.at\users

You might hit a bug here because [homes] on the DC's is not really supported. 
Better might be [users] but this one needs planning... before you change it. 
You understand that..

Installed packages:
Missing attr 
Which is a must install for the DC's. 

Now this was only 1 server but this is exact the same for all DC's 
This must be corrected before we can even look at the DB replication problem. 
Almost all server suffer from simular problems in the setup. 

I suggest start with above. That is the base. 
For the members, hosts resolv.conf nsswitch.conf krb5.conf all need to be fixed first. 
Scary, yes, i understand, start with DC1_fsmo DC. 

Do one at the time, check all the above, so make a checklist for this. 

I have more, but start here, doing this will give you the ability to resync the AD-DB from DC1 to DC2 in site1. 
And from there we can work to the member fixes. 
Most probly some problem will disappear after these fixed, and sure you get some back, but these you get only once.
Because now the base setup is correct, and will never change again. 
My changes on my DC's ( since wheeze and samba 4.1.x ), only 3 lines in smb.conf due to samba upgrades. 
And one in bind configs due to changes in the path of bind_dlz. 

Sorry, its a bit of work, i know, but put in one day now, and your able to set it and forget it and your future ready.. 

Now, im back to building the new 4.10.4 packages. 

For sofar, 

Greetz, 

Louis

> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:sven.schwedas at tao.at] 
> Verzonden: woensdag 22 mei 2019 12:42
> Aan: samba at lists.samba.org
> CC: L.P.H. van Belle
> Onderwerp: Various AD issues; summary
> 
> 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_D
> NS_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
> 
> 