Mapped drive loses authentication daily

We have a client that has 8  XP Pro workstations set up on an AD 2003 domain. The server is set up as a file server and a folder holding 2 applications that they use is shared.  There is a login script that maps the network drive for each user (net use z: \\serverip\folder /persistent:yes). Every day between 5:00 pm and 5:30 pm one of the workstations loses the mapped drive (same workstation every day).  Basically what's happening is the workstation is losing authentication with the server.  When this happens, the workstation is not able to access the mapped drive without logging out and then back in.  If you try to access the folder by UNC then I am prompted with a username/password dialog and if I enter the username/password of the user that's logged in to the machine it gives me a message saying that the username/password I am attempting to use has already been tried.  Using another username/password that's in AD works and I am able to access the folder. Initially we thought that it may be caused by Symantec Endpoint Protection so we un-installed SEP from the workstation.  

A few other things to note:
Another user said that he used to experience the same thing daily on his machine before the user of the current problem machine before the user of the current problem machine worked there.  He also said that he experiences it once in a while but not daily like the current workstation does.  

After we set a static IP and removed SEP from the current problem workstation, it seems as if the workstation that used to have the problem is having the problem again as well as the current machine.  

Looking at the system event logs on both machines shows a warning for LSASRV event ID #40960 & 40961 at almost exactly the time that the users said that they had the problem.  

There is a hardware VPN/Firewall on the network that we don't have access to, the network was set up by another company and we don't have the username/password for the VPN.

We've checked all scheduled tasks (none are set), logon hours are good, and we deleted and recreated the user's AD account.

Thanks,
Jack Smith
egmtechAsked:
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.

Jessie Gill, CISSPTechnical ArchitectCommented:
do ou have any other event log, maybe from teh local machine?
0
Jessie Gill, CISSPTechnical ArchitectCommented:
do you have any other event logs, maybe from the local machine?
0
Jessie Gill, CISSPTechnical ArchitectCommented:
It seems like you have a kerberos problem, that the workstation session tokens are expiring.  

Have you tried restarting kerboros service?  Do, you have any kerboros event log errors?
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

dnudelmanCommented:
net use x: \\machine name\resourcename /persistent:yes

this should "store" the credentials
0
egmtechAuthor Commented:
jessiepak: The lsasrv event is from both of the workstations.  If you're asking if I can provide the log, this is at a business that is one of our clients and I don't have access to it right now but I will be going out there this afternoon so I can be there when the problem happens.  Apparently kerberos logging isn't on by default (?) but I turned it on this morning on the server.

dnudelman: it was originally set as net use z: \\server\ccapps without /persistent:yes.. I changed it to net use z: \\192.168.0.254\ccapps /persistent:yes because of a forum post I found that suggested that setting the path to the IP instead of the machine name and adding /persistent:yes would fix the problem but it didn't.

Thanks,
Jack

0
egmtechAuthor Commented:
Formatting the server fixed the problem, thanks for all of the suggestions.
0

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
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
Active Directory

From novice to tech pro — start learning today.