<< Here's an even simpler idea: use global groups to assign permissions. >>

You can't do that in a large multi-domain enterprise.

Take for example a growing company that uses a new domain for each country. (Back in NT4 days this would be typical and even today with Win2K sites, for security boundary reasons a company might still use a different domain for different countries/depts./areas/whatever.)

Files are shared among the different sites.

FolderRoot | |-----Folder1 | | | |-------Folder1.1 | |-----Folder2 | | | |-------Folder2.1 | | | | |---Folder2.1.1 | |-----Folder3 ( | | | |-------Folder3.1

Let's say you grant a local group, FilerUsers, access to Folder1. The groups "US-Users, UK-Users, DE-Users" belong to FilerUsers so groups from all three countries can access it

Folder 1.1 has some sensitive information in it and only US-Users should be able to access it, FilerUsers access is removed and US-Users access is granted.

Now, let's say the same scenario applies to Folder2 and Folder2.1, but instead, Folder2 has access granted to the global groups US-Users, UK-Users and DE-Users. Folder2.1 only has US-Users access.

Now, along comes, oh, Canada office.

To add access appropriate to folder 1 and all subfolders, you just add CA-Users to the FilerUsers local group. Done. Poof. That's it. Nothing else to do.

Folder2, you have to reset ALL the ACLs on Folder2 and all subfolders. Uh-oh. Problem. How do you know which files and folders have more restrictive ACLs? In this example there is only one sub folder with customized ACLs, but in real life, there could be a very large number of files and folders. You just totally ruined the ACLs on all of them in order to give CA-Users access.

With Win2K-style ACLs and the inheritance model they use, the problem might be a little less of a problem, but only slightly less. I can go into scenarios where the new inheritance wouldn't help but using local groups would (That's why I've got the extra folders up there, but I'm too lazy to keep going at this point!)

So, Local Groups are an evil necessity.

I've found a product called "SuperCACLS" from Trusted Systems to be very helpful in dealing with problems like this and it's a lot cheaper than the comparable Alita product. But, it does take forever to walk large directory structures and is not ideal.

Tom

-----Original Message----- From: Conner, Neil [mailto:neil@mbari.org] Sent: Tuesday, July 03, 2001 6:05 PM To: 'Jeffrey Krueger'; toasters@mathworks.com Subject: RE: An idea on migrating NTFS data

Here's an even simpler idea: use global groups to assign permissions. Cheers, Neil

-----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 2:37 PM To: toasters@mathworks.com Subject: An idea on migrating NTFS data

We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups.

Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier).

Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources.

The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups.

The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever.

-------- THE IDEA --------

Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da!

Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's.

To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group.

Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach??

Again, the idea is to prevent the requirement of a filesystem traversal during migration.

Thanks in advance!!

-- Jeff

-- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com