I've implemented the Always Encryption to encrypt the SSN field for Patient table in my Azure DB.(Using Azure Key Vault as my Key Store Provider)
I'm using SSMS 2016(13.0.16100.1) as Client Tool.
Initially I tried to execute the simple select statement for that particular Patient table.
It comes with the pop-up to Sign*(see below)*. So that i can sign-in with my account in order to decrypt my SSN column.
Here i experienced 2 types of cases:
Not able to logout from the current Credentials
Assume that for the first time itself i entered a valid credentials( who can have access to decrypt the key @ssn)
In this case, those credentials were saved somewhat internally. I couldn't able to logout from my credentials.
Initially i'm thinking that the credentials were saved on session based.So it will work only for that particular session.But it's not...
The same credentials will works for different sessions ,even I've tried with closing my SSMS and reopen in another windows still using the old credentials.
Not able to Re-enter the credentials
Assume that for the first time itself i signed with In-valid credentials( who doesn't have access to decrypt the key @ssn)
In this case, i couldn't able to decrypt the SSN column .So again the credentials where saved somewhat internally.
So if i want to re-enter with my valid credentials.I couldn't do it.
I think in order to solve the both CASES there will be a single solution=>LOGOUT FROM THE CURRENT CREDENTIAL
PS: I've know that we have another option that Login using Active Directory Password Authentication. But unfortunately this will be used only for Configured Active Directory Admin alone .But in my organization there are more than 100 members.So there is no way to give at least 10 members to use the Active Directory login
First, one clarifying comment: the above pop-up dialog is prompting you for credentials for Azure Key Vault (which is where you likely store a column master key for Always Encrypted, which protects data in your Patients table), not for database credentials. Database authentication (e.g. via Active Directory Password Authentication in the Connect to Server dialog) is independent from Azure Resource Manager (Azure Key Vault) authentication. Although you can use the same identity for database authentication and Azure RM, it does not have to be the case.
The issues you described will be addressed in SSMS 17.2, to be released soon, by allowing you to change Azure RM user identity at each authentication point. Also, in SSMS 17.2, the credentials/tokens will be bound to a process and it will not be persisted, so after a restart, SSMS will not remember them. Adding a "logout" control is on our roadmap, but we do not have a specific timeline for it yet.
One workaround to the issues you described, could be to start the Always Encrypted wizard (right client on any table and select Encrypt Columns) and click Change User (on the Column Master Key configuration page) and then click Cancel and cancel the wizard. That should invalidate the current creds in the cache and you query your table after that, the pop-up should open and you should be able to enter the new creds.
Thanks,
Jakub