I have a SMB share for our users home directories. These get created on the Isilon automatically with Home Directory Provisioning. The problem is computer accounts (*not* user accounts) are randomly creating home folders like computer-01$. Is there a way to prevent this?
This is a giant pain. I would like to see a solution for this as well. We have seen it on VNX and Unity as well. We have to run a cleanup script every week to delete them.
What's your OneFS version?
Also I'm assuming Active Directory?
How is the SMB share configured? Could you share a screenshot for the expansion parameters and such?
OneFS Version: 22.214.171.124 (will be updated to OneFS Version: 126.96.36.199 later this week)
Yes we're using Active Directory.
SMB share configured in AD:
SMB share config:
I don't like working with deny-rules, but:
if the computer accounts don't have to connect to the Share, i would Setup a deny rule for Domain\computers on the home-share.
furthermore i would not configure "Everyone" but "Authenticated Users" (if you are in an active Directory integrated Environment)
Please be Aware, that deny-rules (and acls on the share) are against best practices which define to use whitelisting and NTFS-ACLs on the Folders rather than on the share
Thanks for the ideas!! Just curious why you recommend using "authenticated users" over "everyone" for the share. Aren't the permissions all controlled by the ACLs anyways? Just curious...
you are right.
to be honest i never thought that far , I always putted authenticated users as being the "more secure" configuration which still doesn't create any Problems no matter which authenticated account tries to connect. I don't have any reasons why share everyone / ACL authenticated users could be less secure as share authenticated users / acl authenticated users
Reasons to Chose authenticated users over everyone could be:
* i never have to think about the context where i am. I can configure authenticated users at share Level and at top-Folder Level (i.e. Share "Homes" and "/ifs/cluster-a/homes/" can have same permissions)
* i am sure, if someone cracks the ACL that there is a "Minimum protection" on the share-Level and it is not open to "everyone"
after doing some research they removed the unauthenticated users from everyone in Windows Server 2003 so even this Group should be okay in AD-Environment.
so i still would prefer authenticated users over everyone, but just because i'm used to it and it would be work to do it in another way.
Unfortunately the deny did not work. Another home directory for a computer account was created yesterday. Here is the details of the directory and the share permissions I setup:
LBOX-1# id klionsky-popelk$
uid=1000087(klionsky-popelk$) gid=1000050(domain computers) groups=1000050(domain computers)
LBOX-1# ls -ld /ifs/lsi/adenosine/Homes/klionsky-popelk$
drwx------ 2 klionsky-popelk$ domain computers 0B May 22 15:21 /ifs/lsi/adenosine/Homes/klionsky-popelk$
LBOX-1# isi smb shares permission view --share=Home --zone=lbox-zone --group="Domain Computers"
Account: domain computers
Account Type: group
Run as Root: False
Permission Type: deny
This didn't work. We are also trying this with a new isilon and NTFS deny or read only on the share permissions doesn't seem to matter it keeps creating the computername$ folders.
home directory configuration typically says any domains(*) , any users(*) , to the specified path (like a share path) allows to create a folder for that user . But not sure how to filter out computer accounts.
I had this same problem and it was driving me crazy.
The solution I found is to use just "Domain Users" Full Control on the share permissions:
isi smb shares permission list homedirtest$
Account Account Type Run as Root Permission Type Permission
CORP\domain users group False allow full
This works because while Everyone and "Authenticated Users" includes domain computers the AD builtin group Domain Users specifically excludes computers. This allows any user to access (and autocreate) a home directory but any computer using its SYSTEM account (computername$) will get "access denied" and no folder will get created.
We are into the same issue and glad it got resolved for you. May I know the client version of windows you use to connect the share, is it windows 10? or something else. I appreciate your reply.
Clients are Windows 10. Active Directory functional level is Windows Server 2012 R2. Isilon clusters are mixed, we have 2 clusters with OneFS 188.8.131.52 and 2 clusters with 8.1.2 - both show the same behavior with autocreation of homes for computer accounts. Basically any computer that accesses a home directory UNC path gets a folder created for it. I think we may have some group policies that are applying to computer accounts as well as users and cause them to "look" at the path. We also have multiple domains in a forest and I found that I needed to add "Domain Users" from any sub-domains where users might need to access the paths. But removing Everyone from the share permissions has stopped the computer$ folders from being created. I have not seen any negative side-effects so far, but we are watching carefully for any fallout.
We even tried all the options Everyone, Authenticated Users and Domain users but nothing has helped us honestly. But interestingly what we found is, only windows 10 client has created a folder with the computer name and windows 2k8 was not creating it. We suspect SMB version causes the problem here because the additional folder is not getting created when any new user accessing but the moment he starts writing on the share the folder with computer name is created.