There's a reason MS recommends using local groups. For one thing, under NT, you can't add a group to a global group. I believe they changed this with Win2k, but if the original poster has not yet updated their infrastructure to win2k they may still need to use local groups.
This was one of the things MS hammered into you during MCSE training years ago. I don't know if they've changed their tune now.
-----Original Message----- From: Conner, Neil [mailto:neil@mbari.org] Sent: Tuesday, July 03, 2001 3: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