What I have always been taught was that Celerra Home Directory masks users from seeing anything else in a share designated as a home directory; that it is done from the Celerra side, not the AD side. This has satisfied the majority of my clients over the years, especially when I have them try and circumvent it with a regular user account and they can't.
I'm working with one now that understands that, but wants to know *how* it does it. During the testing cycle we're in, they're using IT guys. Naturally, they check share and security permissions then ask why they are so permissive. Thus the reason why I'd like to know. NFS masking? SID/ACL voodoo? What is it?
If T2 or development wants to get real technical, that's fine. They aren't interested in the Marketing answer.
What we're seeing is when a user attempts to map to a homedir that is not theirs, they are denied access even though the share is Everyone:Full. Go to a Domain Admin account and this doesn't happen.
This is telling me that there is some sort of masking going on from the Celerra side based on the username.
What we're seeing is when a user attempts to map to a homedir that is not theirs,
How exactly do they try to "map to a homedir that is not theirs"?
they are denied access even though the share is Everyone:Full.
So you have another share to the homedir beyond the reserved \\sharename\HOME?
This is telling me that there is some sort of masking going on from the Celerra side based on the username.
It's telling me that you are double-dipping: you're using homedirs and then have individual shares to user's home directories. If you use homedir, you do not build individual shares to each user's home directory.
If you don't have individual shares built, then I'm completely missing how you're getting into this position in the first place.
Of course they're double dipping, they're the domain admins.
Currently, they are on an old NS700 with all the homedirs in one 400GB filesystem and each user has their own individual share (over 14,000). I've split it up by the unique identifier (fifth character) they use in their usernames into 36 filesystems under 4 vdms and CIFS servers.
Ex: Filesystem fs01_0 is shared as \\nhcnas100\0\ with the Homedir pointing to \0\ and is shared at Everyone Full, security Domain Admins Full. No other shares except a higher level root share.
alliant:....0...:/fs01_0/0/:regex:create
(had to change the u to user else the forum think's it's HTML for underline)
The full path is hidden, \\nhcnas100\0_root$\0\, where root_0$ is the filesystem root and shared as an admin only share with Allow Inheritable Permissions to Propagate turned off.
In our tests, when a user account (ex ahsn0c02) accesses \\nhcnas100\home they are mapped to \\nhcnas100\0\ahsn0c02 like they're supposed to be. But being the sneaky person a domain admin usually is, they tried to directly map a drive to \\nhcnas100\0\ahsn0c03 with the account ahsn0c02 and were denied even though they are supposed to have share full access. A domain admin account blows right past this.
It seems that there is some sort of username masking being done on the Celerra side and not the Windows side.
Rainer_EMC
6 Operator
•
8645 Posts
221
0
Posted August 26th, 2009 06:00
thats not the point of the homedir feature. You could do this with ABE alone without homedir.
If I understand it correctly it uses the login name to connect the user directly to his home directory and not the directory above.
Kind of like dynamically creating a share when the user connects to the Celerra and removing it when he disconnects.
hope that helps
Rainer