[cvsnt] NetGetAnyDCName vs NetGetDCName

Chris Little cslittle at mac.com
Thu Feb 12 21:40:05 GMT 2004


in article BC4FBB87.35777%cslittle at mac.com, Chris Little at cslittle at mac.com
wrote on 2/11/04 10:59 AM:

> in article 88j420pmv768eg2bpn1db2im6hes91d1p6 at 4ax.com, Tony Hoyle at
> tmh at nodomain.org wrote on 2/5/04 9:13 AM:
> 
>> On Thu, 5 Feb 2004 14:14:25 +0100, "Mathieu Veurman"
>> <MVeurman at seagull.nl> wrote:
>> 
>>> "As long as you have a trust relationship, it'll work."
>>> 
>>> That's the problem. We have a trust relationship, but it doesn't work.
>>> 
>> Install the resource kit and try:
>> 
>> nltest /dctrust:<domain>
>> 
>> ..which will verify the trust account.
>> 
>> The documentation (and a quick search of google) definately confirms
>> what I've seen to be true in the past - the correct way to resolve
>> trust accounts is to call NetGetAnyDCName.
>> 
>> With an Active Directory forest I should really be calling
>> DsGetDCName, but that has issues for NT4.
>> 
> 
> I'm having the same problem as Mathieu in that people from other trusted
> domains can't login using pserver.
> 
> We have an NT4 server PDC and our CVSNT server runs on a Windows 2000
> server.
> 
> I tracked down nltest and ran it on the server.  If I do a
> 
> nltest /trusted_domains
> 
> It list all of the trusted domains but when I run
> 
> nltest /dctrust:<domain>
> 
> I get the error
> 
> NetGetAnyDCName failed: Status 1355 0x54b ERROR_NO_SUCH_DOMAIN
> 
> Are we getting this error because we're using a Windows 2000 server inside
> an NT 4 domain setup and not active directory.
> 
> As an aside, people are able to connect using sppi when they are using
> Windows clients.  People can access the file shares as well.
> 
> Chris
> 

I upgraded our cvsnt server from 2.0.14 to 2.0.25 and it has fixed our
pserver log in issues.  I looked at the code in win32.c and it looks like
there was a significant rework of the authentication code.

Chris




More information about the cvsnt mailing list