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

[Guest 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...