NT 4.0 Wkstn, fails to authenticate after PDC reassigned from Win2K to Win2003 Server

An application server running on Windows NT 4.0 Workstation used to login using a domain user account and authenticate to a Windows 2000 Server.  When that server's RAID array began to fail, a new PDC running Windows 2003 was installed.  The old failing server is still in place.  The domain name remained the same.
After the changes, I am no longer able to authenticate at the NT4.0 workstation.  Upon startup the machine reports that "No DC is available to authenticate, cache values being used" or something to that effect.  
I need to keep this NT4.0 box limping along for a little longer.  I suspect that when the 2003 Server was promoted to PDC, that it doesn't by default allow authentication from the NT4.0 workstation.  
Is there a means of allowing it?
Who is Participating?
from_expConnect With a Mentor Commented:
I suppose, that it is due to lm/ntlm/ntlmv2 authentication problems.

take a look here:
does your nt 4 box have any entries in its lmhosts file?
does your network have a wins server?
anything in the netbios cache on the nt box? (nbtstat -c)
if theres an entry for the netbios name of your domain then try nbtstat -RR
if theres an entry in your lmhosts file that contains #DOM:domain name its probably
pointing at your old server.
Make sure the 2003 server has all of the fsmo roles and is a GC.
johnwbrowniiiAuthor Commented:
<P><STRONG>From exp,</STRONG></P><P>Thanks for your suggested solution.  It certainly looks as if this might fully address the problem but I'm not able to test it yet.  The MS document you provided a link to suggests the installation of NT4 SP6a and IE v6 wSP1.</P><P>This NT 4.0 workstation is the host machine for a very old cost recovery server which might be adversly impacted by the introduction of these service packs. I'm trying to get assurances of compatibility of the hosted application with these service packs before modifying the system.</P><P>Support engineers from the manufacturer have seen similar situation before where they found that operating the network in "mixed mode" allowed for the authentication of the domain users from NT 4.0 boxes.  This suggestion has been rejected by organization managing the client's network.  They contend that authentication has always been done by the Windows 2003 server and that the old 2000 server had nothing to do with authentication. they contend that changing to mixed mode would not make a difference.</P><P>To confuse matters more, I may have pointed in the wrong direction in blaming the PDC changes.  The client recently changed their network's IP configuration to correct some use of "public" IP addresses internally.  After the change, my NT4.0 workstation box suddenly lost its drive mappings to various network locations.  in trying to re-establish these connections I found that I couldn't resolve the machines by name but could map the drives when I mapped to their IP addresses.  This tends to indicate a DNS or WINS issue, Right?</P><P><STRONG>Aterea,</STRONG></P><P>I checked the LMHosts file and found only one entry the "old" pre-change IP address of itself was present.  I changed that entry to the current IP address. I'll have to check to see if the network (still) has a WINS server.</P><P>In order to help mitigate the problems with resolving the other network servers by name I added a record of each in the hosts file of my NT4.0 workstation. </P><P>When I run nbtstat -c from the console of my machine it reports three entries all reflecting the NT4.0 box's name and current IP address. Each is labeled as TYPE <xx> UNIQUE where xx = 03, 00 &amp; 20. All report a life of -1 sec.  I'm not sure how to interpret this information.</P><P>LMHOSTS does not contain #DOM: entry but I do specify the domain username, password and domain name within : HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon where autoadmin logon is activated to restore this machine when power drops/restores.  I noted that the DOMAIN specified here is simply the domain name without extant (ie: .COM or .LOCAL).  This again dates to 1999 when this machien was installed.</P><P>Thanks for all the suggestions. I apologize for the delay in responding but have been on the road for a couple days and am moving slowly so as not to kill this limping old application server unintentionally.</P>
johnwbrowniiiAuthor Commented:
I have every confidence that your suggestion would address the situation. However, due to uncertainty about compatibility with the application running on the server I'll not implement it.  Thanks for your help.
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.