Hello jlear,  first things first, I would highly recommend a service request to track and troubleshoot this issue to its resolution. secondly do you see any difference when you go to the network share by IP address vs smartconnect zone name?  If you are able to authenticate by IP and not by name it sounds very familiar to the following ETA  [URL] SMB/SMB2/SMB3 clients may experience login failures when authenticating through Microsoft AD and the NT LAN Manager Security Support Provider (NTLMSSP). As a result, data residing on EMC Isilon clusters is unavailable to SMB/SMB2/SMB3 clients, causing DU failures. Authentication failures may also affect clients attempting to access data through HTTP-based protocols, such as RAN. For additional details, see Microsoft Knowledge Base Article 3002657 and Microsoft Knowledge Base Article 3068457. it is also worth note that if you have more than one domain controllers (like most companies do) it is possible only one or two of them have these patches installed so you may need this last kb to verify if these patches are installed on ANY domain controller.  [URL]  Again this is all speculative based on the problem description and I would expect all SMB clients not just OSX ones to get this behavior, that being said again I would open a service request to address this as we take Data Unavailability pretty seriously.  Regards, D_Tracy
Hello All,  This past weekend something happened and users who had their PC's off over the weekend could no longer access our shared drive off it. However, all users who had their PC's on, myself included, were fine. No errors in Isilon, no errors in AD, no network troubles, nothing. We have nothing to go on with what happened or why.  Our Isilon authenticates via AD. And for those PC's that were off and no longer able to access the shared drive, you would put in any AD credentials that you know should work, and you would get the error of "Wrong network password." It didn't specifically say "wrong username or password" as it would normally, it said "Wrong network password." To add to this, no AD accounts would work, however, the local accounts we have setup did. To troubleshoot, we unjoined and rejoined from the domain, that did nothing. Then my supervisor had the idea of removing the admin account and putting in another one. Doing that fixed the issue (for the majority), and all of us using Windows have not had a problem since.  The remaining problem here is all the OSX users at our remote site can only sporadically access the network share with their AD credentials; sometimes it works and sometimes it doesn't (but as before, the local credentials work). We have a direct site to site connection, and they are able to ping and hit Isilon, so the connectivity is there. I intentionally tried with the wrong password multiple times to test authentication and the user account I was trying with never locked out; which should have happened with AD authentication.  Anybody have any ideas on what may have happened and/or what we can do to fix the situation with our OSX users?
Isilon is not authenticating OSX Users at Remote Site