authenticatin over WAN 1

[wattsup]

I have users on a segment of a WAN that are giving me problems with authentication. When these users log in they get authenticated by the PDC accross a WAN link even though there is a BDC in the the same LAN. The workstations are in a different subnet from the BDC but I do have connectivity from the workstations to the BDC (ping, map a drive, etc.)

My workstations are all hybrid node which from what I can find means that WINS has something to do with this problem. I've looked at the WINS table and the BDC is there.

Can anyone give me some pointers to help me get my workstations to authenticate where they are supposed to?

Thanks for your input!

 

[polymath5]

There is a command that will force what DC a workstation authenticates to, sorry don't remember it off hand.

Hybrid mode is what you should expect with a functioning WINS server.

Why do you have the local BDC on a different subnet?

 

[wattsup]

The decision was based on IP address limitation and the tech director wanted the servers (f&p, DC, Wins and DHCP) to be in a separate subnet from the users. Is it normal for each subnet to have its own DC on it? I'm probably to new at this to be trusted with a domain admin password...oh well!

The other thing I found was that the important WINS entry is the \\{domain_name}[1Ch] entry. This contains the IPs for all DC's in our network. Does anyone know if the order of these entries is important. The first IP listed in the WINS table is for my PDC followed by the other BDC's. The IP that I wish my users were authenticating to is listed 5th. I'm wondering if this list is parsed in order with the workstation using the first entry on that list.

I also found something in my search that made me thing it would help to run WINS on the DC. I can't think of any harm so I may try that tomorrow...

As stated before...thanks for any help that can be offered.

 

[polymath5]

WINS can run on a DC, but there's no real advantage to it. My WINS servers are NOT on our DCs. The order listed is also not important.

I don't see any advantage at all, to having the DCs running on a different subnet.

If the client is WINS enabled then a query for the resolution of &quot;<domain name> <1C>&quot; will be sent to the WINS server as defined in the clients TCP/IP properties. The WINS server will return up to 25 IP addresses that correspond to domain controllers of the requested domain, a \mailslot\net\ntlogon is broadcast to the local subnet and if the workstation receives a response then it will attempt logon with the local domain controller.

If WINS is not configured then it is possible to manually configure the LMHOSTS file on the Workstations to specify the Domain Controller. This file is located in the %systemroot%\system32\drivers\etc directory.

An example entry in LMHOSTS would be as follows

200.200.200.50 titanic #PRE #DOM:savilltech #savilltech domain controller

The above sets up IP address 200.200.200.50 to be host Titanic, which is the domain controller for savilltech and instructs the machine that this entry is to be preloaded into the cache.

Service Pack 4 includes a new utility, SETPRFDC.EXE, which will direct a secure channel client to a preferred list of domain controllers.

The syntax is:

C:\> SETPRFDC <Domain Name> <DC1, DC2, ....., DCn>

SETPRFDC will try each DC in the list in order, until a secure channel is established. If DC1 does not respond, DC2 is tried, and so on. Once you run SETPRFDC on a WinNT 4.0, SP4 computer, the list is remembered until you change it. You can run SETPRFDC in batch, via the scheduler, or even in a logon script (for future logons). Don't forget to undo any LMHOSTS entries you might have set.

Why is it that you want to force it to authenticate to a specific DC?