The short answer – this is by design. Slightly longer answer below.
The way MD5-DIGEST authentication works, it requires both server and client to exchange nonce numbers, then calculate MD5 of the username and password, then perform some calculations with this hash and nonces. In case of client everything is pretty straightforward as it has user-entered (or stored) plaintext password right there.
Fortunately, domain controllers don’t store plaintext passwords (unless you instruct them, which you should never ever do). The password hash stored by ActiveDirectory is a much stronger one than MD5 and direct comparison is impossible, so for DIGEST compatibility AD pre-calculates 29 MD5 hashes for all kinds of scenarios and stores them in WDIGEST_CREDENTIALS attribute. These include lowercase and uppercase variations of samAccountName, userPrincipalName and user passwords. But — no distinguished name. Obviously, for a domain controller there’s no way to deconstruct these hashes and extract the password portion – just like you can’t turn ground meat back into steak. Therefore ActiveDirectory has no point of comparison and inevitably will return authentication failure. Luckily, you will rarely hear about SASL and DIGEST nowadays as there’s way more secure and flexible Transport Layer Security (LDAPS).
