Strange credential caching behavior

[theniteowl]

Can anyone explain the reason behind this behavior?
We have a Windows 2003 R2 Standard Edition server.
The server is attached to the domain but we log into the server using a local account.

An application on the server has to be able to access resources on several other servers. The application is setup to run as a service and a domain id\password is set for that service to run under.

We used to have drive mappings on the server pointing to a number of other servers and they were setup to use alternate credentials using a domain ID.
We had settings in the User Accounts and Passwords that set the UNC paths and domain ID\password to use for those resources.

We recently tested removing the drive mappings, all Network Places and all entries under User Accounts and Passwords, then rebooted the server. After the server came back up it was still able to write data to the network shares that the local logon ID for the server does not have access to.
Is the server somehow persisting the cached credentials for those shares for some period of time even after rebooting the server?

My first thought was that somehow the credentials stored for the application service were being passed to the remote servers when the shares were accessed, but some of those shares require different credentials so not all of them can be so easily explained.

Thoughts?
We are trying to determine what the best means of providing the credentials to the remote servers is.
The server has to be able to operate without someone having to manually interact to provide login credentials.
It was suggested that we setup Network Places to ensure that the credentials are stored but I am not confident that the credentials are automatically passed without user intervention when it is a background application trying to connect. I can find no information on Network Places that adequately describe how it functions.
I am considering the use of Stored Usernames and Passwords which I believe should work as we need but wanted to test that access was working correctly and after removing all network places, stored usernames/passwords and drive mappings connectivity is still there while it should not be so I cannot effectively test the different methods.



At my age I still learn something new every day, but I forget two others.

 

[pasupport]

Well you could continue the drive mapping which of course provides the need information. As you know since the information is stored in a plain text file that is not secure.

Ideally you would have an account on the remote servers that matched the DOMAIN log on account username and password. That way you can map the drives without supplying username and password, or use a UNC path.