Deep-Dive into Outlook Autodiscover: How Clients Locate, Authenticate, and Connect to Exchange in Domain and Non-Domain-Joined Devices and How to Defend Against Password Spray Attacks

Before the Disaster Begins

Microsoft Exchange Autodiscover Explained

Autodiscover, a service introduced in Microsoft Exchange 2007, is designed to allow Outlook and other email clients to automatically locate and configure a user's mailbox with minimal manual input, By providing only an email address and password, the client queries the Autodiscover endpoint and receives necessary mailbox settings such as server URLs and locations in XML format.

This XML is the Autodiscover response from an Exchange server, telling Outlook where and how to connect to a user’s mailbox. It lists the user’s display name, email, and server settings like URLs for mail, calendar, and other services. Outlook reads this automatically so the user doesn’t have to manually enter server or protocol details.

Autodiscover XML Response Example

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response>
    <User>
      <DisplayName>Jane Doe</DisplayName>
      <Mailbox>jane.doe@contoso.com</Mailbox>
    </User>
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <Protocol>
        <Type>EXCH</Type>
        <Server>MAIL.contoso.com</Server>
        <ServerDn>/o=Contoso/ou=Exchange Administrative Group...</ServerDn>
        <ProtocolCfgFlags>0x0001</ProtocolCfgFlags>
        <AuthPackage>Ntlm</AuthPackage>
        <ASUrl>https://mail.contoso.com/EWS/Exchange.asmx</ASUrl>
        <OOFUrl>https://mail.contoso.com/EWS/Exchange.asmx</OOFUrl>
        <UMUrl>https://mail.contoso.com/EWS/UM/Services.asmx</UMUrl>
        <EwsUrl>https://mail.contoso.com/EWS/Exchange.asmx</EwsUrl>
        <EcpUrl>https://mail.contoso.com/ecp/?p=Customize/PersonalSettings.aspx</EcpUrl>
        <EcpUrl-OwaOptions>https://mail.contoso.com/ecp/Customize/PersonalSettings.aspx</EcpUrl-OwaOptions>
      </Protocol>
      <Protocol>
        <Type>WEB</Type>
        <InternalUrl>https://mail.contoso.com/owa/</InternalUrl>
        <ExternalUrl>https://mail.contoso.com/owa/</ExternalUrl>
      </Protocol>
    </Account>
  </Response>
</Autodiscover>

Here is a common example of the XML structure returned by the Autodiscover service for an Exchange account configuration, This XML provides Outlook with user details (DisplayName = Jane Doe, Mailbox = jane.doe@contoso.com) and account info (AccountType = email, Action = settings).

It also lists protocol settings like Exchange server (Server = MAIL.contoso.com), and authentication (AuthPackage = NTLM). Outlook uses this data to automatically configure the account, select the right protocol, authenticate, and connect to the mailbox and services without manual input.

SCP Usage on Domain Joined Machines

Service Connection Point (SCP) Explained

Now let’s look at another important feature called SCP. The Service Connection Point (SCP) is an object in Active Directory that holds information about network services, such as Exchange Autodiscover URLs. Outlook clients on domain-joined machines query the SCP first to automatically locate the correct Autodiscover URL. This allows clients to discover server settings without manual input, with the SCP essentially serving as a directory-based guide to the proper service endpoints.

SCP request and response works

A domain-joined Outlook client searches Active Directory for an SCP object with the serviceBindingInformation attribute that contains the Autodiscover URL for the user’s domain, then The SCP object contains the Autodiscover URL.

// LDAP Query: 
BaseDN: CN=Services,CN=Configuration,DC=contoso,DC=com
Filter: (objectClass=serviceConnectionPoint)
Retrieve: serviceBindingInformation

// LDAP Response: 
serviceBindingInformation: https://mail.contoso.com/autodiscover/autodiscover.xml

Outlook uses this URL to make an HTTP/HTTPS Autodiscover request to the Exchange server, which returns the full Autodiscover XML with mailbox settings

Using SRV Records for Non Domain-Joined Devices

SRV Record

An SRV (service) record is a type of DNS resource record that is distinguished from other records because it also includes a port number, It's used for service discovery, meaning it tells a client application exactly where a specific service is located, including the hostname and the port on which it is running

The Exchange Autodiscover SRV record tells Outlook clients to use the HTTPS protocol (port 443) for automatic configuration. Outlook searches for the service name _autodiscover over the TCP protocol (_tcp) and is directed to the target hostname, Using a Priority of 0 and Weight of 0 means this is the primary and only configured server for this service.

The Priority number tells the client which server to try first, the lowest number is always the primary option, and the server with the next highest number is the backup (failover). If two or more servers have the exact same Priority, the Weight value is used to decide how to split the connections between them, where a higher weight means that server handles a bigger share of the traffic (load balancing).

Autodiscover.xml, SCP and SRV Recap

The Complete Autodiscover and Outlook Connection Journey

Stepping Into Outlook

When a user opens Outlook on their device, the application starts by asking for the email address to identify the mailbox the user wants to access. For initial configuration, the password is always required. Outlook uses this information to begin the process of automatically configuring the mailbox without manual intervention.

Hunting the Autodiscover URL

To locate the correct server settings, Outlook needs to determine the Autodiscover URL. This service provides automatic configuration for email clients. If the device is joined to a Windows domain, Outlook first queries the Service Connection Point (SCP) in Active Directory, which stores the Autodiscover URL for the domain.

If the SCP is not available, Outlook attempts standard URLs based on the user's domain, such as https://autodiscover.domain.com/autodiscover/autodiscover.xml or https://domain.com/autodiscover/autodiscover.xml. If these URLs fail, Outlook can also check the DNS SRV record _autodiscover._tcp.domain.com to locate the Autodiscover server.

Securing the Line

Once Outlook has determined the Autodiscover URL, it initiates an HTTPS POST request to the server, sending an XML request that includes the user's email address and requests the mailbox configuration. Using HTTPS means that this communication is encrypted using TLS (Transport Layer Security), which protects the data from eavesdropping or tampering as it travels across the network.

Before any sensitive information, is exchanged, Outlook and the server perform the TLS handshake, a multi-step process where both sides agree on encryption protocols, exchange cryptographic keys, and authenticate the server's identity using its digital certificate.

During the TLS handshake, the server presents its TLS certificate, which contains details such as the server's domain name, the public key, and the certificate authority (CA) that issued it. Outlook validates this certificate by checking that it is issued by a trusted CA, matches the requested server domain, and is still within its validity period. Only after successful validation does Outlook establish a secure encrypted channel. This ensures that any XML data sent in the POST request, including the user's email address, cannot be intercepted or modified by attackers.

To request this information, Outlook constructs an XML request following the Autodiscover schema. This XML contains the user's email address and tells the server what kind of response format the client can handle.

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
    <Request>
        <EMailAddress>user@example.com</EMailAddress>
        <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
    </Request>
</Autodiscover>

The server processes the XML request and can respond in several ways. It may immediately return an XML document containing the mailbox configuration, or it might issue an HTTP 302 redirect, directing Outlook to a different Autodiscover URL. If authentication is required, the server can respond with an HTTP 401 Unauthorized status. Once authentication succeeds, the server provides the XML document with the full mailbox settings, which Outlook parses to automatically configure the account.

Domain‑Joined Devices, Autodiscover & Kerberos in Action

For authentication, the client can use Kerberos, because it has access to the domain. The Outlook client requests a service ticket from Active Directory's Key Distribution Center (KDC) specifically for the Exchange service. Active Directory issues the ticket, which the client then presents to the Exchange server. The server validates the ticket, confirming the user's identity without the need to type a password again. If Kerberos is unavailable, Outlook may fall back to NTLM, which involves a challenge-response exchange with the server.

Non‑Domain Devices, Autodiscover, Kerberos Magic

When Outlook runs on a non-domain-joined device (such as personal phones or external devices), it cannot use Kerberos because there is no trust relationship with Active Directory. Since the client cannot request Kerberos tickets, the Exchange server uses multi authentication method based on what is enabled.

If Basic authentication is used, Outlook sends the username and password encoded in Base64 over TLS, which exposes credentials more directly.

If NTLM is enabled, Exchange issues a challenge to the client. The Outlook client then computes a cryptographic hash of the password combined with the server challenge and sends this hash as the response. Specifically, the client uses the password hash along with the server’s challenge to compute the NTLM response. This response proves to Exchange that the client knows the correct password without ever sending the actual password, making NTLM more secure than Basic authentication.

Although Exchange receives the NTLM challenge-response, it cannot validate it locally because it does not store user password hashes. To verify whether the user’s password is correct, Exchange switches protocols entirely instead of validating NTLM, it constructs a Kerberos AS-REQ containing pre-authentication data that is derived from the NTLM response. This AS-REQ is sent to Active Directory, and AD does not verify the NTLM challenge itself in fact, it never even sees it. AD simply takes the user’s stored password hash and tries to decrypt the Kerberos pre-authentication timestamp included in the AS-REQ. If decryption fails, AD logs event 4771 for a pre-authentication failure, AD logs event 4768 for a TGT request. Because AD never processes or validates the original NTLM challenge, the NTLM challenge-response matching becomes irrelevant, and the validation relies solely on Kerberos pre-authentication, not NTLM.

Successful Authentication

Once the credentials are successfully validated, the Exchange server returns the Autodiscover XML containing the full mailbox configuration. Outlook parses this XML and automatically sets up the mailbox. This allows the user to access emails, calendars, and other mailbox features securely, even on devices that are not domain-joined, while Exchange leverages its Kerberos relationship with AD to validate credentials without requiring the client to participate in Kerberos.

How Attackers Leverage the Autodiscover Feature

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/10.0
request-id: ****-****-****-****-************
X-SOAP-Enabled: True
X-WSSecurity-Enabled: True
X-WSSecurity-For: None
X-OAuth-Enabled: True
X-OWA-Version: **redacted**
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-FEServer: <REDACTED-EXCHANGE-SERVER>
Strict-Transport-Security: max-age=31536000; includeSubDomains
WWW-Authenticate: Basic realm="autodiscover.<REDACTED-DOMAIN>"
Date: **REDACTED**
Content-Length: 0

Imagine an attacker has a valid or guessed username and password. Because Autodiscover is a public HTTPS service, the attacker can access the Autodiscover URL just like a normal Outlook client would. If the organization still allows Basic, or other legacy authentication, the attacker can attempt to log in using those credentials. After a successful login, the attacker receives the Autodiscover XML, which does not contain emails but confirms that the credentials are valid and reveals all the Exchange service endpoints needed to proceed.

Once the attacker verifies the credentials work, they can use Outlook, scripts, or legacy protocols to sign in and fully access the user’s mailbox. Without MFA, the username and password alone are sufficient for complete mailbox compromise.

When Autodiscover receives NTLM credentials from the attacker, Exchange cannot validate the challenge-response locally, so it forwards the authentication attempt to Active Directory by converting the NTLM proof into a Kerberos AS-REQ containing pre-authentication data. Active Directory then attempts to decrypt the Kerberos pre-authentication timestamp using the user’s stored password hash. If the password is incorrect, the decryption fails immediately, and AD returns an error instead of issuing a valid TGT. This generates event 4768 for the TGT request and event 4771 for the pre-authentication failure. No TGT ever reaches Exchange because AD never creates one.

Simulated NTLM to Kerberos Authentication Flow Logs

The table simulates an NTLM to Kerberos authentication logs flow Generated based on AI tools. Each user initiates a login through Exchange, which submits a TGT request (event 4768) to Active Directory using a Kerberos pre-authentication timestamp derived from the NTLM response. Active Directory then attempts to validate the timestamp, generating a pre-authentication success or failure event (4771), depending on whether the NTLM derived data matches the user’s stored password hash.

Kerberos Grants TGT Issued

Event ID: 4768
Event Source: Microsoft-Windows-Security-Auditing
Log Type: Security

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:     john.doe
    Supplied Realm:   CONTOSO.LOCAL
    User ID:          CONTOSO\john.doe

Service Information:
    Service Name:     EXCHANGE$
    Service ID:       S-1-5-20

Network Information:
    Client Address:   ::1
    Client Port:      0

Additional Information:
    Ticket Encryption Type: 0x12
    Pre-Authentication Type: 2

Result: 
    Success (0x0)

Client Address: ::1 or 127.0.0.1 or even the Exchange server IP is because Exchange performs Kerberos on behalf of the external attacker, as for Event ID 4768 in Windows security logs indicates a Kerberos Ticket Granting Ticket (TGT) was requested. It is triggered on domain controllers and is crucial for auditing the initial logon process, with a successful request showing a result code of 0x0.

Kerberos Rejects the Key

Event ID: 4771
Event Source: Microsoft-Windows-Security-Auditing
Log Type: Security

Kerberos pre-authentication failed.

Account Information:
    Account Name:       john.doe
    User ID:            CONTOSO\john.doe

Service Information:
    Service Name:       EXCHANGE$
    Service ID:         S-1-5-20

Network Information:
    Client Address:     ::1
    Client Port:        0

Additional Information:
    Failure Code:       0x18 (Pre-authentication failed)
    Ticket Encryption:  0x12

Result:
    Kerberos Authentication Failed

This 4771 event shows that Kerberos pre‑authentication failed because the supplied password was incorrect (failure code 0x18). The request appears to come from EXCHANGE$ because the attacker is authenticating through Autodiscover, and Exchange forwards the authentication to AD on the attacker’s behalf. Since the password is wrong, AD rejects the attempt and logs this failure. When many 4771 failures appear for multiple users at regular intervals, it strongly indicates a password spray attack.

Security Recommendations for On-Premises Autodiscover and Exchange Environment

In an on-premises Active Directory and Exchange environment where external Outlook users require Autodiscover access and you cannot fully block the endpoint from browsers, the best way to prevent attackers from performing password spray attacks is to enforce strong authentication controls and limit attack surfaces.

First, disable Basic authentication on the Autodiscover and rely on NTLM or Kerberos over TLS to prevent credential submission. Second, implement account lockout policies with thresholds that balance security and usability to stop rapid repeated login attempts.

Third, use a reverse proxy or WAF to filter traffic, blocking requests with browser user-agents while allowing Outlook clients, and apply rate-limiting to slow automated attacks. Fourth, require external users to connect via a corporate VPN, ensuring Autodiscover is accessible only when the VPN is active, which prevents direct browser access from the internet.

Fifth, monitor IIS and Exchange authentication logs for abnormal patterns, failed login bursts, and impossible travel events to detect attempted attacks. Sixth, ensure TLS 1.2/1.3 with strong ciphers is enforced to prevent interception of credentials.

Seventh, Consider implementing MFA, and keep the Exchange and AD environment patched and hardened, removing unused authentication methods and Lastly, encourage users to create long passphrase style passwords, which are far harder to guess or crack compared to short, traditional passwords.

Supporting References

o365devx Autodiscover for Exchange

AshaIyengar21 Autodiscover service in Exchange Server

Tony Teaches Tech What is SRV in DNS? (service record)