AWS re:Inforce 2022 - Deploy and secure Active Directory with AWS Managed Microsoft AD (IAM203)

Aug 16, 2023

AWS re:Inforce 2022 - Deploy and secure Active Directory with AWS Managed Microsoft AD (IAM203)

Bringing Active Directory-dependent workloads to the cloud is no longer optional; it’s a necessity for modernization. In this session, learn how to deploy AWS Managed Microsoft AD, extend it across multiple Regions, and implement security configurations to meet your security and compliance requirements. Dive deep into popular implementations of Active Directory on AWS and how to leverage users from your existing Active Directory.

Learn more about AWS re:Inforce at https://bit.ly/3baitIT.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInforce2022 #CloudSecurity #AWS #AmazonWebServices #CloudComputing

Content

1.35 -> - Hello, everyone. Welcome to re:Inforce.

4.86 -> So I'm Dennis Rothmel,

6.69 -> senior product manager from AWS Directory Services.

9.84 -> And with me today, I have Jeremy Girven,

11.37 -> solution architect from AWS.

13.32 -> And we're here to talk to you about deploying

15 -> and securing Active Directory with AWS Managed Microsoft Ad.

19.92 -> So let's talk about deploying.

21.9 -> A little bit of backstory.

23.4 -> Windows Server 2000 gave us Active Directory.

26.13 -> And deploying Active Directory, back then,

28.08 -> looked a little bit like this.

29.28 -> You worked with procurement, legal, et cetera,

32.16 -> to get yourself a license,

33.54 -> and then you got something in the mail

35.13 -> that looked like this.

36.6 -> And probably in parallel to that,

38.19 -> you did a lot of calculators,

39.48 -> you figured out how many servers you need,

41.25 -> where you needed to get them around the world,

43.41 -> all your network connectivity.

44.91 -> And then you had something like this,

47.58 -> at which point you could finally start installing

49.8 -> and configuring Active Directory.

51.3 -> And that process was three, four, five, six months,

55.44 -> and then you finally got started.

58.08 -> So thankfully, things have changed since then.

60.45 -> And nowadays, with just a couple of pieces of information

64.35 -> through your favorite cloud services,

65.85 -> you can have a fully managed Active Directory deployed

68.01 -> for you in minutes.

69.9 -> And additionally, if you want to go the route

72.3 -> of extending your existing Active Directory,

74.13 -> you can with, just a couple of clicks,

75.63 -> have Windows servers built in the cloud,

77.55 -> and then quickly promote them to be domain controllers.

80.34 -> So that was then.

82.5 -> And now you have an Active Directory,

85.44 -> so what are you gonna use it for?

87.99 -> Well, typically, Active Directory was the defacto solution

91.05 -> for workforce identity for many, many years.

93.45 -> And so what you have here is,

95.31 -> within your corporate network and your private IP ranges,

98.37 -> you have an identity solution that suits your workforce

101.58 -> and your human identity needs.

102.84 -> So I'm Dennis and I work for Amazon

106.2 -> and I have a user account that was created for me.

108.72 -> I'm a member of many groups.

110.34 -> And then those groups are all attached to servers

112.86 -> and resources and applications

115.23 -> that help me get through my daily life.

117.3 -> So in these types of Active Directories,

118.77 -> you'd deploy them within your network,

120.48 -> you'd connect them across your WAN link,

121.89 -> get many sites up and running,

123.51 -> and you'd have kind of tens, hundreds,

125.73 -> maybe millions of users available to you

128.34 -> in Active Directory.

129.75 -> Now, some customers that have had a lot of success

132.3 -> with the scalability of Active Directory

133.8 -> then turned and said,

135.007 -> "Active Directory works great.

136.68 -> Gives me good identity solution for my workforce.

139.8 -> Why not turn around

140.7 -> and extend that for my custom applications?"

143.01 -> So whether you're building an application

144.33 -> that's used completely internally

145.98 -> or you build another application

147.36 -> that maybe works B2B between you and another business

151.02 -> or between you as your business and your customers,

154.29 -> these applications can then use Active Directory

156.69 -> as part of the application stack

158.52 -> to handle all the authentication needs,

160.41 -> identity storage, and permissions management.

162.6 -> And so some customers went down that route

164.58 -> and have had a lot of success with that

165.9 -> in the scalability built into Active Directory.

168.57 -> Now, what do these two things have in mind?

171.75 -> They both sit comfortably behind the firewall

174.09 -> in private IP ranges

175.68 -> and are kind of only exposed

177.03 -> to the internet via the components actually need

179.52 -> to be there.

180.45 -> And that worked really well for many years.

182.971 -> So why change anything?

184.77 -> Well, there's been needs to modernize

187.92 -> and migrate that have been driven

189.21 -> by a couple of factors, right?

190.95 -> One of the big ones is kind of developments

193.53 -> and advancements in technology and security.

195.99 -> So things like leveraging identity

197.7 -> as the new security parameter instead of your firewall

200.04 -> and instead of your internal network have caused people

202.77 -> to push away from Active Directory

204.09 -> or at least figure out how to move it into the cloud.

207.06 -> And additionally, as we've all probably experienced

209.64 -> over the last couple of years,

211.29 -> the work from anywhere initiatives

213.18 -> that have come into play have really kind

214.98 -> of stunted the growth

216.09 -> of Active-Directory-dependent workloads

217.86 -> with their reliance on being required

219.51 -> to be inside of your IPv4 internal private networks.

223.2 -> And then, additionally, business agility

225.75 -> and innovation needs have pushed us

227.55 -> to kind of figure out how to grow faster,

229.89 -> save more money, and then use new tools

232.59 -> that are only available in the cloud

233.85 -> to innovate and grow quickly.

236.4 -> So customers say, "Well,

237.233 -> what do I do with my AD-dependent workloads now

239.52 -> that I want to achieve all these goals

241.2 -> and I want to adopt cloud services?"

243.06 -> Well, one of the two patterns

244.743 -> that customers typically do is they'll do lift and shift.

247.74 -> I need to get out of my data center quickly.

249.45 -> I need to get into the cloud

250.47 -> and be able to benefit from all the scalability

252.48 -> and availability that I get there.

254.28 -> And so this is deploying like for like.

256.08 -> This is the virtual machines that you currently host,

258.15 -> and then moving them to services like Amazon EC2.

260.85 -> This is the storage appliances that you currently use

263.52 -> and moving them to services like S3, for example.

265.98 -> And then, in addition, some customers will say,

267.967 -> "You know what, I'm gonna skip that step.

269.16 -> I wanna modernize directly into the cloud."

271.11 -> And maybe you just take your first step and say,

272.947 -> "I'm gonna go from self-managed,

274.65 -> fully hosted on my side,

276.12 -> to at least a managed service in the cloud."

278.34 -> So that would be something like taking your SQL server

280.71 -> and the databases that are in it

282.09 -> and moving them to a managed service,

283.65 -> like RDS from Microsoft SQL Server or Amazon Aurora.

287.85 -> So that way you can at least get out of the business

289.62 -> of managing the infrastructure,

291.06 -> as you've moved it to the cloud.

295.38 -> So how does AWS help me with this?

297.54 -> Well, AWS Directory Service provides two capabilities

300.57 -> that I wanna talk to you about today.

302.79 -> The first one is AD Connector.

304.5 -> And that is what it sounds like. It's a connector.

306.54 -> It's a directory gateway or proxy

308.85 -> that you're able to take your existing Active Directory

311.4 -> and use AD Connector to bridge that

313.5 -> into assigning permissions in the cloud.

315.84 -> So if you think of it this way,

317.1 -> it's not doing any replication

318.78 -> or caching of your directory into the cloud,

321.48 -> it's simply when you need to authenticate to a service,

324.24 -> it'll go in connect to your on-premise Active Directory

326.91 -> and authenticate you, and then go

328.5 -> and provide you the access you need in the cloud.

330.57 -> So what you can do here is, with your AD accounts,

332.76 -> bring them to AWS.

333.96 -> So you can plug them in

334.95 -> and use your AD accounts

336.06 -> for things like the Management Console access

338.13 -> or AWS applications like QuickSight, for example.

340.77 -> So if you're doing big data things

342.12 -> and you need to do QuickSight in the cloud,

343.86 -> you can do that using your AD credentials.

346.14 -> The thing to remember here about AD Connector is,

348.21 -> yes, it's hosted in AWS,

349.95 -> and then it will need connectivity back

351.87 -> to your on-premise or self-managed AD.

354.15 -> So that'll be in the form of a service account

356.31 -> and password as well as network connectivity.

358.59 -> And this is one connectivity,

360.27 -> sorry, one connector to one Active Directory

362.46 -> and one AWS account.

364.08 -> So if you need to have connectivity in another account,

366.84 -> you would then need to deploy another connector.

369.81 -> So on the other hand, on the other side of the fence,

371.55 -> we have AWS Managed Microsoft AD.

373.74 -> And that is kind of a fully managed Active Directory

375.93 -> in the cloud provided to you by AWS.

378.27 -> So think of it as like standalone AD as a service.

381.12 -> It integrates with the AWS applications and services,

383.61 -> like QuickSight, like WorkSpaces, WorkDocs, et cetera.

387.54 -> It can also connect to on-premise

389.31 -> through things like trust relationships

390.72 -> and network connectivity.

391.74 -> And we'll talk about that quite a bit more.

393.63 -> And then, also, AWS handles the operations

396.6 -> for you automatically.

397.89 -> So what that means is no more patching,

400.47 -> no more managing of scale in, scale out, et cetera.

405.36 -> So let's dive in a little bit more

406.59 -> about what is Managed AD for you.

408.75 -> So when you deploy Managed AD,

410.79 -> you get a single-tenant experience, right?

412.59 -> So it's a single forest, single domain just for you,

416.04 -> not shared with anyone else.

417.72 -> It's deployed into two VPCs

419.28 -> across two availability zones, at minimum.

421.5 -> And then you can connect all

424.08 -> of your AD-aware workloads via these VPCs.

427.05 -> So if you look at the diagram on the right, for example,

429.42 -> what happens is, as part of the Managed AD,

431.37 -> we deploy two domain controllers for you, right?

433.62 -> These are actual Microsoft Windows domain controllers.

436.23 -> We deploy and manage them for you.

438.06 -> And then on your side of the fence,

439.77 -> there's two ENIs or network adapters

442.02 -> that sit in your VPCs that are connected

443.91 -> to these domain controllers.

445.26 -> So when you go to deploy EC2 Windows instances

448.14 -> or even just connect back

450.06 -> to your on premise with Direct Connect,

452.22 -> you'll be able to connect to them via those ENIs.

454.71 -> And that's fully routable, as you'd expect.

458.22 -> Managed Microsoft AD supports multiple AZs,

460.35 -> as well as multiple regions.

461.64 -> And by default, you get two domain controllers,

463.71 -> but you can choose to scale out

464.94 -> to both additional domain controllers and more regions.

467.49 -> I'll talk about that a little more in a minute.

469.62 -> So when you deploy Managed AD,

471.932 -> AWS is responsible for building the servers.

474.54 -> We're responsible for replacing them,

475.95 -> if they ever go unhealthy.

476.97 -> So we do all the monitoring for you.

478.86 -> If there's a server issue, we either repair or replace it,

481.8 -> and it's all handled for you automatically.

483.99 -> We take care of all the patching, all the monitoring,

486.21 -> and we also do automated snapshots for you, right?

488.73 -> So by default, we do like five rolling snapshots.

491.88 -> You always have the last five days' worth

493.41 -> of your directory snapshotted.

494.7 -> And manually, you can take additional snapshots

497.01 -> at certain points of time as well.

498.57 -> So if you're making a big change in your directory,

500.37 -> you can grab a snapshot that'll stay there,

501.84 -> as long as you keep it.

503.01 -> So we handle all that stuff for you in the back end, right?

505.11 -> We do all the windows backup and restore it

507.12 -> and all that work.

508.2 -> So then you, as the customer,

509.28 -> just simply benefit from having a directory.

511.44 -> You go in and you create users,

512.82 -> create groups, create OUs,

514.83 -> set delegation, things like that.

516.75 -> You can create GPOs with any configuration you want

519.21 -> and go ahead and deploy it, right?

520.65 -> So things like password policies,

522.15 -> fine-grained password policies for your structure.

524.64 -> You can go ahead and set that up.

526.44 -> And then, additionally, some of the things

528 -> that require elevated rights to the directory

529.98 -> or direct access to the domain controller,

531.69 -> we've kind of provided them all

533.22 -> to you through our AWS console and CLI.

536.49 -> So things like creating trust relationships

538.23 -> or even ascending the schema can all be done automagically

540.9 -> for you just by you specifying

542.85 -> or setting your desired configuration

545.22 -> and we go off and do the work for you.

548.49 -> So let me talk to you about,

549.69 -> what are your deployment options for Managed Microsoft AD?

553.26 -> So if you're new to Managed AD,

555.15 -> I highly recommend you start with the console.

557.34 -> It just kind of guides you through everything.

559.05 -> We don't ask a lot of questions

560.4 -> when you create a directory.

561.75 -> We take care of a lot of the work for you.

563.61 -> But the console experience makes

565.08 -> it very straightforward, right?

566.34 -> You open up the console, you select an edition.

568.62 -> We have Standard and we have Enterprise.

571.02 -> And then you provide a DNS name.

572.82 -> You can also provide an NetBIOS name,

573.86 -> optionally, if you like, or we'll pre-create it for you.

577.53 -> You put in a password, and then you hit next.

579.72 -> On the next page,

580.553 -> you're gonna get a list of VPCs you can select from

582.78 -> or create a new one,

583.62 -> and then a couple of subnets that you can select.

586.8 -> And then, after that, you just hit deploy

588.33 -> and we go off and we build a directory for you.

590.88 -> So that's the simple route.

593.01 -> And then once you've gotten comfortable with that experience

595.11 -> through the console, it's then very easy to turn around

597.42 -> and extend that into being programmatic

599.58 -> or declarative in the way you deploy your infrastructure.

602.1 -> So in the center, you'll see we support CloudFormation

604.047 -> and we also support Terraform and CDK.

607.2 -> And so what that lets you do is say,

608.617 -> "I have an AD-dependent workload

610.71 -> and it needs a couple of VPCs and some domain controllers,

614.28 -> as well as some EC2 servers to put the application on

617.003 -> and RDS SQL servers to put the SQL database on,

620.34 -> et cetera, et cetera, et cetera."

621.87 -> You can go and declare that entire infrastructure stack

624.42 -> as a Terraform or CloudFormation template

627.12 -> and go and deploy it all automagically, right?

629.28 -> And those EC2s can automatically join

631.77 -> the domain after it's built,

632.94 -> and same thing with the RDS instances, et cetera.

635.25 -> So it really does put the power back in your hands

637.44 -> to state how your infrastructure needs to be

639.87 -> and just have it deployed for you automagically.

644.58 -> So let me talk to you about patterns of

646.35 -> how customers typically deploy Managed AD.

648.99 -> And I'll give you some good kind of use case examples

651.36 -> to go with each one.

652.35 -> So the first one is Managed AD with a trust.

656.37 -> So a lot of folks here probably have had Active Directory

659.79 -> in their environment for even as long as two decades, right?

662.517 -> And so what's the value of the additional AD

666.63 -> that you would deploy in the cloud?

667.86 -> Well, with Managed AD in the cloud,

670.23 -> you can then go ahead and kind of connect it

672.81 -> to Amazon first-party applications,

674.61 -> like RDS, like EC2,

676.77 -> and have that stuff all deployed automatically

678.84 -> in a resource forest,

680.31 -> and then connect back to your on-premise or self-managed AD,

683.49 -> so that way your users and groups

685.38 -> that everyone already logs

686.4 -> into their laptops with have transparent access

688.92 -> to the applications or databases

690.45 -> that you've deployed in the cloud.

692.01 -> So this is the classic example of,

693.78 -> I'm doing a database migration.

696.15 -> I'm gonna run my databases in a cloud.

698.1 -> Those databases and applications need an AD

700.83 -> that sits in AWS and is highly resilient,

703.23 -> and I'm not worried about any network connectivity blips

706.35 -> between my on-premise and the cloud.

708.51 -> And then that's all kind of handled

710.01 -> on one side of the fence,

711.18 -> but all of my users can still connect directly

713.01 -> through that application or database.

716.07 -> So next one is AD Connector.

717.96 -> So typically I see customers start out

720.33 -> with an AD Connector connected to their AD on-premise,

724.5 -> and they'll go and use us to deploy things like WorkSpaces.

727.11 -> So that way you can start

727.943 -> to become familiar with the AWS ecosystem

730.38 -> and you don't have to deploy

731.46 -> a secondary domain in the cloud,

733.2 -> but you can still use your existing AD service principles

735.84 -> and security principles from day one.

739.38 -> Next up, we have fully standalone Managed AD.

741.9 -> So like I said, Managed AD is a standalone directory

744.66 -> in the cloud.

745.493 -> So new forest, single domain,

747.06 -> and by default, it's not connected to anything.

749.43 -> So a classic example of why would I do this

751.65 -> is maybe I have outsourced

754.23 -> or kind of isolated unit in my business

756.66 -> that needs infrastructure quickly.

758.73 -> So the example I've seen customers deploy is Managed AD

762.12 -> with Amazon Connect for a call center application,

764.97 -> and then WorkSpaces for the desktop

766.98 -> for the call center users.

768.18 -> You get an entire business in a box.

770.01 -> You can deploy the whole thing through Terraform,

771.81 -> through CloudFormation.

772.89 -> And it's really quick and easy,

774.6 -> isolated from the rest of your business,

776.61 -> or it can be connected.

778.32 -> But you get that kind of everything runs in the cloud

781.17 -> and I kind of don't have to manage any

782.79 -> of the bits underneath.

785.01 -> The fourth option here I have

786.09 -> is just extending your existing AD

788.43 -> with Amazon EC2, and then letting it replicate.

791.61 -> So this would be,

792.63 -> I have AD and I have Direct Connect in place

796.74 -> and it's connected to some VPCs,

798.36 -> and now I just wanna take my domain controllers

800.07 -> and put some of them in Amazon.

801.84 -> So that way if I ever have a connectivity issue

803.91 -> or some kind of issue with my domain controllers on-premise,

806.4 -> there's still a couple sitting in Amazon

808.08 -> or AWS that are being taken care of by Amazon.

811.89 -> And then, lastly, a combination of all the above.

814.89 -> And this is actually pretty common

816.24 -> for customers that are highly dependent on Active Directory.

819.03 -> Taking your existing domain

820.23 -> and extending it into AWS with EC2 provides you

822.915 -> with a local copy of your database

825.09 -> that's available in whatever regions you deploy it in

827.91 -> and is highly resilient to fault.

831.03 -> But then, in addition to that,

832.23 -> a Managed AD with a trust, then,

833.73 -> can take all of your workloads

835.68 -> that are kind of the managed applications, like RDS,

838.65 -> and have them all kind of operating

840.3 -> in an isolated environment

841.86 -> that is kind of limiting your blast radius

843.72 -> or susceptibility to any issues there.

848.01 -> So these are common combinations of deployments

850.65 -> that you can see customers doing

852.57 -> when they have a lot of reliance on Active Directory.

856.53 -> So let me talk to you about a couple more things now

858.09 -> that we have Managed AD

858.923 -> and we kind of have some ideas of how we wanna deploy it.

862.32 -> Let me talk about multi-region extension first.

864.57 -> So this is available for Enterprise Edition directories.

868.35 -> And what this does is you select the region

870.72 -> that you want to be in,

871.59 -> that you wanna extend your existing directory to.

874.02 -> You'll go and do the same thing,

875.19 -> which VPC, which subnets do you want it to be in,

877.77 -> and click next.

878.7 -> And we'll do the same work that we did like

880.26 -> when we created a directory, right?

881.28 -> We will build additional domain controllers

882.87 -> in those regions.

884.19 -> Then we'll go and connect back

885.33 -> to the other domain controllers

886.62 -> and replicate all that data apart.

887.97 -> This is part of your standard DCPromo process.

890.76 -> All that replication occurs kind of

892.62 -> on the AWS service's side of the network.

894.84 -> So anything you change in your VPC doesn't really impact

898.71 -> the way replication works.

899.91 -> That's all handled on our side of the fence.

902.04 -> On your side of the fence, then,

903.36 -> what you have is those same two ENIs in your VPCs

906.77 -> in that other region.

907.92 -> So for example, I would have maybe North Virginia

910.89 -> as my first region and my second region might be Singapore.

913.77 -> Now I have a local copy of that AD database in Singapore,

916.77 -> and my applications can access that database locally.

919.56 -> So no more kind of cross-region calls

921.3 -> or any of that kind of stuff to be concerned about.

923.91 -> Change notification is enabled on replication.

926.37 -> So that takes the kind of standard, quote,

928.29 -> unquote, "15 minutes of replication" down to seconds.

931.53 -> So you get quite high speed replication.

934.02 -> And that all happens on the AWS backbone,

936.06 -> so it's pretty quick.

938.16 -> And then the last bit you might wanna know,

939.9 -> while this is a managed service,

941.49 -> it's kind of good to know where the FSMO roles might lie,

944.19 -> in case you need to connect to kind of the FSMO role holder

946.68 -> for any reason.

947.55 -> And those are always kept in the primary region by default.

950.61 -> So just in case you needed to know where those are,

952.89 -> that's where they're at.

954.6 -> Now, you have multi-region

956.52 -> and that's all within one AWS account.

958.95 -> Well, what about if I want

959.783 -> to use multiple AWS accounts, right?

961.74 -> So let's follow the standard practice

963.18 -> of one application, one account,

965.37 -> and then identity is maybe somewhere else, right?

968.01 -> So this lets you do that with Managed AD sharing

970.77 -> or directory sharing, as we call it.

972.36 -> So this is to help you take a single directory

975.12 -> and share it with multiple accounts

976.56 -> and we don't deploy additional infrastructure

978.33 -> in every account.

979.35 -> So it's very like network connectivity

981.24 -> and kind of places the directory available to you.

983.467 -> So you go to the Directory Service's console

986.07 -> and you can see directories shared

987.33 -> with me listed in the console,

989.49 -> and then you'll be able to see which ones are there.

991.32 -> You can establish kind of more and more VPC connections

994.11 -> and do kind VPC routing, et cetera.

996.51 -> You'll get a basically virtual directory ID

998.73 -> in the other account that is then a kind of pointer

1002.3 -> back to your original account.

1003.41 -> That kind of way, you'll see a different directory ID,

1006.26 -> but it's the same directory.

1008.93 -> You can share this within your AWS org's method.

1012.62 -> And what'd you do is you would go

1013.76 -> to kind of the orgs management account,

1015.29 -> where the Managed AD is deployed,

1017.03 -> and then you can select other accounts from your org tree

1020.18 -> and those accounts will automatically

1022.19 -> then receive Managed AD shared at that point.

1024.62 -> So you still do have to select them,

1026.09 -> but at that point, the work is done.

1027.5 -> The other account will then see the Managed AD

1029.24 -> and then can start deploying workloads

1030.8 -> that leverage that directory.

1032.33 -> Additionally, you can do it via a handshake method

1035.18 -> with any accounts that are not in your org.

1037.4 -> So what this would be would be you'd put

1038.84 -> in the account ID, hit request,

1042.38 -> they'll receive a request,

1043.73 -> and they can go and accept the directory.

1045.38 -> And once that handshake's complete,

1046.88 -> now they have access to Managed AD

1048.53 -> and they can go and leverage that for workloads, et cetera.

1052.07 -> Directory sharing is also per region,

1054.59 -> which then helps you keep all your traffic localized.

1057.86 -> Now, I said a lot and it sounds maybe a little complicated.

1060.11 -> Let me give you a diagram to make it simpler.

1062.39 -> So in the center of this,

1063.83 -> you'll see this is the AWS account

1065.81 -> that's holding your Managed AD, right?

1067.94 -> So that is example.com.

1070.16 -> Could be your companyname.com.

1071.81 -> And what you're seeing here on the left

1073.04 -> and the right side is that there's two different regions.

1074.87 -> So like I mentioned earlier, right,

1076.19 -> Northern Virginia and Singapore, for example.

1078.83 -> These two regions are connected

1080.42 -> and they replicate kind of on the back end.

1082.52 -> And then if you look on the left and the right sides,

1084.53 -> you're seeing kind of an application account.

1086.51 -> So we'll just stick with the left side for now.

1088.79 -> So on the left, I've deployed any,

1090.95 -> you kind of name your favorite software.

1092.39 -> PeopleSoft or whatever.

1093.8 -> And that would be sitting in VPCs,

1095.72 -> which then have access to the Managed AD.

1097.58 -> And the reason why they see that is

1099.02 -> because of this directory sharing line kind of

1101.21 -> across the middle.

1102.29 -> And so that provides those VPCs connectivity

1104.69 -> to that Managed AD,

1105.77 -> so then you can go off and deploy all your workloads

1108.32 -> and then keep all your traffic localized.

1110.57 -> So now you have Managed AD, you've deployed it,

1114.44 -> and you have lots of methods to deploy it.

1116.24 -> You understand some kind of patterns

1118.25 -> that are pretty common in how to implement this,

1120.41 -> but now let's talk about that other piece.

1122.42 -> Let's connect this back to your existing AD

1124.76 -> so that way you can start assigning access

1126.38 -> to your workloads.

1127.55 -> So Jeremy, why don't you to talk to them about it?

1131.42 -> - Thank you, Dennis.

1133.04 -> I hope everyone can hear me,

1135.05 -> since this is a silent session.

1137.42 -> Yeah, I'm Jeremy Girven.

1139.49 -> We're gonna talk about trust.

1141.35 -> This is one of the larger hurdles to adoption sometimes.

1143.75 -> And usually once we talk it through,

1146.27 -> it ends up not being a hurdle at all,

1148.46 -> 'cause there is some misconceptions,

1149.66 -> which we'll touch on later on.

1151.61 -> But I wanna talk about the trust types

1153.05 -> that are supported by Managed AD.

1155.03 -> You have the forest trust and an external trust.

1157.94 -> You might hear me say domain trust.

1160.46 -> Just keep that in mind.

1161.69 -> If I say domain and mean external,

1163.55 -> they're kind of switchable

1164.75 -> 'cause they're a point,

1166.49 -> a one-to-one relationship there.

1169.88 -> Well, that said, let's go ahead and dive into this.

1172.97 -> Forest trust.

1175.52 -> We support forest trusts

1177.05 -> in a direction of one way or two way.

1181.058 -> I'll talk about direction.

1182.15 -> What that means is who's trusting who.

1184.88 -> In a one-way trust,

1185.84 -> that means one side is trusting the other side.

1188.27 -> And a two-way trust means both sides are trusting each other

1190.85 -> and authentications can flow both ways.

1192.71 -> With a one-way, authentication can only flow one way.

1196.46 -> Transitivity.

1197.293 -> That means how authentication can flow,

1199.94 -> especially with a complex forest.

1201.41 -> I have a diagram which will dive into that

1204.05 -> and actually explain that a little bit more.

1206.24 -> And authentication type.

1208.37 -> Supported by a forest trust is Kerberos and NTLM.

1210.763 -> NTLM is a legacy protocol.

1213.41 -> Kerberos is kind of a legacy protocol,

1215.09 -> but NTLM is even more so.

1216.86 -> And recommended not to use NTLM, if you can avoid it.

1221.48 -> Kerberos is definitely the much more secure protocol to use.

1226.22 -> And the big difference you're gonna see between the two,

1228.44 -> at least on this slide,

1229.46 -> is external/domain trust only support NTLM,

1234.17 -> but they can work with Kerberos.

1236.66 -> There's some caveats with it.

1238.94 -> And we have a link to a blog post

1240.59 -> that actually explains some of those caveats there.

1242.63 -> So you can get Kerberos to work with it,

1244.34 -> but there's a reason it says NTLM.

1246.65 -> And this is actually pulled

1248.06 -> from Microsoft's documentation on this.

1250.31 -> And external trusts are not transitive,

1253.04 -> which basically means it's a one-to-one relationship

1255.23 -> and authentications can only flow

1256.82 -> between the domains that are trusted with each other.

1259.88 -> And I also put realm trust in here.

1262.61 -> Managed AD currently doesn't support this today,

1264.59 -> but if you have a use case where you want this,

1266.75 -> we want to hear your feedback on that

1268.64 -> and see if that's something we should prioritize.

1270.53 -> So that's why I threw that in there as well.

1272.69 -> So if you do have a use case,

1274.25 -> please get with us afterwards

1276.14 -> and we'd love to hear your opinion on that.

1279.95 -> So let's talk about transitivity.

1282.5 -> So to keep it simple,

1283.88 -> we have a two-way trust here

1285.08 -> between example.com and corp.local.

1289.7 -> And in this first scenario,

1291.299 -> we have a two-way trust

1295.34 -> and it's gonna be a forest trust.

1297.23 -> So what that means is users

1299.27 -> from example.com could access resources in child.corp.local,

1302.96 -> or resources in child.corp.local could access resources

1306.92 -> in example.com.

1308.3 -> That's transitivity.

1309.2 -> Basically means it can flow within the forest,

1311.63 -> between the two points.

1313.85 -> Now, let's say scenario two,

1315.71 -> I only have an external trust

1317.03 -> between corp.local and example.com.

1320.72 -> Example.com users can't access resources

1323.15 -> in the child or tree,

1324.68 -> and also, the child or tree can't access resources

1328.01 -> in an example.com because a domain/external trust

1331.52 -> is only between those two points and that's it.

1335.57 -> And another thing to keep in mind,

1337.4 -> we and Microsoft recommend that you use a forest trust,

1340.79 -> if all possible.

1344.15 -> Both of us don't recommend using external trusts

1347.75 -> because of the limitations with Kerberos

1349.46 -> and things like that.

1351.29 -> So something to keep in mind,

1352.97 -> if you can avoid it at all costs.

1358.01 -> Speaking of Kerberos, let's dive into Kerberos a little bit.

1361.01 -> This is a 200-level session,

1363.53 -> so I'm not gonna go into extreme depth on Kerberos,

1366.95 -> but we could talk about it for quite some time.

1369.77 -> There is a link at the end of this deck

1371.84 -> that actually has a link to a blog post

1373.34 -> that actually walks you in detail

1374.57 -> through all these different steps.

1375.77 -> So if you want more details.

1377.03 -> And it actually has links

1378.44 -> to where you can get even deeper with Kerberos, if you want.

1381.92 -> But I do want you to understand a few points here.

1384.83 -> So the very first part, you authenticate.

1387.59 -> Like, one and two on this screen,

1390.11 -> you're gonna see it's an authentication.

1392.36 -> That typically happens when you sign in to your Windows box.

1394.64 -> You get your ticket-granting ticket,

1397.1 -> which basically allows you to get other Kerberos tickets.

1400.22 -> So the next thing I'm gonna do is I want

1402.77 -> to access this file system in domain B.

1406.43 -> So what I do is I send a request

1409.13 -> to my domain A domain controller

1411.77 -> with the SPN for domain B,

1414.05 -> a service principal name,

1416 -> and I say, "Hey, I don't think it's in our realm

1419.24 -> or domain and I might need a referral."

1421.91 -> And the domain controller evaluates it and says,

1424.137 -> "Yes, you need a referral.

1425.24 -> Here's a service ticket for a referral.

1427.4 -> Go talk to domain B."

1429.23 -> So I take that referral ticket,

1431.12 -> and then I go talk to domain B and say,

1433.257 -> "Hey, I want to access this system.

1435.08 -> Domain B evaluates it, says, "Yes, it's a valid ticket.

1438.35 -> Here you go.

1439.183 -> Here's your service ticket that you can go send

1441.768 -> to the FSx system in domain B and access it."

1444.77 -> So if you understand anything

1446.75 -> with this process and remember it,

1448.25 -> all I want you to remember is no passwords

1450.41 -> or pass between domain A or domain B,

1452.42 -> even the authentication from the client on to domain A.

1455.03 -> No passwords being passed here.

1457.37 -> And also remember referrals.

1459.83 -> That's pretty much how Kerberos works across a trust.

1461.95 -> It is referrals.

1464.45 -> And this exact diagram that you see here

1466.34 -> is actually on the blog post as well.

1467.84 -> So it is a public diagram

1469.49 -> that you can easily get online as well.

1473.84 -> Let's talk about some of the myths I've faced.

1476.3 -> These are actually conversations I've had

1478.61 -> with customers on some of these items.

1480.23 -> I mean, all these of items

1481.25 -> are actually conversations I've had,

1482.66 -> and I've had to pull up either the public documentation

1485.51 -> or talk through it and explain it

1487.4 -> and expand upon the public documentation with customers.

1491.93 -> Trusts synchronize objects between domains.

1493.82 -> A trust does not synchronize any objects between domains.

1496.76 -> Yes, there is a trust object on each domain

1499.55 -> and there is a password on that trust object.

1501.32 -> That part is synchronized,

1503.06 -> but the objects within the domain itself

1505.04 -> are not synchronized.

1506.18 -> And the only reason that I have

1507.53 -> to synchronize that password is to allow the domains

1509.63 -> to communicate with each other.

1511.55 -> So there is no synchronizing of users

1513.41 -> and groups from one domain to another over a trust.

1515.84 -> Now, there's tools that can allow you to do that,

1518.57 -> but by default, when you create a trust,

1520.4 -> nothing is synchronized.

1522.8 -> Another comment I've had is trusts are inherently secure.

1527.51 -> In and of themselves,

1528.41 -> trusts do not give additional permissions,

1531.41 -> especially depending on,

1532.73 -> even in a two-way,

1533.72 -> which is the most permissive of trusts,

1535.91 -> the most you could do is enumerate objects

1538.4 -> in the other domain and see objects.

1540.5 -> But if you have private attributes

1542.12 -> and things like that in your objects,

1543.68 -> you won't be able to see them.

1544.88 -> You'd have to delegate those permissions.

1546.59 -> Even with the right permissions, they have to be delegated.

1550.19 -> We kind of touched on this with Kerberos,

1551.81 -> but I just wanna hammer at home

1553.49 -> because I've had many conversations on this.

1555.32 -> Passwords are not passed across the trust.

1559.61 -> It doesn't happen.

1560.63 -> You don't have to worry

1561.463 -> about someone stealing your password

1562.79 -> when you do a Kerberos referral or anything like that.

1566.72 -> Also, one-way trusts are unidirectional.

1572.3 -> It doesn't go both ways.

1573.5 -> Now, there is some,

1574.91 -> I've read some security articles

1577.4 -> where there's some ways you could hack the trust account

1579.68 -> and do all that,

1580.91 -> but it's really exotic

1582.5 -> and you'd have to have full access

1584.48 -> on both sides to really do something with it.

1587.66 -> So it's unidirectional with the one-way trust.

1591.17 -> And we generally recommend,

1592.52 -> if you don't need a two-way,

1594.02 -> and I'll talk about scenarios

1595.46 -> when we talk about applications here shortly

1597.26 -> where a two-way is applicable and a one-way is applicable.

1601.04 -> If you only need a one-way, just do a one-way.

1603.29 -> No need to do a two-way, unless it's absolutely needed.

1607.88 -> And I kind of touched on this already.

1609.35 -> Users are not granted permissions

1610.85 -> when a trust is created.

1612.2 -> By default, with a two-way,

1613.58 -> they could enumerate, but a one-way,

1615.35 -> they can't enumerate.

1616.25 -> And what you'd have to do is type

1617.42 -> in credentials to enumerate objects in the other domain.

1620.27 -> And any write operations have to be delegated.

1624.92 -> By default, no write operations are allowed.

1627.44 -> It always has to be delegated.

1630.98 -> And with that, let's go ahead

1631.94 -> and talk about application integration.

1635.375 -> AWS Managed AD integrates with a variety of applications,

1638.45 -> whether they be AWS

1639.86 -> or actually self-managed options as well.

1642.77 -> I have a laundry list of them I'll show you.

1645.11 -> I'm not gonna touch on each of these,

1647.42 -> but some of these actually reside in the VPC.

1649.7 -> So like Amazon RDS for SQL Server

1652.55 -> or most of the RDS flavors do integrate with Managed AD.

1656.51 -> And there actually is a resource that resides in your VPC.

1658.97 -> Same with FSx, Amazon Fsx for a Windows file system,

1662.15 -> where FSx for ONTAP as well integrates with Managed AD.

1665.75 -> Or you just have standard EC2 instances.

1668.63 -> You technically could have on-premise resources.

1670.82 -> As long as there's a network route

1672.44 -> and you have the proper port open,

1674.498 -> you can join machines to a Managed AD

1676.94 -> from on-premises or other cloud providers,

1678.95 -> if that's your choice.

1681.59 -> Then we have these other AWS-managed applications,

1684.98 -> whether they be Chime,

1686.78 -> Amazon Single Sign-On, WorkSpaces, WorkDocs,

1691.4 -> all these applications.

1694.25 -> Minus WorkSpaces and I'll touch on WorkSpaces in a moment,

1697.31 -> but all these in the right-hand column don't actually have

1701.27 -> a data plane component that talks to the VPC directly,

1704.51 -> and they talk through the AWS network

1706.13 -> to the Managed AD to be able to authenticate.

1708.47 -> So a thing to remember with this, with trusts,

1711.86 -> I want you to go, before I talk about WorkSpaces,

1715.46 -> if it's an item that integrates directly with the VPC,

1717.89 -> like you see RDS and FSx

1721.64 -> or just standard EC2 instances,

1723.8 -> more than likely, you can get away with just a one-way trust

1726.29 -> in that scenario.

1727.43 -> Now, if there's a AWS sign-in page

1729.71 -> that you're signing into,

1730.64 -> so like, say, WorkSpaces has a sign-in page,

1733.7 -> Chime has a sign-in page, WorkDocs,

1735.53 -> whether they be a client or a webpage

1737.99 -> that you sign in to,

1739.46 -> a two-way trust is generally gonna be required

1741.5 -> in those situations.

1742.333 -> So that's the easy way to figure out

1743.75 -> whether you need a one-way or a two-way trust.

1746.93 -> A thing with WorkSpaces.

1748.64 -> It still would require a two-way trust,

1750.5 -> but there is a component of it that does live in the VPC.

1753.62 -> So the workspace itself does need full access,

1757.85 -> as if it's a Windows client on the network

1760.61 -> with a Managed AD.

1761.443 -> So it's not completely isolated like some

1763.4 -> of these other applications.

1767.87 -> And this is the long list of applications

1770.9 -> that are currently supported with Managed AD.

1772.88 -> This list will change.

1774.62 -> It is in our public documentation as well,

1777.62 -> but I just wanna show.

1779 -> And it'll grow.

1781.58 -> I wouldn't be surprised, in the future,

1783.11 -> there'd be some new service that gets added to it.

1784.97 -> So it's constantly growing.

1786.08 -> It's grown quite a bit over the years

1787.76 -> from when since I started with Amazon.

1791.63 -> I just put it here as a reference.

1793.49 -> The next one I wanna talk about

1794.66 -> is the natively integrated applications.

1796.82 -> So these will be the ones

1798.68 -> where you actually just integrate them

1800.54 -> as if it was just a member server

1802.46 -> or things like that into your Managed AD.

1804.56 -> And it would be like traditional AD, even in that use case.

1808.61 -> Most applications,

1809.6 -> as long as it doesn't require domain admin

1811.25 -> or enterprise admin, should work just fine.

1815.33 -> That's been my experience.

1816.56 -> Now, obviously, we haven't tested everything.

1819.47 -> The products listed on here I have personally tested

1822.26 -> and they do work with Managed AD.

1824.27 -> A thing to keep in mind.

1826.55 -> With ADFS, you can't use the GUI installer.

1828.95 -> You actually have to use the command line

1830.6 -> 'cause you have to point it

1831.433 -> to a particular container to install it,

1833.6 -> but it can be installed without enterprise admin

1835.88 -> or domain admin.

1837.74 -> But there is some caveats to installing it,

1839.48 -> but it will actually work.

1841.22 -> With PKI, it does work.

1843.89 -> You can deploy into Microsoft Enterprise CA just fine,

1848.21 -> but there is some limitations with that.

1849.83 -> And that has to do with Active Directory certificates,

1854.39 -> Certificate Web Enrollment Service

1856.61 -> and Certificate Web Enrollment Policy Service.

1859.85 -> Those two items cannot be installed

1862.34 -> because they do a blind check

1863.93 -> to see if you're a member of enterprise admins

1865.61 -> and that's something we can't delegate around.

1868.52 -> So that is why those two features

1871.07 -> of PKI will not work with Managed AD.

1874.58 -> But other than that, you can deploy PKI,

1877.58 -> have it issue certificates

1878.66 -> to the domain controllers, to your clients.

1880.37 -> You could do native smart cards

1882.95 -> and everything else with it as well,

1884.12 -> if you chose to go that route.

1886.88 -> And the rest of these just work as they will.

1889.34 -> A thing to note with System Center.

1890.63 -> Yes, System Center Configuration Manager,

1893.78 -> SCCM, does require a schema extension.

1896.36 -> And what you end up having to do ahead of time

1898.7 -> is take the LDIF file for the schema extension

1901.97 -> and upload it through our API.

1903.407 -> And then you can extend the schema

1905.51 -> to what you need it to be, then install SCCM,

1908.66 -> and it works just fine.

1913.07 -> Let's go ahead and talk about monitoring.

1916.4 -> We actually have a session, IAM352,

1919.58 -> for anomaly detection based on the CloudWatch logs

1922.88 -> that we allow you to send.

1923.81 -> So we have this feature called log forwarding,

1926.51 -> where you can send the Windows Security event logs.

1928.49 -> So these are actually the raw Windows Security event logs

1932.33 -> that can be sent to your CloudWatch Logs account

1934.51 -> in your account.

1935.69 -> And they're not filtered in any way or form.

1939.14 -> You're getting the raw logs

1940.82 -> as they are in the Windows event log.

1944.63 -> So we highly recommend you turn the service on.

1947.42 -> It is not on by default

1948.89 -> because there is a cost to store CloudWatch logs

1952.16 -> in your account.

1953.45 -> So we didn't wanna just incur charges for you,

1955.94 -> but yes, we highly recommend you turn it on, if possible.

1960.23 -> We also recommend that you turn

1961.4 -> on Amazon Simple Notification Service, or SNS,

1965.27 -> for directory status.

1967.16 -> So let's say the underlying hardware has a failure

1971.27 -> with your Managed AD

1972.2 -> and one of the domain controllers goes down

1973.67 -> and we end up having to rebuild it.

1975.35 -> The rebuild process takes 20, 30 minutes, potentially.

1978.53 -> And during that time,

1979.79 -> you do have one domain controller down,

1981.65 -> but the other one's up,

1982.52 -> but you're still in this state called impaired state.

1986.81 -> You'd get notified of that status change through SNS,

1989.96 -> if you have it configured.

1990.89 -> So it's good to know when you have an impairment

1993.26 -> or, for whatever reason, if there was a major issue,

1995.75 -> you'd be notified of that as well beyond that.

1998.27 -> So that only affects the status changes of the directory.

2002.8 -> So we highly recommend you turn it on.

2004.48 -> And granted, yes, there's charges with SNS,

2007.45 -> but very rarely statuses do change.

2011.59 -> So it shouldn't be a high volume type of thing.

2017.23 -> Also to note, if you have CloudTrail enabled,

2019.78 -> all directory service APIs are tracking CloudTrail.

2023.14 -> So it's the AWS service APIs.

2026.14 -> So these would be APIs like CreateTrust,

2028.854 -> CreateConditionalForwarder, CreateDirectory,

2031.709 -> DeleteDirectory, things like that.

2033.19 -> Now, if we're talking

2034.06 -> like native Active Directory API calls,

2036.79 -> let's say you use the Active Directory PowerShell module

2039.37 -> to create a user or delete a user,

2040.84 -> those will not be logged and CloudTrail

2043.06 -> because CloudTrail has no awareness

2044.59 -> inside what's going on with Active Directory.

2046.87 -> But those items will be logged

2048.22 -> in the Windows Security event log, which you can view.

2051.52 -> And you do actually have access

2053.02 -> to some of the Windows event logs via the MMC.

2055.18 -> You can actually remotely connect

2056.65 -> to the domain controllers to view those event logs.

2059.2 -> So you do have access to the DNS server event log,

2062.23 -> the DNS server audit event log,

2064.42 -> the SMB audit event log,

2065.92 -> and the Windows Security event log as well.

2068.86 -> You have access to those four event logs via the MMC.

2073.87 -> So if you did wanna see them.

2074.763 -> A thing to note with the security log.

2076.6 -> Since there is a lot of auditing turned on,

2079.48 -> those logs will roll over quite fast.

2081.67 -> So that's why we highly recommend you use CloudWatch Logs,

2085.27 -> so you always have those logs

2086.86 -> and you can set retention policies

2088.3 -> and clear them after a period of time,

2090.76 -> whatever meet your needs there.

2094.3 -> We also have some additional security recommendations.

2098.89 -> If you aren't aware,

2100.3 -> we just recently launched the directory settings feature

2104.95 -> to where you actually can turn off network protocols

2108.64 -> and ciphers.

2109.473 -> So if you want to turn off RC4 on the network stack

2112.42 -> or turn off SSL, well,

2115.69 -> SSL 3.0 is already turn off by default,

2118.21 -> but if you wanna know for sure that it's turned off,

2119.86 -> you actually can turn it off or turn it on,

2121.96 -> if you choose to live dangerously there.

2124.66 -> But you actually do have the ability

2126.19 -> to do that via the console now or the APIs.

2130.24 -> That feature was just launched a couple months ago.

2133.42 -> Highly recommend you look at that

2134.74 -> and disable any of these old protocols that you don't need.

2137.77 -> Like, RC4 is enabled by default in Windows.

2142.18 -> If you no longer need RC4

2143.737 -> and all your clients are modern,

2145.18 -> you probably could disable that and just be fine.

2147.16 -> But a thing to note,

2149.26 -> always test before you disable protocols and ciphers

2152.86 -> 'cause you could potentially break some

2154.51 -> of your older clients.

2157.72 -> Another recommendation is remove domain admin

2160.957 -> and enterprise admin access

2162.49 -> from any domain-joined machine.

2164.83 -> So I highly recommend that customer set up a group policy

2169 -> that applies to their OU

2170.44 -> and applies to their computer objects within OU

2173.02 -> to not allow domain admin/enterprise admins,

2177.13 -> to be able to log in to these machines via the net,

2180.07 -> access the machine via the network

2181.48 -> and log in interactively or through remote desktop services.

2185.92 -> It's not gonna happen,

2186.97 -> but this way you know for sure

2188.38 -> that no one other than you can access your machines.

2192.25 -> Also, with Managed ADs provisioned,

2194.65 -> it's provisioned with the admin account,

2196.96 -> is what it's called, and it is named admin.

2199.57 -> And that account should be treated as a break glass account.

2202.69 -> It should not be used for regular logins.

2205.75 -> And a reason for that is

2207.04 -> when you log in with a shared account like that,

2209.77 -> it's hard to attribute who did what,

2211.63 -> especially if multiple people have access to that account.

2215.5 -> So we highly recommend that everyone

2217.81 -> with elevated privileges,

2218.95 -> or every account, really,

2219.82 -> should be unique and independent.

2222.01 -> And the admin account should be treated as a break glass

2225.85 -> and only brought out in the cases if,

2227.92 -> for whatever reason, all the elevated admin accounts,

2230.86 -> for whatever reason, were locked out in that rare case.

2233.92 -> But it should just be, have a password set,

2238.15 -> some random, long password,

2240.13 -> preferably longer than,

2242.86 -> I would do 128 or more characters.

2247.99 -> Windows has a limitation with interactive logins

2250.51 -> where you can't log in via RDP

2253.15 -> with a password longer than 127.

2255.52 -> So I would do like a 128-character password on it,

2257.86 -> something ridiculously long.

2259.48 -> And that way, it should prevent people from using it

2263.02 -> when they shouldn't be.

2265.57 -> Also, we recommend that you use managed service accounts

2268.54 -> or group managed service accounts

2269.71 -> wherever possible for your service accounts.

2272.89 -> Let AD and the member server handle the password changes

2277.3 -> 'cause that way you don't have to manage that

2279.16 -> and it's rotated automatically on behalf.

2283.12 -> Obviously, not every application can support that,

2285.34 -> but if possible, highly recommend you do that.

2288.34 -> That's supported out of the box with Managed AD.

2290.95 -> And also, Dennis kind of touched on this as well,

2293.71 -> implement fine-graind password policies.

2295.45 -> The password policy out of the box

2297.25 -> with Managed AD is the default for Microsoft,

2300.43 -> which is okay.

2302.74 -> I mean, the password timeout is default to 42 days,

2305.92 -> which is a little short,

2307.57 -> but I'd rather it time out sooner

2310.24 -> than have it last for a longer period of time.

2312.76 -> But everyone has different policies

2314.38 -> as far as that goes.

2316.09 -> With the fine-graind password policies,

2317.53 -> you can set all those different policies.

2319.81 -> And I recommend setting a password to 15

2322.12 -> or more characters simply

2324.07 -> because when you do that,

2325.72 -> there isn't an LM hash, LAN Manager hash, for your password.

2330.94 -> And it's just an additional layer of security.

2334.96 -> So my recommendation is always 15

2336.88 -> or more character passwords for any account.

2340.21 -> Longer the better.

2345.04 -> Another item to touch on is Active Directory security.

2351.88 -> I already touched on this with a trust.

2354.07 -> If you don't need a two-way trust,

2355.69 -> you only need a one-way trust, just do a one-way trust.

2358.78 -> Yeah, it can be a little more work,

2360.16 -> but it's also the most,

2362.65 -> it's more secure to do a one-way trust versus

2364.81 -> a two-way trust.

2366.07 -> It's always recommended to do the minimum,

2367.9 -> whether that be permissions or anything else.

2371.2 -> If you are using your Managed AD as like a user store

2374.53 -> and you plan to doing LDAP calls to it,

2377.77 -> highly recommend that you enable LDAP over SSL.

2381.25 -> Currently, what that requires you to do

2383.17 -> is deploy a PKI solution,

2384.94 -> a Microsoft enterprise PKI solution.

2388.03 -> We actually have, I don't think the link is here,

2390.55 -> but if you're interested in it,

2392.08 -> we actually have what is called AWS Quick Start,

2395.2 -> which can automate the deployment of PKI for you.

2397.837 -> You can choose a one-tier or two-tier PKI deployment,

2402.28 -> and it'll deploy the CAs and set everything up for you.

2405.223 -> It's basically almost one click.

2406.81 -> You basically point to the AD,

2408.67 -> point to some credentials,

2410.32 -> and choose the VPC you want,

2411.28 -> and then it'll take care of everything for you.

2413.47 -> And we also have a blog post that describes

2415.09 -> how to do that as well.

2419.53 -> If possible, it's recommended

2422.14 -> to implement multifactor authentication.

2424.45 -> You could do that natively with smart cards,

2426.37 -> YubiKeys, or whatever you want with your AD users.

2431 -> Multifactor is generally a good idea,

2433.03 -> especially for elevated accounts.

2435.73 -> I've worked in places where my regular account,

2439.78 -> yeah, I just had my normal username and password,

2442.51 -> but my admin account,

2444.7 -> I had to log in with a smart card

2446.59 -> for a multifactor factor, multiple factor.

2449.41 -> So I highly recommend doing multifactor,

2451.27 -> especially for privileged accounts,

2453.04 -> because those could be the keys to the kingdom,

2456.49 -> as some people say.

2458.89 -> Out of the box, there is some confusion

2461.5 -> about the VPC security group out of the box.

2465.61 -> It is 0.0.0.0/0.

2469.42 -> And that does cause some concern.

2472.57 -> And in a way, it's not opening your Managed AD

2475.33 -> up to the internet.

2476.163 -> So it's not really insecure

2479.02 -> 'cause you can't add an elastic IP

2480.94 -> to your Managed AD ENIs that are in your VPC.

2484.15 -> So there is no way for it to be public.

2487.24 -> But what it does allow is allow anything

2489.37 -> within the VPC to communicate with a Managed AD.

2492.13 -> That may or may be appropriate.

2494.226 -> If that's not what you need,

2496.09 -> you can tighten that down even further

2497.62 -> to certain CIDR blocks or IP ranges

2501.73 -> and only allow that communication.

2505.39 -> The lower the blast radius, the better for everything.

2509.08 -> Also, another thing to keep in mind is

2510.58 -> where you place your Managed AD and Active Directory,

2513.25 -> even on EC2.

2517.542 -> Whoever has full admin into an account can take snapshots.

2520.54 -> They can change security group rules,

2522.58 -> change network ACLs, change routes.

2525.28 -> So they could cause you pain.

2526.66 -> Also, they have the ability to take a snapshot of an AD,

2529.72 -> which you may or may not want.

2532.12 -> So keep in mind where you're placing the Managed AD

2534.76 -> and who actually has full access

2536.98 -> to the AWS account that it resides in.

2543.746 -> With that said, some of the items we touched

2545.71 -> on are flexible deployment options.

2550.06 -> A variety of patterns that we use to deploy Managed AD,

2553.96 -> whether that be using it

2556.72 -> as a standalone Managed AD

2558.37 -> or integrating it with another on-premise AD via a trust.

2563.02 -> We talked about some of the ways you can secure your AD.

2565.63 -> And also, we can talked about trust relationships

2568.39 -> with AD as well, and some of those myths.

2571.78 -> And we also talked

2572.71 -> about some recommended security practices.

2576.88 -> We're gonna be around after this as well.

2578.407 -> And if you have any feedback

2580.09 -> or anything you'd like to talk more about,

2582.94 -> I'm also here for the next two days.

2584.77 -> So I'm available, if you want to set up a meeting,

2588.43 -> set up some one-on-one time to dive deeper,

2590.517 -> 'cause I know this is a 200 level session.

2592.18 -> So sometimes the depth might not be where you want it to be.

2595.72 -> So if you want to go deeper,

2597.43 -> I'm happy to do that with you.

2599.74 -> And these are the links that will be in the slide deck

2602.74 -> once it's available to you.

2605.71 -> It's kind of self-explanatory there.

2607.87 -> The very bottom one is the blog I was talking

2610.33 -> about with trust.

2611.163 -> So it goes into details

2612.04 -> and has that diagram that's actually

2613.45 -> in the slide deck as well.

2615.67 -> The hybrid DNS on Active Directory,

2618.1 -> that's using route 53 with your AD,

2620.95 -> using route 53 resolvers with it.

2622.587 -> That's a really interesting read.

2624.37 -> And I've used that one with a lot of customers

2627.07 -> and it's actually a recommended approach

2629.08 -> to use route 53 resolvers

2630.52 -> and create resolver rules

2632.8 -> to forward DNS traffic to where it belongs.

2635.41 -> And then you can just point everything to the VPC's .2,

2639.19 -> which is the .NET resolver for the VPC.

2645.01 -> With that said, I wanna say thank you for your time

2648.79 -> and we appreciate you being here.

2650.972 -> And like I said, if you have any questions,

2652.24 -> we'll be available afterwards.

2655.45 -> And my email address is in there

2657.25 -> and Dennis' Twitter accounts there as well.

2660.4 -> Feel free to reach out.

2662.89 -> And please complete the survey.

2668.817 -> - Thank you.

2669.65 -> - Thank you.

Source: https://www.youtube.com/watch?v=UsL3ilSUeyM