Thanks Sandip. So what are my options now? What's going to happen if i do not configure secondary usermapper ? This is a migration effort, source Celerra will be going away once all cifs/nfs resources have been migrated.

case 1:

i have CIFS servers on physical DM that i want to replicate to destination Celerra. I will create a VDM on destination Celerra, create CIFS server(s) inside of that VDM, mount that file system to this CIFS server once it's been replicated from the source.

case 2:

I have CIFS servers inside of VDMs ..so here i would follow documented process of replicating CIFS servers. For each CIFS server(s) in VDM ..at predetermined time, failover will happen and once CIFS server up and running on target, destroy replication relationship.

Message was edited by:
dynamox

Message was edited by:
dynamox

First of all - to replicate CIFS Environment, the CIFS Server must be on a VDM - in other terms it is referred as VDM replication. So the CIFS servers which are not on a VDM can not be a part of the CIFS replication - you can only have the data or file system replication for them.

For CIFS replication - it is recommended to configure the Destination Data Mover as Primary Usermapper and configure the Source Data Mover as Secondary Usermapper - with destination being its Primary. This way you replicate the Usermapper data base as well and use only one usermapper configuration. However, if you are setting up two way replication - I don't think it really matters which side is primary and which side is secondary.

But in your case, you are running Primary Usermapper on both the sides - which is not recommended.

I understand we'll have more posts on this thread Till then,

Regards,
Sandip

Thanks Rainer,

i have a few users that i think have accessed both CFS14 and NS80. I also have one file system that is used for multi-protocol access. Since they have connected to CFS14 and NS80 for other CIFS resources, that means they probably have different UIDs assigned to their AD accounts. If this is just a couple of users, once i replicated my file system to NS80 and make it available, how can i rectify this situation? Can i manually create entries in usermapper so that it matches UIDs that are currently on the file system ?

Besides this one multi-protocol file system everything else is either NFS or regular CIFS. We do not use user/group quotas, only tree quotas. So besides these two items can you think of anything else that would cause problems if i leave both systems running primary user mapper ?

On CFS14 i have some cifs servers that are port of VDM and some are not. How does this complicate the situation? What about secmap ? Will it be purged once it gets replicated to NS80 ..and get re-populated as users access resources on NS80 ?

Thank you so much for your help.

for replication itself the usermapper doesnt matter

However if you are later switching to that other server it depends on your usage

If the two systems users are disjunct you could import the old systems usermapper db into the second one

If you dont the following can happen:
user1 has at some point connected to the first system, created a file and gotten a UID/GID assigned from the usermapper there
then you switchover to the second system
on the second system the same user1 (SID) gets a different UID/GID

If you are doing multi-protocol thats bad

If you are only doing CIFS for that fs with the native access policy it shouldnt matter in terms of access checking - we only use the ACL there and not the Unix rights

BUT if you are doing user quota's these I think are based on UID's so this users files will now be counted as belonging to two different users

This is further complicated by the fact that each VDM has its own secmap

to change the usermapper database you can use server_usermapper -Export / - Import

secmap gets consulted before - if there is an existing secmap entry then usermapper wont be asked

secmap entries never update - unless you add/delete/change them using server_cifssupport
to delete all secmap entries you need to ask customer service

secmap is part of the VDM root_fs - so you replicate the VDM you will automatically replicate its secmap

To be clear - changing usermapper and secmap only will make only make a difference for newly created files. (or if we have to do a reverse lookup)
For existing files the Unix and Windows owners are stored in the file system as SIDs and UID/GID and not as user names

If you really need to change the Unix user or group of a file I think you have to resort to chown.
If you are going to change to multi-protocol with MIXED access policy you can take a look at nas_fs -translate - but I'm not sure if only changes the ACL or also the UID/GID

Ok ..i think i am missing some fundumentals here. If i have a file system on Celerra that is only used for CIFS access. When somebody saves a file to this file system it will have ACLs (NTFS permissions) assigned to it. Will it also have UID/GID assigned to it ?

So now i am a user trying to access this file, Celerra looks at UID/GID of the file first , then looks at matching SID in usermapper and if SID matches to user's who is trying to access it ..only then this user can read/write to the file ?

This will be definitely bit confusing and may be little hard to explain. The UID/GID is simply to map (or identify) the right windows user (SID) - but the permission (ACL) is applicable only when the user is accessing it from Windows machine and the users SID defines what access the user has got.

The user mapper database is only a mapping table for each SID to corresponding UID/GID. Since on Unix environment SID does not exist (and on Windows environment UID/GID does not exist unless you have ways to expand the AD schema) - thus the need for mapping SID to unique UID/GID.

For CIFS only access - where user mapper service is running - this is done seamlessly and an internal process to the Celerra itself. You may take a dump of usermapper database and check what all it contains. It is a simple mapping table.

Again - celerra does not authenticate Windows users and also does not restrict any file access - which is entirely depended on the SIDs. But UID & GIDs are required for each SID to provide the interoperability between windows client and UNIX file system. User mapper role is to only ensure that one user is assigned a unique UID & GID - so that no user gets different UID & GID while accessing or writing a file.

Am I able to clarify or creating more confusion?

May be Rainer or someone else will be able to clarify it in a easy to understand statement. - Sorry for making it long but may be more confusing
Thanks,
Sandip

By the way - have you received all required guidelines and directions for your replication need? I just saw some of our EMC Celerra experts joined this forum (from support team and customer service team) - they may provide you some more details and guidelines if required.
Cheers,
Sandip

Thanks Sandip,

so a file residing on uxfs file system has 3 properties: ACL, UID, GID.

UID and and GID are only used to grant access to the file system itself, not the files (unless user has explicit NTFS permissions). I am just confused how UID/GID enforce file access when you have NTFS ACLs doing the same thing.

Yes. User Mapper is for CIFS access only. The need for user mapping is because the file systems on Celerra are uxfs - which has UID & GID concept with User, Group, Other permission for Read. write & Execute. If you export a file system on NFS - there is no need for any user mapping as it is all UNIX. But for Windows client - there is only SID - Windows AD does not provide any UID or GID by default - so to allow any windows user to access the uxfs file system on Celerra, each user must have a unique UID & GID.

For CIFS only box - this is does by the user mapper service running on the data mover. But Celerra does check only mapping for each Domain authenticated users, it does NOT do any authentication. The user authentication and permission checking is done by AD itself.




Celerra only checks the User mapping part - there is a sequence of checking the UID & GID - if secmap is enabled (be default yes) - then first it checks the secmap, then local passwd & group files, then NIS and at the end the usermapper database. If the User's SID is already mapped it uses that information - or else, if the user is a Domain authenticated user it creates an entry for the respective SID. So Celerra only checks the mapping part and ensures unique UID/GID is used for a given SID.

But the NTFS permission is checked by AD - User mapper does not authenticate or check for permissions per SID. The ACLs are matched against the SID just like any other Windows server or share.

My 2 cents I am sure more will follow from others.

Thanks,
Sandip