On 16/02/2021 15:23, Matthias K?hne | Ellerhold AG wrote:> Hello, > > I thought I needed "security = USER" in order to SSH into my DC with my > AD-user credentials. > > I've removed the uidNumber from "Administrator" and the gidNumber from > "Domain Admins". > > SSH works, but the problem still exists: > > desktop $ ssh matthias.kuehne at DC-2 > matthias.kuehne at DC-2's password: > > DOMAIN\matthias.kuehne at DC-2:~ $ sudo -i > [sudo] password for DOMAIN\matthias.kuehne:try running 'net cache flush' ,it should look like this: rowland at devstation:~$ ssh rowland at dc4 Password: SAMDOM\rowland at dc4:~$ sudo -i [sudo] password for SAMDOM\rowland: root at dc4:~#> > DOMAIN\administrator at DC-2:~ # whoami > DOMAIN\administratorroot at dc4:~# whoami root> > DOMAIN\administrator at DC-2:~ # id > uid=0(DOMAIN\administrator) gid=0(root) groups=0(root)root at dc4:~# id uid=0(root) gid=0(root) groups=0(root)> > Should be "root" I guess? I'd could accept this state if it weren't for > saltstack frantically wanting to chown a lot files back to "root". The > chown works (exits 0) but the check after fails because the files / dirs > are still owned by "DOMAIN\administrator". > > Plus there is now another crontab for "DOMAIN\administrator" thats > different from the root crontab.Once you do get 'root', delete Administrators crontab> > Seems like I'm missing the "username map" but afaik this only works on > domain members and not on DCs?Yes, you only use the username map on a Unix domain member, the mapping on? a DC is done in idmap.ldb (or at least it is stored there)> > Funny enough... this only happens on the DC-2, not on the Primary DC > (DC-1) nor on the DC-3...net cache flush ? Rowland> > > Ive demoted the DC on DC-2, deleted all *.ldb and *.tdb files in > /var/lib/samba/ and rejoined it into the domain - still the same > behavior! > > > Next Ive demoted the DC-2 again, purged all samba packages incl. apt > autoremove --purge. I deleted all DC-2 objects in LDAP (the user and the > computer). After that I reinstalled from scratch. > > The error still happens although it took some time until it presented > itself. > > > Thanks for your help! > > Any other lines in my smb.conf I should purge? I've tried to minimize > them while also trying to keep every functionality I want... > >
Matthias Kühne | Ellerhold AG
2021-Feb-17 11:56 UTC
[Samba] Root user shows up as "administrator"
Hey, sadly "net cache flush" did nothing. But this did the trick: systemctl restart nscd nslcd nscd --invalidate=passwd nscd --invalidate=group nscd --invalidate=hosts nscd --invalidate=services nscd --invalidate=netgroup net cache flush root is root again at last. After around 10 mins it reverted back to DOMAIN\Administrator. Running net cache flush -> still administrator. Ive demoted the dc-2 again, cleared out all entries in ADUC and DNS and reverted the VM to a snapshot directly after it was freshly installed. I installed samba, joined the domain as DC ... root is root again! ~ 10 mins later root is Admin again. I checked again 40 mins later and voila - its root again. Somethings definitly not right here... I rechecked the other DCs: root at DC1# id DOMAIN\\administrator uid=10372(DOMAIN\administrator) gid=10072(DOMAIN\domain users) groups=10072(DOMAIN\domain users),3000004(DOMAIN\domain admins),100000519(DOMAIN\enterprise admins),100000520(DOMAIN\group policy creator owners),100000518(DOMAIN\schema admins),100000572(DOMAIN\denied rodc password replication group),3000009(BUILTIN\users),3000000(BUILTIN\administrators) The DC1 didnt pick up the removal of the UID! After clearing the cache (see above): root at DC1 # id AD-ELLERHOLD\\administrator uid=0(DOMAIN\administrator) gid=10072(DOMAIN\domain users) groups=10072(DOMAIN\domain users),3000004(DOMAIN\domain admins),100000519(DOMAIN\enterprise admins),100000520(DOMAIN\group policy creator owners),100000518(DOMAIN\schema admins),100000572(DOMAIN\denied rodc password replication group),3000009(BUILTIN\users),3000000(BUILTIN\administrators) # whoami DOMAIN\administrator WHAT? Oh no :/ After a reboot of the machine: # id DOMAIN\\administrator uid=0(root) gid=0(root) groups=0(root) # whoami root Yay! Then I thought: Is running NSCD on a DC the problem? Should I disable it? Or should I disable parts of NSCD (described here: https://wiki.archlinux.org/index.php/LDAP_authentication#NSCD_Configuration although this is a tutorial for SSSD instead winbind) Same question(s) for a domain member! DC2's root is back to DOMAIN\administrator. root at DC2 # id AD-ELLERHOLD\\administrator uid=0(DOMAIN\administrator) gid=10072(DOMAIN\domain users) groups=10072(DOMAIN\domain users),3000004(DOMAIN\domain admins),100000519(DOMAIN\enterprise admins),100000520(DOMAIN\group policy creator owners),100000518(DOMAIN\schema admins),100000572(DOMAIN\denied rodc password replication group),3000009(BUILTIN\users),3000000(BUILTIN\administrators) root at DC2 # whoami DOMAIN\administrator root at DC2 # systemctl stop nscd root at DC2 # whoami root root at DC2 # id DOMAIN\\administrator uid=0(root) gid=0(root) groups=0(root) Seems like nscd is the problem! It's confused that 2 users (root and DOMAIN\Administrator) have the same UID (0) and returns one at random (or something like that)? Is my suspicion correct? There is one sentence in https://wiki.samba.org/index.php/Samba_Member_Server_Troubleshooting to disable nscd completly. IBut there is no mention of nscd in https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member nor in https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller . If I'm correct - could you please add a line in each of the HOW-TOs to disable nscd completly (or disable parts of it)? Thanks for your help! -- Matthias K?hne Senior Webentwickler Datenschutzbeauftragter Ellerhold Aktiengesellschaft Friedrich-List-Str. 4 01445 Radebeul Telefon: +49 (0) 351 83933-61 Telefax: +49 (0) 351 83933-99 Web www.ellerhold.de Twitter www.twitter.com/Ellerhold_AG Youtube www.youtube.com/user/ellerholdgruppe Amtsgericht Dresden / HRB 23769 Vorstand: Stephan Ellerhold, Maximilian Ellerhold Vorsitzender des Aufsichtsrates: Frank Ellerhold ---------------- Diese E-Mail und Ihre Anlagen enthalten vertrauliche Mitteilungen. Sollten Sie nicht der beabsichtigte Adressat sein, so bitten wir Sie um Mitteilung und um sofortiges l?schen dieser E-Mail und der Anlagen. Unsere Hinweise zum Datenschutz finden Sie hier: http://www.ellerhold.de/datenschutz/ This e-mail and its attachments are privileged and confidential. If you are not the intended recipient, please notify us and immediately delete this e-mail and its attachments. You can find our privacy policy here: http://www.ellerhold.de/datenschutz/