Modernization Hub

Modernization and Improvement
Best Practices for Using Microsoft Active Directory (AD) and Apps on Google Cloud (Cloud Next ’19)

Best Practices for Using Microsoft Active Directory (AD) and Apps on Google Cloud (Cloud Next ’19)

[MUSIC PLAYING] SIDDHARTH BHAI: Good morning. Welcome, everyone. Welcome. My name is Siddharth Bhai. I’m a product manager with
Google Cloud Security, very excited to be here today. Happy to see a few familiar
faces in the audience, especially excited to
be talking about Active Directory on Google Cloud. I’ve been a product
manager in the industry for about 12 years. As I look back, interestingly,
my first conference talk was also about Active Directory. It was at the good old
directory experts conference. And if you remember that– seeing a few head nods– many years ago, on a
windy Chicago morning. And here we are, different
decade, different windy city, San Francisco this time,
though the weather today looks gorgeous. Different cloud, a
cloud like no other. I’m glad I’ve had an
opportunity to spend about 2/3 of my career working with
large customers on enterprise security, especially
delighted to have one of the most distinguished
AD and cloud professionals in the industry today. Kenny Hill from Capital One,
joining me a little bit later in this session. We’ll invite Kenny
up to come and share Capital One’s journeys and
experiences, running Active Directory on Google Cloud. So let’s jump in. So you’re at a Google
Cloud conference, and you chose to skip
all the Kubernetes, BigQuery, AI and ML talks, and
come out to an Active Directory presentation. So I think I can safely assume
you’re well-versed with AD and understand its needs
in cloud environments. But if you wanted a quick
refresher, Kerberos, LDAP, domain join, group
policy, .NET APIs, these are all good reasons why
you still need Active Directory and cloud environments. And so we’ll dig
deeper into that today. Before you go deploy your
first domain controllers and production,
you obviously want to make sure you’re
prepared well for that. When you look to do
that on Google Cloud, here’s a few things you
want to think about. First up, you want to
think about securing your infrastructure. We have great investments in
Trusted OS images, Shielded VMs, VPC Service Controls. So you want to think about where
will you deploy our AD domain controllers and how
will they work out. Second, you want to make sure
only the right people can get to the projects that you are
running your Active Directory domain controllers. So you want to think about
identity and access management. In particular, we have
other sessions that cover this in more depth,
but there is a project level permission, a folder level
permission, and folder sits inside of an
organization notes. So you want to think about IAM
across all of those levels. And even after you have the
right IAM rules in place, you want to make
sure that people who are accessing those projects
are authenticating security. We’re big fans of Titan Security
Keys and 2FA here at Google and encourage you to
think more about those. When it comes to the actual
deployment of Active Directory, you want to think about, of
course, a variety of items. I’m glad to share
we’ve been working on putting out more
solutions guides, guidance. There was a talk here last
year at Next San Francisco, where we spoke about
do-it-yourself Active Directory. It’s recorded and available
on our YouTube channel if you want to go check it out. But mostly, I’d like you to just
make a note of these resources and dig into those offline
so we can actually cover fresh, new material today. Sounds good? OK. So one of the things
that we notice as we work with
people in the industry is Active Directory
is very important and a very
specialized skill set. I see a couple of heads nodding. And one of the things
that we tend to find is there’s people who’ve been
great with Active Directory, working with it for a
dozen or more years. But they haven’t had as much
experience running things on cloud environments,
or their organizations haven’t empowered them. The other thing that
you find is there’s people who are
really up to the top notch when it comes to
running things on cloud, but oftentimes
that experience is more with cloud-native
applications, stateless applications,
which have very different characteristics. And so when you look
at this connection, you find that the set of people
who have both Active Directory and cloud skill sets available
and know how to do it well and securely is a challenge. And to help address
that, I’m very excited to share
that today we’re announcing Managed Service for
Microsoft Active Directory. Those of you who were at
the keynote this morning must have heard our Google
Cloud CEO, Thomas Kurian, announced the service publicly. We showed a quick demo. And if you missed
it, no worries. We’re to do demos
in this session. Most of the talk
today is now focused on how is it that you
can automate your best practices and leverage
the managed AD service for your workloads. In particular, it’s a
highly available service running on Google Cloud with
an actual Microsoft Active Directory domain
controllers in production. Some of you in the audience
I was speaking with earlier were saying you were
interested in learning how you can have this work
well with your current AD. So we’re definitely going
to cover that in more depth as well. And, all in all,
the idea is we’ll take care of a lot
of the heavy lifting. So you can be more
relaxed and focused and working on our
cloud infrastructure. As I mentioned, it’s actually
running Microsoft Active Directory on Windows Server. It’s a net new service. So we start off on the most
recent and updated bill, Windows Server
2019, that Microsoft supports on the long-term
servicing channel. So all our beta Active
Directory domains will be running on that OS. And because it’s
the actual AD, you are not having to worry as much
about application compatibility or other challenges. With it, you get
all your standard Active Directory features,
single sign-on, domain join, group policy, and so on. And most of all, you can use
your familiar Active Directory tooling, Remote Server
Administration tools, and other scripts to
work with the service. It’s a fully managed service. It runs in a highly
available configuration. You can actually choose to have
your domain controllers come up in any of a number
of regions which are supporting with the beta. Service takes care of
automatically patching servers, making sure we’re
taking snapshots, and worrying what all of
those operational details. It’s very important but
somewhat repetitive. And we make sure we keep that up
in a good and healthy state, so your free from the
mundane and can focus on what’s most important
and relevant for organizations. And it’s hardened with secure
configuration baselines. It’s designed with
security in mind, which we’ll expand more over
the coming 20 minutes or so. Also, we’re baking in the
principles of hybrid identity management, pretty core. It is 2019, so I’m guessing a
lot of you are not starting out with your first Active Directory
or identity as a service product. We understand that. So we interoperate well
with your user identities, whatever the might recite. And I’ll show how in
the rest of the session. As you read through this,
you’ll notice that we are also integrating well with Google
Cloud DNS and our Google Cloud VPN and interconnect solutions. Windows Server
Active Directory is something that isn’t recommended
to ever be directly exposed to the internet. So if you have your
private network from your corporate on-premises
environments connected up to GCP in these
forms, we can actually work further with that. And as we get closer to
GA, we will back this up with enterprise-grade SLAs. I’ll let you take a moment to
understand what the service is about, and then I’ll elaborate. So the interesting
thing about this service is, although it’s a
cloud service working for a large set of
customers, we’re making sure that we bring
up every Active Directory domain for every customer. So each customer’s AD
runs in a special project on a segregated network
that’s dedicated just for you. So you’re not sharing that with
any of the other customers. We also bake into our
service the principles of AD delegation. So we have a preconfigured
admin account for you to use. And you’re welcome to create
additional users and groups to use with your Active
Directory tiered administration models as you see fit. Also, it works alongside with
your existing on-premises AD. Based on your security
posture and needs, we support, both one-way and
two-way forest level trust with your existing
Active Directory domains, one or more domains. So whatever works well for you. What the service is really doing
is going ahead and automating a bunch of different
best practices, which you would otherwise have
to worry about and manage on your own into the
nature of our design. For instance, when domain
controllers come up, they come up one in
each zone, so it’s highly available in
whatever region you specify. They’re running a bunch
of diagnostics regularly every few minutes
and making sure that the Active Directory domain
health is getting populated and reported back. We’re backing up your
Active Directory domain data every single day so
that we could recover in the instance of any issues. But addressing
the IAM challenges we mentioned earlier and
the operational challenges by having engineers or
bill skilled in both Active Directory and Google Cloud
as you build out the service. And the security aspect
is so clearly ingrained into the service
that if you just ask us to make an
AD domain available, we don’t just go ahead and
make it available on any of our networks. You authorize
specific VPC networks, and the AD domain is
accessible only from those. So if you’re in a
segregated environment, you can definitely do that. Building out and talking
more about the security aspects of the service, we’re
automating our firewall rules. And one of the challenges that
happens when you self-deploy is you may have the right
firewall rules in place on day one. But somebody else
came in after the fact and changed the firewall
rules, because they were deploying a web server. And before you know it,
you have sensitive data coming onto the same network. So because it runs in
an isolated network, and we automate and
enforce the firewall rules, we’re able to address
this very well. As you’re aware, Windows
Server releases typically monthly security patches. So we go ahead and patch
our domain controllers. Now, when you’re
updating AD, you need to make sure that you’re
doing it systematically so the AD domain
remains available while the OS is being updated. So we go ahead and take care
of all of that orchestration on your behalf. The service level APIs
operations are integrated with Cloud Audit logging. So if somebody came in and
reset the admin account password to our service API,
you would definitely be able to see that in Cloud
Audit Logging from the get-go. The last two points are
pretty interesting and key to understanding how the
service works with security. Anytime our service
code needs access to sensitive Active
Directory credentials, we’re taking the utmost
care to make sure that we’re protecting
them in a safe manner. We actually have a key for
Active Directory domain, but Active Directory managed
domain held in Cloud KMS. And this key is what is utilized
to go ahead and make sure that your secrets are
encrypted and your AD domain specific credentials are
getting rotated every 30 days. We also enforce safeguards
for preventing elevation to Domain Admin. In particular, a lot of
our service level code has actually been
through and released after it passes peer reviews and
our internal security reviews. In the event that a human needs
to go in and access or manage the domain in the
event of an incident, we actually have a whole
internal process in place. They need to be on-call. They need to be in
the right groups. And they get that
elevated access for only very short
amounts of time that may be needed
to address the issue. And then it goes back to being
fully automated from then on. So I’ve been talking about
this service for a few minutes. You’re probably interested in
taking a look under the hood. So let’s jump in. So we have the UI for
the managed service. As you can see, I have
precreated two managed AD domains here for you– corporate and partners. If you go in and
dig a little deeper, you’ll see that it is running– the domain controllers
are deployed in us-west1. The Active Directory
is working just fine. Let’s jump in. You’ll see a few more details
come up about the service. In particular, I wanted to focus
your attention on the networks. So you can see, though I have
other networks in this project, it’s only available on
the authorized network. This one. And there’s a few more
aspects of the service you can read through. Now I want to pause here and
ask you, how are you guys doing? Oh, good? Head nods and thumbs up. One sign. As you think about what
it goes into making sure an Active Directory
environment is up and healthy. Is DNS up? Is the application working? Is LDAP working? Is Kerberos working? Are people able
to connect to it? Are the right
signals being sent? I could go on. It’s tens of items
that are checked– on each and every
domain controller, an aggregated backup to give
you that simple thumbs up. And that’s what’s going into
that health monitoring signal. So we’re taking care
of that complexity, so you can just focus on
the service being available and be productive with it. And I’ve actually integrated
the signal with Stackdriver. So as I go ahead
and dig in, you’ll see our Stackdriver UI
come up in a second. And what you’re noticing is
that the moment it comes up, you’re able to get a simple
graph of how the service has been performing. So you can see, as
we expect, there were no issues with the service. It’s all good. Using the Stackdriver
UI capabilities, you can very quickly
go and take a look how did it perform over six
hours, over the last day, over the last week. And you can notice this
managed AD domain has been behaving perfectly fine. You can actually
get at-a-glance view of not just this domain but all
your Managed Active Directory domains. So if I drop the
filter on the FQDN, you’ll see both
the rows come up. So both the corporate
and the partner’s domain have been behaving well
over the entire week. So this saves you time
in being able to get a quick, at-a-glance view. And if you ever needed to go
back and investigate things, you can see how it
performed historically. What we have done
with the service is really distill
down all the items that go into creating it
to a few simple steps. How many of you
remember DCPromo? Yes? You’ve seen how it’s
evolved over the years from it being a very
specific bunch of inputs that need to be given to somewhat
more simplified but still multiple-step process
in the Add Rules Wizard for Windows Server. And what we do is we go ahead
and take all of that complexity down to what’s the absolute
minimum set of things we need from you. And I have to precreate it. I’ll try and zoom into it. All we need is the name
of your Active Directory domain, the network you
wanted to be authorized on. So it could be default.
You could select others in the project, the IP
ranges we should use, and which region would
you like to bring up the domain controllers in. Another interesting thing I
should call out is in GCP, our VPC networks are
multi-region aware. So if I make it available
on the default network and the default network
has subnets from 5, 6, 10 different regions, then
your infrastructure running and all of those regions can
still access this Managed AD Domain even when the domain
controllers are being deployed in the us-west2, so something
to think about as you design your infrastructure on GCP. So this is a service-level view. I also wanted to hit
one more point, which is you can utilize your
standard Active Directory tooling to manage this Active
Directory Managed Service. So let’s jump over. I’m already RDPed
in to a Windows VM. Now this VM is domain join
to the GCP-managed Active Directory domain. You can see I’m logged in
via a user account that sits inside the corporate
domain I showed you a couple of minutes ago. You can now see that I’m
looking at the service through the Active Directory
Users and Computers UI, which I’m guessing a lot of
you are probably familiar with. The same VM we are now
RDPed into, as expected, has a computer account in
the Active Directory domain. So you could use AD you
see to do other items. Those are a few who
are using the newer tool, which is the Active
Directory Administrative Center. That works well with this too. You can see that I’ve
organized my users and drops into two OUs. One for finance, the
other for marketing. And instead of finance,
I have a few users, I have a couple of groups
precreated and so on. Also, Active
Directory operations are scripted a lot of the time. So this also works with
Active Directory PowerShell. This Is the standard get AD
group member, Active Directory PowerShell Command. And as I go ahead
and run it, you will see that it’ll
show two of those users are a part of that group. So whichever may be
the standard ED tool that you’re used to
utilizing, you actually use that on the
infrastructure VM that you control to connect
up to this managed AD service. So that’s the service
that’s been under the hood. Let’s come back to the slides. And I’m especially excited
to invite on stage Kenny Hill from Capital One,
who will come and share Capital One’s
experiences running Active Directory on GCP. Welcome, Kenny. Excited to have you here. KENNY HILL: Hi, guys. I’m Kenny Hill from Capital One. I’m in the identity and
access management space. My main focus is directories
with an emphasis on the cloud. Thank you, Sid. At Capital One,
we are still very dependent on Active Directory. As I imagine, many of
you are here today. Many of you have probably gone
through mergers, acquisitions, maybe a handful of
domain migrations. Your directories are
possibly fairly complex. You have a laundry list
of applications that are dependent on Active Directory. Fast forward a bit to
taking your directory into the cloud where you have
a whole new level of capacity management, a new
type of monitoring and really does the
same security model that you had on-premise hold
true to being in the cloud. We currently domain join all
windows in most of our Linux to Active Directory
during the boot process. So this is built
into our image where before that any instance is even
available, it’s domain joined. Doing this allows us to apply
default domain policies, fully control who’s able
to authenticate, including local
administrative rights. And these many commercial
off-the-shelf products are just dependent
on Active Directory. Examples are anything with
IIS integration or SQL dependencies. When we first got started, we
domain joined our instances to our on-premise directory. This worked. It was also not the most popular
due to the number of firewall ports we had opened. So think about opening
every application project, I don’t know how many have
you gone to a network review and said, I need some AD ports. Well, no, I don’t
want all of them. I only need like
44,000 of the 64,000. We also experienced a little
bit of latency on our domain joins with this and a little bit
slower log on policy processing time. One thing to point
out in this model is it also kind of pins you
to a single point of failure with your network. So if you were to lose
your network connectivity, you are not really taking full
advantage of built-in Active Directory resiliency. So AD next closest site
gives you a little bit more with DC locator
where it can find where you want it to go next. SIDDHARTH BHAI: That’s
actually really interesting. And I wanted to reflect on
that because sometimes when customers start out, you first
think about just connecting up your networks through our
hybrid networking solution. But as Kenny’s team started
experimenting with that, you notice that it was
leading to a higher latency. And so then right upon you,
Kenny, do share with us what did you do next to
lower that latency down? KENNY HILL: Sure, Sid. We knew that you’d lie going
back to on-premise presented too much risk. If we were going to require
everyone to domain join and we lost network, then
applications couldn’t scale. And that’s part of
going to the cloud. You want to be able
to scale up and down. So we decided to expand our
enterprise directory to run on GCP compute instances. Essentially, we’re treating
GCP as infrastructure as a service for our
Active Directory. This model worked, and it
gives us more resiliency that our business required. In order to make
AD truly resilient, though, in this model, you may
not achieve the cost savings that you’re being asked to get
to with moving to the cloud. You’re going to have to run
a large number of domain controllers. You’re going to run
in multiple zones. You’re going to run in
multiple regions where you are. You also are going to take
on a whole new level– and I mentioned it–
of capacity management. There’s a new type
of monitoring. And there’s a lot of
automation building out domain controllers,
monitoring site reliability, to keep domain
controllers running as infrastructure as a service. One of the challenges
for us was staffing. Active Directory he’s
been around 20 years. I don’t know how many have you
been utilizing for 20 years. To take a traditional
team of Active Directory subject matter experts
and have them also– still remain really
good at keeping Active Directory
running and secure, but also learn new
CI/CD, site reliability, and other dev strategies
is a bit of a challenge. There’s a large potential
gain in this model, but it’s something
you want to weigh against the additional
overhead and challenges. SIDDHARTH BHAI: Right. So the interesting thing
from these experiences is you saw Capital One
deploy self-managed Active Directory in
production, which is definitely a supported choice. And our similar
talk last year, we went into detail how you can
set that up in best practices. However, oftentimes as you
look to do that, you end up realizing that there
is more operational overhead your teams
are having to take on. What we’ll hear
from Kenny is how is it that Capital
One looked to reduce their operational overhead by
utilizing Google solutions? KENNY HILL: I’m pretty
sure these are probably Sid’s favorite slides. Managed directories in
the cloud is the direction Capital One is trying to go. We have not quite figured
out what sits in the central as our central repository
for authentication and authorization. What we do know,
though, is we are going to still have
Active Directory dependent applications for any
foreseeable future. Utilizing managed AD as a
software-as-a-service model allows us to reduce our
normal day-to-day domain admin directory and
infrastructure tasks, and focus more on additional
identity access management components in the cloud. Removing the computer
traffic directly to our enterprise
directory also allowed us to reduce some of the
number of domain controllers that were deploying
in the cloud. So also adds a little bit–
a few security benefits that we’ll go into in a bit. SIDDHARTH BHAI: Makes sense. And so what you hear
from Capital One is how they then started using
the GCP-managed AD domain. However, this is a standalone
to me and in its own forest. So, Kenny, can you
share how you connected this with your existing
Active Directory topology? KENNY HILL: Sure. What we did as you
can see is it– It’s a huge requirement for
us to continue to manage in our own identities. So we are a
multi-cloud, and we want to treat our enterprise
directory as a hub for really any service we’re going to use. You can see in this model, we
are creating a one-way forest trust from managed AD to
our enterprise directory. This allows us to
continue to utilize our corporate credentials for
authentication or AD groups that we have built
into our provisioning system for authorization. We already had domain
controllers running in GCP. So we kept those in place,
and we just reduced the number that we had deployed in this. This gives us more or less
dependency on the network, going back to on-premise. So almost everything
in Active Directory will work with an isolated
domain controller. There are a couple
of things that won’t work like password
reset, but hopefully, you’re not using a cloud for
password resets like that. We domain join compute
instance to managed AD. Then all user authentication
traffic or authorization with your AD groups is
going to go from the managed AD to enterprise directory,
while all computer authentication traffic
is going to go to– And even GPO stuff is going
to go to the managed AD. SIDDHARTH BHAI: Interesting. So we can see now
how Capital One was able to use the managed
AD domain with the trust relationship with their
existing on-premises AD and get operations to work. What’s especially
exciting is, Kenny, if you can share how this
actually held an answer cloud security overall. KENNY HILL: Definitely. So let me go over a couple
of the security benefits. This slide is kind of busy. You guys in the room
may not be scared to put your infrastructure
into a public cloud, but I guarantee you,
there are a few naysayers. There are few people in
your company who are scared. And it’s really fair, right? The number of breaches we read
about on almost a weekly basis, and Active Directory is
oftentimes maybe not called out in the news article, but
in the post-follow-up of how the breach occurred. Active Directory was one of the
things that was compromised. So in this model, the
top the top diagram, you can see that a
computer directly domain join to the corporate forest. You may not be
aware, but a computer can authenticate
the same as a user. If you’re familiar with the
Active Directory schema, really a computer is a member
of the user object class. In the top diagram,
a computer domain joined has the
capability of running a system if you were
to lose that instance to query your AD data. And no, you’re most
likely not going to have sensitive data
in your directory, though it’s not
really a good idea to really give somebody
a path on how to– of your user accounts
or your computer names. In the bottom model, utilizing
a resource forest model, the computer has no ability
to query the directory without additional credentials. This next slide’s a little
bit more about monitoring. Active Directory is super
chatty, so logs often roll in– when you’re running
in the cloud and you have a large number of instances
of spinning up or scaling, if you’re not really
careful, it is easy for– to hit in Windows event log
limits per second, where you aren’t getting the logs. I’m not sure if any
of you have seen that, but there’s times that
things are occurring, and they’re not going
into the event logs, because you’re going
over your limit. So in the bottom model, removing
the computer authentication, GPO processing, and
all of that, you’re able to focus on your
user authentication. And this allows you to be
a little bit more precise and look for
promiscuous activity. You can still monitor the
traffic to the managed AD. It’s just not as critical
as monitoring the user authentications. Many of you may be familiar
with selective authentication. If not, setting up selective
authentication on the trust allows you to
really choose who’s going to authenticate
across the trust. When you’re fully mature
in the cloud, really, you shouldn’t have
users logging in. With that said, that is a
very long transformation, and there will
always be exceptions. So you should only need
to have service or system accounts, whichever
term you use, that are authenticating
on your systems. And then maybe a small
subset of privileged users who are allowed to directly log
in to an instance in the cloud if there is SEV
incident or something. So with that smaller set of
credentials that you’re are allowing, you can then apply
a more complex password set, and you can rotate the
passwords more frequently. You can deny most regular
users from ever logging into anything. Say if you’re running Citrix
or something like that, you can build out an OU
in managed AD that has allowed to authenticate on it. And those users could log
into the Citrix instances, but they would never be able
to log into anything else. In the corp model above at
the top, what I’m showing is this is completely dependent on
a local resource access control list. And anyone with administrative
rights can add more. So maybe they want to
add their co-worker, because I think
they need access. In the bottom model with a
selective authentication, really, you’re
adding another layer. So you have the local
access control list, but then you also
have another layer that you can tie into
your provisioning system, and you’re controlling
who’s going to ever be able to go
across the forest trust. So, essentially, you’re
doubling your access checks. To recap, utilizing
GCP-managed AD as a resource forest
allows us to maintain the resiliency in our
business requires, reduces our
operational overhead, and continue to utilize
our internal directories for authentication and
authorization, while also adding a few additional
security elements to us. So we’re looking
forward to consuming in general availability. And, Sid, I want to thank
you and your whole team for allowing us to take part in
the alpha and inviting us back. And, everybody,
thank you very much, and feel free to
connect afterwards. I love questions. Thanks, Sid. SIDDHARTH BHAI: Thank
you so much, Kenny. So to recap where we are at,
you’ve heard about our service, you’ve heard how Capital One has
been using it and connecting it with their existing domains. And what I wanted to
do in the next segment is speed through a few
specific uses of the service. So as you’re mulling about,
well, how do I use this thing? Which use cases are interesting? And I’m going to go
through five GCP use case very quickly to help
spark some ideas. So let’s jump in. First up, that’s
probably the first thing that you do with
Active Directory when you’re bringing
up an infrastructure. You go ahead and domain join it. And so we have made investments
to make that domain join process be easier. How so? Remember when we created
an Active Directory domain, you asked for it to be available
on an authorized network? And, by the way, you can come
back and update those networks later as your needs change. No problems. What we do is we actually
create a private-managed DNS zone in each of those networks
so that when you then bring up a VM, it can just discover the
managed AD domain without you having to do any kind
of complicated per-VM configuration. So that’s how domain join works. You also saw Capital One talk
about how they are actually solving another interesting
identity requirement I hear often from our
customers, which is, I want my user identity to
still originate on-premises. And so what you
can do is you can have your VM be domain joined
to GCP-managed Active Directory domain while your users can
still reside on-premises. Let’s jump in and take a
look at this in a demo. In the interest of time,
I prerecorded the video, and I’m just going to talk
through it as it comes up. Great. So what you see as we
go ahead and hit start on the video is when
this starts playing– can we do that from the
back of the room, please? Great. Thank you. So as this comes
up, you will see that I’ve already created
a managed Active Directory domain. And that managed
Active Directory domain is So we have the
domain controllers deployed in us-central1,
and it’s in a healthy state. As I jump in, you
can actually see that I’ve preconfigured this
managed Active Directory domain with a one-way
forest level trust, going back to your
on-premises AD domain, which is onpremad.demo. So that’s the name of
my on-premises domain. I’m now going to go ahead and
switch out into an application. So you’re actually seeing
SharePoint run in a VM on GCE. And the user identity, which
you have used to access it just now, was actually a
user account to start in your on-premises domain. So this is how you can
go ahead and actually have your Active Directory
domain, the managed one, help your infrastructure while
your identities originate on premises. Let’s come back to
the slides and dive into the next use case. And so as that
comes up, the thing that you think about doing after
domain join is group policy. So we’re going to
go ahead and see how we can have a group
policy be working well with the GCP-managed AD domain. What you can see here is inside
of the GCP-managed Active Directory domain, I have an OU. And as your computer
accounts come up and domain join the GCP-managed
AD domain, you have those computer
accounts coming up in that organizational unit. We can actually go
out and create a GPO that links directly to that OU. And what this enables for you
is your computer accounts, your service account’s
related group policy. All of that is processed
entirely in the cloud without having to go back
to on-premises improving performance and latency for you. Next use case, number three. We actually have an
interesting feature in GCP called as OS Login. Have some of you heard about it? A few. One of the things that
we hear about on OS Login is it works great for Linux. How can I get something
similar for Windows? So using GCP-managed Active
Directory domain, what you can do is you can actually
have the same group policy processing mechanism,
we utilized to let you be able to control
RDP access onto your VMs. In particular, we actually
precreate for you a RDP admins group, and you can just add and
remove people from that group. And that sort of users
are the only ones who will then be able to
RDP to those windows VMs. I do want to call out
that while the service can enable this, all the
things we spoke about IAM– because this is not your
infrastructure– do apply. So you still want
to think about who has compute instance
admin, set IAM policy, and other permissions
on those GCP projects while you utilize the service. But this is a use
case we also enable. So far, we’ve been covering a
lot of traditional enterprise use cases. So let’s mix things up a bit. I’m now going to talk about
managed instance groups. Now this is actually
an interesting feature that GCP already
supports, that allows you to treat a large collection
of VMs as a single entity to control and manage. One of the interesting
things that we have done is we have a script and a
solutions guide which we intend to publish with the beta of the
service, which actually allows you to have these VMs coming up
in the managed instance group. And we automatically join to
the GCP-managed AD domain. Now what this does
is it, therefore, allows you to utilize
managed instance groups in interesting ways. For instance, IS Servers tend
to be an interesting web server that a lot of you
still potentially use. And ISF servers and
other websites contents are good target use cases
for managed instance scripts. Let’s go one step further and
actually cover a fifth use case, which is how can this
managed AD service actually help modernize
your applications. So for that, we’re going to
go ahead and switch to a demo. And I’ll talk you through it. As the demo starts, one of the
interesting things you notice is we are starting
off on on-premises. So this is an app, and
its back-end database running in an on-premises
VM is actually a Linux-based VM this time
that we’re looking at. I go ahead, and I have this ADUC
from on-premises connected up to the GCP-managed
Active Directory domain. As you can see,
that is a user Jane we have precreated
in that AD domain. I’m now logging in
using Jane’s identity into SuiteCRM app, which
is so far and still running on-premises. As this loads, Jane can
get to all of her data and go about her work. We’ll now do
something interesting. a You heard us talk about Anthos
Migrate, also known as– well, to start out– V2K technology yesterday. The command that I just ran
in the bottom of the screen actually went ahead and took
those VMs and modernized them. As I hit refresh
and this comes up, you will see that those
applications are now running in a StatefulSet on GKE. I dig in, and I’m going
to go ahead and make a note of the IP address. This is where the
application is running now. So you just saw state.vm
running on-premises, now running in a container using
our other GCP offerings, while still utilizing the
GCP-managed AD service. The way that fits
into the picture is we’re now going to go
ahead and log in to that app, now running in a container,
using the same user account we logged in with
while it was still on-premises. And so as we go
ahead and hit log in, you’ll see this complete. Jane can access her data. And this is how– while we do
focus and empower traditional applications– you have a good example of
utilizing the managed AD service to even help you
modernize your applications. So these are the few use
cases specific to GCP. As we come back to
the slides, I want to go ahead and build upon
these with two more very interesting examples. I’m glad we have exciting
industry partnerships with other technology partners. And, in particular, I’m excited
to talk to you about what we have done with Itopia. The Itopia team is
actually in the room today. I’m excited to announce that
before we launch our beta, they have pre-integrated
with the GCP-managed Active Directory service. In particular, what’s
interesting is a year or so ago, the Itopia team built
out automation on GCP, where as a part of bringing
up their automation, they needed Active
Directory deployed. So they were bringing up
the AD domain themselves and managing on their own, with
the GCP-managed AD service that actually able to
offload the creation and management of that
AD domain over to us by adding an integration
into their UI. You’ll see a screenshot
come up in a second. And you can see the
third option for GCP manage Active Directory domain
is integrated with the Itopia offerings. I’m also excited to share that
we have worked with Citrix. Citrix is, of course, a
company which a lot of you are familiar with and
likely using their products in a variety of ways. Like many enterprise
applications, Citrix also requires
Active Directory, product integration signed
into apps and desktops that run on GCP. The interesting thing that
I wanted to touch upon about the Citrix integration
is when we work with them, they work with us and some
other managed services on GCP. And they were able
to really reduce the amount of
infrastructure, but somebody needs to run and self-manage,
from seven instances down to two, by utilizing more
than the platform offers. Something to think about as you
plan out your own deployments and infrastructure automation. So to summarize what
we have covered so far, we’re excited to
share with you today. We have Managed Service for
Microsoft Active Directory. It helps you solve
concrete GCP use cases, supports production apps
running on Linux and Windows, helps you in your app
modernization journey, reduces overhead, helps you
automate best practices, and enhance your cloud
security footprint. The service will be coming
up to you in later this year. It’ll be in beta. And, in particular, I want
to highlight these two links. We’re not only
charging for the beta. It will be free to test. You’ll still have to pay
for your own infrastructure. And the second
link, in particular, is exciting,
because that’s where we’re happy to share we’re
launching a pre-signup form. So if any of these
looks interesting to you and you’d like to
try the service out, please go to
and fill out the interest list form. We’d be happy to get
back in touch with you when the service is available. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *