See Why and How to Audit and Protect SYSVOL Directory

[MUSIC PLAYING] Welcome. This is Quest Unscripted. A vlog series on trending topics. And Quest solutions related to Active Directory. Office 365. Oh, and don't forget Azure AD. You are here because you have questions. We're here because we have answers. I think. We will address questions we've received from customers. Who experience the same challenges as you. All with the goal of helping you confidently move. Manage. And secure Your Microsoft environment. We call the show Quest Unscripted because, Except for the central Nothing we see is scripted or rehearsed. And we're pretty sure you'll notice that right away. All right guys we're going to be talking about Cisco. Question for you Brian. Can we audit Cisco Directory changes and why should we do it. We can audit changes within Cisco either by changing the files or somebody is trying to change the group policies which are contained within the Cisco Directory. So absolutely, we can do both those different things. In fact, the GPL setting changes are audited by default. But I'm thinking the question more relates to, if somebody had physical access to the files on Cisco, could we detect it. And that answer is yes. Let me ask you this. Why should we do it and can we protect changes from happening? Yeah, well, change audit has events out of the box to provide that-- the event data that we need to audit Cisco. And it's just a matter of-- like Brian said, it's just a matter of configuring a template to include that Cisco Directory. So it's a good idea because GPL templates in there you don't want them being modified directly. There's other ways to audit like Brian said. Ways to audit the GPL themselves. But the templates, the files, the actual files that are within the Cisco folders should be audited. Just for the same reason why we would audit any file that could be compromised or modified in a way that it would affect all in the entire environment. And the other part but-- There's the auditing. But then there's the protection, what can we do to prevent something from happening in the first place. Is that where you were going, Rob? Right. So from a protection perspective, it can definitely be done. We can definitely configure within Change Auditor a template that's going to stop access to those-- to the Directory into the content by then. But the question I have sometimes with doing that, with any protection that we set up with Change Auditor is you have to consider that there may be other systems, other things that are changing within the environment. And by blocking the access you may be preventing day to day activities that shouldn't be happening. So it's a good idea to acknowledge that the protection is there, be aware of it, maybe set up alerting. So that when there is a change and it is prevented someone knows exactly why those changes are being prevented. So a good idea to lock the doors but know that some other folks have the keys and be alerted when someone's trying to get in. But you know it's all about just security postures. It's to be aware that I have this level of security for good or bad. I will allow the good, allow the day to day changes that will occur but I will know and I will be alerted if something happens. In case it's a bad actor, I will know about it and I will stop it. So it's all about awareness of what you are actually protecting. It's just a more secure surface area for us. And I'll try to point out something else as well. If you're trying to get more control over GPL management, we do offer GPL admin or maybe advanced propulsion to Microsoft. You could actually have that exclusion within change Otterson to Change Auditor to prevent everything except from this allowed account that's processing changes on. All right. I appreciate it guys. Thank you so much. Thanks Thanks.