Course Intro and Overview
Azure Active Directory Authentication
Access within the Database
Summary
The course is part of this learning path
Authentication and access control are two crucial factors in securing databases and their servers. One, authentication, controls who can access the data resource, and in what capacity, while the other, access control, specifies what a user can do once they have been authenticated.
Historically, authentication and access have been managed entirely by SQL Server, but Azure has enabled integrated password and multi-factor authentication courtesy of Azure Active Directory, along with built-in SQL DB roles.
This course looks at various ways to integrate Azure SQL with Azure Active Directory and how to best manage user privileges once logged into the database.
If you have any feedback relating to this course, please contact us at support@cloudacademy.com.
Learning Objectives
- Get a basic understanding of the history and context of SQL authentication
- Understand how to to use Azure Active Directory to authenticate users with a SQL database
- Learn how to use database roles to customize access
- Understand the principle of least privilege and how to apply it
- Learn how to fine-tune access to database objects
Intended Audience
This course is intended for database administrators using Azure, or anyone who wants to understand more about using Azure Active Directory to authenticate a user to access a database.
Prerequisites
To get the most out of this course, you should have a basic understanding of databases and the Azure platform.
I want to begin with a little bit of history to give us some context of how Azure SQL database authentication is the way it is. Azure SQL has evolved out of SQL Server to become a platform as a service product. SQL Server was first released in 1989, so it predates the Internet as we know it today and also predates Active Directory, which was released 10 years later.
Even though SQL Server only ran on the Windows operating system, that is, it didn’t have to integrate with any other OS authentication mechanisms, it was still self-sufficient in terms of user authentication. Active Directory came along, and Windows authentication matured, but SQL Server and the applications connecting to it managed authentication separately.
For many organizations and systems, this process has remained unchanged. People need to authenticate with a domain when logging on to their computer and then log into an application or system with another username and password. This is bad enough from an individual user’s point of view, but when you multiply that by dozens, hundreds, or even thousands of users and then several applications, the process of managing and onboarding users becomes a bit of a chore. I think it’s safe to say that most of us have had the experience of starting a new job and spending way too much time sorting out logins to various systems.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.