ncacn_np NETLOGON with workstation trust account ok?

[Dave Daugherty]

Michael,

We encountered a similar problem.  In our case someone had changed the Domain Policy -> Local Policies -> User Rights Assignments -> Access this computer from the network and changed the groups. In particular "Authenticated users" was removed and "Domain Users" was added. This allowed AD users to logon but not domain member computers.

Check both Domain Policies and Domain Controller Polices.  Usually the groups are configured on the Domain Controller policy but in our case they were overridden in the Domain Policy.

Dave Daugherty
Centrify

---------

On Behalf Of Michael B Allen
Sent: Wednesday, April 15, 2009 11:13 PM

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