Thanks for the log.
05/10 12:46:18 NetUseAdd to \\LOCKE\IPC$ returned 1326
05/10 12:46:18 Trying add to \\LOCKE\IPC$ using NULL Session
05/10 12:46:18 NetpJoinDomain: status of connecting to dc '\\LOCKE': 0x0
What's happening here is that on the basis of what the NetJoinDomain API has found by probing the DNS and NetBIOS namespaces, it has decided that it's working against a downlevel (i.e., NT4) domain controller rather than an AD one. The above sequence of operations is part of the classic NT4 domain-join procedure, and because it uses classic SMB network it's probably inheriting some behaviour from some of the NT4 networking system.
In NT4 networking, for workgroups, in order to deal with the fact that every machine is a domain to itself what happens when making a connection to another machine is that it presents local-account credentials as if the current user's account exists in the target system. In NT4 workgroups, this means if you have an account with the same name and password on both machines, file sharing "works". This is almost certainly why you're seeing the "GhostJoinDomainUser" auth attempts against your domain, because when trying to set up the SMB-level connection to follow the NT4 path it's passing through code that implements this workgroup hack.
The question then is, why is this happening? For
Windows domains, it shouldn't end up in this code path if it's not an NT4 domain.
The first thing is that the code in the NetJoinDomain API goes through different paths depending on whether the incoming domain name has a dot in it or not. So, if you can use a DNS-format name for the domain being joined, you should try that. Just by itself, that can completely alter how this API works, and may correct its behaviour.
The second thing to check is whether you do have the right DNS SRV records for your DC that satisfies this API, because there are a few of them under the
_msdcs subdomain that need to be present (some background on this is
here, or
here, and the
dcdiag tool can help test the DNS setup).
A third possibility is that if the DNS records are present, there are startup timing issues affecting whether the records are being found. That's complicated to diagnose, though, so check the first two first. The fact the NetBIOS side of things works suggests this isn't timing-related.
Samba is a completely different deal: I've not done any work with Samba as a DC working in conjunction with GSS to know whether there are any issues with it specifically. From a quick scan of the Samba3 docs, one does have to use the old NT4 joining procedure with Samba, but it seems that the code which does this in NetJoinDomain is interacting badly with the SMB session manager because of this temporary local account.
Probably we'll need to try and set up a Samba3 domain here to test this with, and then do some experimenting with different scenarios to see what we can work out. However, that will be something that requires management approval, which we'll have to look at getting next week. I'll try and have this discussion with them on our Monday and see what's going to be possible.