The claims to windows token service account gets set to the shared service account (spservice) and the account also gets added to the local administrators.
This is not best practice, and also implies people should use the shared service account for claims to windows token service which has basically god powers from the "Act as part of the operating system" and "Impersonate a user after authentication" local security policies.
Attached is the changes where I created a secondary function called UpdateClaimsProcessIdentity, in the XML I created a managed account entry with the common name "ClaimsService"
```
<ManagedAccount CommonName="ClaimsService">
<Username>test\C2WTS</Username>
<Password>passjigger</Password>
</ManagedAccount>
```
As it stands today AutoSPInstaller is __introducing critical security flaws__ to installations when users set UpdateAccount = true on the claims to windows token service line.
```
<ClaimsToWindowsTokenService Start="true" UpdateAccount="true"/>
```
Comments: ** Comment from web user: brianlala **
This is not best practice, and also implies people should use the shared service account for claims to windows token service which has basically god powers from the "Act as part of the operating system" and "Impersonate a user after authentication" local security policies.
Attached is the changes where I created a secondary function called UpdateClaimsProcessIdentity, in the XML I created a managed account entry with the common name "ClaimsService"
```
<ManagedAccount CommonName="ClaimsService">
<Username>test\C2WTS</Username>
<Password>passjigger</Password>
</ManagedAccount>
```
As it stands today AutoSPInstaller is __introducing critical security flaws__ to installations when users set UpdateAccount = true on the claims to windows token service line.
```
<ClaimsToWindowsTokenService Start="true" UpdateAccount="true"/>
```
Comments: ** Comment from web user: brianlala **
I may look into allowing granular control of which service accounts get assigned to which services (as some folks have requested in the past), rather than having most of them just use the default SP_Services account. I'm just fearful that in the hands of an inexperienced SP person, this could mean a proliferation of app pools in a farm...
Brian