>> In the first section of this series,
you learned about network security,
the second aspect of secure
the Azure SQL as identity and access management.
So far when you've seen some demonstrations from Anna,
you've seen her in one of the portal,
deploy an Azure SQL Database and even set up network security.
What you might not have noticed is the fact
that she had access to Azure.
How would you get access to deploy an Azure SQL Database,
before you even get security to log into SQL Server.
Just like maybe in your data center where you've got
certain policy setup or
access controls to operating system methods,
there has to be a way to give people permission
to do various things in the Azure ecosystem.
We call that Azure Role Based Access Control or RBAC.
All Azure operations that you're doing to
deploy various resources are going to use RBAC.
It's a system based on specific permissions from subscriptions,
people that have subscriptions based on various roles.
For example, you have an owner of
a subscription or something called a contributor,
like in this particular case,
Anna was probably a contributor who had access and was given
permission to deploy Azure resources like Azure SQL.
Azure RBAC is separable from
the SQL security system that you would give
authentication rights to login to a SQL Server,
but it's going to give you-all those rights and access as
to control and manage Azure resources.
A separation of duties concepts from deploying and
managing Azure resources to the SQL server security system itself.
You can use the Azure portal or
CLI to go through and use RBAC type policies and systems.
Now what we've done for you,
instead of you creating specific roles for Azure SQL access,
we actually have some built-in roles.
You can be a SQL Database Contributor,
which is going to give you specific rights to deploy
Azure SQL Database or even a
Managed Instance Contributor to deploy Managed Instance.
We even have a SQL Security Manager role where
you do not have access to deploy things in Azure for Azure SQL,
but you have certain rights to audit access to things
going on in the Azure ecosystem for Azure SQL.
Once you get past that,
you get the traditional process and capabilities you need to learn
about authorization to do authentication into Azure SQL.
This is going to feel very familiar to you
and still very similar to SQL Server.
The very first thing you need to think of
is Mixed Mode authentication.
We talked a little bit about this in an earlier module.
Remember in SQL Server,
you have two types of modes;
you have Windows Authentication or
Integrated Security and SQL Authentication.
Because the fact that we require
a SQL Server login as an admin, and in fact,
when you deploy, you get what's called
a server admin is that SQL Authentication,
both for the logical server or for Managed Instance.
Mixed-mode is forced, it has to be.
In fact, this server admin that SQL is going to be
a server-level principal for
your logical server in Azure Database,
and it's going to be a member of
the sysadmin role for Managed Instance.
Now, you're saying to yourself,
"That's interesting, but I need Windows Authentication,
I need that Integrated Security
Authentication," and so we supply and allow you to do
Azure Active Directory Authentication
for administrators and for logins.
This is what it looks like for Managed Instance.
For Managed Instance, it
additions that SQL login, that's a sysadmin,
you can create an Azure Active Directory Server admin as well,
and that becomes a member of the sysadmin role.
You can addition can create
logins just like you're used to today with SQL Server for
SQL logins or Azure Active Directory
logins just like you would for Windows logins.
You then can go to process of creating
database users that are mapped to these logins.
We even support the concept like in
SQL Server of a SQL Server Contained Database system.
Now, what does this look like for Azure SQL database?
Well, very similar to MI,
you can create an Azure Active Directory
server admin that'll be just like
that SQL admin you created in
the beginning when you deploy an Azure SQL Database.
You also can create SQL logins,
but this is where it divergence a little bit.
We have special server admin roles
in the logical server that are going to
allow certain logins to manage logins
or to manage databases across your logical server.
Now, you could create
database users mapped to these logins as well in Azure Database,
but here's what we recommend;
we have the concept of Contained Database users
without creating a Contained Database,
and they could even be Azure Active Directory users.
Think about this scenario here,
you got capabilities for authentication,
just like you do in SQL Server,
but what you're going to end up using is
Azure Active Directory as an integrated type mode.
Now that you've seen what
the capabilities look like for authentication, what do you do?
Remember when you deploy,
you're going to choose your SQL Server admin.
But after you deploy,
you can actually add
an Azure Active Directory admin both for MI or Azure Database.
Then just like with SQL Server, what do you do?
Well, admins that you've
authenticated can now create other users, other logins.
Then once you're done with that process,
you grant access to SQL Server within this system
just like you would a SQL Server whether it's using roles,
whether that's granting specific authentication to objects,
to logins or to users.
Think about what we've talked about in
the concept of identity and access management.
You need Azure RBAC to get rights to do things with Azure.
Once you've got that down and deployed resources,
then you're going to use SQL Server authentication methods,
are slightly different in some cases with MI and Database,
including Azure Active Directory authentication.
Then it's going to feel just like a SQL Server.
It's going to grant that access to
the objects you need based on roles,
or based on logins that you've created,
or based on Database users.
I look forward to seeing you in the next video.