I recently had to assist with setting up an Exchange Alternative Service Account (ASA) credential on an Exchange CAS array. We did get the ASA working properly however I have some questions about how ASA Credientials work under the hood.
The scenario is that we needed to enable an Exchange CAS array for Kerberos authentication. I'm familiar with Kerberos and know that in this situation you create a service account in Active Directory and associate any necessary SPNs to that serivce account and only that service account. At this point for most load balanced or clustered services you would then visit each node in the cluster and configure the service been load balanced to use the service account you created.
This is indeed what you do when configuring an Exchange CAS array for kerberos authentication. Microsoft provides a script called rollalternativeserviceaccountpassword.ps1 which automatically configures the services on all the members of the CAS array to use the service account you have created. Here is some documentation on this process
The script works and our array is using Kerberos, however the way the script deployed the service account seems very bizarre to me. After we ran the script I was expecting to see various Exchange services and application pools on the array members running as the service account, however they aren't. They are still running as other LocalSystem or NetworkService, not the service account name. My understanding of Kerberos tells me this can't work, but obviously it is.
I did some more research and found this article.
Which suggests that somehow or another the behaviour of the OS has been changed a bit so that LocalSystem and NetworkService will both be able to act like the service account as well as like LocalSystem and NetworkService. The relevant paragraph is in The Solution section. Other then this document there seems to be almost no information on how ASAs work under the hood.
Can anybody explain how this was done?