How do I fix Shared folder access denied for IIS7.5 32-bit ISAPI on Server 2008 R2

I am moving a once-working ISAPI written in Delphi 7 from Server 2003 to a Server 2008 R2 named KAKA. It runs in a 32-bit pool as NetworkService. KAKA is a domain controller. Most of the ISAPI works, except for where it should search a folder using findfirst, findnext on a share on the other DC (\\KEA\MPE). Findfirst returns 5 (access denied). I have tested it with a local folder which works fine. The share has 'Everyone full' for protection, and the NTFS permissions are Read/Execute/list/Read for Dom\KAKA$. which I am told is how NetworkService presents itself to the other machine. I looked at it with windows explorer 'effective permissions' from an XP client, and it shows OK read etc access for Dom\KAKA$. If I use ISAPIFWD (from Eggcentric) on KAKA to debug the ISAPI DLL on my XP machine, it works fine (probably because the debug user has domain-wide admin permissions).

What am I missing? I am all for enhanced security, but when it stops the app working completely, it is somewhat frustrating.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ephraim WangoyaCommented:

Try starting the service with a different administrative logon user.
kmaynardAuthor Commented:
Do you mean the main WWW Publishing Service (which is currently running as LocalSystem)? The Application Pool which hosts the ISAPI is running under NetworkService.
kmaynardAuthor Commented:
WS2008 R2 won't let me change the service logon credentials. I tried changing the App Pool credentials to administrator, but that made no difference. I set security logging on the share on the file server, but no access was logged. I then did security logging, and I could see that the Web server logged on to the file server with anonymous access, not Dom\WebServer$ as I expected.

I then altered the access to the webserver Scripts dir (where the ISAPI is) to use Basic Authentication, rather than anonymous. As expected I got a userid/pass dialog, and when these were entered the problem disappeared. So - it seems that the ISAPI App Pool used authentication inherited from me, as web page viewer, rather than have permissions in its own right. (Or something!)

Does this provide a better clue as to what is going wrong?
kmaynardAuthor Commented:
The answer was to go to the Authentication icon for the Scripts dir, edit Anonymous Authentication, and change the anonymous user identity to the Application Pool Identity (it was set by default to IUSR). The ISAPI module was then able to access the network share using the Dom\WebServer$ permissions.  

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
kmaynardAuthor Commented:
It was the only complete solution offered. Worth a C because it took a long.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft IIS Web Server

From novice to tech pro — start learning today.