Welcome to our KO Cole webinar, ensuring the security of Microsoft Active Directory and Azure Active Directory. This webinar is supported by St.
Paris, and speakers today are GUID Clinton Meyer, who is Chief Technologist at Samis and me Martin Koo. I'm Principal Analyst at cope, Cole Analyst. Today we will have a look at the changing roles from on-prem ad to is a hybrid or pure Azure ID environments and what is relevant from a security perspective. We have a look at, we'll have a look at the agenda in a minute before a bit of housekeeping. So we have audio control turned on, so there's no need for you to care for your audio.
We have a q and a session by the end, but you can enter questions at any time into the right hand side of your screen. Usually you'll finally go to webinar control panel and there's also the option to enter questions and I always say the more questions the better for the q and a.
We do a recording of the webinar and we will provide the podcast recording as well as the slidex for your convenience later on so that you can review the webinar or look at the slidex, whatever you need. And last not least, we will run a few poll that during the, in fact we run two polls.
And the first poll is one which we run right now, which is a very simple one to answer is really about what do you have in place today? Is it the traditional on-prem ad? Is it only the Asher active director? Is it both or is it none of them? So let's launch that poll and give you some 30 seconds or so to provide you answers. Please enter your current states. So the more answers we have, the the better it is, the more valuable if time allows, we'll then look at the results during our q and a session. So don't be shy in answering.
Okay, another 10 seconds I'd say and then we'll close the first poll.
Okay, with that, let's have a look at the agenda for today. It's a already told will go look at really the world of Azure ID and ad from a security perspective. The first part of we will be take a little bit higher perspective in the sense of, I look at how is this evolving, which is the role of Azure id also a bit different than, than than where the strategy heading. And so which type of security and why do we need in these environments and what are some of the key aspects to look at security.
And then follow me, I'll take a maximum 20 minutes following me and will really dive into the very detail of this and look at the most common abilities and ad and ready, the danger, how to fix it and how to really work and then analyze security in these environments.
And as I've already mentioned, then we will have the q and A session by the end. So I think the, the important thing is I had, I personally have a long history when it comes to active directory. So I've been working with that since the early earliest available beta versions.
I've been, I've started working with Windows and T back in the days with the early beta versions. So I've been, and I even worked with OT with some of the bridge. So I have a long history, I've wrote a book number of books and trauma about whatever Windows server 2003 to handbook and all that stuff. So I have quite some legacy, but when I go back to to AD and, and how this entire thing is evolving, then I think we need to take a different perspective today and we, we, we need to understand this that all of this is part of a bigger identity management story.
So this specifically Azure ID is, is really delivering into a, into a broader identity management capability for smaller and meeting sized business that might be more or less the solution for, for key requirements. While for larger organizations you still need to think about which parts of your entire identity and access management think, think just about all the authentication stuff, the federation stuff that comes with should provide it be provided with by these platforms. So it takes a central role. And what really is changing is that we, we see this, and I I'm blunt on that.
We see that the traditional Microsoft active directory, so the on-premise active directory is on its road to legacy. The Microsoft tradition is very clear and it's clear for I would say at least two or three years for everyone. There's a clear focus to this Azure active directory as part of their right now called Microsoft and platform.
And it's not on-premises active directory anymore. That doesn't mean that on-premises active directory will disappear quickly everywhere.
It will take the time because we have applications depending on the on-prem directory, we have environments that take the shop floor, the factory where it may even survive for for many, many years because things aren't changing that fast. But we also need to be clear, the active director is not a strategic part. The active director is the preferred choice and it's also the standard nowadays to put Azure active directory, so to speak, at the forefront. And if so then then go back to on pre 80, not the other way around anymore.
That also affects the primary user authentication, which is changing as well. And why I brought up this identity fabric picture is also because that to my understanding affects the ownership of directory. So on directory is still frequently owned by an infrastructure team, more as a network team, which to certain extent has its validity from from, from a historical perspective.
But with the the capabilities and Azure active directory has, you also need to be very clear, Azure active directory must become a part of the overall Im poster because it provides APIs for building digital services to work against. It provides the integration to assess services to to support federation, but also a lot of integrations, legacy applications. So quite a number of hybrid capabilities, proxy integration, head HD integration and different other things. And so we should resy where, where is Azure AD placed?
And my perspective is very clear, it must not be part of a workplace team or infrastructure team. It must be part of the Im because this where where it really fits in. Having said this, let's continue and look a bit more at how does it pop up, how does it appear and and what does it mean from a, from a overall security perspective.
And here we have a bit different patterns where when we look at which place does it take, so, so one of the common patterns, and this is at a very high, very abstract level I have to say one of these patterns is, is really a very simplified big picture for large organizations when it comes to life cycles like access governance etcetera. And there's on the left hand side to HR and other data sources are feeding workforce information and others maybe done beyond workforce information into the IGA solution, the identity governance and administration which has connectors, workforce etcetera.
And that connects them to the active director and the Azure ID as a target system or it might may even be that active director and Azure Id also form a central vital part of the IHA offering. So that at the end depends, but in many cases it's, it's another IHA tool sometimes also quite quite legacy out there for more than a decade.
We, we frequently see solutions these days that are out there for for close to two decades or or even a bit more. It goes straight maybe SAP access control or SAP cloud IGA or other solutions and connects them to system and supports these systems. But we also have truly direct connections and these large organizations then security frequently something which runs a bit different on the right hand side like the STEAM tool and others. So for security information and management that runs in the security operations center.
However with the ID role in there and the Azure ID role actually it holds true for both but Azure ID becoming the more and more relevant part of it. We also need to understand, we just can look at security at a high level across all these things, but we need an in-depth security for these central platform even more if you really fully utilize the the IM capabilities and when you go to a a bit of separate path IM, which is the access management part.
So authentication, think about windows, hello for businesses cetera, then it becomes clear that Azure ID is a very sensitive part of what you have in your IT infrastructure and that means you can do a ton of things and you should really position it well and think about how strategic is, how relevant is it, which is the right role of it, but you also need to protect it.
Well because specifically actually really but also in fact on ED where we run still a lot of authentications on, its part of your front door to your organization and you won't leave in the age of five crime, you won't leave your front door open and unattended. So we need an then also to the point is yes, clearly there are things we can look at from an out perspective and collect and see, but there are many, many specifics and GUID will will talk about this more in detail but we, we need the specific capabilities without any data.
When we go to perspective, also very simplified in monarchy oversimplify picture for small, small and medium business or small and medium organizations. Then you have some manual fulfillment for systems that are not connected to AD or Azure ad and you have some systems that directly connect to that. In that case, security actually looks a bit different again because you need that security tool that at least serves your world around AD Azure AD and maybe systems, but mainly this really this world we are talking about today. Maybe it goes beyond that and can do other systems as well.
But at the end in in these environments very commonly the on premised and increasingly active directory and most of you have answered that they have. So I think more than 90% that responded to our earlier poll today that we have Azure AD in place. So it's aous, we need to protect it, we need to understand how important it's and how can we ensure, can ensure that it remains secure. So we need that security solutions and provide us insight into the details as well.
The insight into what is specifically happening in that world with for SMBs with the focus on AD and Azure for large businesses as an addition to what you have in security for deeper level of security for these relevant and highly sensitive environments. Ideally it also supports your world of traditionally exchange nowadays Microsoft three five or three five however you you call it. So this is what we, what we need. We need strong good security here.
Security is is really the thing we need to have. And what are some of the key capabilities?
I don't want to go that much into detail because Peter will, will, will really talk way more about it and and look at many, many specific aspects really drill down very deep. So, but look at some of these aspects I feel are are essential to cover here.
So, so one is clear the system support, it must, what do you do in security must support your courses. So AD and Azure AD are or systems for a few of you who only have Azure ad it maybe might be simpler because you say okay I just concentrated on that for a device venture majority, so close to 90% saying we have both. It means ideally a solution covers both in depth cause as I've mentioned the on-prem id, it's legacy, no doubt about it but it will not, most environments will not go away quickly.
That's the other side of the coin.
You need interfaces that that help the administrators doing their job efficiently to understand your risks drill down. So modern capabilities ideally not just something in the good old management consult style but beyond in-depth analysis because this is at the end, how can you really understand what is happening, what does it mean, what are the the back, what is the background of that? So not just generic security but really in depth asses easy to use a subset for everyone without a steep learning curve. Yes there are things that are highly complex.
I remember in whatever two days, decades ago or so I started using the network networker to monitor, to analyze how the DHCP protocol really works and how other things really work. That's probably not the level of of of knowledge you need at the beginning, but it should enable you to, to get to a certain good level where it's relatively quickly easy to deploy.
It's a hybrid world and it must run in a way that is adequate to that world and it must help you now immediate results without complex setups and configurations but out of the box analyzes, reporting cetera.
This is what I feel we need for securing this essential area here at the center of what you have. And truly we can add more things around that as a service and XDR and whatever is is popular there but at the end if you don't do the the groundwork and protecting ad and A is part of the ground work, you don't do robot trump. So that was basically my presentation. I wanna close with the second poll which is more about what is your strategic plan for the use of on-premises if director, Is it a good old ad, has it never been in use, is it already retired?
Do you plan to retire ever in the next 36 months or will it take longer to retire? So when I look at the intermediary results, no big surprises here, please participate, we leave it open for another 15 or 20 seconds. The more people participate the better it is.
So come on.
Okay, thank you. And with that I hand over to
Welcome and thank you for having me on this call we're gonna drill down into the topic of the most common vulnerabilities in active directory in Azure AD right now. And what I first want to start with is a lovely statement from the CSO of Microsoft, Fred Asana around, you know, how do hackers actually work? Well they don't break in, they log it basically has it all in that one line that this is all about protecting your identities.
Yeah, wherever they are located, hackers don't use some crowbar to get into your environment. They basically use an identity, they log on and then they do harm. They take over an identity that somebody else has been using before and from St. Paris. We've concentrated on basically looking at what are those risks that are out there with your on-prem active directory and Azure active directory. Basically the identity space that's currently used in 90% of companies that are often very Microsoft centric, that is where you live.
You still have your on-prem active directory like Martin already just mentioned in the previous part of this session that even though you want to migrate to Azure AD and that is clearly what Microsoft also anticipates you to do because let's not forget active directory is old enough to now drink. Yeah. So we are officially all enough to drink 22 years. That's when it was released in in with Windows 2000.
And that makes it just by its age legacy technology, but not only its age as product also from the, from the focus from Microsoft, Microsoft is putting all of their energy into enhancing and they're doing a very good job at that Azure active directory. Your on-prem active directory has had the last update in coding in terms of features and and functional updates with Windows Server 2016. There were a lot of updates still back then.
That's six years ago. Yeah. So nobody should be expecting that anything new is going to come in this world of protecting your active directory.
At the same time you are combining the authentication workflows from your on-prem environment with your cloud environment. This picture shows Azure and basically other identity providers that you might be working with Okta G Suite and to essentially access cloud resources Office 365 and whatever else. Now at the same time while we are moving into this direction, the bad guys have noticed hmm that nice technology that's still being used in majority of companies out there, the on-prem active directory is still around and like Martin mentioned, it won't go away anytime soon.
We have it dependencies. We built dependencies on this technology over the past two decades, not so much for our end works stations, end user workstations. I would hope that a lot of you have already migrated those to be be Azure joined and basically have your users authenticate against Azure.
At least you have the capability to do so, but you will still have your user accounts in parallel to that in your on-prem active directory for the legacy applications for what drives your business because this is all about application migration to the cloud.
Yeah, making your business applications work natively in the cloud, just running the same Windows net application in the cloud doesn't allow it to use oof and other protocols for proper authentication and authorization. So that's known by the intruders. And so instead of trying to get to your Azure active directory, typically the focus is how about we first go on-prem and from there we go anywhere.
So it starts with for the majority still with phishing emails and malicious websites and I think we can all agree if we didn't have any users in our environment, we'd be much safer because they would not click on those links then.
But let's also agree that well business couldn't run without the users obvious point. But the point is also that those phishing emails, they get better, more or less every day they get more tricky even I need to check on some of those things.
Mm, okay, that's that's, that's not good. And yes we have tools on our end devices and you need them to help protect your users to not click on those links to, you know, to categorize emails as spam and whatnot. That's good help. But there's always some new things that come through where you wonder why is that, why wasn't that detected yet? And somebody will click on those links and if the right system is being used by that user, some zero day will be used by those malicious websites, malicious links and there you go.
The intruder is inside your network and once they're in, the first thing that they will do is basically working on building a control system.
That's that second part of the in face, the post post exploit face where the intruder from that loader downloads other malware for the recon phase established remote connectivity to have something to actually work against in your environment. And very often that's not just a single uncontrolled system but multiple at this point. Ideally your security tools will pick those up and of course warn you.
But too often that's still not the case and the next phase begins and that's exactly where your active directory comes in and to the most extent it is your on-prem active directory with vulnerabilities. We're gonna have a look at quite a few in the next couple of minutes, but why is it that that it is being thought after? Well because it basically holds the keys to your kingdom.
Yeah, your active directory is controlling access to all of your business systems and and the intruders, they don't care for your active directory, they just use it.
It's a great tool. It's basically the system that most of your Windows systems in your ecosystem on-prem and often even in the cloud trust. Yeah. So you give your active directory the trust if you're authenticated to it, you can think of group policies, you can assign tasks and perform changes on any system out there that is connected to your active directory domain or forest.
And so if I get ahold of that, I can do anything and that is exactly what the intruders are after and what the tutors are doing, they basically don't care about active directory. They use it as a tool, extract the proper information, the credentials to get to your core business data to eventually extract business data to hold it against you with a ransom fee. Pay this or we're going to release that business data or sell it to other interested parties and often it's a dual attack basically adding an encryption to all of your systems to of course make you pay faster.
Now to give you a sense of how quickly such an attack can work today, mind you this is in a not well protected environment, not even a day. Yeah. From the initial access, this is from a, a recent evaluation from cyber reason on the Bumblebee loader that after the initial access that is a user clicking a malicious email link and performing some reconnaissance and different steps in between, well described in the link that I've provided here, worth a reach to understand the mechanisms used by intuitives.
The bumblebee loader was able to basically get to that level credential theft and privilege escalation within 19 hours. Basically at that point the intruder was already domain admin had domain dominance and then extracted the NTDs did, which is basically the database of active directory containing anything, all your users and all your groups and passwords. Now that's not just the risk for your on-prem active directory now to then get to data in your on-prem environment that risk, that active directory is carries on with you into the cloud.
We are reminded of solar Solaris.
So gate attack where basically a Golden SAM attack was used, that's basically a Golden SAM ticket was used, was created to attack Azure Active directory. The basically where the Solaris tenant was located or that was the Solaris tenant where the Orion software was located. And that golden SAML token worked because the Azure active directory basically trusted the ADFS Federation on the Solaris on-prem active directory to create a token to allow somebody into the Azure world.
Well an attacked on-prem active directory can retrieve the secrets required to generate a proper token that ADFS would generate and pass it on to a to Azure active directory without being reauthenticate. There is no MFA requirement there. And that's basically the path that in that case attackers used. That's why federation, it's good as a technology but of course it needs proper monitoring.
You must monitor it from both sides, Azure and on-prem active directory with timestamp differences as to like when was the token actually generated from your on-prem federation system to allow somebody in and does that match on my Azure side? Did the right guy actually enter? That's not a trivial task to perform. You don't have that when you use Azure deconnect with password hash synchronization.
So with all of the examples that I'm giving here, of course you have an underlying synchronization of your user accounts from your on-prem active directly to Azure AD and like Martin mentioned, could also already start going the other way around, did your provision into your Azure ad? But your users still need a representation in your on-prem ad to then have access to your legacy business applications.
So the Azure AD Connect, allowing the password hashtag synchronization is something that I personally prefer because it's giving you an in in independent log on to your Azure AD resources from your on-prem active directory.
Just for a moment, think about what it means when your on-prem active directory isn't there. Completely encrypted, wiped out and customers that I've had the pleasure to of course support to survive have been there when AD is gone, nothing works. Yeah.
And if you at least have those passwords synchronized into Azure ad your users can still authenticate into the Azure ad world and if you're lucky, of course your Azure tenant wasn't compromised at the same time. That depends on how you configure the two in terms of interoperability. So the last option pass through authentication on this slide is basically just one more option that mostly SMB clients are using to spare themselves the setup of additional system like Federation server but they don't want to synchronize the hash into Azure, which again I recommend as a good option.
And then you have the pass through agent on your, on a system in your on-prem environment that basically authenticates on behalf of your on-prem active directory and then you know, France the signin into your Azure world.
It's doable but be aware of the risks. There are always new findings out there and I've just talked about the golden SAML exploit with Solar Gate and the Solaris Orion attack.
But even for past with indication there has been findings, this was actually already basically introduced sometime in August or so by Secure Works they've found a way to basically add another PTA server to for the Azure active directory system to point those those authentication requests to and then that rogue system was able to garner credentials just by being there. Good explanation in this in the link that I'm posting here.
Again, worthwhile to know about to get a good feeling. Are you safe? Is this how you want to continue or do you maybe want to change your approach on integrating on-prem active directly and Azure ad There is an update coming from Microsoft that apparently addresses that PTA issue but don't bet on it that there won't be something new.
So looking at the overall and very generic cybersecurity framework, I think the key thing is you have to identify your own risks in your environment and that's what I'm gonna try to help you with for the last minutes that we have in my presentation here to understand what is it actually that I need to protect against. And it all begins with, first of all understanding that there are a lot of default read permissions that Microsoft has basically built into even any new active directory that you deployed today.
Mostly when you start something new today, you wouldn't generate new active directory domains but you will have situations where that's required. Maybe your OT environment that you simply cannot connect to the Azure world, to the cloud world that you want to keep offline. Basically not connected. Active directory is still a great service for those environments.
Nothing wrong with even deploying new systems in those environments, but be aware of the default security.
So what I'm showing here is the pre Windows 2000 compatible access group permissions or actually memberships just the name should make you feel awful that that, that that group is being used because that of course means we're looking at using a technology before when those 2000 was released. Yeah, that's NT four style security and that's exactly what that group does.
It gives full read permissions to user objects, group objects and of course another l d type INET or person that hardly anybody uses but so it's, this is mainly about your group and user objects that this group with the authenticated user by default allows anybody to read. Yeah, so any of users can read all group contents and specifically even security sensitive user details, hardware settings, last password set if password is even required.
Those are secret or not secret but sensitive settings on a user object that you don't have to be able to read as a normal user.
Other tools might need it but not your normal users And of course intruders know that that's, those are the default permission and they won't go too much into detailed on the next default permission, which is just as bad or even worse with the admin SD holder, which is the permission that is stamped on your most privileged objects, the main admin group and of course all of its members. Yeah, enterprise admin schema, you name it. The groups that are most sensitive to manage active directory and their members are protected by this acle and by default inheritance on this is disabled.
Maybe I should have even used the green color here because that's good that it is disabled by default. I've seen customers where that was enabled, that's why I'm highlighting it here.
And that means you're actually removing a key element of a protection of your privileged accounts because that means other permissions that you might have set down the tree help desk reset password permissions may also apply to your domain admins. Unless this domain admin is protected without inheritance, then that is blocked but worse.
You see there's again read permissions for authenticated users and that pre witness to thousand committable access group, those can be removed. There's nothing wrong with that. You need to do some additional, you know, adding of tools that might also build on those permissions. But your active directly has no problem working without your users being able to read whose domain admin and who is enterprise admin and whatnot. That's exactly that permissions that intruders are using to do reconnaissance in your environment.
So making that hard for the intruder gets you very far already intruders and of course red and blue teams are using and should be using security scanning tools in the context of your normal user to find out what an intruder once they're inside your environment can actually see that will allow you to get an understanding of what it is that that that is potentially dangerous and can be misused against you when an intruder makes it into your network.
I'm gonna show you a few slides on Purple Night. That's a free tool from St.
Paris that we've brought out last year and it's massively successful because it's easy to use. You basically download it, it's a zip file that you download, you're extracted nothing to install and then you run it and you can even check the security of your Azure active directory with it as well. We're focusing on the on-prem active directory because that is the directory of the most, hm, let's say vulnerabilities that that you currently have in your infrastructure most likely.
And for the Azure ad check you create an application account, basically an application identity in your Azure read only very low privilege to also evaluate some other details in that environment. And once you run such a tool it'll then help you understand what are the weaknesses that I maybe should take care of.
So we're gonna look at some examples. This is just a screenshot to give you a highlight of the, let's say the most critical findings in my demo environment that I was running this with.
And again I was doing this with a non-privileged account, just a normal user that is looking at your environment through the eyes of the intruder. That's exactly what they do. They use similar reconnaissance tools to find, hmm, which users do I need to hack in the on-prem ad that are then also privileged in the Azure active directory, building a bridge into the Azure ad or which privileges which users are privileged to sync the act, the on-prem active directory hashes, et cetera will get into some more examples in a second.
Just wanna highlight on this next slide that there's many, many more, maybe not so critical but still important findings that we also highlight with the tool.
And again, that is something free for you to use. Let me give you some more specifics already mentioned that if I have something that is looking my on-prem active directory and my Azure active directory, hey I can actually make guided guided. I can give you guided information on risks that you might have not been aware of that in my case of course it's a bad actor but it could be a normal domain admin that you have on-prem.
Of course granted privileged access and also added to privileged roles in Azure. That's like jackpot for an intruder. If he finds that you don't want that, you shouldn't even sync any of your privileged account to Azure active directly. That is the bridge that intrus are looking for because eventually of course they want to not just attack your on-prem environment, they also want to get into your Azure environment and you shouldn't build those bridges for them.
Here we have that finding of non default principles with DC sync rights on the domain.
Now most of you, especially those that have set up a hybrid environment, will find an account in this indicator for exposure that should be your on-prem Azure AD connect account. The account that's been granted the permission to sync with your Azure ad environment and that is a risky permission to grant but of course that account needs it specifically risky to grant the get changes, all permission DS replication get changes. All those last three letters are very important. The all cuz that allows that account to sync the hashes, the password hashes.
And again I recommend that you do do that to sync the hashes into Azure ad but you do need to have an account that has that permission. Now where is that running on? That's the question you need to answer for yourself.
Where is my Azure AD connect system? It should not just be any other server. You need to treat it like a domain controller. Tiering. Tiering is the the topic here. Tier zero is where your domain controllers are and tier zero is also where your Azure DECONNECT system should be.
If you find other accounts with these permissions like my Fred account here, of course you need to rip them out or explain yourself. Why is this required? So a domain controller is not an administrator. A simple thing that you can overlook, simple thing that an intruder can find, it is just a permission on your domain controller's object and you'll be surprised how often we find it. Why?
Well because often it's a different user, a lower privileged user and let's say normal server operator, not a domain administrator that often provisions machines in your environment and and maybe your process is designed that that's the server team that even provides a new system, a new server for your domain, for a new domain controller that then is taken by your domain admins and you know performs to promote.
But at that time that system was already in the domain.
It was a computer object that had the owner of the creator, your server administrator, your lower level server administrator potentially. So again a nice attack vector for an intruder to get to domain privileges because if I own the domain controller I own not only your domain but your forest. So last example that we find everywhere in in environments using active track for quite some time, there's plenty of service principle names that are privileged and that the problem is the privileged. You do need service principle names for functional use of legacy application to ize them.
SQL is a good example and installation of sql, you know Microsoft is always trying to help. So in the insulation routine of sql, if you happen to authenticate with a domain admin account, SQL just registers against that service against that account is actually not necessarily a service account at that stage, but basically allowing to be found by intruders for curb roasting.
Spns service principle names are again a mechanism that is used for izing applications. Nothing wrong with that but they should not be privileged accounts.
Curb roasting means I can extract the hash as a normal user, I can extract the hash of that user through the method of how I find that SPN and then I can hack it very often it's not well protected in the sense of a long password, shorter passwords, all the accounts often have short passwords can be hacked very, very easily and then I'm in, I can take over the environment so just hide that again free tool purple night. But let's be clear, it's not just risks that intuitive use that are on-prem native. There are key risks that are native to Azure active directory.
There would be plenty more to talk about that we can't dive in in this rather short time that we have today.
But of course you need to be aware that Azure active directory has little in common with active directory except for those last two words in its name Azure ad. Yeah it's a totally different technology Underneath there is no organizational units, there's administrative units at least, yeah isn't forced but you have tenant, you don't have root policies, you need other tools like in tune to manage your clients, to manage settings on your clients.
Currently that's all inside your on from active directory, which by the way does make it so attractive for in tutors. You've got new machine identities, application identities to worry about in Azure active directory.
So the, the whole concept of how to secure Azure active directory is different and Martin was right what used to be, you know probably infrastructure oriented teams managing the on-prem active directory cuz it was seen as not so much a security tool but you know a system management tool is just different in in the cloud.
So it's your security teams, your IAM teams should be managing your Azure ID and they'll certainly have a say in how synchronization would work with your on-prem directly.
So the permission model in Azure IDs of course built radically differently from the on-prem D with built in roles, lots of built in roles, maybe even too many of the point is it's difficult to know what they're actually doing without delving really into the details. You have to understand which permissions you're actually granting when you add users to a role or potentially via a group that's now possible to add them that way. You have to basically really work on doing the lowest privilege possible to grant users application.
And yeah, data access and guest accounts is just not the same as as guest account in your on-prem active directory.
The first thing that you did in on-prem ad disabled that account if it wasn't disabled already in your Azure active directory, the guest accounts or your B2B accounts that you need to trust and basically make sure that you configure on the setting accordingly in Azure AD to not trust them too much cuz by default there they can also read and enumerate group memberships and you can tighten that down to just grant access to the the literally the information that the guest account itself has in your tenant.
Nothing else.
So they can then not be used for enumerating other risks in your environment. So active directory remains the of a hybrid environment and I've mentioned don't sync your on-prem ad admin accounts, any privileged account into your Azure ad that is something that is perfect lead for intuitives to use against, you don't want that. That goes the same with that third bullet that you of course even more don't want to grant them privileged access in Azure Id use native Azure ID accounts for privileged roles in Azure id. That's the way to go.
And doing some of that lockdown of your active directory security really makes it harder to have any reconnaissance in your environment. Don't forget intruders do take that least effort path if you and your neighbors are attacked and your neighbor makes it much easier to get further while the intruders go that path.
If they have a hard time finding who's actually privileged in your environment to go after those accounts and elevate their privileges. So make it hard for them. That goes a long way continuously scanning those environments. There's it's, it's a requirement.
Any tool that you use, again named a few good ones, they're point in time tools. It's worthwhile looking at professional tools that help you to do that. Continuously scanning your on-prem and your Azure active directory for vulnerabilities that you might otherwise not be aware of.
Okay, that's it from my session. Thank you very much. And we now have enough time for q and a.
Yeah, so we are at the q and a. We have a couple of questions here.
Maybe one, one more formal technical question I'd like to answer first. We will not send the slides but we will make them available for downloads. So when you go to the event web where you register cetera, I think usually latest by tomorrow find the recording of the webinar as well as the PDFs of slid there. So that that is this question then I have, I think it's, it's, yeah I think basically there are two questions. The one is, can you just read stuff and analyze or can you make changes to ad and ad?
Can you just repeat the question Martin?
I'm not sure I
Can you can you only, only sort of speak read information out of ad and AD for analyzes or can you also make changes in response?
Oh okay. So that's actually a good question and and it's probably regarding the tooling.
Yeah so, so you have a tool that scans active directly for vulnerabilities and a question basically probably for RS Paris tool, is there also like a right click fix at four B option And the clear answer is no. And that would also be quite dramatic because most of the findings that you see are elements that basically require the administrator to look at it, understand often it's application related things that you must check with your application responsible people before you rip out ker constraint delegation as an example.
There's plenty of those things that you cannot just fix with a touch of a button. There's guidance as to how you fix it. And that goes also for Azure ad where for example we might highlight legacy authentication is still in use. That's not a good idea. You should basically disable it and where to disable that.
Yeah, but we don't disable that for you and we couldn't because we expect to be used with a non-privileged account.
Okay, so do you require an agent another question on your tool?
Not for, not for this initial scan. There's, this is agent list, this is all running through LD queries. Ideally you actually have in your sock environment sensors that would blink and highlight something fishy is going on in my environment because don't forget the, the queries that such tooling is doing, not just our tooling. Also other tooling is doing, it's checking for sensitive information in on-prem and in your Azure active directory that a typical user wouldn't check. A typical user doesn't enumerate all spns in your forest.
A typical user doesn't check for ous configurations of computers and users. Yeah. Et cetera.
It's, it's those enumerations that the right sensor tools, Microsoft Identity as an example actually highlights and says I've seen these LD queries coming from that machine. Take a look.
Is that, is that okay? Because if it's not you doing that scan, it might already be the intruder.
Okay, there's an interesting question. Do you offer some sort of a sandbox or or testing or demo environment where, where users can, where customers can have a look at the tool not needing to ly play around with it from the beginning in a production environment?
That's the case for our commercial products that I didn't intend to introduce here cuz this is not a marketing session for our tools. Of course we do have professional tools to scan active directory continuously.
Our directory services protector does that and to also protect active directory from, you know, be able to back it up without malware and more importantly restore a whole forest in case that everything is too late and you've been flattened those tools. DSP Directory Service Protector and adfr, that's what we have sandboxes for that customers can try and in those sandboxes they can technically of course also run purple night. But since Purple Night is such a simple tool to use, anybody can use it in their own middle test environment.
And don't forget, even if you run it in your production environment as a normal user there you don't have, there's no risk. Yeah, there's inherently the risk that your sock says, Oh bad boy that wasn't nice. So ideally of course you do this with your security team.
Okay, another question, a bit more technical and, and probably more on the good behavioring ain't good actions in your environments. How can I ensure that I don't accidentally synchronize privileged accounts from my on-prem ID to Azure id?
That's a good, that's a good question because it comes down to, I've mentioned the tiering model. It comes down to good hygiene of managing active directory where you have to have a separate OU where your privileged accounts are in.
Yeah, you first of all have separate accounts, you don't have your office account that you manage an active directory with. So that's where it starts. You have a separate admin account and, and that account is in a different ou it's completely located differently from your normal office worker accounts.
Yeah, in a different OU structure. I mean active directory does offer that nice structuring through organizational units and typically would be a top level ou, where then with your Azure AD connect or other synchronization mechanisms, you wouldn't sync right from the root of your domain or domains in, in a forest you'd select your proper users container. If for some reason they're spread all over starting from the root, then you could still in the tools exclude that tier zero OU were your privileged accounts are in.
So it's all about positioning the accounts correctly, that's how you are successful and not accidentally synchronizing them.
Okay. So I wanna, in interest of time, I wanna quickly raise the result of one of our two polls and then we maybe can take one more question and I proposed either the student can follow up directly for the questions we can't answer within the session.
So, so when we have a quick look at the poll, it's I think interesting and not really surprising to see that most have or are using some form of active directory. So on-prem AD has been retired at least 12%, which is above my expectations. There are plans to retire, but I think two-thirds still, and I think this is just reality not planning to retire on prem ad within the next 36 months. So we will have hybrid environments for, for quite some time and we need to protect them adequately maybe in the remaining time was trying to answer the long question short.
So, so the question is one of the guiding principles the person has us or that organization has to leverage ever increasing collection of security capabilities and tools that are provided within ad and ad. So where, where are the, from your perspective, the, the main reasons where you really need additional tools beyond what comes?
So what, what, what I see in, in most accounts right now, and I think that's that's not a bad start, is to start on your end points. You have to protect your end points. The point is that if you don't also do something to monitor actively your on from active directory for changes and your Azure ad for, for things of the unexpected Yeah. Activities that are happening in this, these environments that, that you want to be informed about a change of a role in Azure, a change of a privilege group in on pre AD as an example, then you're blind. Yeah.
Because you don't know once an insurer has garnered some credentials, some, some privileged credentials, what they actually do with it. And that's what you want to know about and that's why your next step is to have active monitoring in both of those environments to ensure that you can respond.
Okay, great. So we, we are done with what we can answer today. As I've said, you will follow up directly with the ones who have open questions. Thank you very much. Thank you very much to Empress for supporting us. Thank you GUID for all your input. Thank you to all the attendees for listening to this call webinar. Hope to have you soon back to one of our other upcoming webinars. Thank you.
Thanks.
