Ilias Chasapakis forumZFD
2021-Nov-18 14:41 UTC
[Samba] RODC infrastructure instability (Samba v. 4.13, 4.14)
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>