SOLVED Active Directory SMB share missing groups Bug or Limitation

[berrick]

Hi All,

Looking for guidance regards the following "issue/bug" please

Have spun up a temporary TrueNAS box running TrueNAS-12.0-U8 and joined to domain
This is on a

• Lenovo Thinkstation 20
• Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
• 8GB ram
• One mirrored pair of 2TB disks
• dataset configured for smb

The problem encountered is that not all groups from the Domain are showing. Most notably yourdomain\administrators
This is causing issues when trying to copy data to the mirror, using robocopy or icacls so folder/file permissions are copied to destination. I suspect this is because the owner of all the folders to be copied is set to this group.

The question I guess, is, Are all groups from AD supposed to be available to TrueNAS smd shares or are some, like yourdomain\administrators not?

 

[anodos]

Hi All,

Looking for guidance regards the following "issue/bug" please

Have spun up a temporary TrueNAS box running TrueNAS-12.0-U8 and joined to domain
This is on a

• Lenovo Thinkstation 20
• Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
• 8GB ram
• One mirrored pair of 2TB disks
• dataset configured for smb

The problem encountered is that not all groups from the Domain are showing. Most notably yourdomain\administrators
This is causing issues when trying to copy data to the mirror, using robocopy or icacls so folder/file permissions are copied to destination. I suspect this is because the owner of all the folders to be copied is set to this group.

The question I guess, is, Are all groups from AD supposed to be available to TrueNAS smd shares or are some, like yourdomain\administrators not?

There are some exceptions to this case, but in general in unix groups can't be owner (user) of a file (unlike in Windows). Well-known / built-in SIDs have some caveats with regard to handling of them. Often users have assigned permissions via S-1-5-32-544 / S-1-5-32-545 (rather than Domain\ Domain admins or Domain\ Domain users). This can be problematic depending on the situation. You should see all of your AD users / groups in wbinfo -u / wbinfo -g output.

There is an smb.conf parameter that maps unknown SIDS into the current user running the job (this can help with migration issues where the admin has assigned permissions to a local rather than AD account on the server being migrated). This parameter will have to be added as an auxiliary parameter.

 

[berrick]

@anodos

Thanks for the reply
Only a small set of doamin groups are returned when issuing either wbinfo -g or getent group
Neither returns the domain bultin administrators group which is what I need.

Domain\domain admins is what we used but this fails when trying to use robocopy to copy data to smb share with permissions etc. I suspect because we can add the domain\bultin administrators group as its not found.

Due to time constraints I have created an iSCSI share as this allows the data to be copied with out issue using robocopy as described.

If you dont mind another question. Where are the iSCSI block files located on TrueNAS?

I will take a look at SMB Permissions Overview thankyou

 

[anodos]

> Only a small set of doamin groups are returned when issuing either wbinfo -g or getent group

Are these domain groups or well-known / built-in SIDs? Do they exist in "Active Directory Users and Computers"?

 

[berrick]

> Only a small set of doamin groups are returned when issuing either wbinfo -g or getent group

Understood

Are these domain groups or well-known / built-in SIDs? Do they exist in "Active Directory Users and Computers"?

Please see image for clarity

 

[anodos]

Right, if you look in the advanced attribute editor you'll see that the SID for this administrators group is S-1-5-32-544. I.e. BUILTIN\administrators. It's not _really_ a group unique to your domain (domain objects begin with S-1-5-21 followed by the domain component of the SID), and my previous comments about this apply.

 

[anodos]

Builtins do not appear in wbinfo output because they're not something we get from the AD domain. If you grant permissions to BUILTIN\administrators / BUILTIN\users in windows, it also means that local administrators and users (non-domain) will have access to the files in question. This also means on same server if you leave the AD domain, the local admins / users still have access.

To view these separate mappings you can us `midclt call smb.groupmap_list` or `net groupmap list`, but in general I recommend avoiding using them if possible for permissions.

 

[anodos]

Which bumps up to a fundamental Unix feature. There are users and there are groups. A group cannot be the Owner/User of a file.

 

[berrick]

@anodos Many thanks for the detailed information
I guess this can be marked as resolved