REPUBLIC OF CAMEROON

Peace-Work-Fatherland

AFRICAN INSTITUDE OF COMPUTER SCIENCES

CENTER OF EXCELLENCE PRESIDENT PAUL BIYA

MANAGEMENT OF AUTHENTICATION AND AUTORIZATION

COMPILED BY

GROUP MEMBERS

EPAH FONZOCK MANYI

BILL NELSON
MANAGEMENT OF AUTHENTICATION AND AUTHORIZATION

1. Authentication of connection

There are two different authentication methods for connecting to SQL Server: Windows and
SQL Server.

Windows authentication requires a user to first authenticate to Windows with their login and
password. Once a user has been authenticated to Windows, they can then connect to SQL
Server using Windows authentication.

Figure 1: Authentication using SSMS

a. Setting up SQL Server to support different authentication modes

1|Page
When installing SQL Server, you have the choice to support only Windows authentication or both
authentication methods, which is known as mixed mode. During the installation process, you
decide whether or not to use mixed mode when defining the database engine configuration, as
shown in Figure 1.

Figure 2: Determining Authentication mode

Figure 2 shows that my instance supports mixed mode authentication because the radio button next
to the red arrow is enabled.

2|Page
 Another method to check which authentication modes are set up is to use TSQL code. The code in
Listing 1 displays the Authentication mode setup.

1SELECT CASE SERVERPROPERTY('IsIntegratedSecurityOnly')

2 WHEN 1 THEN 'Windows Authentication Only'
3 WHEN 0 THEN 'Windows and SQL Server Authentication'
4 END as [Authentication Mode] ;
b. Changing authentication methods After SQL Server is installed

There are times when you might want to change the authentication settings for a SQL Server
instance. This might occur if you used the default settings during installation to support Windows
authentication only and later acquired some software that can only connect using SQL Server
authentication. Or possibly you want to make your instance more secure by removing support for
SQL Server authentication. The authentication options can be easily changed using the properties
page in SSMS shown in Figure 2.

If I wanted to change my instances to support only Windows authentication, all I would need to
do is click on the “Windows authentication mode” button in Figure 2, and then click on the “OK”
button to apply that change. After making this property change, I would need to restart my instance
for this change to take effect.

2. Authorization of login accounts to access a database

To authorize access to database in SQL Server, one can grant permissions to users or roles.
Here are a few steps to do so:
a. Using SSMS (SQL Server Management Studio)
➢ Login to SSMS.
➢ In Object explorer, expand the database folder.

3|Page
Figure 3: Authorization using SSMS. Login
➢ Select the specific database you want to authorize access for.
➢ Navigate to security and users’ folders.

Figure 4: Navigation to users' folder

➢ Right click on the users to whom you want to grant or revoke permissions
➢ Choose properties

4|Page
Figure 5: Choosing permissions
➢ In the user mapping section, tick the checkboxes for the desired permissions
(e.g. SELECT, INSERT, UPDATE, DELETE etc.) for the user.
➢ Click on Ok to apply the changes.

Figure 6: Validating
b. Using Transact SQL
You can you the keyword “grant” to grant permissions directly. Follow the syntax
below:
GRANT <permission> TO <user> [with grant option] [AS <user>]
✓ <permission>: SELECT, UPDATE, DELETE etc.

5|Page
 ✓ <user>: User to which permission is granted.
✓ [with grant option]: Indicates that the user can also grant permissions to other
users.
✓ [AS <user>]: Specifies the user from which the executing role derives its right
to grant permissions.
In case you want to revoke permissions from a user:

Practical Example:

Figure 7: Granting permissions using transact-SQL

REVOKE <permission> ON TABLENAME TO <user>

Figure 8: Revoke permission of a user to a table using Transact-SQL

6|Page
One can equally revoke a user from accessing a particular database, to do that, you need to first
use the database in question and the write the command:
REVOKE CONNECT FROM username;
Example:

Figure 9: Revoking connection to a database from a user using transact-SQL

3. Authorization of users to access objects

a. Schema-Level Permissions:
In addition to object-level permissions, SQL Server allows granting permissions at the schema
level. A schema is a container that holds objects within a database. By granting permissions at the
schema level, you can provide access to all objects within that schema, reducing the need to grant
permissions individually.

b. Database-Level Permissions:
Database-level permissions apply to the entire database and are useful for managing high-level
access control. These permissions allow users or roles to perform actions across the entire database,
such as creating tables, views, stored procedures, or managing security settings.

c. Using Roles for Authorization:

7|Page
Roles provide a convenient way to manage permissions for multiple users or groups. Instead of
granting permissions individually to each user, you can assign permissions to roles and then add
users to those roles. This simplifies permission management and allows for easier role-based
access control.

d. Practical Examples:
Let's explore practical examples to illustrate the process of authorization in Microsoft SQL Server:

Example 1: Granting Object-Level Permissions:

Suppose we have a database named "SampleDB" with a table called "Employees". We want to
grant SELECT, INSERT, and UPDATE permissions to a user named "User1".

• Granting permissions:
USE SampleDB;
GRANT SELECT, INSERT, UPDATE ON Employees TO User1;

Example 2: Granting Schema-Level Permissions:

Assume we have a schema named "Sales" in the "SampleDB" database, containing multiple tables.
We want to grant SELECT and INSERT permissions to a user named "User2".
• Granting permissions:
USE SampleDB;
GRANT SELECT, INSERT ON SCHEMA::Sales TO User2;

Example 3: Granting Database-Level Permissions:

Suppose we want to grant CREATE PROCEDURE permission at the database level to a user
named "User3".
• Granting permissions:
USE SampleDB;
GRANT CREATE PROCEDURE TO User3;

Example 4: Using Roles for Authorization:

Let's create a role named "SalesTeam" and grant SELECT permission on the "Orders" table to the
role. We will then add users "User4" and "User5" to the "SalesTeam" role.
• Creating the role and granting permissions:
USE SampleDB;
CREATE ROLE SalesTeam;
GRANT SELECT ON Sales.Orders TO SalesTeam;

• Adding users to the role:

USE SampleDB;

8|Page
 EXEC sp_addrolemember 'SalesTeam', 'User4';
EXEC sp_addrolemember 'SalesTeam', 'User5';

Proper authorization is essential for maintaining a secure and well-controlled database

environment in Microsoft SQL Server. By granting permissions at the object, schema, or database
level and utilizing roles, you can ensure that users have appropriate access to the necessary
database objects while maintaining data security.
Remember to follow security best practices, regularly review and audit permissions, and stay
informed about the latest security updates and patches for SQL Server.
By implementing robust authorization practices, you can protect your data and maintain the
integrity of your SQL Server database.

ILLUSTRATION:

Figure 10: Authorization of users to access objects part1.

9|Page
Figure 11 Part 2 of authorization of users to access objects

4. Authorization between servers

Different methods and technologies available for managing authorization between servers
in SQL server environments

Managing authorization between SQL Server servers involves controlling access and
permissions for various entities.

1. Changing Ownership with ALTER AUTHORIZATION

• The ALTER AUTHORIZATION statement allows you to change the ownership of
different securable entities within SQL Server. These entities can include objects
like tables, views, stored procedures, and more

10 | P a g e
 • The syntax for ALTER AUTHORIZATION syntax varies based on the entity type
and context( SQL Server, SQL Database, Azure Synapse Analytics, or Parallel Data
Warehouse).
So down is the command used to change the ownership of a database in the SQL
server, so this is the syntax in the SQL server;

ALTER AUTHORIZATION ON [class_type::] entity_name TO {

principal_name | SCHEMA OWNER };
<class_type> represents the type of securable (e.g., OBJECT, ASSEMBLY,
DATABASE).
entity_name refers to the specific entity (e.g., table, view, schema).

use master;
-- created the login at the server level
CREATE LOGIN NewLogin1 with password = N'passw0rd' must_change, check_expiration = on,
check_policy=off;
use SE3;
-- creating the user at the database level

CREATE USER DONFACK for login NewLogin1

-- Now we need to add the user to the 'db_owner' role to have the required permissions
ALTER ROLE db_owner ADD MEMBER DONFACK;

USE master;

ALTER AUTHORIZATION ON DATABASE::SE3 TO guest;

SELECT name, type_desc

FROM sys.server_principals;

SELECT name AS DatabaseName, owner_sid, SUSER_SNAME(owner_sid) AS OwnerName

FROM sys.databases
WHERE name = N'SE3';

SELECT name, type_desc, authentication_type_desc

FROM sys.database_principals
WHERE name = 'DONFACK';

SELECT name, type_desc

FROM sys.server_principals

11 | P a g e
WHERE name = 'NewLogin';

SELECT dp.name AS UserName,

sp.name AS LoginName,
dp.sid AS UserSID,
sp.sid AS LoginSID
FROM sys.database_principals dp
JOIN sys.server_principals sp ON dp.sid = sp.sid
WHERE dp.name = 'superUser1';

SELECT dp.name AS RoleName

FROM sys.database_role_members drm
JOIN sys.database_principals dp ON drm.role_principal_id = dp.principal_id
WHERE drm.member_principal_id = USER_ID('DONFACK');

SELECT permission_name, state_desc

FROM sys.database_permissions
WHERE grantee_principal_id = USER_ID('DONFACK');

SELECT ORIGINAL_LOGIN() AS [ExecutingUser];

SELECT SUSER_NAME() AS [CurrentUser];

SELECT r.name AS role_name, p.name AS principal_name

FROM sys.server_role_members m
JOIN sys.server_principals r ON m.role_principal_id = r.principal_id
JOIN sys.server_principals p ON m.member_principal_id = p.principal_id
WHERE p.name = 'DESKTOP-C12MAOV\CHRISTIAN';

12 | P a g e
Figure 12: Changing ownership of Database

Figure 13: Selection

13 | P a g e
Figure 14: Authorization between servers

Here we have a database called SE3, which has as owner 'DESKTOP-C12MAOV\CHRISTIAN

and we want to change the owner with another principal called FosLogin but to do it we need first
to create a login at the server level ( in the master database) and create an associated user in the
database level (SE3 database) and assign the login to the user created

NB: to change the ownership of the database use the login instead of a user to be able to change
the ownership

Figure 15: Using Login to change ownership

5. Permissions of users to access code

14 | P a g e
User permissions, part of the overall user management process, are access granted to users to
specific resources such as files, applications, networks, or devices. A user permission can also
specify the type of access—for example, a user might be allowed to read data without modifying
it (read only) or be allowed to read and write data, specific functions a user can access—for
example, most systems have an administrator role that allows users to change configuration or
assign permissions to other users.
User permission is tightly related to two concepts that are Authentication and Authorization. User
authentication involves verifying a user’s identity before allowing them to access a system or
application. Authentication requires the user to prove their identity using one or more
authentication factors. These factors can include things the user has (for example, a digital
signature, ID, security token), information the user knows (such as a password or PIN) and the
user’s biological characteristics (such as fingerprint, voice, or retina scan).
User authorization is the process of determining which resources users are allowed to access. For
example, users in a website content management system (CMS) can be assigned permissions to
comment on articles (guest), author and edit articles (contributor), and change website look and
feel and configuration (administrator). Authorization can also segment content in an application
and allow each user to access content that is relevant to them.
Steps to follow in other to grants permissions to users
*Step 1: Connect to SQL Server
Open SQL Server Management Studio (SSMS) and connect to your SQL Server instance.
*Step 2: Create a Code Object
For illustration purposes, let's create a stored procedure as a code object. Execute the following
SQL script to create a sample stored procedure:
sql
USE YourDatabaseName; (Replace with your database name)
CREATE PROCEDURE dbo.GetCustomer
AS
BEGIN
SELECT * FROM Customers;
END
This script creates a stored procedure named GetCustomer in the dbo schema.
*Step 3: Create a User

15 | P a g e
Next, you need to create a user who will be granted permission to access the code object. Execute
the following SQL script to create a user:
sql
USE YourDatabaseName; (Replace with your database name)
CREATE USER YourUserName ; (Replace with your desired username)
FOR LOGIN YourLoginName; (Replace with your Windows login or SQL Server login name)
Ensure that you replace YourDatabaseName, YourUserName, and YourLoginName with your own
values.
*Step 4: Grant Permissions
Now, you can grant permissions to the user for accessing the code object. Use the GRANT
EXECUTE statement to grant execute permission on the stored procedure. Execute the following
script:
sql
USE YourDatabaseName; -- Replace with your database name
GRANT EXECUTE ON dbo.GetCustomer TO YourUserName; (Replace with your username)
This script grants the EXECUTE permission on the dbo.GetCustomer stored procedure to the user
YourUserName.
*Step 5: Test the Permissions
To verify that the user has been granted permission to access the code object, you can test it by
executing the stored procedure using the user's login. Execute the following script:
sql
USE YourDatabaseName; -- Replace with your database name
EXECUTE AS LOGIN = 'YourLoginName'; (Replace with your Windows login or SQL Server
login name)
EXEC dbo.GetCustomer; (Execute the stored procedure)
REVERT; (Revert back to the original login context)
Replace YourDatabaseName and YourLoginName with your own values.
If the user has been granted the necessary permissions, the stored procedure will execute
successfully.
That's it You have successfully granted permissions to a user for accessing a code object in SQL
Server. You can follow similar steps to grant permissions for other code objects like functions,
views, and triggers.

16 | P a g e
1. Permission Types:
- EXECUTE: Grants permission to execute a stored procedure, function, or trigger.
- VIEW DEFINITION: Grants permission to view the definition of a code object (e.g., stored
procedure, function, view).
2. Granting Permissions to Roles:
- Instead of granting permissions individually to each user, you can assign users to roles and
grant permissions to those roles. Then, add or remove users from the roles as needed. Example:
sql
USE YourDatabaseName;
CREATE ROLE YourRoleName;
GRANT EXECUTE ON dbo.GetCustomer TO YourRoleName;
EXEC sp_addrolemember 'YourRoleName', 'YourUserName';
3. Revoking Permissions:
- If you need to revoke previously granted permissions, you can use the REVOKE statement.
Example:
sql
USE YourDatabaseName;
REVOKE EXECUTE ON dbo.GetCustomer TO YourUserName;
4. Server-Level Permissions:
- In addition to database-level permissions, SQL Server has server-level permissions that apply
across all databases on the server.
- Examples include CREATE PROCEDURE, ALTER ANY PROCEDURE, VIEW ANY
DEFINITION, etc.
- Server-level permissions are managed separately from database-level permissions.
Remember to adjust the script examples to match your specific database, code objects, usernames,
and role names.
ILLUSTRATIONS

17 | P a g e
Figure 16: Grant permission

Figure 17:Creating user from login

18 | P a g e
Figure 18: Execution

Figure 19: Grant execute permission to users

19 | P a g e
Figure 20Execution 2

Figure 21: Creating procedure

20 | P a g e
NOTE: Authentication checks whether a user has the permission to login while authorization
specifies what actions they can perform once connected.

Login is created at an instance level; user is created at the database level.

21 | P a g e