In the previous chapter, we solved the problem of customizing the listener address for Azure Storage Emulator, which is far from enough, because in our DEV/QA environment we have our own SQL Server Instance, and we need to build the ASE database into its own Instance.
First look at the results of AzureStorageEmulator.exe help init:
Uh, No-to-set SQL Server connection string. So it's necessary to use Windows authentication. There are several ways to use Windows authentication for different servers, one is to use NTLM authentication, which is simpler, both servers set up an identical account, the same password, and then a login to the account in SQL Server. The ASE then runs as this account, and when Init specifies instance, all the conditions are met.
It's comfortable to have AD, add a user on ad, and then SQL Server gives this account a login,ase run as this account, and everything OK.
But neither of these methods is what I want, because ... I'm going to run the ASE in a container. While running an ASE in a container and using Windows authentication, there is only one way, that is GMSA. So, to the PS Dafa (what?) Photoshop? No no No,powershell):
New-adserviceaccount-name asesvc-dnshostname Ase.contoso.com-principalsallowedtoretrievemanagedpassword [ASE-HOST $]-kerberosencryptiontype RC4, AES128, AES256
On the server running the ASE (ase-host):
Install-windowsfeature rsat-ad-powershellinstall-adserviceaccount asesvctest-adserviceaccount Asesvc
The output "True" indicates that GMSA is ready (for more information on creating GMSA, see my other post, "Using GMSA in Windows containers").
Next, add login in SQL Server:
OK, everything is ready, only the east wind, the next chapter, we are going to run the ASE in the container.
Running Azure Storage in Windows server Container Emulator (ii): Using a custom SQL Server Instance