[Samba] RODC infrastructure instability (Samba v. 4.13, 4.14)

Thu Nov 18 14:41:21 UTC 2021

Dear list,

We are using a number of ADDCs and we were planning to maintain RODCs
for some security and resiliency reasons.

Unfortunately the experience till now is of instability that makes us
hesitate to rollout this infrastructure on more sites.

A description of what we encountered related to how authentication on

mounting shares is handled:

Samba versions tested: 4.13, 4.14 (all machines equipped with the same
version each time)

Some days or weeks after having the RODC working correctly, eventually
we get "Permission denied (13)" for users that till that moment had
correctly logged in. There is no shares issue as this has been checked
and other users for example can mount those. The ADDCs show a [All Good]
regardin the replication status.

The latest attempt that made us thinking going back to ADDC was after
changing user´s data on an ADDC and then preloading on the RODCs.
The preload works well.

But "Permission denied (13)" with samba client on Linux and "Access denied
error 5" under windows appeared. Testing then with known already
preloaded users gave the same result.
Clearing the cache with "net cache delete/flush" on the file-server side
did not give any results. So this is why we concentrated on an
authentication issue on the RODCs.

The same user logging in with a client on the side, where only ADDCs
exists, has access to any share on which he gets an "Access denied error
5" on the "RODC side".Replacing the RODC with an ADDC gave access for
the user again.

As on two of those it happened that the share would actually open but
after a first failed login ("second click") we could presume that one of
the two authentication handling RODCs used in that context, had the
problem. Shutting down only the first gave the same "second time access"
on windows while still "Permission denied (13)" in Linux. A dmesg
reports some question related to Samba "dialects" but even explicitly
declaring the version in the mount command has no effect. Shutting down
only the second had similar results. Shutting down both we correctly had
no access at all so we presume there were no cached items in the
previous attempts either (we would have been faced with the credentials
request window, but we correctly did not).

This kind of behaviour is not consistent and we could not reproduce
exact steps that lead to that, even because in the beginning everything
seems going fine and there is no log evidence of something "strange"
happening. And the logs during the failed mount attempts are rather poor
in information.

Are we looking at the "wrong place" for evidence? Do we miss/need
something in the infrastructure? Like the sites or sites interconnection
settings?

Any information on this would be highly appreciated as we would like not
to abandon the idea of using RODCs.

-- 
forumZFD
Entschieden für Frieden|Committed to Peace

Ilias Chasapakis
Referent IT | IT Consultant

Forum Ziviler Friedensdienst e.V.|Forum Civil Peace Service
Am Kölner Brett 8 | 50825 Köln | Germany

Tel 0221 91273233 | Fax 0221 91273299 |
http://www.forumZFD.de

Vorstand nach § 26 BGB, einzelvertretungsberechtigt|Executive Board:
Oliver Knabe (Vorsitz|Chair), Sonja Wiekenberg-Mlalandle, Alexander Mauz
VR 17651 Amtsgericht Köln

Spenden|Donations: IBAN DE37 3702 0500 0008 2401 01 BIC BFSWDE33XXX

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba/attachments/20211118/f6ad0cc6/OpenPGP_signature.sig>