[MUSIC PLAYING] Hello, everyone. Thank you for joining our session around securing your Active Directory migration. I'll go ahead and start with a quick introduction of myself. I am Bryan Patton. I've been at Quest a little bit over 20 years.
And my first migration was literally in the year 2000. You can see my picture, I've changed just a little bit with my feature set over the last 20 plus years. That picture was actually taken January 2002 when I first started at Quest Software.
My first migration was shortly after getting out of the Marine Corps. I was an emotional wreck in the fact that it's my first job out of the Marine Corps. I was doing consulting.
I had some experience with Banyan VINES during my time in the military, but I was tasked with helping a customer move from Banyan VINES. They had had an acquisition of another company that had Novell So we had to get from Novell to this new system of Active Directory and Exchange 2000.
So I've learned a lot. I had a bit of imposter syndrome at that time where I felt way over my head in that I was scared I was going be losing my job. So that's a little bit about me. And Joe, can you tell me a little about your first migration?
Sure. So my first migration was in 1999. I had been a messaging and collaborative computing administrator before that and got a job working for a really large Silicon Valley company. And they had everything, everything that you could imagine, from operating systems to messaging systems.
And one of my jobs was to help them consolidate all of those systems together. And boy, that was a fun time. It was really interesting time in Silicon Valley and being able to do those migrations, try to consolidate all those things has really of started my career in focusing on migrations and the migration space.
So leading to this, there's a lot of different changes you'd probably do differently now that you're old and you have a little more wisdom, right?
So things have definitely changed a little bit.
I'm thinking back to the year 2000. AD was built to interoperate with absolutely everything. Microsoft wanted everybody to be able to use this different system.
Can you tell me a little about how-- I mean, you're focusing only on migrations. I focus on a lot of the different security stuff. How have things really changed in the last 20 plus years of you doing migrations?
Right. So migrations have changed. The biggest thing that we face today is simply the technology's changed. Technology's changed significantly over the last 20 years.
The biggest thing to understand is that 20 years ago, the tools that were available to do migrations were very limited. There was only really one, it was ADMT. ADMT version 2.0 came out in 2003.
I remember that.
Yeah. And so understand, though, that the environments that we're working in are different today. The security, the requirements around doing AD migrations in 2003 were very different. We have situations in 2003 where we were worried about high school kids with their USRobotics dial up modems trying to break into companies to steal games.
We saw the Anti-Root Force being recommended for most organizations.
Right. Right. Exactly. And so the thing with it is that that's not how security and corporations are designed today. Security is much more prevalent. There are ransomware attacks every single day. Every single day there are ransomware attacks.
You have a lot of ransomware 20 years ago?
None. There wasn't. There was no ransomware 20 years ago. And it's really important to understand that using methods to do Active Directory migrations that were designed 20 years ago do not fit in today's world in today's corporate environments. And it's understanding that the technology that you're using, the architecture, the methodologies that you're using to do AD migrations today cannot be the same methodologies that you use 20 years ago.
Yeah, 20 plus years ago you're still burning CDs to--
I haven't seen a CD in a while.
It's crazy. The other thing to keep in mind, and this is really important, is that Active Directory migrations in the past were simply that, just Active Directory migrations. There wasn't cloud technologies 20 years ago. But today it's prevalent. In almost every single environment that we work in, cloud technologies have some part and some component of most corporate infrastructures today.
So when we talk about doing Active Directory migrations, we're talking about not just AD. We're talking about all of the other systems that come into play when we start talking about these migrations. So everything is connected. What you used to know about Active Directory migrations where you take a server from here, a workstation, and you move it over there.
You didn't have to worry about all the other ancillary things that were coming into connection-- connecting into that AD environment, but today you don't have a choice. Everything is going to impact everything else and it's really important to understand all of those connections. Because if you miss those during your Active Directory migrations, your migration's going to fail.
Well, I'm even thinking the reason why people are doing migrations a little bit differently as well. At that time, people were getting off of Novell, off of NT, antiquated technologies. So the thought process when you're doing a migration early 2000s was I want to get there as quickly as possible so I can move all of my life. I think things have shifted just a little bit recently as well.
Absolutely. And understand that what it means for your project, your migration project, is that with these additional complexities, your project is going to take longer. You're going to need to spend more time planning. You're going to need to take more time doing discovery, testing, and validation. So the migrations that you did 20 years ago, again, are very different than they are today.
So what kind of considerations should people dealing in planning-- and that's keyword, planning an Active Directory migration.
Yeah. So the idea is that there are a lot of things you need to take into consideration. Again, we talked about everything being connected. All of your cloud infrastructure needs to be addressed. What servers are you moving? What workstations are you moving?
Are you dealing with people who work from home and not coming into an office, print servers, GPOs? All of those things are absolutely critical to understand before you start doing your migration project. If you don't have a good understanding of exactly what's going to be migrated before you start doing your migrations, you're going to run into problems. Your project's going to have issues and delays, and there's going to be some very unfriendly executives.
Another thing to understand, too, is that when you're doing these types of migrations, you have to take into consideration the health of your source environment and your target environment. So those are things that are really, really important to understand that if you're trying to migrate a very unhealthy source environment into your target environment, again, you're going to have to have problems. So it's important to understand what's happening in that environment, not just what's in it, but what's the health of it. Is replication time valid?
Are there lots of DC issues? All of those things have to be taken into consideration before you actually do that migration and before you actually start doing any work.
So we want a healthy relationship--
--not an unhealthy relationship.
Very. Very much so.
Well, and thinking back, too, there wasn't-- 20 years ago there, wasn't any tenants, or Azure instances, things like that.
So there definitely seems to be like a lot more complexity--
--today, versus the days of yesterday.
That's why planning is so important.
So unfortunately habits get created. People are creatures of habit. You learn how to do things one way, you don't want to ever deviate.
So there's a lot of common misconceptions around migrations. What are you seeing? What would you be doing differently now than 20 years ago? What do you hear about all the time? So you're dealing with this all the time. I only hear about it occasionally.
Yeah there's so much that you have to understand about AD migrations. For those folks that have been doing AD migrations since ADMT came out, they have some basic understanding of how it works in that they tend to stick with those ideas. And so there's a lot of misconceptions that have to be addressed when you're doing migrations. Really important stuff when you start planning because again, remember this is not 2003. So there's a lot of different things that we have to address in these migrations.
Do you migrate GPOs? Do you need SID history to come over? Trusts, passwords, DL, security groups. In the past, there was a very specific way that you had to follow in order to do your migration. If you didn't follow it that way, it caused problems. But it's important to understand, again, that technology has changed and the typical things that you did 20 years ago do not apply again.
Yeah. I smoked 20 years ago. I don't smoke anymore. Luckily some things have gotten better for me, personally.
Exactly. So let's talk about these misconceptions and let's talk about them specifically, because I think that's going to be really important to go through. So you don't need a trust. We don't need a trust anymore. Most cases, you don't need a trust to do these migrations.
But I trust you.
I trust you, too. But again, it's really important to take the knowledge that you had from those legacy migrations and throw it away. It's a totally different world today when we're talking about doing Active Directory migrations. Again, prereqs. Oh my gosh, when we talk about the legacy tools and we talk about prereqs, it's pretty scary.
You have to deploy very old services that have a lot of vulnerabilities in them. You don't want to do that. You don't have to anymore. Again, the problem is that a lot of people get very comfortable with how they do migrations.
I've been using an ADMT for 20 years. I know exactly what to do. I know what buttons to click and PowerShell scripts to run, and all this stuff. And switching is challenging. Switching technology, switching tools.
It's a little bit hard to learn a new tool, a new methodology. But don't be the guy on the screen sitting on the couch with his remote control just flipping channels. Just because it's easy doesn't mean that you should continue to do it that way.
I remember Windows 2000, they didn't even have firewalls. So it's like OK, that's why you need to set up firewalls. The original versions didn't even have firewalls.
Right. Yeah. Again it's using technology from 20 years ago, using methodologies from 20 years ago where-- shut off firewalls. It's OK. Again, you had to worry about high school kids and dial up modems. It wasn't such a thing right. OK, it's all fine. It's a really, really different world today.
All right. I know this comes up all the time, group policies. There's been a little bit of a hiatus, like OK, some customers are actually going out to Intune. They're changing their managing, but they still exist. And it's a common thing because GPOs are there to set up configurations that you want across all these computers. It's a common thing. Should you migrate your GPOs?
So all right. This is a question I literally get asked three or four times a week for doing migrations. What do I do with them? Of course, I'm going to migrate my GPOs because that's where all my security containers-- everything is defined within my GPOs. Of course, I need to migrate my GPOs.
Don't do that, OK. Don't migrate your GPOs unless you need to, unless there's a specific reason to do that. The problem with GPOs is that in most cases, in most cases, not all, GPOs have been in place forever and that I've added a GPO to do this and a GPO to do that, and I've added a GPO to address the problems that this GPO created, and now I've created another one to do this, and you have suddenly massive layers of GPOs, no idea who administers them, or what they do.
And so most people when they think, oh, well, I have to migrate my GPOs, it's because I don't know what they do. I don't have a good handle on what's happening with my GPOs. And so the problem is if you take those GPOs as they sit today, move them over into the target environment, what are you migrating over?
What are you bringing over? What are the security ramifications of doing that? Oh, I don't know. So the reality of it is in most cases, my recommendation to customers that are doing these types of Active Directory migrations that have a lot of GPOs, catalog, inventory, identify the GPOs that you have in your source environment. Figure out what they do.
Then, as you start moving into the target environment, understand what's business and mission critical for those GPOs and start building those in the target. Because this is your once in a lifetime opportunity to reassess, reevaluate everything that you're doing. Take advantage of this time. Evaluate your GPOs. Start developing better policies and processes around creation and maintaining those GPOs. Don't just migrate them blind.
And Joe, remember Active Directory came out, what was it, 1999, 2000, it was GA. GPOs were new.
Yeah. Oh, yeah.
And the people that created those GPOs 20 years ago probably aren't there anymore and their experiences have changed. So you're really going to move over 20 plus year old settings. Or I got out of the Marine Corps in the year 2000.
Since then, the government has what's called the STIGs, Security Technical Implementation Guides. Why not look what the government's recommending people get configured compared to what you do and create some new policies? I don't know, it sounds like a good idea to me.
Yeah, absolutely. Absolutely. So again take this opportunity to clean things up. Take this opportunity to address your GPOs. Because again, GPOs are critical to the security of your infrastructure, and getting it wrong, moving garbage over to a new environment, that's going to not be so good.
All right. Age-old question, I remember SID history getting released. It was a big thing, even Server 2003, that Microsoft had the ability to delegate out the ability to do SID history for certain different objects as well. And SID history was added to make people get to AD a little bit faster back from the NT days.
And I think-- I've done a migration, my first migration, we did not use SID history. And it still just blows my mind because people always think that you have to. Do you have to use it? Should you use it? Pros and cons.
Yeah. So that's a big one. Again, it's a question that we get asked every time we talk to customers doing migrations. Do you migrate SID history? So the easy answer, that's why the easy button's there, the easy answer is sure, push the easy button. Let's do SID history. It'll be make things better. The migration will go smoother.
But the reality of it is that if you don't migrate SID history, you're doing a lot to protect your environment. The idea is that if you do SID history synchronization and move SID history over, it will provide seamless access to applications that still exist in that source environment, meaning that you're logged into the target, it will allow you to access those applications, those resources, things like that in the source environment without having to authenticate.
Well, that sounds great, right? That sounds like exactly what I want because I want to try to minimize the disruption for my end users. But there's problems. There's significant problems with synchronizing SID history around security. There are many vulnerabilities tied to SID history.
You have to weigh the security risk with the end user convenience because it's important to understand if you don't synchronize SID history, what does mean for the end users? Well, it simply means that when they try to access a resource in that source environment, they just have to provide credentials to do it.
Or you reacl it.
Or you reacl it. So again, try not to push the easy button. Try not to take the old school way of doing Active Directory migrations. Oh, of course, we've got to do SID history. You don't. You don't anymore. Because the impact to the end users isn't what it used to be. It's very minimal now.
Project risk, security risk. Which is more important
Passwords and trust. Oh, this is always a fun one. I did a security assessment last year and I saw a password that hadn't changed literally since 1997. They did an in-place upgrade from NT and they still had a very privileged account with a password that hadn't changed-- well now, if they haven't changed it yet, it's been 25 years. You going to migrate that password?
Right. And again, this is really important. Passwords. Everybody is saying, oh, well, of course I've got to migrate passwords.
But do you? Do you need to migrate all the passwords? Do you need to migrate the passwords for your system accounts, and your privileged accounts, and your administrator accounts versus just the user accounts?
The idea is that you have options now. You can choose whether or not you want to migrate passwords for some, all, or none. It's important to understand also password policies and complexities.
Is it less complex in the source versus more complex in the target? How do you deal with that? Well, you change the password policy complexity in the source to match what's in the target prior to doing any type of migrations.
The other thing to understand from a security perspective and it's really important. If you're syncing passwords and an account gets compromised in the source, it's now compromised in the target as well. Very important to understand that you now have account for two separate environments.
Yeah, there definitely-- there's a relationship there that needs to be understood.
OK, trusts. Again, old school. Of course, you have to have a trust. A trust is actually required for the old school tools, for the ADMT tools. You have to have it.
Adding trust adds exposure.
Oh my goodness. So the idea is that, again, using methodologies from 20 years ago, you were required to have a trust. You don't today.
Trusts in almost every scenario are not required to do a full Active Directory migration. So just understand that the technology has changed significantly. And those methods and the processes that you used 20 years ago, they don't apply anymore.
There are ways.
Yes. Yes, indeed.
Oh, this is always a fun one, group migration. I still see this all the time. People are merging, doing admin groups, stuff like that. So what are your thoughts around group migration and should you even migrate them?
So this is one of the actual most important things to discuss, and this is around data security and why groups are really, really important to get a handle on before you actually do your migration. Let me give you an example. You have a source environment and a target environment.
In your source environment, you had a file server, had a folder in it. And in that folder was an Excel spreadsheet with everybody's salary information in it. Everybody could see it who had access to that folder.
That folder was protected by the source HR group. That source HR group was really tightly controlled, monitored. There were only four people in it. Only those people who really needed access to that information had access to it. But now you're doing a migration.
So now you've got this HR group in the source that's protecting this folder. What do you do with it? Do you sync it over to the target? Well, but there's already an HR group in the target. Again, really important to understand that you now have to deal with two groups called HR with two different sets of uses.
So if we were to merge the two groups together, we take those four people that are in that source HR group and move them into the target HR group, we move, then, that data, we reacl that folder, and move it over into the target, suddenly a lot more people are going to have access to that Excel spreadsheet with everybody's salary information in it. That's not good. You do not want that.
So you have to, again, plan ahead for how you want to deal with these types of groups because it will 100% affect the security of your data if you do not have a good plan for dealing with group synchronization and migration. I mean, domain admins group. Oh my gosh. Who knows what's in there?
Hopefully you have zero domain admins. Unfortunately, that's very rare.
But that's the recommended things that people should be doing. So don't just migrate stuff that you have now. You may want to change the way you're managing your environment, even before you do the migration. I see an example there, Joe, greenfield does not mean secure or healthy.
I did a security assessment on a greenfield environment and they still had users and domain admins logging on to workstations. So if you don't change the behavior in the target environment, and you just migrate everything from the source to the target, do you think the environment's going to stay pretty and clean?
So you may want to consider changing behavior before migration, [INAUDIBLE] different policies that are more relevant to 2022 versus when AD first came out.
Yeah. And spend the time. Again, spend the time to evaluate and assess not just the source environment, but the target environment as well before you actually start moving people over.
All right, future state migrations. So for the longest time, it's been move everything from here, from this building, to this building. But now there's more variables put in place. There is Azure and other IS stuff and other different things.
There's other capabilities as well. What are your thoughts around future state migrations?
So this is, again, a really important thing to take into consideration. The adoption of Azure has been significant, has been steadily growing. More and more customers are talking to us today about doing Active Directory migrations to a hybrid environment, becoming hybrid connected, or even moving to an Azure-only environment.
The important thing to understand is, again, going back to the planning phase, making sure that you understand that doing things like moving to an Azure-only environment are very beneficial in the long run, but take time to be configured properly, set up properly. Because, for example, there's no GPOs in Azure. They don't exist.
You have to use Intune and all of the Azure-based tools to manage the security of your environment. So it's not just as easy as picking up a workstation in your source environment and moving it up to an Azure-only environment because you have to have the entire infrastructure in place, everything secured, everything planned, everything configured before you migrate that first workstation up into the Azure environment.
So again, please remember that you have to do a lot of planning, configuration, before you can start adopting those types of Azure configurations and start doing your migrations.
I'm thinking about exponential growth, too. There's Azure and I have a theory that there may be some groups in Azure that were created back in the '80s. So going back to different operating systems, I used to work on Banyan VINES that got released in 1984. Novell, 1983.
Quest, four years we've had NDS migration tools. Back in the '90s, we had Banyan migration tools to NT, and people keep kicking that can down the road. Groups are typically used for authorization of stuff. I've had many organizations that have migrated groups from Novell and Banyan to NT, to Active Directory, then they hook it up with Azure AD Connect and now those groups and objects may be sitting in Azure Active Directory.
At a certain point, you may want to consider not kicking the can down the road and start cleaning up a little bit, right? Do we really even need this different group? I've seen many organizations where there are more groups than there are user accounts in the environment.
That's a little bit problematic. Groups are authorizing access to different stuff. One, let's identify what those groups are actually being used for to see if they're relevant or not and start getting that under control.
Now you mentioned the word, assessment, identify. Let's clean some different stuff up. I feel that before even doing a migration, since security is very relevant, we need to start thinking about our security model.
There is the enterprise access model. It's a matter of categorizing and tiering different things. I've heard other different speakers at TEC talking about tier zero. If you have not yet established a tier zero, why are you doing a migration to begin with?
You should be understanding that certain assets are more important than others. You should change the way that you manage those different assets to begin with. This is a slide from the enterprise access model from Microsoft and I highly advise every organization, before doing a migration, start categorizing this. Start figuring out what should be categorized as tier zero.
And once you have the tier zero, we obviously have [INAUDIBLE] that helps out some of that stuff, there's other stuff that you have to really understand those relationships. Your AD backup server, your ADFS, your Azure AD Connect. Those should always be categorized as tier zero.
And as you're doing a migration, I don't care if you're using ADMT, if you're using Quest, whatever, categorize that as a tier zero server. If I can get access to that server, I can do whatever that account has access to. And typically, most migration accounts, what kind of access do they have, Joe?
Oh, they have global admin, domain admin, they have enterprise admin, you name it.
So figure out those relationships to those most critical assets. Understanding those relationships will allow you to change your behavior, especially before you put it in a different trust. And if you're already at a high exposure rate and you add a trust, now your exposure rate is even higher because objects from the other directory can now compromise this directory as well. That is if you choose to do a trust to begin with.
Another recommendation, KRBTGT. 20 plus years ago, most people didn't even know what it is. This is part of Kerberos. Remember, Microsoft used to work with just NTLM. Kerberos was implemented within Active Directory. It wasn't until some different breaches happened that different recommendations for different people are like you know what, maybe you ought to change that Kerberos Golden Ticket, or the KRBTGT every once in a while to get rid of any Golden Tickets that may be the environment.
Golden Ticket. Do you remember what the default time to live is per Golden Ticket?
So somebody's created a golden ticket because they had that KRBTGT password hashed, maybe before I do a migration I had to create those policies and procedures where I start changing that periodically.
Exactly. You got it.
Get in the habit of some good security practices. You can look at your KRBTGT password last set now. Did you know that it's a best practice to change this twice a year? I personally like to change it any time anybody has access to get it to that hash leaves the environment. So that's just one thing you may want to take consideration. Let's change the way that we're managing our environment.
We talked about SID history earlier.
Yes, we did.
There is a MITRE ATT&CK matrix. I recommend checking it out. There's a lot of great information on SID history.
SID history has been used for a lot of our attacks for many, many, many different years. And you'll notice in MITRE it mentions you should clean up SID history. So if you decide that you want to use SID history, it's not always bad, because maybe you have to do a quick migration. You don't have the luxury of time. Make sure you add the ability to clean it up.
Yeah, and to add that, I was working with a customer a couple of months ago and we were talking about doing attribute migrations, and they came to me and they said, well, we need to make sure that the SID history value in the source objects get moved over.
Yeah, they wanted to actually migrate this the old SID history to the new environment. And I was trying to figure out what was going on. And we started talking and they had six different SIDs in the history value because the objects had been moved six different times.
Now we're migrating them again. We're going to add a seventh. And I asked them, well, why do you need this? Why do you need to migrate six old SIDs that probably don't work anymore? And their answer was, well, we don't know what it'll break.
So we figured we'd just bring it all over. Yeah, don't do that.
Overcome your fear. Have a backup plan. There are options available. So a couple just things to recap on SID history. You don't have to migrate using SID history. You don't. I've done a migration before without using SID history. I think you've probably seen some customers recently do without SID history.
Yeah. Oh, yeah.
Or most of them think that you have to.
Exactly. It's that--
They automatically go down that route.
--old school way of doing migrations.
You shouldn't migrate existing SID history. Stop kicking the can down the road. Go ahead and clean it up now before you're just muddying your new environment during a migration.
And if you are doing a migration, SID history injection's a real thing. Maybe you want an allow list where only my migration account can do SID history from this one box. If anybody else is doing SID history, maybe I want to know about that because that's automatically bad behavior. So just then to take in consideration.
Applications. NTLM, Kerberos, do we even know what these different applications are using? We still see organizations with NTLM version 1.0. We don't know what's using NTLM version 2.0.
This is a little trick I always like to recommend. When you're doing application remediation, you can put a regular user in the protected users group. And what is the protected users group? It restricts the ability to authenticate with NTLM. So if their account gets locked out, you know the application they're testing against--
Yeah, you now.
--is using NTLM. You can use this time to actually gather more information about your network, learn about it so you understand what you can or can't do. So just another something to think about.
And if you're not using protected users to manage your other different environment as well, maybe you've got to start taking into consideration. It's been around for 10 plus years, and it does add some extra level of protections to any kind of [INAUDIBLE]. Just remember, don't use it for your service accounts, but use it for administrator-type activities.
Password policies. Some password policies were created probably back in the '80s with Novell and Banyan and haven't been modified. NIST has a lot of new different guidelines. So the guy that set the initial password policies from NIST in the early 2000s, he regrets it. He's looking back, his perspective has changed.
We don't need to change passwords every 90 days. I still see organizations doing migrations that haven't had the thought process that their password policies should be changing as well. If you're making change happen, maybe you actually change your password policy before doing a migration. Maybe you make them change it now before you do the migration so you can migrate over a better password.
Obviously, password requirements have changed, your password policy suggestions have changed. I saw some other presentations. Service accounts to be 25 plus character-type passwords. So you really migrate over a password hash that hasn't changed in 20 years? Probably not. Yeah, let's go ahead and have that impact prior to the migration and not during the migration.
And there's a lot to this because it's important to understand the impact of the users. We understand that password policies are complex, and they're tough on the end users, and they're challenging to implement in an existing environment. We know that going in and putting in a 25 character password minimum size is going to be really challenging for your existing users, but for those people that you're migrating, right now you can take advantage of the migration to say, hey, for those users, we're putting in a new policy.
This is the new policy. And then you can start slowly introducing it into your existing targeted environment if you need to. But again, take advantage of the situation. Take advantage of this migration to make those changes that you have been hesitant to change before.
So we started off talking about my first migration, Joe's first migration. I've changed personally, professionally along the last 20 years. Migrations have changed. They'll probably continue to change. So the biggest takeaway I have that I'd like everyone to absorb is hopefully you can change your thought process and your perspective how you're doing migrations.
Right. And again, I talk to people every day about migrations, and so many of the people that I've talked to are still stuck in 2003. They're still stuck knowing the old technology, the old methodologies for doing Active Directory migrations. Take that information, throw it away.
Really important to understand that technology has changed significantly and that we can do migrations much more secured, much safer than you could 20 years ago. So again, please do some research, look at some of the third party applications that are out there to do Active Directory migrations, and understand that you don't have to go old school.
You don't have to be the guy on the couch clicking the remote control. Take the time to learn the new tools. It will help your organization maintain the security of your environments during these types of migrations.
And thank you for attending. And if we can answer any additional questions, I don't know all the answers, but I'll do whatever I can to help you out.
All right. Thank you, folks.