SOLVED Changing hostname retains original SMB mappings

Joined
Jan 4, 2014
Messages
1,644
I've recently transitioned from FreeNAS 11.3-U5 to TrueNAS 12.0-U3 on core servers. FreeNAS servers had the prefix freenas in the hostname e.g. freenas-l. It made sense to change the hostnames to use the prefix truenas instead e.g. truenas-l. I have since noticed that the original hostname is still referenced when ACLs are viewed from Windows clients and both user and group SIDs are translated to friendly names. I suspect that some Samba magic is required on the TrueNAS servers to have the SIDs use the updated hostname instead, but I'm not sure the best way to proceed from here?

acl2.jpg
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
Code:
commit cc0d94fe24fb76ede60dee638f56c8181b20f0c7
Author: Andrew <awalker@ixsystems.com>
Date:   Thu Apr 15 18:31:11 2021 -0400

    NAS-109803 / 12.0 / Ensure that domain sid component of groupmap entries updated properly (#6614)
   
    Wen Samba's netbiosname changes, the server's local SID is automatically
    regenerated and reflected in Samba's passdb. Groupmap entries are not
    updated in a similar way. This commit simplifies and fixes smb.fix_sid
    so that the domain component of each group's SID matches our current
    system SID. If it doesn't, then the group_mapping.tdb is removed and
    regenerated. The system SID stored in the TrueNAS configuration database
    is also updated at this time. A backgrounded groupmap synchronization
    job is started when our netbios name is changed in an SMB service update.
    This commit also forces smb4.conf [global] section to be regenerated on
    every configuration update (even if SMB is not running). The config file
    is read during passdb and groupmap generation and must be kept up-to-date.


Didn't quite make it into U3.
Regression tests were added here:
Code:
commit 9838e87f2fa0ca793f269d404b7353293f8816e4
Author: Andrew Walker <awalker@ixsystems.com>
Date:   Thu Mar 18 08:02:12 2021 -0700

    Add dependencies to SMB SID tests

commit 4afafbd792f7a77181ef9f7f70a72a75b3042cf8
Author: Andrew Walker <awalker@ixsystems.com>
Date:   Mon Mar 15 07:37:00 2021 -0700

    Add regression tests for domain sid modifications
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
If you want to regenerate the group mappings, you might be able to just rm /var/db/system/samba4/group_mapping.tdb then run midclt call smb.synchronize_group_mappings.

Of course, do this sort of thing in a maintenance window if this is at $placeofwork.
 
Joined
Jan 4, 2014
Messages
1,644
If you want to regenerate the group mappings, you might be able to just rm /var/db/system/samba4/group_mapping.tdb then run midclt call smb.synchronize_group_mappings.
Thanks anodos! Will this also fix the user SIDs, or just the group SIDs?
 
Joined
Jan 4, 2014
Messages
1,644
If you want to regenerate the group mappings, you might be able to just rm /var/db/system/samba4/group_mapping.tdb then run midclt call smb.synchronize_group_mappings.
Unfortunately, this hasn't had the desired effect, unless there's another step I'm missing. These are the steps I took before rolling back to the original group_mapping.tdb.

For the example shown in the OP:
Code:
root@truenas-l:/ # net groupmap list
...
admins (S-1-5-21-1713679434-2450322213-1063807635-1042) -> admins
...
connor (S-1-5-21-1713679434-2450322213-1063807635-1066) -> connor
...

I took a copy of group_mapping.tdb, so I could roll back to it if required.
Code:
root@truenas-l:/ # cd /var/db/system/samba4
root@truenas-l:/var/db/system/samba4 # cp group_mapping.tdb group_mapping.tdb1

I then executed the specified commands.
Code:
root@truenas-l:/var/db/system/samba4 # rm /var/db/system/samba4/group_mapping.tdb
root@truenas-l:/var/db/system/samba4 # midclt call smb.synchronize_group_mappings
15084
root@truenas-l:/var/db/system/samba4 #

Checking the group map again, I notice the SIDs have changed.
Code:
root@truenas-l:/var/db/system/samba4 # net groupmap list
...
connor (S-1-5-21-1713679434-2450322213-1063807635-1086) -> connor
...
admins (S-1-5-21-1713679434-2450322213-1063807635-1091) -> admins
...


From the TrueNAS UI, I then restarted the SMB service.

Checking the Windows ACL this time, I note that group SIDs are not being translated to friendly names. It appears the earlier SIDs are still being referenced.

acl2.jpg


Rolling back returns the previous behaviour.
 
Joined
Jan 4, 2014
Messages
1,644
SIDs in passdb should already have changed in rename. You can check by comparing output of pdbedit -Lv with net getlocalsid.
If you look at the screenshot in the OP, you'll notice this is not the case for the user SID.
Code:
root@truenas-l:/var/db/system/samba4 # pdbedit -Lv
...
---------------
Unix username:        connor
NT username:
Account Flags:        [U          ]
User SID:             S-1-5-21-1713679434-2450322213-1063807635-3010
Primary Group SID:    S-1-5-21-1713679434-2450322213-1063807635-513
Full Name:            Connor Hendroff
Home Directory:       \\freenas-l\connor
HomeDir Drive:
Logon Script:
Profile Path:         \\freenas-l\connor\profile
Domain:               FREENAS
Account desc:
Workstations:
Munged dial:
Logon time:           0
Logoff time:          9223372036854775807 seconds since the Epoch
Kickoff time:         9223372036854775807 seconds since the Epoch
Password last set:    Sat, 11 Aug 2018 23:38:27 AWST
Password can change:  Sat, 11 Aug 2018 23:38:27 AWST
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
---------------
...
root@truenas-l:/var/db/system/samba4 # net getlocalsid
SID for domain FREENAS-L is: S-1-5-21-1713679434-2450322213-1063807635


 
Joined
Jan 4, 2014
Messages
1,644
One other observation. The SMB service in the TrueNAS UI shows the NETBIOS name as freenas-l. The help though does (correctly? unless I'm misinterpreting this) state that this is the original hostname of the system. I'm not sure if this has any bearing on what I'm observing with the Windows ACL.

acl3.jpg
 
Last edited:
Joined
Jan 4, 2014
Messages
1,644
Right, the mystery is solved. These are the steps I needed to execute to fix the SMB mappings when changing hostname on a TrueNAS server.

1. Match the NetBIOS name to the hostname.

acl4.jpg


2. Regenerate the group mappings (see post #3 above).

3. From the TrueNAS UI, restart the SMB service.

Windows ACLs now show the correct friendly names e.g.

acl6.jpg


Thanks, @anodos for the group mapping hints.
 

Phil1295

Explorer
Joined
Sep 20, 2020
Messages
79
Necromancing this
Right, the mystery is solved. These are the steps I needed to execute to fix the SMB mappings when changing hostname on a TrueNAS server.

1. Match the NetBIOS name to the hostname.

View attachment 46858

2. Regenerate the group mappings (see post #3 above).

3. From the TrueNAS UI, restart the SMB service.

Windows ACLs now show the correct friendly names e.g.

View attachment 46859

Thanks, @anodos for the group mapping hints.

Necromancing it to add a note:
In order for the SIDs to show in windows or be queried in TrueNAS, the corresponding user or group MUST have the option "Enable Samba Authentication" checked. It is the case by default, but I tweaked the settings to secure my server and forgot about it until I struggled to get SMB Access Share Enumeration working with the "Share ACL" restrictions.
 

pjhunt

Cadet
Joined
Dec 10, 2015
Messages
1
Right, the mystery is solved. These are the steps I needed to execute to fix the SMB mappings when changing hostname on a TrueNAS server.

1. Match the NetBIOS name to the hostname.

View attachment 46858

2. Regenerate the group mappings (see post #3 above).

3. From the TrueNAS UI, restart the SMB service.

Windows ACLs now show the correct friendly names e.g.

View attachment 46859

Thanks, @anodos for the group mapping hints.

FYI for others... I followed the following steps and had success.

1. Match the NetBIOS name to the hostname.
2. From the TrueNAS UI, restart the SMB service.
3. Close, and reopen windows explorer.

I did not need to;
Regenerate the group mappings (see post #3 above) or Enable SMB1 Support as suggested.

Thanks for the help on this!
 
Top