ISABELLA LUBIN: Hi.
Today we're going to be talking about how you can centralize
authentication for Cloud SQL, for SQL Server,
using a service called Managed Microsoft Active Directory.
We're going to cover three topics today.
First, we're going to talk about why now is the time
to move your databases over to Cloud SQL for SQL Server, which
is a managed database service.
We're going to talk about a service called
Managed Microsoft Active Directory which integrates
with Cloud SQL to allow you to authenticate to Cloud SQL using
Windows authentication.
And then finally, we're going to demo
how these two services work together
to create a seamless authentication experience.
First, a little bit about us.
My name is Isabella Lubin, and I'm a Product Manager here
at Google Cloud focused on Cloud SQL for SQL Server.
MUTHURAJ THANGAVEL: My name is Muthu.
I'm here a Product Manager for Managed AD.
ASHRITH PRABHU: Hi, I'm Ashrith.
And I'm a software engineer working
on Managed AD on Google Cloud.
ISABELLA LUBIN: So first, let's talk
about Cloud SQL for SQL Server.
SQL for SQL Server is a fully managed database service.
It makes it really easy for you to run your databases here
in Google Cloud with a seamless setup, maintenance,
and administration experience.
Cloud SQL allows you to lift and shift SQL Server.
Because it's a fully compatible service,
it works easily with Microsoft SQL Server, and with the tools
that you're already leveraging, to manage
SQL Server-- including SQL Server Management Studio.
But at the same time, it's a fully managed service.
So a lot of the pain and toil that you
have to have right now for handling backups, replication,
patches, and updates, Cloud SQL handles that for you.
So while it's a compatible service,
we're going to handle the maintenance that takes away
a lot of the time that your database administrators are
spending.
And furthermore, we build reliability and availability
into the service.
So those features that you need for high availability are
really, really easy for you to set up and leverage.
Now, a lot of our customers worry
that moving to a managed service means that they're giving away
a lot of the control that they previously had on premises.
Cloud SQL for SQL Server gives you
a lot of flexible configuration options
so that even though it's a managed service,
you get to decide how your SQL Server will work.
For example, we support instances of up to 96 vCPUs
with 624 gigabytes of RAM and a 64 terabyte SSD.
There are a lot of automations that you can enable right
when you create your Cloud SQL instance so you can ensure
that storage is automatically increased,
so that as your database grows, your instance grows as well.
You can enable automated backups by default.
And those backups will take place
on a daily basis at a time that you designate,
so you can always have a copy of your database in case
you need to go back.
If you need more frequent backups,
you can also take backups on-demand.
High availability, as I mentioned before,
is built into the service.
If you need high availability, you
can select Regional Availability and a replica
of your primary instance is going
to be created in another zone.
If a disaster occurs, and for some reason
that primary instance is no longer available,
Cloud SQL will automatically failover
to that secondary instance, ensuring that your application
remains up.
And finally, you have a lot of control over the maintenance
day and time, when Cloud SQL is going
to perform those maintenance events,
so that you can ensure that when maintenance actually happens
it doesn't disrupt your application or your users.
We're continually building new features
into Cloud SQL for SQL Server.
And I want to highlight just a few of the ones here.
First of all, as I said before, we're constantly
trying to ensure that maintenance
is minimally disruptive to your users and to your application.
So we're continually shortening the maintenance event duration
and giving you more and more controls over
when that maintenance event is going to happen--
and the ability to defer or set deny periods
on that maintenance event when you
have a critical period for your application,
where it can't take a maintenance event.
Additionally, we're building more and more
self-service controls for you, so
that you can ensure that your Cloud SQL instance works
the way that you want it to.
For example, we just released cross-region read replicas.
Cross-region read replicas allows
you to scale out your Cloud SQL instance with replicas
either in the same region or in other regions,
so that you can serve reads from instances
other than the primary, and offload
some of those read workloads.
But you can also promote those read replicas.
So in a disaster, you can create a replica
to be in another region, and you can go and promote that replica
to be its own standalone instance.
A lot of releases have been coming in the last year.
And we're really just getting started.
More and more are coming with every month.
Now, we know that authentication is critical.
And while a lot of our customers are using SQL Server
authentication, a lot of our customers
are also using Windows Authentication,
which is a mechanism that they may
have been using on premises.
Cloud SQL for SQL Server enables Windows Authentication
through a service called Managed Microsoft Active Directory,
which is another fully managed service
that lets you run Active Directory here on Google Cloud.
And to share a little bit more about Managed Microsoft Active
Directory, I want to hand it over to Muthu.
MUTHURAJ THANGAVEL: Thank you, Isabella.
Let's now look at the Managed AD Service.
Just like Cloud SQL, this is, again,
a highly available managed service
that means just normal management for you [INAUDIBLE]
or do your planning overheads.
This is just 100% Microsoft AD, Active Directory,
running on Cloud, which you can use
to support your idea of ad workloads running here
on Google Cloud.
You can extend your on-premises domain just
using Cross Forest Trust.
That means your users can now seamlessly sign
into Windows workloads that you have deployed in Google Cloud.
You can also extend to any region
that you would wish to, very simply, just by selecting
the region as well.
And hence, it's a multimedia and resilient deployment as well.
This is an area where we are continuing to invest.
And here are some of the recent releases
that we had in the last year--
of course, the highlight being the Cross-Project SQL Server,
where we have the--
now the SQL server customers can actually
enable Windows authentication using
a domain that is located in a different project as well.
The underlying foundation for it is the domain pairing,
which is also [INAUDIBLE] so that Managed AD can also
be made available to other workloads running
on Cross-Projects or non-domain projects as well.
We already support automated backups
that happens every 12 hours.
But now we also have a feature to create on-demand backups.
This is now in the preview mode so
that you can create backups, also,
additionally when you need.
And you can restore when needed as well.
Managed AD support tags, which means applying policies
across multiple domains is now simplified.
And you can simultaneously do that for all the domains
that have the same text.
And with that, let me invite my colleague Ashrith
to walk us through the domain of how these two Managed
services come together seamlessly to give you
the power of Windows authentication.
ASHRITH PRABHU: Thanks, Muthu.
So in this demo today, we will be covering five steps.
The first step involves creating a Managed AD instance.
And then on an existing on-prem setup,
we will be creating a trust back to our Managed AD.
We will move on to create a Cloud SQL instance, which has--
with the Windows authentication enabled on the Manage AD.
And then we will create logins for the existing on-prem users
in the Cloud SQL.
And then finally, we will be logging
in using that on-prem users.
So the first step involved in creating a Managed AD
instance-- you go to the security home page
and then go to Managed AD.
Create a new AD domain.
Here, I'm going to be using a FQDN of demo.org and selecting
Cloud SQL test VPC on the domain.
So in this scenario, we have selected a normal VPC.
But you can always authorize the shared VPC,
and that opens to the advantages of shared VPC,
like the possibility of having SQL instances
on one of the service project.
I'm selecting the US-WEST1 region.
You can add multiple regions, too.
It typically takes about 60 minutes for the Managed AD
to be created.
You can track the creation of the AD in the top right,
as well as on the Managed AD page.
The domain is in unhealthy state right now because it's not yet
moved to the ready state.
So the domain is in ready state right now.
If you click on the domain, you will
find that one region has been added,
and the region is in healthy state.
The delegated admin which we created was setup admin.
You can copy the credentials of the setup admin
and make a note of it, which could
be used to log into those domain joint [? VMs. ?]
Moving on to the next step, we have an existing on-prem setup
with the name of onpremdomain.org.
I'm going to go ahead and create a trust with the newly
created Managed AD.
Creating this new trust gives me the option
of using the existing users and existing security groups
on my on-prem setup to authenticate to the SQL
instance.
I provide the FQDN of the Managed AD, which is demo.org.
I'm going to create a forest trust.
For this demo, I'm creating a bidirectional trust,
but you can always create a single direction.
While creating the trust, you make
a note of the trust handshake which has been created.
The trust will be created only from on-prem side.
From the Managed AD side, we will
be using the API provided from the Managed AD to create it.
So the trust creation has now completed.
You can verify that the trust has
been created by logging into the PowerShell
and then checking the get AD trust.
So this command will give you the output
of the domain on which the trust has been created.
And you can also see that this is a bidirectional trust.
And FQDN is demo.org with [INAUDIBLE]..
Now, we move on to create the trust from the Managed AD side.
We provide the on-prem domain name, which is onpremdemo.org.
And again, for this demo, we will be
creating a bidirecitonal trust.
But you can always create a one-way outbound trust.
We provide the trust handshake, as well as the DNS server
IPs for the on-prem.
The DNS server IPs, which has been provided,
will be added as the DNS conditional forwarders
in the Managed AD domain controllers.
Once the trust has been created, validating the trust always
helps you to avoid entering the password again.
As you can see, the trust has been created.
We always maintain a note of the trust created for a Managed AD
domain on the domain page.
And then the state of the trust is also tracked.
And, as you can see, it's in active state.
We wait for the trust to be validated.
And once the trust has been validated,
now we have created a connection between your on-prem
and your Managed AD.
Moving on to the SQL instance creation
with the Windows authentication, we're
going to create a new instance of SQL Server.
You provide the name of the instance
that you want to create.
The password which you provide here
will be used to create a default SQL Server user.
So the two important things which you have to keep in mind
is when you're creating a connection,
we have to select the private IP to enable the Windows
authentication.
When you select the private IP, you
will be given an option to select the VPC.
In this case, it has to be the VPC on which the Managed
AD was authorized.
In our case, it was Cloud SQL test.
For selecting the private IP, you
need to select the authentication.
In the authentication, it will list all the domains which
can be used to authenticate.
In our case, it's the demo.org.
We wait for the instance to be created.
In this scenario, the domain and the SQL instances
were on the same project.
But with the latest feature, you can always
authenticate a SQL instance with a Managed
AD in a different project.
You will also have to create a domain pairing
in that scenario.
Once the Cloud SQL instance has been created,
you can always check on the page that it
has been joined to the Active Directory,
demo.org If you click on the demo.org,
it takes you to the domain page.
And on the domain page, you can note that the Cloud SQL
integration starts showing up.
On the page of Cloud SQL, you can make a note of the ways
to connect with the Cloud SQL instance.
In our scenario, we are going to select the Cloud SQL proxy.
Along with that, you can also make
a note of the default user which has been created,
which is the Cloud SQL Server.
Make a note of the password, which
will be used to create the logins for the Windows users.
Moving on, we have a VM which has been domain-joined
to the Managed AD, demo.org, with the delegated admin
setupadmin.
We are going to open the Cloud Microsoft SQL Server
Management using on-prem user.
Creating the trust enabled us to use the on-prem user on a VM
which was domain-joined with Managed AD.
Before we do a Windows authentication using
the on-prem user, we have to create a login
on the SQL Server.
To create a login, you can use the proxy
which was displayed on the SQL instance page.
Select the sequence server authentication,
use the default user which was created,
and log in to the SQL instance.
Once you log in, you create a Windows sequence
of a login for on-prem user.
Once the login has been created, you
can go ahead and do a Windows authentication.
Let us try doing that.
The management tool was logged in using on-prem user,
as you can see here.
And once I select Windows authentication, this time,
I'll be able to authenticate into the SQL server.
There you go.
We are inside the instance now.
We can just verify that the instance has been
created using the on-prem user.
Along with the on-prem user, you can always
use a security group or any user on the Manage AD too.
That's it for the demo today.
Thank you.
Handing it over to Muthu.
MUTHURAJ THANGAVEL: Thank you, Ashrith.
Thank you for walking us through the demo.
Authentication is critical.
And we know a lot of you have been
asking for Windows authentication for your SQL
Server.
That's exactly what we saw today on how we have simplified
the setup for you so that you don't have to worry,
spending a lot of time and effort
in setting up your Windows authentication for SQL Server.
Instead, get it up and running very quickly with the managed
servers, and you can directly move on to using your SQL.
Server What more, we also have a lot of links,
the curated links that we have put together in the description
to get you started right away.
Thank you, everyone.