Extest accounts logt in met Aextest

Na de SCOM implementatie van een klant werd ik aangesproken op het feit waarom er een groot aantal keren met het account Aextest wordt ingelogd via de Exchange 2010 Client Access servers. Deze events werden gegenereerd op de CAS servers en het Security pakket monitoorde de Domain Controllers waarop de requesten binnen kwamen.

Voor mij zelf vond ik al snel het volgende KB artikel waar uit blijkt dat dit “as designed” is. Nu nam de betreffende Security Officer hier geen genoegen mee en wilde dit verder uitgezocht hebben.

Dus hebben we een case bij Microsoft hiervoor geopend. Tijdens het onderzoek bleek dat de test Test-OutlookConnectivity dit veroorzaakte:

It was good to talk to you. As discussed the reason that the 4625 audit event is logged is down to an internal checking function in the TestOutlookConnectivity cmdlet that uses an invalid account (in this case the extest_guid account with an a appended to it) in order to determine the configuration of various virtual directories. This change was implemented to overcome a problem where customers had basic auth configured on the /RPC virtual directories and the mechanism used to detect the authentication type could result in the actual extest_guid account becoming locked, usually down to AD replication times. If the account gets locked out then monitoring ceases to function so this test was implemented in code to determine the available auth types on the vdirs (This is passed back during handshake when any account attempts to access the site) and prevent the possibility of the account becoming locked.
I’m afraid I don’t believe we would be able to change this as the impact on other customers could be very large so this would require an extremely strong business justification. As described in the article explaining this (http://support.microsoft.com/kb/2591305) these events can be safely ignored. There are two possible workarounds as has been discussed by previous engineers that include enabling the Outlook Anywhere feature of exchange or by disabling the rules that call the Test-OutlookConnectivity Exchange 2010 Powershell CMDLet. A list of these rules can be found here: http://technet.microsoft.com/en-us/library/ee758035(EXCHG.140).aspx. Disabling these rules will impact monitoring of these synthetic transactions only so I’d assume that any issue that is identified by a failed login would be alerted via a different monitor such as mailbox monitor or server monitoring so the impact of disabling the rules/monitors should not create a significant gap in the monitoring of the exchange environment but will reduce the overall effectiveness.


Met dit antwoord hoopte ik de case te mogen sluiten, echter nam de Security Officer hier nog geen genoegen mee. Hierna kreeg ik het volgende antwoord:

The addition of an ‘a’ to the account name simply prevents us logging in as that account and subsequently locking it out if AD replication is delayed. There is no link between that actual account (extest_guid) and the attempt to login using the aextest_ account other than the fact it gives us a reasonable confidence that an account with that name doesn’t already exist and we therefore don’t impact a real account. The exchange team could have achieved the exact same thing by arbitrarily deciding to use an account named jelle.balk and in almost every organisation it would have achieved the desired result which is to send a login request to the Web server using an account we expect to fail to log in so the web server provides us with various configuration settings (such as available auth types) as part of the login handshake that are required to deliver the required monitoring. Clearly in your organisation this would have caused your account to be locked out frequently.

The reason this problem existed in the first place is actually because the Exchange team ensure that there is no security risk created when using these cmdlets and the associated monitoring account as the password is changed frequently to a randomly generated strong password. If this password change is not replicated quickly enough the account can be locked when attempting to determine the auth methods available using an authenticated RPC ping.

Nu kon de case uiteindelijk worden gesloten. Hopelijk brengt dit verduidelijking in waarom er gebruik wordt gemaakt van (a)extest accounts.

Free subscription

You may also like...

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *