2011-04-20 01:50 AM
This is driving me nuts.
We have moved our installation sources from a regular W2K3 server to a NetApp filer
We have a special in house created tool to let our Windows 7 user elevate their rights to "NT Autority\Local System" and run specific setups from the NetApp
The computer then uses it's computer account to access the resources.
This works fine, except for computers which belongs to another forest. We have full trust between the forests.
I tried to add OTHERDOMAIN\Domain Computers to the share and even OTHERDOMAIN\PCNAME$ and the netapp accepts that as valid account.
I enabled cifs.guest account and added that to the share permissions, still not workin.
I enabled autiting and the autit log seems to give event ID 537 (Unexpected Error) when trying to access the share.:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 537
Reason: An unexpected error occurred during logon
User Name: -
Logon Type: 3
Logon Process: Data ONTAP
Authentication Package: Extended Security
Workstation Name: -
Status code: -
Substatus code: -
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: 0
Transited Services: -
Source Network Address: 192.168.1.111
Source Port: 0
Caller Process Name: -
I tried to access the share using a remote command session on the PC and it reports 1223: Invalid Password.
Is it even possible to let computer accounts from other forest access an application share ?
2011-04-20 12:12 PM
i get the same windows error message in the filers security log, but i have a single domain.
I have some windows 2003 servers and some windows xp clients from which i cannot connect to the filer when i use it's dns alias.
Using the dns A record everything is ok.
From windows 7 or windows server 2008 or 2008r2 i never saw this message.
Tonight i upgraded to the latest ontap level 8.0.1P3, but the problem still exists.
I will start a case on this and will post here if we have a solution.
2011-04-21 05:27 AM
i found that the cifs.LMCompatibilityLevel works differently than on a windows server.
cifs.LMCompatibilityLevel 3 equals the highest compatibility level on windows.
The error came for me on level 4.
2013-06-26 05:00 AM
I realize this was some time ago but I am seeing this issue now that NMCI is rolling out Windows 7 devices in another domain where users need to access our resources. No problems from XP machines in their domain. Exact same error as described by you. Any chance you remember what you ultimately did to fix this? My cifs.LMCompatibilityLevel is at 1 so it should be accepting everything from what I understand? Cifs.signing.enabled is also on.