Windows 10 Problems using Microsoft RSAT From A Non-Domain PC - wrong negotiation (?)

[El_Presidente]

I have two machines (Win 10 pro 1903) that connect to my AD to do basic management that are outside of the domain.

Since Saturday I cant connect from one pc anymore, while the other one works fine. I use this "script" below to connect.

@echo off
runas /netonly /user:<domain>\<username> “mmc /server=<DC or domain>”

It gets even weirder because I found out that it has something to do with my local user profile. When I created a fresh profile on the non working pc, I was able to connect without a problem. I did not change anything nor installed any piece of software, not even a windowsupdate.

So I ran wireshark to find out what was the problem and I found, that my malfuncioning profile uses a different auth method and therefore is not able to authenticate with the AD.

On the working system the bindrequest is done with NTLMSSP as you see below:

---

Frame 12: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface 0
Ethernet II, Src: 00:ff:1c:f4:5d:5f (00:ff:1c:f4:5d:5f), Dst: 00:ff:1d:f4:5d:5f (00:ff:1d:f4:5d:5f)
Internet Protocol Version 4, Src: 172.24.0.3, Dst: 172.16.1.1
Transmission Control Protocol, Src Port: 53688, Dst Port: 389, Seq: 151, Ack: 261, Len: 80
Lightweight Directory Access Protocol
LDAPMessage bindRequest(3) "<ROOT>" sasl
messageID: 3
protocolOp: bindRequest (0)
bindRequest
version: 3
name:
authentication: sasl (3)
sasl
mechanism: GSS-SPNEGO
credentials: 4e544c4d5353500001000000b78208e20000000000000000…
GSS-API Generic Security Service Application Program Interface
NTLM Secure Service Provider
NTLMSSP identifier: NTLMSSP
NTLM Message Type: NTLMSSP_NEGOTIATE (0x00000001)
Negotiate Flags: 0xe20882b7, Negotiate 56, Negotiate Key Exchange, Negotiate 128, Negotiate Version, Negotiate Extended Security, Negotiate Always Sign, Negotiate NTLM key, Negotiate Lan Manager Key, Negotiate Seal, Negotiate Sign, Request
Calling workstation domain: NULL
Calling workstation name: NULL
Version 10.0 (Build 18362); NTLM Current Revision 15
[Response In: 13]

---

while on there malfunctioning machine (profile) it is tried via SPNEGO without NTLM.

---

Frame 9: 516 bytes on wire (4128 bits), 516 bytes captured (4128 bits) on interface 0
Ethernet II, Src: 00:ff:96:6b:a9:38 (00:ff:96:6b:a9:38), Dst: 00:ff:97:6b:a9:38 (00:ff:97:6b:a9:38)
Internet Protocol Version 4, Src: 172.24.0.2, Dst: 172.16.1.1
Transmission Control Protocol, Src Port: 51728, Dst Port: 389, Seq: 151, Ack: 261, Len: 462
Lightweight Directory Access Protocol
LDAPMessage bindRequest(3) "<ROOT>" sasl
messageID: 3
protocolOp: bindRequest (0)
bindRequest
version: 3
name:
authentication: sasl (3)
sasl
mechanism: GSS-SPNEGO
credentials: 608201a006062b0601050502a082019430820190a01a3018…
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
Simple Protected Negotiation
negTokenInit
mechTypes: 2 items
MechType: 1.3.6.1.4.1.311.2.2.30 (NEGOEX - SPNEGO Extended Negotiation Security Mechanism)
MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
mechToken: 4e45474f4558545300000000000000006000000070000000…
SPNEGO Extended Negotiation Security Mechanism
NEGOEX INITATOR_NEGO
Header
Random: 9bb65ef528ae8b18c96fcd2e51713ae8715edef07789ea8d…
ProtocolVersion: 0
AuthSchemes: 1 at 96
Extensions: 0 at 0
NEGOEX INITIATOR_META_DATA
Header
AuthScheme: 0d53335c-f9ea-4d0d-b2ec-4ae3786ec308
Exchange: 188 bytes at 64
[Response In: 10]

---

and getting this LDAP response:

LDAPMessage bindResponse(3) invalidCredentials (8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 57, v1db1)

---

Is there a way to force my "profile" back to use NTLMSSP? For me this whole thing cries "here are dragons" ...

More...