Showing posts with label Windows Server. Show all posts
Showing posts with label Windows Server. Show all posts

Tuesday, January 26, 2010

Stop Monitoring a Server in Varonis

When you have a Windows server that is going offline, but you want to retain all the historical information in Varonis ( the events and permissions) here are the steps you need to follow.

From within the Configuration Screen select File Servers. Then move to the server that you want to decommission.
1) Uncheck all of the boxes for Collect Events.
2) Uncheck the box for Local Accounts.
3) For each drive make sure the Crawl File System is set to Disable.
4) Click OK and you are all set.


Saturday, June 6, 2009

Active Directory Security Groups

Yesterday, during a Varonis training session, Paul Ezhaya started a great discussion by asking my opinion on strategies for naming security groups and organizing folders on file servers. The primary debate was whether to use security groups named after departments and roles or to use security groups named after folders that they provide access to. For example, if there was folder called Human Resources with sub-folders such as Employee Data, Forms, and Terminations, and folders specific to several departments how would we set this up from a security perspective? Would we create Active Directory groups based on Roles for the HR people who handle each department and then apply those groups to the corresponding folders on the file server? Or would we create AD groups named after the specific sub-folders and then add the specific people to those groups as needed? Along with the security groups we would take the lead in organizing the folder structure to match the security group naming conventions.

There is no “right” answer, but here are some of my thoughts on the Role versus Folder question.

In general, I prefer the Folder-based solution. The first reason is for the long-term security of your organization. Finding the data is always top priority so regardless of how you organize the folders; users will learn the taxonomy and adjust to it. You need to force the organization to apply security; therefore, if you organize the infrastructure in a secure manner, they won’t have to. Second, When you first set up your Role-based Security Groups you might have an accurate grouping of the users by department. However, over time people will not make the appropriate adjustments to those groups. After the initial setup fades away, when you add someone to a role-based security group to they can access a particular set of data, you may not realize what else that gives them access to. You may not it even give it any consideration because security will always be an afterthought. In a Folder-based solution, the security of the data is pushed to the forefront as the IT department knows what folders the Active Directory group gives them access to. And if the access is insufficient user will surely let you know, where the odds of them notifying you that they were given too much access in the Role-based scenario is highly unlikely.

Of course, we may have a hybrid approach. At the top level shares we might want to have security groups for the department and apply those at that level. Then we would turn off inheritance on folders with confidential data and apply the folder-based security to those folders. So we end up with a set of groups like this:

grp_HumanResources
grp_Terminations-RO
grp_Terminations-RW


Where RO is for the group with Read Only privileges and RW is the group with Modify privileges.

If there are other reasons for you to use a Role-based strategy then I would highly recommend an automated Identify Access Management system. I think that you will still find that the default will be to provide too much access, but the results will be better.

Saturday, March 14, 2009

Unresolved SIDs

When we are working on cleaning up security in a Active Directory environment using Varonis DatAdvantage, one of the common problems that we run across are SIDs that Varonis cannot resolve to a useful name. In most cases this is because someone has deleted the user from Active Directory, rather than just disabling the user account. However, there are cases when the SID (security identifier) represents a group or machine account. Here is an example:

SID: S-1-5-32-544

Nobody ever remembers what those are. In walks Jennifer!

A Varonis user that we were working with, Jennifer Crusade, found this great Knowledge Base article that explains common security identifiers in Windows operating systems.

http://support.microsoft.com/kb/243330

Hope this helps you resolve a question or two.

Friday, March 6, 2009

Turning off the Windows Server - Shutdown Event Tracker

I often need to reboot the lab server that I am working on. One of the minor annoyances is the Shutdown Event Tracker that pops up and asks for a reason. When you are restarting the box several times during one work period this can be a real pain. So I learned how to shut it off.

Running gpedit.msc (Group Policy Object Editor) gives you the option to change this. Go to Computer Configuration:Administrative Templates:System and find the Display Shutdown Event Tracker settting.

Change the setting to Disabled and you are all set. Another minute saved.