SOLVED!

I had read on some web page somewhere that this isn't a problem if you use IPs in your service address instead of machine name. I don't know why that should make a difference, but I changed all my addresses to use an IP and voila! the problem disappeared! This is fine, because we're using fixed IP addresses for our VMs and whenever we eventually install our products, our clients will likewise be using fixed IPs.

Can anyone poke any holes in this or does this sound like the correct way to go ...

~~Bonnie




>AFAIK, yes. I don't think that the client attempts to authenticate the server.
>IAC, I suppose specifying the username of the currently logged in user in the config wouldn't have changed the behaviour anyway
>
>Few thoughts (which may be a red herrings) :
>
>(a) In your OP you said that it worked when logged on to the client machine using a local 'Administrator' account. Were the account names *and* passwords identical on both the client and the server? Only ask because, thinking back to .NET remoting, this scenario would result in the server accepting the authentication without any reference to the domain. If the passwords were the same then it might be worth trying with different passwords. If that fails it will at least explain why the original was working.
>
>(b) Are you sure that the problem is not with the domain/ADS itself rather than specific to WCF ?
>
>(c) You could try using the service trace log to get more insight into the problem.....
>
>(d) One thing I'd probably try:
>Fire up the service then use a VS project on a client machine to see if you can add a service reference there via the wizard.