asked on

Error: No domain server was available to validate your password

I'm troubleshooting a problem on a single PC running Win95/OSR2 attempting to logon to an NT 4.0 domain server. The network settings consist of: Client for MS Networks, Novell IntraNetware client 2.2, protocols IPX/SPX, NetBEUI, and TCP/IP. The MS Client accesses NT via Logon validation to the Domain. I've thoroughly checked the networking settings...even compared to all 16 other PCs accessing the NT server the same way. It logs in to the Netware box fine, but pauses and displays the error message:
"No domain server was available to validate your password. You may not be able to access some network resources."

The user and passwd is set up correctly in NT, also. In fact, I've deleted and readded the user just to be safe. I can access shared resources, etc. on NT, but the login script won't run. I've noticed that the error doesn't appear when NetBEUI is not installed on the Win95 PC.

Thru my trials I've been unable to determine whether it's a Win95 or NT issue. I've scoured Microsoft's KB and searchd the net, but all references to this message do not provide an answer. Obi-wan, you're my only hope...

Lee W, MVP

You're problem may be with both. Do you use WINS or LMHOSTS? We had a similar problem and the NT server's WINS database was corrupt. A work around (and as I view it, safety feature) is to use an LMHOSTS file along with the WINS service. If you add your domain controller and domain to an LMHOSTS file with the following entries (adjust the domain names, "internet" in my example, to match yours and change the computer name to your server's name.

123.45.6.37      computername      #PRE #DOM:internet
123.45.6.37      "internet \0x1b"      #PRE
123.45.6.37      "internet \0x1c"      #PRE

Incidentally, in the example above, the "" area must be 20 characters long. the \0x1b, c must be at the end of the quotes like in the example.

This LMHOSTS file should be placed on the client.

Then, when you have an opportunity, rebuild the WINS database (and it's best if you can do this with all the clients off. And the WINS server should also point to itself as both the primary and secondard server. And there should be no static mappings (unless you need to connect to macs or unix boxes).

See http://support.microsoft.com/support/kb/articles/q168/7/12.asp?FR=0 for information on rebuilding the WINS database.

Let me know if this solves you're problem and I'll post it as an answer.

mwyatt

ASKER

I don't use WINS resolution, nor is a LMHOSTS file present. This is strictly NetBEUI in use as a transport for simple peer file sharing. I will add that the problem presented itself on one other machine some months ago, but even after reinstalling Win95 on it the problem persisted. Finally, we replaced it with a new PC which, of course, resolved the problem. Unfortunately that isn't an effective solution in the long run...

I'm open for more suggestions.

wayneb

Try removing all network cards and protocol stacks and re adding them and the network card. Be careful if you do this as the novell client may have to be uninstalled first and then reinstalled. There are 2 possibilitys here, the network stack is corrupted or the registry is damaged, the later is a major problem.

mwyatt

ASKER

Removing network cards and protocol stacks was one of my first approaches, however that didn't work. Some of the other things I've tried include (all with no successful effect):
-Changing the computer name
-Change to quick login
-Deleted password files (*.pwl)
-Remove clients and stacks, restart and re-add clients/stacks

I've spent a great deal of time observing it by doing the above incrementally rather than in one fell swoop so as to hopefully spot the trouble area. In the adding of clients/protocol stacks the following version conflicts appeared (where an attempted file to copy from Win95 OSR2 was older than the existing file):
secur32.dll (4.10.1057)
rpcltc1.dll (4.71.112590848)
rpcltc5.dll (4.71.112590848)
rpclts5.dll (4.71.112590848)
vredir.vxd (4.0.1116)

jminck

you might try a network sniffer & see what is going on during the login process.....

trd

Have u tried another NIC? Or updated the existing NIC driver?
What about NetBios for IPX/SPX? If it is installed, try removing it.

ahood

At your configuration the Computer log's to Novell and pass the parameters to the NT logon.

Are both Novell and NT using same USER NAME ?

I suggest rename / delete the "*.pwl" at the windows directory , i guess somthing is wrong with the paswword list.

mwyatt

ASKER

I haven't tried a network sniffer yet, but that's a possible idea. This shows no indications of a hardware issue, so replacing the NIC is probably not a worthy choice. Also, Netbios is not enabled over IPX, and Netware and NT use identical names. I'm still testing other areas...

Tim Holman

MWyatt,
For a long term solution, why not disable NetBEUI ?
I've come across this problem before and have fixed it by either shifting the PC to another network port or by logging on locally, changing the domain, then changing it back again...
I put it down to a network problem.
Sometimes turning it off for five minutes, then powering on again sorts it out..
You may have a duplicate NetBIOS name on ANOTHER segment ??
Try changing the NetBIOS name....
Oh dear... broadcasts broadcasts broadcasts....

Tim

ASKER CERTIFIED SOLUTION

ChrisRobin

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Tim Holman

This isn't really a solution...
Windows, when configured to 'automatic' will pick up and use as default the first IPX/SPX frame type it sees.
So - if manually selecting a frame type cures the problem, then this means there are definitely other frame types reaching your PC that you need to either filter out or eliminate from source in order to reduce network congestion.