Shares for userprofile/redirects is not inheriting perms

UCS - Univention Corporate Server
#1

Sorry, but this is going to be long, but I am hoping to streamline my process here so I included lots of pictures with hopefully few words :wink:

So, I have folder redirection and roaming profiles in my test env, either works as the user folders are created as needed, the user owns them and can edit the contents and the administrator@domain account can access them for backup purposes. However, they do not inherit the permissions on the share that should specify the domain admins group (for testing, will leter be a backup group used specifically for backup purposes) to be able to access them. The result is everything works until I try to access them with a domain admins account I can’t access the folders, if I login as administrator@domain I can view them just fine. If as the administrator@domain account I enable inheritance then permissions are inherited and the domain admin accounts can access them fine. This is requiring manual adjustment to each folder as it is created, in the case of roaming profiles this will be really tedious with varieties of desktop OS and v1-5 folders being created, and really it shouldn’t be necessary at all since it has never been so on M$ domains. The domain admins that might show in the pics below are ‘jp’ and ‘jptechnical’ and the domain users are ‘test’, ‘test1’, etc.

I was hoping to nail down this to a repeatable process and then make an FAQ to contribute back since I have a LOT of experience with this on the Windows side. This will be a rinse and repeat kind of thing for my business, my hope is about 4 UCS Domain deployments this summer so far.

Here are my configs in hopefully pretty graphics.

UCS shares page, I might not need to check the ‘other’ row. I did not adjust anything beyond the general page other than the options specified in the UCS manual I think.








Windows shares settings, when to compmgmt.msc > connecto to computer > and edited the share from there. These are the same security settings as I would use for a windows server for the intended affect.




This is the result of browsing the folders created when a user logs in for the first time as a domain admin and the administrator@domain account.




This is the result of viewing advanced security settings of the folders created when a user logs in for the first time as a domain admin and the administrator@domain account.



#2

Hey,

I’m not entirely sure if the following is really the case, so take it with a grain of salt, please.

Windows and Unix/Linux ACLs are fundamentally different and cannot be mapped onto oneanother 1:1. In order to support the full Windows ACLs Samba has to do some magic. It translates certain aspects of Windows ACLs into both traditional Linux permissions as well as Linux ACLs. Aspects for which no direct mapping is possible are stored in extended attributes, though. Samba can make use of those extended attributes for access checks, but the Linux kernel itself doesn’t; it simply ignores those extended attributes.

What you can set in the UMC’s share properties are those aspects of the ACLs that are actually Linux ACLs. What the UMC doesn’t provide settings for and what it cannot set are those parts of the Windows ACLs for which no Linux counterpart exists. I’m therefore thinking that the inheritance setting is part of those ACLs stored in the extended attributes when set via Windows/Samba.

According to the Samba Wiki editing the ACLs of the share’s root directory should be possible, even from Windows. So give that a try.

If it doesn’t work then a possible workaround for you might be not to store the profiles in the share’s root directory but in a sub-directory. Create the sub-directory, set the inheritance and permissions as you need them from Windows, set the profile paths accordingly.

There’s a Linux tool to modify (get/set) the NT ACLs for a given directory (“samba-tool ntacl get /path/to/directory”), but it’s a bit cryptic to use (to say the least). If you’re willing to experiment with it you could also try to apply the same NT ACLs onto the share’s root directory instead of a sub-directory. Maybe use one of those directories for which you’ve set the NT ACLs already as a template.

Kind regards,
mosu

#3

Subdirectory
 intriguing idea, I am going to try that and let you know if it works. Thanks!

As far as the ACL differences, I totally understand, I have been mixing environments for nearly 2 decades
 but seeing it represented by checkboxes instead of cli is proving to be tough for my brain to wrap around.

Mastodon