ncacn_np NETLOGON with workstation trust account ok?

[Michael B Allen]

On Wed, Apr 15, 2009 at 10:56 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> On Wed, 2009-04-15 at 22:44 -0400, Michael B Allen wrote:
>> On Wed, Apr 15, 2009 at 9:42 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>> > On Wed, 2009-04-15 at 21:12 -0400, Michael B Allen wrote:
>> >> On Wed, Apr 15, 2009 at 7:57 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>> >> > On Wed, 2009-04-15 at 19:44 -0400, Michael B Allen wrote:
>> >> >> Hi,
>> >> >>
>> >> >> Does anyone know of an issue with authenticating an SMB named pipe
>> >> >> using a workstation trust account? I have someone who is getting the
>> >> >> following error during the NTLMSSP session setup:
>> >> >>
>> >> >>   0xC0000199 STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT "The account
>> >> >> used is a Computer Account. Use your global user account or local user
>> >> >> account to access this server."
>> >> >>
>> >> >> My code is just some Java that is basically does what winbind does
>> >> >> (last I checked winbind also used ncacn_np as opposed to ncacn_ip_tcp)
>> >> >> so I'm wondering if you guys have ever seen this issue with winbind?
>> >> >>
>> >> >> I have tested this with many other people without ever seeing this
>> >> >> error so I'm somewhat perplexed as to what the problem could be.
>> >> >
>> >> > Is your issue that you have a member server that you implement, that you
>> >> > wish to accept connections too, or that you have a client that is trying
>> >> > to contact a Windows member server in the AD domain.
>> >> >
>> >> > Anyway, what is happening here is that the domain controller returns
>> >> > that error message unless a flag
>> >> > (MSV1_0_ALLOW_WORKSTATION_TRUST_ACCOUNT) is set in the
>> >> > netr_IdentityInfo.parameter_control element in the eventual SamLogon
>> >> > request to the DC.
>> >>
>> >> Hi Andrew,
>> >>
>> >> Thanks for the quick response. Unfortunately I do not think that this
>> >> is the problem. The failure occurs way before the NetrLogonSamLogon
>> >> call and NetrIdentityInfo.parameter_control is 0x00000820 so it has
>> >> the MSV1_0_ALLOW_WORKSTATION_TRUST_ACCOUNT (0x800) flag on anyway.
>> >>
>> >> The code is basically just JCIFS' DCERPC acting as a member server for
>> >> authenticating web clients using NTLM. The point of failure is the
>> >> SMB_COM_SESSION_SETUP_ANDX between JCIFS and the NETLOGON pipe on the
>> >> domain controller - the SMB_COM_SESSION_SETUP response is in error
>> >> with the aforementioned STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT.
>> >
>> > Is this an old-style NTLM session setup, or full NTLMSSP extended
>> > security (blobs)?
>> >
>> > The domain controller will not internally apply the
>> > MSV1_0_ALLOW_WORKSTATION_TRUST_ACCOUNT to an old-style session setup, in
>> > order to trigger a behaviour used in enrolling early Windows NT 4.0
>> > machines into a domain (the password would be set to the machine name,
>> > and the machine would check that the password was so by logging in using
>> > SMB, and expecting this error).
>>
>> It's full-blown NTLMv2 extended security (blobs) with NTLM2 session
>> security (for NTLMv1 as well as NTLMv2), key exchange and Secure
>> Channel.
>>
>> But still I don't see how that flag could be involved if the code does
>> not even get past the SMB_COM_SESSION_SETUP_ANDX.
>
> What is the DC in this case?

Well I just received new information that the configuration may have
some properties set that they know are not supposed to be changed.

Anyway the DC is Windows Server 2003.

I actually spoke with the admin on site who was installing the
software and I asked him if there was any special security policy but
aside from migrating to NTLMv2-only he was very quick to claim that
there was nothing special about their domain.

But hopefully this is just a configuration issue. That certainly would
make a lot more sense.

Thanks for your input on this.

Mike