SQL Server Logins or Using Windows Impersonation

Connecting with a SQL Server database via Windows authentication requires a "SQL Server login" that allows the database platform to recognize the user and gives access to the ReliaSoft database. There are three ways that a user account may be recognized by SQL Server:

• Individual Login: The user has an individual SQL Server login that is associated directly with his/her Windows username.
• Group Login: The user belongs to an Active Directory group that has a SQL Server login shared by all members of the group.
• Use Impersonation for Connection File: The user does not have an individual or group login but he/she connects to the database with an enterprise connection file (*.rserp) that impersonates another Windows user account that does have a SQL Server login.

Your organization may choose to use any or all of these methods for your implementation (e.g., some users may have their own individual logins, while other users connect using Windows identity impersonation). This document provides an overview of all three options.

Option 1: Creating Individual SQL Server Logins

If you choose to create individual SQL Server logins for some or all of the user accounts, you have two options.

1. A database administrator for SQL Server can create SQL Server logins in advance for every potential user and give the logins access to the application database (at least the db_datareader and db_datawriter roles are required). This would be performed directly in SQL Server (not via one of the ReliaSoft applications).
2. A database administrator for SQL Server can grant the appropriate level of database authority for creating SQL Server logins and database roles (e.g., securityadmin or sysadmin) to any user who has the ability to create user accounts in the ReliaSoft database. The additional authority would be added directly in SQL Server. Then, when any of these administrative users creates a new user account via the ReliaSoft application, the required SQL Server login can be created and the application database roles can be assigned automatically at the same time.

If you are using the first approach, make sure the Create SQL Server login check box that is displayed when you are adding or importing a user account is not selected. If you are using the second approach, select this check box.

Tip: If the user already has a SQL Server login and access to the application database, it does not matter whether you select or clear the Create SQL Server login check box because the application attempts to create the login only if one does not already exist.

Furthermore, if the user who is creating the user account does not have the necessary level of database authority in SQL Server, the login will not be created even if the check box is selected.

Option 2: Using a Group Login

If the user belongs to an Active Directory group that has a SQL Server login shared by all members of the group and that group has access to the application database, you can clear the Create SQL Server login check box that is displayed when you are adding or importing a user account.

For example, base installations of Microsoft SQL Server Express include the "Builtin\Users" Active Directory group as a SQL Server login by default. This means all users with a Windows account for that domain will be able to log in to the enterprise database with no need to create individual SQL Server logins in SQL Server Express. However, it will still be necessary to grant access for this group login to the application database (at least the db_datareader and db_datawriter roles are required).

Option 3: Using Windows Impersonation for the Connection File 

If you choose to have some (or all) users connect to the SQL Server database with a connection file that impersonates a shared Windows user account that has a SQL Server login, you must do the following:

• A Windows network administrator must establish the shared user account on Windows.
• A database administrator for SQL Server must create a SQL Server login for the shared Windows user account and grant this login access to the application database (at least the db_datareader and db_datawriter roles are required).
• A user must create an enterprise database connection file that impersonates the shared Windows user account:
  1. Choose File > New then click Enterprise Database Connection File.
  2. Under Database Connection Settings, select Microsoft SQL Server (2014 or later) from the drop-down list and then select the Use impersonation check box.
  3. Enter the server and database name for the SQL Server database, then enter the domain, username and password for the shared Windows account that users will need to impersonate.
  4. Click OK to create the connection file (*.rserp). It will be stored in the location specified under Connection File Name. Note that the default filename will be "SQL_(Server Name)_(Database Name)," but you can assign any name that fits the process your organization will use for distributing the file to users. (Note that while the window shown next is for Weibull++, the settings are the same for all ReliaSoft applications.)

Once you have created a connection file that impersonates the shared Windows user account, you can distribute the file to any user who needs it. To connect to the database using this file, the user can:

1. Choose File > Open Database and browse for the connection file.
2. Click Open to connect with the database.

After the first connection, this *.rserp file will be saved in the list of recent databases, which can be accessed by choosing File > Recent.

Note: For the purpose of being recognized by SQL Server and accessing the application database, the user will be impersonating the shared Windows login. For the purpose of performing actions via the ReliaSoft applications, the user’s actions will be governed by his/her own user account in the ReliaSoft applications. In other words, multiple users can connect with the database using the same enterprise connection file, but their activities within the ReliaSoft applications will be governed by the permissions established in their own individual user accounts, and any changes made to the analysis data will be recorded in the application under their own usernames.