0

We have recently been challenged by the network team on the failed NTLM authentications captured by AD domain controller. The requests were fired from one of Services hosted on a Windows 2008 Server which have joined the domain. The service is using a local system account to logon. It is reason why failed NTLM login has been captured as there was no failed login captured by using a domain user login. But the domain user login is not allowed by the company policy.

With the Wireshark tool, we have found the requests come from the X509Chain object's Build function. This is the default function provided by .NET framework and we cannot find any useful supporting document to:

  1. Explain why the NTLM requests are fired
  2. Prove there was no security threat from the requests
  3. How to configure in the application level to avoid the failed log in requests (changing the policy rule or AD audit is not allowed)

Part of the code (VB.NET):

        Dim chnCerts As X509Chain = New X509Chain()
        chnCerts.ChainPolicy.RevocationFlag = X509RevocationFlag.EndCertificateOnly
        chnCerts.ChainPolicy.RevocationMode = X509RevocationMode.Online

        chnCerts.ChainPolicy.UrlRetrievalTimeout = New TimeSpan(0, 0, 120)
        chnCerts.ChainPolicy.VerificationFlags = X509VerificationFlags.NoFlag

        If certType = Crypto.CertType.PrivateKeyCert Then
            certPrivateValidationStatus = Nothing
            chnCerts.Build(certPrivate)
MYB
  • 1

2 Answers2

0

As an AD and PKI guy, I find the conclusion suspect. Chain verification has nothing to do with NTLM. Certs and CRLs (AIAs and CDP) should be over HTTP and use anonymous auth. It could be that you have a home grown PKI that is misconfigured and the AIA or CDP is requesting auth. I'd love to see the wireshark capture...

markgamache
  • 436
  • 2
  • 6
  • Thanks a lot for your prompted reply. The Wireshark capture screen capture [link](https://dl.dropboxusercontent.com/u/99098699/WireSharkCapture.png) – MYB Nov 22 '16 at 04:27
0

Check your certificate properties. It probably has an ldap:// based Authority Information Access or CRL Distribution Point endpoint registered, which are registered in the cert properties by Windows Certificate Services (by default... when it's the CA and it's domain-attached).

The LDAP endpoint means (for Windows) "in Active Directory", so it's trying to access AD to download the data. When that fails it moves on to the second entry, which is probably http://. (And even if it isn't listed first, it's possible that Windows prefers LDAP to HTTP)

[1]CRL Distribution Point
 Distribution Point Name:
      Full Name:
           URL=ldap:///CN=Our%20Corp%20CA,CN=CRL,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=ourcorp,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
           URL=http://corppki/crl/Our%20Corp%20CA.crl
           URL=http://crl.ourcorp.com/crl/Our%20Corp%20CA.crl
bartonjs
  • 30,352
  • 2
  • 71
  • 111
  • Thanks a lot for your reply. We really want to skip the first try "in Active Directory". Is there any way to skip this step which can help to avoid the "try" in the hosting windows server? Like set the firewall in the host machine to block the NTLM requests sent from the service with name specified, change registry. etc. – MYB Nov 22 '16 at 04:42