Loss of File share Connections / mapped drives

I've seen some related questions posted, but none have yielded a fix:
I'm running a Win2k3 memeber server in a flat domain.  I don't have access to the DC and can't change any domain-wide policies.  I control an OU for my office, with the member server and a dozen XP workstations.  Login authentication is routed through kerberos servers.

I recently switched from an NT 4 domain to the 2003 OU set up, and now some of my workstations are dropping their connections to the shared file network drive for no apparent reason.

The server shows an event ID 529 - bad username and password with the NTLMSsp process, then locks out the workstations shortly after.  I can reconnect after rebooting, but none of the fixes I've seen have stopped it from happening.  I also have repeated 1048/1030 event ID's, stating that the GPO objects can't be reached and policy processing is aborted.  I'm wondering if my access rights or permissions are mistaken, but I can't figure out where I might have erred.  I'm hoping someone has an idea of what's behind these errors.
Who is Participating?
Joseph NyaemaIT ConsultantCommented:
This is the description I can find for that event on the microsoft website.


Doesn't look very helpful...

Further research shows that Windows XP service pack 2 might sort your probelm out

Though you have not mentioned what version of Kerberos you are using
this articles might apply to you but more specifically applies to to MIT Kerberos


Given the dates the articles were written
you will find that the relevant hotfixes have been included in Windows XP Service Pack 2

Joseph NyaemaIT ConsultantCommented:
Make sure all the clients are pointing to the same DNS server windows 2003 server is using for active directory

Also make sure they are not pointing to a WINS server.
Joseph NyaemaIT ConsultantCommented:
What OS are the clients giving you this problem?
Are there any clients running win98/95?

Do you still have the NT4 servers running somewhere in your network?
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Zeek0Author Commented:
No, the NT 4 system is dead and gone.  All the workstation systems are fully up-to-date XP systems, and the member server is a fully updated 2k3 system.  
Zeek0Author Commented:
I fixed the 1058/1030 errors (turned on the TCP/NetBios helper service).  I can't figure out what's up with the NTLMSsp failure audits on the server, though.  Kerberos logins are fine, but at the same time as the Kerberos stuff checks out, I'm getting the bad username/password (529) errors all over the server's event log.  Is there a permission that needs to be given to a particular account for NTLMSsp?  I know these aren't attacks, and I know the usernames and passwords are correct, so something is hanging up - sending bad information or the information is not being read correctly, but I don't know where.  
Zeek0Author Commented:
Here's a copy of one of the event notifications I get on the file server when these logon failures start occuring.  

Event Type:     Failure Audit
Event Source:     Security
Event Category:     Logon/Logoff
Event ID:     529
Date:          8/13/2004
Time:          11:38:20 AM
Computer:     (SERVER)
Logon Failure:
      Reason:          Unknown user name or bad password
      User Name:     (Username)
      Domain:          (DomainName)
      Logon Type:     3
      Logon Process:     NtLmSsp
      Authentication Package:     NTLM
      Workstation Name:     (WSNAME)
      Caller User Name:     -
      Caller Domain:     -
      Caller Logon ID:     -
      Caller Process ID:     -
      Transited Services:     -
      Source Network Address:     (ip.ip.ip.ip)
      Source Port:     0

I've tried the net config solution, no dice.  The domain set up (which is new to me and not a standard AD implimentation) authenticates sign on through external kerberos servers, and all the kerberos authentication is fine.  I get successful audits of the kerberos processes and logins at the same time as I'm getting these 529 errors from the NTLM deal.  It seems like the info NTLMSsp is trying to use to authenticate is no good for some reason - it's not an incorrect username or password though (unless one or the other is being relayed incorrectly).  
Joseph NyaemaIT ConsultantCommented:
Are the machines part of the domain
or are they in a network
Zeek0Author Commented:
all part of the domain.  i'm wondering if i have a setting somewhere in a GPO that's screwing it up, i.e. not giving access to the system in a particular way that allows the NTLM stuff to connect and transfer data properly.  

you just make sure that you are  using  same  Version of NTLM at DC and client.

See this URL for more help.   http://support.microsoft.com/default.aspx?scid=kb;en-us;Q239869

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.