Need help to create a login for maintenance of a single database in a multiple databases, single instance environment

Question

Hi,
We are in the process of consolidating several databases on a single instance of SQL Server 2012.
Databases are developed by outside vendors; they have to be able to install and support their databases but they shouldn't be able to do any thing with the other databases.
When I tried to migrate the first database, the vendor told me that on the former server he used the sa account in some batch.
On a previous thread
https://social.technet.microsoft.com/Forums/sqlserver/en-US/dc1f802f-d8de-4e2b-87e5-ccb289593fb7/security-for-multiple-applications-on-a-single-sql-server-2012-instance?forum=sqlsecurity
it was suggested to me that I create a login for each vendor and that this login should map a user in their respective databases.
To test, I simulated the process in a test database:
1 - I create the login and I scripted the command:
USE [master]
GO
/* For security reasons the login is created disabled and with a random password. */
/****** Object:  Login [M02_Test]    Script Date: 2014-12-02 16:23:58 ******/
CREATE LOGIN [M02_Test] WITH PASSWORD=N'ÈS^y¡¶=Å€"+y¤j|úªhÖféÎЕœEu
c', DEFAULT_DATABASE=[M02], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
ALTER LOGIN [M02_Test] DISABLE
GO
2 - I create the user and scripted it
USE [M02]
GO
/****** Object:  User [M02_Test]    Script Date: 2014-12-02 16:29:41 ******/
CREATE USER [M02_Test] FOR LOGIN [M02_Test] WITH DEFAULT_SCHEMA=[dbo]
GO
Questions:
What should we do with te scrambled password: is it saved as it was entered and should it be kept somewhere in a safe place?
Would that do the job for the vendor who used sa before?
Thanks for your advice

Answer 1

I'm not sure why you would save the script. Why not create the login, in one way or another give the vendor the password. Keep the login disabled until needed.
I don't recall exactly what we said last time, but it occurs to me that the application setup things on server level. Jobs is the prime thing that comes to mind, but there could be other things.
Now, here is an important observation. As long as the vendor's application was alone on the server, that was OK, and it was OK to give the vendor sysadmin rights. In this situation this is less OK, and as we said, you should only give the vendor db_owner
in the database.
But the vendor will need to tell you what they do on server-level. They should know this - unless they sell their app as a "alone-on-a-server application". (And there are indeed such applications out there, even from Microsoft.) But there is a
risk that they will bill you extra if you make their installation more difficult.
Maybe you will have to give some vendors sysadmin for the installation, but in such case, you should ask them why they need it. If they don't, give them db_owner, and they will have to find out their hard way. (And you don't pay them for learning
their own application.)
Erland Sommarskog, SQL Server MVP, [email protected]