Thanks for the update, this sounds much more plausible then the resetting of the user mapping on the cluster. It sounds like the client is connecting to their AD credentials properly on one network, then authenticating as a guest or alternative account on the other method. Hopefully this gets worked out quickly!
We may need some more information about the environment to answer the question.
I assume this is an SMB share.
How are they normally authenticated, Active Directory?
Are they able to get into the share, but not access files, or can't get to the share at all?
Normally a Windows user will already be authenticated through Active Directory - they'll have their own SID as their identity. When connecting to the cluster through SMB, there are share permissions that would be checked. We often recommend share permissions are left wide open, but if you are restricting access to a certain set of groups or users, they might get stopped here and not see the share.
If wide open, they should get into the share and see files.
Now when trying to access a file or folder - now you are comparing their identity against the folder/file permission settings.
So if all is working well, their SID is mapped in our mapping database to a correct identity along with their group memberships, etc. and compared against those permission settings.
This comparison shouldn't change on a day-to-day basis without something else big going on. Was there a big change in group memberships, or permission settings on the cluster? Has the user logged in as themselves, or have they logged in through some other method that they aren't getting the same identity mapping?
All this to say - there isn't an easy simple answer here. If it does turn out you just need to adjust the mapping, then you are on the right track with isi auth mapping. Here are some reference articles that might help further:
We found out that this issue is somehow isolated to when the user has their laptop plugged into their docking station and when its not. When the user is not on their docking station they are using wifi. We believe there is faulty configuration with the workstations certs. when over wifi that is not properly authenticating the machine account to the domain, intern somehow effecting the users token integrity on the network. When I check the logs on the Isilon to see if I can find where the user is failing in their attempts to connect to the Isilon I cannot find such entries.
cadiletta
1 Rookie
•
106 Posts
0
February 4th, 2015 08:00
Thanks for the update, this sounds much more plausible then the resetting of the user mapping on the cluster. It sounds like the client is connecting to their AD credentials properly on one network, then authenticating as a guest or alternative account on the other method. Hopefully this gets worked out quickly!
cadiletta
1 Rookie
•
106 Posts
1
February 3rd, 2015 11:00
We may need some more information about the environment to answer the question.
I assume this is an SMB share.
How are they normally authenticated, Active Directory?
Are they able to get into the share, but not access files, or can't get to the share at all?
Normally a Windows user will already be authenticated through Active Directory - they'll have their own SID as their identity. When connecting to the cluster through SMB, there are share permissions that would be checked. We often recommend share permissions are left wide open, but if you are restricting access to a certain set of groups or users, they might get stopped here and not see the share.
If wide open, they should get into the share and see files.
Now when trying to access a file or folder - now you are comparing their identity against the folder/file permission settings.
So if all is working well, their SID is mapped in our mapping database to a correct identity along with their group memberships, etc. and compared against those permission settings.
This comparison shouldn't change on a day-to-day basis without something else big going on. Was there a big change in group memberships, or permission settings on the cluster? Has the user logged in as themselves, or have they logged in through some other method that they aren't getting the same identity mapping?
All this to say - there isn't an easy simple answer here. If it does turn out you just need to adjust the mapping, then you are on the right track with isi auth mapping. Here are some reference articles that might help further:
https://support.emc.com/kb/16604
https://support.emc.com/docu50075_Identities,_Access_Tokens,_and_the_Isilon_OneFS_User_Mapping_Service.pdf?language=en_US
This topic can of course explode with complexity - so I also do recommend speaking to EMC Customer Service if the need is at all urgent.
chjatwork
2 Intern
•
356 Posts
0
February 4th, 2015 08:00
We found out that this issue is somehow isolated to when the user has their laptop plugged into their docking station and when its not. When the user is not on their docking station they are using wifi. We believe there is faulty configuration with the workstations certs. when over wifi that is not properly authenticating the machine account to the domain, intern somehow effecting the users token integrity on the network. When I check the logs on the Isilon to see if I can find where the user is failing in their attempts to connect to the Isilon I cannot find such entries.