ADC VPN and MS Configuration Manager SMS host agent service causing account lockout

[Scott Bertolami]

Hello,

Our domain member laptops are running Gateway client 12.x. We also use the Microsoft Configuration Manager client for endpoint management.

Whenever the Citrix Gateway Client is connected to full VPN, and the SMS Agent host service attempts to connect to our Config Manager server using NTLM (as it normally does on site), the request is seen as coming from Netscaler and is refused by the SCCM server. Multiple events eventually cause the user's AD account to lock. Anyone else experiencing this or using Configuration Manager client successfully over VPN? This is from the security log of the Config Manager server...

 

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          3/13/2019 10:51:05 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      <fqdn of sccm server>
Description:
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:        -
    Account Domain:        -
    Logon ID:        0x0

Logon Type:            3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:        <AD username>
    Account Domain:        <domain>

Failure Information:
    Failure Reason:        Unknown user name or bad password.
    Status:            0xC000006D
    Sub Status:        0xC000006A

Process Information:
    Caller Process ID:    0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:    NETSCALER
    Source Network Address:    -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:        NtLmSsp 
    Authentication Package:    NTLM
    Transited Services:    -
    Package Name (NTLM only):    -
    Key Length:        0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
 

 

Thanks in advance.

Scott

[CarlStalhood]

In your VPN Gateway configuration, did you configure Intranet IPs? Does it work if you do?

[Scott Bertolami]

Hi Carl,

No, I have not configured intranet IPs. We're seeing the traffic coming in on the SNIP as expected. 

I'd been dealing with this problem for a while before I posted to the discussion board, but shortly after I posted I managed to fix the issue. I noticed my auth vserver did not have an authentication domain specified. Not sure how this was missed. Up to now it hadn't occurred to me that the auth vserver might be impersonating and passing creds for a Windows service on the remote client computer, but soon as I entered our FQDN auth domain, the NS began to pass creds correctly and the issue resolved..

 

Thank you very much for your reply and guidance. I relied heavily on your documentation and it was a huge help in getting this set up. 

 

Scott

[David Cohen1709164082]

On 3/14/2019 at 4:19 PM, Scott Bertolami said:

Hi Carl,

No, I have not configured intranet IPs. We're seeing the traffic coming in on the SNIP as expected. 

I'd been dealing with this problem for a while before I posted to the discussion board, but shortly after I posted I managed to fix the issue. I noticed my auth vserver did not have an authentication domain specified. Not sure how this was missed. Up to now it hadn't occurred to me that the auth vserver might be impersonating and passing creds for a Windows service on the remote client computer, but soon as I entered our FQDN auth domain, the NS began to pass creds correctly and the issue resolved..

 

Thank you very much for your reply and guidance. I relied heavily on your documentation and it was a huge help in getting this set up. 

 

Scott

Hi,

Where exactly did you enter the FQDN auth domain?

I'm experiencing the same issue in our environment and didn't understand the solution.