CIFS Home Directories in AD Environment

[anodos]

WARNING - I'm writing up an alternative howto that should work better than the one below. I don't recommend using this howto for the time being because of the way that the "creator-owner" ACE behaves in FreeNAS. In short, this method ends up being too cumbersome.

In the spirit of Cunningham's Law, I've decided to post what I have done to configure home directories for my users in an AD environment. This is mostly a how-to-ish stub. I will flesh it out over time (maybe).

Overview:
The goal of this tutorial is to demonstrate how to create a single share [Users] where user's home directories will be stored. If followed properly it should yield the following:

(1) All users have access to \\<server>\Users.
(2) Users with home directory will have access to \\<server>\User\<home directory>
(3) Domain admins will have access to all directories under \\<server>\Users
(4) Home directories will be automatically generated with proper permissions.
Requirements:
FreeNAS server be configured as an AD member server
Have necessary privileges to modify user profiles in Active Directory

Procedure:
Step 1: Create [Users] dataset
Create a dataset with the following characteristics:

• Windows permission type
• Owner - Admin : Domain Admins

Step 2: Create [Users] share
This share should have the following characteristics:

• Default permissions
• Browsable to Network Clients

Step 3: Using "Computer Management", configure permissions on \\<server>\Users
3.1 Connect through computer management to FreeNAS computer

3.1a Log in to windows client as a Domain Admin
3.1b open "computer management"
3.1c right-click on "Computer Management (local) and click on "connect to another computer"
3.1d enter the hostname or ip-address of your FreeNAS server

3.2 Configure Share Permissions

3.2a Expand "Shared folders", and click on "Shares"
3.2b Right-click on the share you created to hold Home directories, click properties, then click the "Share Permissions" tab.
3.2c Add the following users / groups with the following permissions:

SYSTEM - Full Control
Authenticated Users - Full Control
Domain Admins - Full Control​

remove the "Everyone" entry
Click "apply" and OK​

3.3 Configure Security Permissions

Through "Advanced Security Settings" modify Access Control Entries for the Home Share as follows:​

CREATOR OWNER - Full Control - Apply to Subfolders and files only
SYSTEM - Full Control - This folder, subfolders, etc.
Domain Admins - Full Control - " "
Everyone - Read Only - This folder only ( you will have to add the atomic permissions necessary for proper read-only access)​

Step 4: Modify User Profile Properties in Active Directory to Add Home Folder
While logged in to the DC as a domain admin or user with appropriate privileges, do the following:

• Open "Active Directory Users and Computers"
• Find the user for whom you wish to create a home directory, and right-click, click on properties, then click on the "Profile" tab.
• Under "Home folder" click the radio button for "Connect", select a drive letter, and type \\<server>\Users\%USERNAME%
• Click "Apply" and "OK"

 

[depasseg]

Great writeup. Do you know how the "Home Shares option affects this (that option isn't listed in your Step 2: Create [Users] share)?

 

[anodos]

Great writeup. Do you know how the "Home Shares option affects this (that option isn't listed in your Step 2: Create [Users] share)?

I didn't list " home shares" parameter because I'm trying to give a working config. :)

[Homes] is a special section of the smb4.conf file. When you c)check the box for "Home shares", samba will assume that every time a user tries to connect to a nonexistent share, he really wants to connect to his Unix home folder on the server. Samba then evaluates the username that is being used for authentication, and dynamically creates a share that exports that user's Unix home directory. This is odd behavior from a windows perspective and renders it impossible to access another user's home share (because it doesn't exist for you). Very metaphysical / postmodern. Like all things postmodern, it is annoying, headache inducing, and mostly doesn't work well.

 

[Ericloewe]

I didn't list " home shares" parameter because I'm trying to give a working config. :)

[Homes] is a special section of the smb4.conf file. When you c)check the box for "Home shares", samba will assume that every time a user tries to connect to a nonexistent share, he really wants to connect to his Unix home folder on the server. Samba then evaluates the username that is being used for authentication, and dynamically creates a share that exports that user's Unix home directory. This is odd behavior from a windows perspective and renders it impossible to access another user's home share (because it doesn't exist for you). Very metaphysical / postmodern. Like all things postmodern, it is annoying, headache inducing, and mostly doesn't work well.

That simultaneously sheds light on what the hell is going on and raises a crapton of questions. For starters, who the hell would want such a behavior?

 

[anodos]

That simultaneously sheds light on what the hell is going on and raises a crapton of questions. For starters, who the hell would want such a behavior?

Mandatory XKCD response:

 

[anodos]

The following robocopy powershell script can be configured to run as a scheduled task for user. It will backup select parts of the user profile to the user's home directory.

Code:

$SourcePath = "$env:USERPROFILE"
$TargetPath = "$env:HOMEDRIVE\$env:COMPUTERNAME.Backup"

#Robocopy Logging Variables
if(!(Test-Path -Path "$env:HOMEDRIVE\BackupLog"))
  {
   new-item -Path "$env:HOMEDRIVE\BackupLog" -Value "BackupLog" –itemtype directory
  }
$LogPath = "BackupLog\$env:computername.$(get-date -f yyyy-MM-dd).log"

#Run robocopy job. Exclude junctions, appdata, and temp files. I have disabled DOS attributes and so "/COPY:DT".
robocopy $SourcePath $TargetPath /MIR /COPY:DT /Z /W:2 /R:15 /FFT /XJ /XF ntuser.* *.dat *.db *.tmp NTUSER* /XD "$SourcePath\AppData" /LOG:$env:HOMEDRIVE\$LogPath

I use a customized version for users who have difficulty with the concept of network drives.

 

[SweetAndLow]

That simultaneously sheds light on what the hell is going on and raises a crapton of questions. For starters, who the hell would want such a behavior?

I'm not sure of the real answer but it would allow users to not need to know the whole path of the share. they just need to know \\server\homes and that homes share can map to something crazy like /mnt/tank/company1/org1/users/$U. When you start looking at customer workflows that have 10k+ users little things like this have real benefit. Just my thoughs and there are probably more solutions the the problem but remember to keep in mind scalability and maintainability.

 

[anodos]

I'm not sure of the real answer but it would allow users to not need to know the whole path of the share. they just need to know \\server\homes and that homes share can map to something crazy like /mnt/tank/company1/org1/users/$U. When you start looking at customer workflows that have 10k+ users little things like this have real benefit. Just my thoughs and there are probably more solutions the the problem but remember to keep in mind scalability and maintainability.

The homes share makes sense in an NT4 domain. In active directory, you can configure user profiles / group policy so that, for example, o:\ is always mapped to \\Server\Users$\%username%

 

[Luke Jaeger]

This is odd behavior from a windows perspective and renders it impossible to access another user's home share (because it doesn't exist for you).

Users only see their own home share when connecting via SMB, but they can SSH in and roam freely through everyone else's home unless we set proper POSIX permissions on /path/to/homes/$U .

 

[anodos]

Users only see their own home share when connecting via SMB, but they can SSH in and roam freely through everyone else's home unless we set proper POSIX permissions on /path/to/homes/$U .

The above permissions scheme in this example prevents them from being able to do this.
/mnt/tank/homes/
has permissions
owner@ - full control (root)
group@ - full control (Domain Admins)
everyone@ - read only (this folder only)

/mnt/tank/homes/<user> will only inherit
owner@ - full control
group@ - full control

It is impossible for anyone other than the owner or members of "domain admins" to browse user home directories. Unless, of course, your users are also members of "domain admins". In this case, you have much bigger fish to fry.

BTW why give them SSH access at all on your filer? :D

 

[Luke Jaeger]

The above permissions scheme in this example prevents them from being able to do this.
/mnt/tank/homes/
has permissions
owner@ - full control (root)
group@ - full control (Domain Admins)
everyone@ - read only (this folder only)

/mnt/tank/homes/<user> will only inherit
owner@ - full control
group@ - full control

It is impossible for anyone other than the owner or members of "domain admins" to browse user home directories. Unless, of course, your users are also members of "domain admins". In this case, you have much bigger fish to fry.

BTW why give them SSH access at all on your filer?

It's a little trickier than that, because I want the ownership on student homes to be $U:'faculty AD group', drwxrwx--- .
Faculty homes should be drwx------ . This is why I'm using a script.

Also, I don't run the AD server so I'm hoping there's a way to set desired permissions on the FreeNAS side. Otherwise I have to wait for the AD admin to have free time and he never does.

We give them SSH access because this is a college Comp Sci department and they need to get used to using the shell!

 

[anodos]

It's a little trickier than that, because I want the ownership on student homes to be $U:'faculty AD group', drwxrwx--- .
Faculty homes should be drwx------ . This is why I'm using a script.

Also, I don't run the AD server so I'm hoping there's a way to set desired permissions on the FreeNAS side. Otherwise I have to wait for the AD admin to have free time and he never does.

We give them SSH access because this is a college Comp Sci department and they need to get used to using the shell!

You can set it as follows
Students

Code:

getfacl /mnt/Tank/Homes/<Student>
# file: /mnt/Tank/Homes/<Student>
# owner: <user>
# group: facultyADgroup
            group@:rwxp-daARWc---:fd----:allow
   group:Domain Admins:rwxpDdaARWcCo-:fd----:allow
            owner@:rwxp-daARWc---:fd----:allow

Faculty

Code:

getfacl /mnt/Tank/Homes/<Faculty>
# file: /mnt/Tank/Homes/<Faculty>
# owner: <user>
# group: OtherAdmingroup
            group@:rwxp-daARWc---:fd----:allow
   group:Domain Admins:rwxpDdaARWcCo-:fd----:allow
            owner@:rwxp-daARWc---:fd----:allow

The above can be achieved through chown and results in the following:
Student folder:
* Student - read, write, modify
* Domain Admins - full control
* facultyADgroup - read, write, modify

Faculty folder:
* Faculty member - read, write, modify
* Domain Admins - full control
* OtherAdmingroup - read,write,modify

 

[Luke Jaeger]

thanks, will try

 

[fgatl]

I'm going to be implementing something similar on TrueNAS-11 in the very near future ... do you have any updates or improvements?

Thanks.