samba - Apr 2022 - ODP: ODP: Demoting AD DC failed, now it won't start up after ldb and tdb files removed

Thanks Rowland,
Yea, I tried 'net cache flush' command now, and I tried that before I
started fiddling with removing the tdb and ldb database files, doesn't seem
to do much of anything, but maybe I need to do more than that? Tried stopping
samba before that and restarting after, but no joy here either.

Btw the things You suggested I remove from my config files is not stuff I
invented myself - I mostly followed the  https://wiki.samba.org/ pages which
might mean some of them are out of date. Could those lines be responsible for
this weird DC behavior, or is just stuff that's surplus to requirements of
any kind? If I remember correctly, some of those things came about when I
introduced the physical DC next to the one I've always had on a VM to
prioritise the physical one. That was my idea of some weird clock sync problems
I've been observing which I though might be down to the DC being run off a
VM which can sometimes have clock problems, having no hardware clock of their
own.

Cheers,
Chris
________________________________
Od: samba <samba-bounces at lists.samba.org> w imieniu u?ytkownika Rowland
Penny via samba <samba at lists.samba.org>
Wys?ane: sobota, 2 kwietnia 2022 17:32
Do: samba at lists.samba.org <samba at lists.samba.org>
DW: Rowland Penny <rpenny at samba.org>
Temat: Re: [Samba] ODP: Demoting AD DC failed, now it won't start up after
ldb and tdb files removed

On Sat, 2022-04-02 at 14:42 +0000, Krzysztof Kucyba?a via samba
wrote:
> Thanks a lot Andrew, it did help... kind of.
>
> So I managed to rejoin the domain and restart samba services. But for
> some reason on the physical DC that I fixed with the help of Your
> instructions now winbind seems to be a bit off (which was my original
> problem and reason why I started meddling with it in the first
> place). Basically, the user ids and group ids are not what they
> should be. The box recognizes users, but their IDs are not what's in
> the database. For instance my account should be this (as depicted on
> any other box correctly in the domain):
>
> localadmin at eonia:~$ id krzysieq
> uid=1000016(krzysieq) gid=20002(adults)
> groups=20002(adults),20001(cansudo),20004(gdocs),20006(gaudio),20005(
> gphoto),20008(gstuff),20007(gvideo),20010(jirauser),20011(bitbucketus
> er),20012(bamboouser),3001(BUILTIN\users),3000(BUILTIN\administrators
> )
>
> However, on my secondary, physical DC this same ask comes back with:
> root at meraki:/etc# id krzysieq
> uid=3000007(***\krzysieq) gid=100(users)
> groups=100(users),3000007(***\krzysieq),3000008(***\domain
> admins),3000009(***\gvideo),3000010(***\gdocs),3000011(***\gaudio),30
> 00012(***\jirauser),3000013(***\cansudo),3000014(***\gstuff),3000015(
> ***\gphoto),3000016(***\bamboouser),3000017(***\bitbucketuser),300001
> 8(***\denied rodc password replication
> group),3000001(***\users),3000000(***\administrators)
>
> The Id numbers are the ones stored in samba database, I'm not sure
> how's the idmapping kicking in. I masked out the domain name with ***
> of course. Below are my configs, first from a domain member where
> everything works as it should (eonia box in fact):
> [global]
>         workgroup = ***
>         realm = ***.COM
>         security = ADS
>         winbind refresh tickets = Yes
>         map acl inherit = Yes
>         dedicated keytab file = /etc/krb5.keytab
>         kerberos method = secrets and keytab
>         winbind use default domain = Yes
>         bind interfaces only = Yes
>         interfaces = lo enp3s0
>         idmap config * : backend = tdb
>         idmap config * : range = 3000-7999
>         idmap config ***:backend = ad
>         idmap config ***:schema_mode = rfc2307
>         idmap config ***:range = 10000 - 9999999
>         idmap config ***:unix_nss_info = Yes
>         idmap config ***:unix_primary_group = Yes
>         idmap cache time = 1
>         idmap negative cache time = 1
>         winbind cache time = 1
>         template shell = /bin/bash
>         template homedir = /home/%D/%U
>         username map = /etc/samba/user.map
>         server string = %h server (Samba, Debian)
>         log file = /var/log/samba/log.%m
>         max log size = 1000
>         logging = file
>         panic action = /usr/share/samba/panic-action %d
>         server role = standalone server
>         obey pam restrictions = Yes
>         unix password sync = Yes
>         passwd program = /usr/bin/passwd %u
>         passwd chat = *Enter\snew\s*\spassword:* %n\n
> *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
>         pam password change = Yes
>         map to guest = bad user
>         vfs objects = dfs_samba4 acl_xattr recycle
>         local master = no
>         domain master = no
>         preferred master = no
>         os level = 0
>
> And from the DC that is acting up:
>
> # Global parameters
> [global]
>         dns forwarder = 192.168.1.1
>         netbios name = MERAKI
>         realm = ***.COM
>         server role = active directory domain controller
>         workgroup = ***
>         idmap_ldb:user rfc2307 = Yes
>         template shell = /bin/bash
>         template homedir = /home/%D/%U
>         unix extensions = Yes
>         vfs objects = dfs_samba4 acl_xattr recycle
>         local master = yes
>         preferred master = yes
>         domain master = yes
>         os level = 255
>         bind interfaces only = Yes
>         interfaces = lo enp3s0
>
> For reference, the config from the primary dc that works off a VM
> (winbind is not configured there though, I don't log on to that box
> with domain accounts but I do need that option on the second physical
> DC)
>
> [global]
>         dns forwarder = 192.168.1.1
>         netbios name = PRIMARYDC
>         realm = ***.COM
>         server role = active directory domain controller
>         workgroup = ***
>         idmap_ldb:use rfc2307 = yes
>         template shell = /bin/bash
>         template homedir = /home/%D/%U
>         unix extensions = Yes
>         vfs objects = dfs_samba4 acl_xattr recycle
>         local master = yes
>         preferred master = no
>         domain master = no
>         os level = 128
>
> Could You point out what is wrong please? I'm a bit clueless,
> especially that it all used to work fine a while back and I've not
> changed these configs. Appreciate any help.
> Cheers,
> Chris
First can I suggest you remove these lines from your Unix domain member
smb.conf:

        server role = standalone server
        local master = no
        domain master = no
        preferred master = no
        os level = 0
        unix password sync = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        pam password change = Yes
        idmap cache time = 1
        idmap negative cache time = 1

You do not need them and the 'server role' is definitely wrong.

Can I also suggest you remove these lines from the DC:

        template homedir = /home/%D/%U
        unix extensions = Yes
        local master = yes
        preferred master = yes
        domain master = yes
        os level = 255

Having got that out of the way, lets turn to your main problem, the
different IDs on your DC and the Unix domain member.

I note that you are using the 'ad' idmap backend and this appears to be
working, this shows that you have added RFC2307 attributes to AD. These
attributes should override the IDs found in idmap.ldb, provided that
'idmap_ldb:user rfc2307 = Yes' is set in the DCs smb.conf (which you
appear to have), have you tried running 'net cache flush' ?

Rowland



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

On Sat, 2022-04-02 at 15:55 +0000, Krzysztof Kucyba?a via samba
wrote:
> Thanks Rowland,
> Yea, I tried 'net cache flush' command now, and I tried that before
I
> started fiddling with removing the tdb and ldb database files,
> doesn't seem to do much of anything, but maybe I need to do more than
> that? Tried stopping samba before that and restarting after, but no
> joy here either.
Stopping and restarting Samba will do what 'net cache flush = yes'
does.
> 
> Btw the things You suggested I remove from my config files is not
> stuff I invented myself
I never said you did :-)
>  - I mostly followed the  https://wiki.samba.org/ pages which might
> mean some of them are out of date.
No, most of those lines should not be in a DC or are the defaults on a
Unix domain member and a Unix domain server can never be a 'standalone
server', that is a totally different beast.
>  Could those lines be responsible for this weird DC behavior, or is
> just stuff that's surplus to requirements of any kind?
They are just surplus to requirements and shouldn't have any affect on
the IDs.
>  If I remember correctly, some of those things came about when I
> introduced the physical DC next to the one I've always had on a VM to
> prioritise the physical one. That was my idea of some weird clock
> sync problems I've been observing which I though might be down to the
> DC being run off a VM which can sometimes have clock problems, having
> no hardware clock of their own.
AD is very time critical, so if the time is out by about 5 minutes,
replication might not be working. I suggest you run:

'samba-tool dbcheck' on both DCs
'samba-tool ldapcmp' from one of the DCs 

See if that throws up any errors.

Rowland