[Samba] Various AD issues; summary
L.P.H. van Belle
belle at bazuin.nl
Thu May 23 09:59:36 UTC 2019
Hai Sven,
Ahh great, so as you see this worked ;-) .
So first goal .. Check.. Fixed resolving, which fixed the db replication.
Basicly what happend, at least, from what i see and observed in the long run.
You where running on setups of years ago, that worked.
But after so many bugfixes, not only samba itself, but that complete package.
As in debian samba cifs kernels SMB ntlm_auth and more.
Now windows also tightening its security, and that full package was the problem.
As you where slowing hitting small problems, untill it exploded..
Now, at least now all pressure is gone, you know what to do, finish these things up as i suggested.
Do make that checklist and force yourself to follow it.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Sven
> Schwedas via samba
> Verzonden: donderdag 23 mei 2019 11:15
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Various AD issues; summary
>
> Replication now shows zero problems. One user's account was still
> nonfunctional, but as far as I can tell it was created in the
> middle of
> the replication issues and L1 support deleted it a few times on
> different DCs and recreated it until it somehow worked. We're
> working on
> improving internal communications?
>
> Recreated user account seems to work, logon failures also seem to be
> gone. Now if there was /any/ information as to /why/ it failed the way
> it did when it did, and not months earlier (or later), that'd
> be really
> great. But I'll take what I can get.
>
> On 22.05.19 17:52, Sven Schwedas via samba wrote:
> >
> >
> > On 22.05.19 15:31, L.P.H. van Belle wrote:
> >> 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)
> >
> > Yeah, now that I have the time for it. That's why I posted them all.
> >
> >> 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.)
> >
> > Fixed.
> >
> >> 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
> >
> > Fixed.
> >
> >> 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.
> >
> > No idea what systemd-networkd is even doing there. None of this is
> > intended? Fixed now.
> >
> >> /etc/resolv.conf
> >> nameserver 192.168.17.1
> >> Only one DC? And you have 4..
> >
> > For the record, that's not a DC, that's a dnsmasq on the firewall.
> > Requests for ad.tao.at and internal range RDNS requests are
> forwarded to
> > the samba servers, the rest goes to external servers.
> >
> > DNSMasq is there to provide stuff not related to the samba
> domain, which
> > is mostly needed for client PCs. So switching over DCs and member
> > servers to using AD DCs directly is easy, but client PCs
> will need to
> > remain on DNSMasq. From what I've seen, all AD related
> queries resolve
> > fine with it, too.
> >
> >> For every DC and per site, you have 2 sites correct?
> >
> > 2 physical sites (192.168.17/24 and 192.168.16/24) in
> different subnets,
> > but they're organized as a single logical site in AD and
> VPN'd together
> > via default gateway.
> >
> >> 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.
> >>
> >> 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.
> >
> > Should be fixed now.
> >
> >> 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.
> >
> > Shouldn't be an issue with how few clients are involved
> here, but I'll
> > keep an eye on it.
> >
> >> 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?
> >
> > Legacy setup had our domain on tao.at directly, I think we
> needed that
> > to smooth over the transition. But that was years ago and
> shouldn't be
> > needed any more.
> >
> >> /etc/nsswitch.conf
> >> passwd: files winbind
> >> group: files winbind
> >> shadow: files < winbind removed here.
> >
> > Fixed too, probably.
> >
> >> /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.
> >
> > Might want to actually document that somewhere, this isn't
> clear from
> > either wiki nor manpage.
> >
> >> 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.
> >
> > Some horribly obsolete PHP5 LDAP library breaks with SSL, as a
> > workaround we're SSH tunneling it until we can kill it. Which
> > *hopefully* should be sometimes this month anyway, so no
> point in fixing
> > it now.
> >
> >> Because here, i think you forgot to also define
> /etc/ldap/ldap.conf
> >> .. And i missed this in the script, i'll add this ..
> >
> > Added as well.
> >
> >> 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..
> >
> > I don't think we're even using it nowadays, so I've gutted
> it from all DCs.
> >
> >> Installed packages:
> >> Missing attr
> >> Which is a must install for the DC's.
> >
> > Should be fixed too.
> >
> >> 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.
> >
> > They should be all modified accordingly now:
> >
> > https://up.tao.at/u/samba/graz-file.info2.txt
> > https://up.tao.at/u/samba/graz-mail.info2.txt
> > https://up.tao.at/u/samba/graz-dc-sem.info2.txt
> > https://up.tao.at/u/samba/graz-dc-1b.info2.txt
> > https://up.tao.at/u/samba/villach-file.info2.txt
> > https://up.tao.at/u/samba/villach-mail.info2.txt
> > https://up.tao.at/u/samba/villach-dc-1a.info2.txt
> > https://up.tao.at/u/samba/villach-dc-bis.info2.txt
> >
> > And now that business hours are over, also all restarted.
> I'll let them
> > do their thing overnight and check up on replication status tomorrow
> > morning.
> >
> >
>
> --
> 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
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
More information about the samba
mailing list