Have you tried using preferred servers? This is the most reliable way to authenticate in software distribution.
Also make sure that both the share permissions AND the NTFS permissions are set properly. Still, preferred servers is the best way to do UNC authentication.
If Domain Computers have access check the folders and files below to make sure the rights are propagating.
Ok, here's the only thing in Group Policy that might be stopping this from working:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options
Network Access: Shares that can be accessed anonymously: COMCFG, DFS$, SYSVOL
I do not know if this setting was changed recently. Would the lack of a certain share in this policy cause my problem? Should IPC$ or ADMIN$ belong here?
No, that is to allow ANONYMOUS access to shares, which you don't want. Don't worry about that setting.
The reason I thought that might be it was, when I check the Security Log of the server hosting the share, all I see is SUCCESS AUDIT for User ANONYMOUS LOGON :
Successful Network Logon: User Name: Domain: Logon ID: (0x0,0x755C1) Logon Type: 3 Logon Process: NtLmSsp Authentication Package: NTLM Workstation Name: COMPUTERNAME Logon GUID: - Caller User Name: - Caller Domain: - Caller Logon ID: - Caller Process ID: - Transited Services: - Source Network Address: IPADDRESS Source Port: 0
we've the same problem in the past if "Local System" tries to connect to a network share.
Add the groups "network" and "Domain Computers" (read and execute) to the share permissions and create a "Null Session Share" (core\ldmain\Utilities\SysShrs.exe), than it will work .
Soooo.... I've pretty much pulled out all of my hair dealing with this issue now. The problem is INTERMITTENT which makes it extra tough to track down. I can run the same PSEXEC command repeatedly and get ACCESS DENIED, then the command spontaneously starts working properly. Run it some more, and then start getting ACCESS DENIED again. It's happening on all production servers in our environment that have a share with Domain Computers access.
Here's what I've tried since the original post in an attempt to re-create the problem:
Set up a new VMWare 2003 R2 server, pre-created a domain account for it, made sure NO GPO is being applied to it, joined it to the domain, and made a Packages$ share and gave it Domain Computers. NO PROBLEMS
Compared Windows Updates of the VM server against our production servers, and manually installed each update by hand, rebooting after each one and testing Domain Computers access. NO PROBLEMS
Moved the VM server account in Active Directory to the same group as the production servers, so that GPO would be applied. NO PROBLEMS
Installed MS Forefront on the VM server, applied all product updates, applied Forefront-specific GPO. NO PROBLEMS
Sniffed network packets between the computer running the PSEXEC command, between the target computer to execute the command and the server hosting the file to be executed, and also between the Domain Controller and the server hosting the file.
Attached is the network trace of an ACCESS DENIED scenario.
FAILED.TXT 73.5 K
OK, I have a few thoughts about this:
If you are getting access denied errors, run a Process Monitor trace to see exactly which account and which resource (file, folder, etc.) is generating the access denied error. You can get the utility here:
I've seen a lot of issues with administrative shares (ending with a "$" sign) and don't use them.
If you haven't yet tried preferred servers, it's the most reliable way to do software distribution. Even if the only server you have for software distribution is your core, you can still use it.
In the console on the core, Click on Configure, then Preferred servers. Configure the core (or any server you want) as a preferred server. The nice thing is you can specify the account that will be used by your clients when they access the preferred server for downloads. This way you get out of the mess of giving permissions to the Local System account for each machine.
Thats the kicker - we ARE using preferred servers, 50 of them. Even with a read-only credential, we still get the intermittant ACCESS DENIED. In the LD 32-bit console when you open PREFERRED SERVERS and click TEST CREDENTIALS, the test comes back successful.
The only other thing I've solidified in this issue is that using
IP.ADD.RESS\share$ only works intermittantly for LocalSystem accounts, but
Fully.qualified.domain.name\share$ ALWAYS works for LocalSystem. I really don't want to have to go change all my batch files and Preferred Servers just to add the FQDN.
We have a support call in to Microsoft for this issue. I'll post my findings in this thread when (if?) we find a resolution.