>>>>I've seen those examples of using the identity tag with the userPrincipleName, but I just don't get that. WTF is username@domain.com supposed to be in real life? I haven't a clue.
>>>
>>>When you created the domain in Active Directory, you have to specify a domain name. That's what "domain.com" is supposed to be. "username" is your user name that you use to log into the domain with.
>>
>>Doh!! Don't know why that didn't pop into my brain by itself. Thank you for explaining that. I think that using that might be a better path to go down than what I've been trying in the past few hours.
>
>I just tried that and it didn't work. Still getting an SSPI error. This only goes in the client endpoint, right?

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.