EMC Celerra NAS Device Issue

We are currently in the pilot phase of a migration and we seem to be having some issues around the NAS head devices which are EMC Celerra.  The users are not able to access their file share post migration getting an access denied message.  We are currently using QMMAD 8.8 and migrating SIDHistory.  We have not processed the NAS heads yet we were hoping to use SIDHistory.  Has anyone seen any issues that we should be aware of with the EMC Celerra devices.

Thanks,

Ray

  • Does the destination domain have 2012 domain controllers?

    If so you could be having an issue with some of the enhancements in 2012, specifically the SID compression functionality. See the interoperability notes in the “KDC Resource SID Compression” section of the below:

    blogs.technet.com/.../maxtokensize-and-windows-8-and-windows-server-2012.aspx

    Essentially 2012 will try to compress the SID’s in the token, including the Domain(s) SIDs, and then only the RID(s) into the token to work around token bloat and the max token size issues that may have been seen in previous versions. I believe many of the NAS vendors have not yet updated their underlying authentication mechanisms to accommodate for this. The article details how you can disable this.

    You may want to open a ticket with EMC to confirm, however I would suspect this may be the issue you are seeing.

  • Brian,

         Thanks for the reply but we do not have any Windows 2012 domain controllers in the environment.

    Thanks,

    Ray

  • Hello Raymond,

    Can the users logging onto the target domain access resources back in the source domain on a regular windows share?

    Enrico

  • Thanks Ray – in that case have you instructed the device to honor sidhistory with the usermapper configuration?

    It’s been a while since I’ve been up against an EMC during a migration, but I believe this is a requirement (or should I say was a requirement). It may not be in the later versions of the devices…

    If you add the target user to a test share somewhere on the device, are they able to access the resource? Assumedly sidHistory is working fine for access to other resources?

  • Enrico,

    Sorry for the delayed response has been crazy here.

         Yes it does appear the the windows servers are not an issue the issue appears to be with the NAS devices specifically.  The thing is that not all users are having the issues with the NAS devices there are some users who have no issue but then a subset of users which are having problems. We are leaving users accounts enabled on the Source domain and I have heard this could cause an issue with sidhistory has anyone ever encountered that issue?

    Thanks for all the help.

    Ray

  • Raymond,

    We have a slew of NETAPPS with CIFS have not encounetered such an issue.  We actually do leave the source accounts enabled in the source do not have an issue with sidhistory.  Silly question are the security settings on the share ok?  We actually had an issue were they just created the share and just gave rights on the share itself and not on the NTFS portion.  Not sure if EMC Celerra shares function the same way.

    Enrico

  • Enrico,

         So we have noticed that there are some share and NTFS permissions using the domain users group and we are working through that but these other shares do not have that issue.  The one thing we have seen is that the NTFS permissions are set at the top level then there may be one to two levels in which they do not have permission and then at the bottom level they have permission again.  So when they map the drive they map it down to the last level which has permissions.  They do not have any rights to travers the folders above which I think maybe part of the issue here. This was working prior to migration and now they are getting access denied issues. We have also tried to do an effective permissions on the folder and there account in the target domain and the permissions appear to be fine.

    Thanks,

    Ray

  • Raymond,

    We worked backwards on that issue, took the migrated computer and account had them log backinto the source domain context.  Verified if they were able to access the data fully without issues.  Then had them log back in with the same account but in the target context and verified accessibility to the shares back in the resource domain.

    You said "This was working prior to migration and now they are getting access denied issues."  try to reproduce this by logging back into the source domain conext with the user account in question.

    Enrico

  • Ray, is it correct to say that some of the permissions are assigned to the Domain Users group, and that those files and folders cause trouble now?

    When you look them up do you always see 2 entries, for each user and group? You should see them twice, one entry for the source object and one entry for the target object.

    I wonder if Domain Users group was migrated and is present in the ADAM DB and in the INI file, which was used when processing the resources. Basically check if the affected users/groups are present in the INI file and don't be afraid to run the processing again, you can run it as often as needed, no risk and no damage and no negative effects. Also make sure you process in 2 runs, once the share permissions and once the file permissions. Vmover can be executed against a folder with a set of subfolders, too, by using the "volume" switch.

  • Wally,

    Thanks for the reply actually what I meant to say is that we have some situations in which they have applied domain users to share permissions and/or NTFS permissions.  We have not migrated the domain users group and do not intend to migrate that group.  We also have not processed the NAS heads we were trying to use access via sidhistory and process the devices at a later time.  I think that it is going to come down to processing the NAS heads to resolve the issue just wondering why sidHistory is not working.

    Thanks,

    Ray