Posts

Managing Data Access on Windows Fileservers: Tooling & Reporting

Step 5: Tooling & Reporting

Tools, Quality Checks, and Reporting

The last step in managing data access on Windows fileservers is implementing proper tooling and reporting. Management of folders through tools, quality checks, and reporting is important for maintaining the integrity of your IT infrastructure.

Without using appropriate tools for checking the permissions, effectively managing folders can be a cumbersome process and prone to security leaks.

A professional folder permissions tool will run a quality check and give a report listing all the users/groups together with their allowed level of access, allowing you to make informed decisions.

Even if you create multiple security groups with permissions for each individual data object, as much as this could seem to be a very large number of groups in the AD (Active Directory), a good reporting tool will make your life a lot easier.

Deploying a reporting tool will minimise any administrative confusions and the advantages will make you have more quality sleep.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-10.png

Support Using Scripts

Scripts are versatile tools that can be used for managing folder permissions and ensuring their security.

The administration may seem confusing at first glance, but the construction of permissions can be mapped in an Excel worksheet, as explained in the previous chapter.

That is, the administration of permissions can be monitored using a simple Excel table. One can, for instance, create a matrix for every object type (file access, mail distribution, SharePoint access).

By using a simple VBA or PowerShell script, the permissions can be transferred to the AD automatically.

In this way, an administrator does not have to have direct access to the file system. In addition, administrators will no longer have to fight through the AD and the file server ADLs.

By running a script, requests requiring changes in the permission structure can be easily taken care of.

Support Using Tools

There are, of course, comfortable systems for taking care of administration tasks that provide the administrator or person in charge of permissions with a nice UI with many possibilities, especially if none of them have scripting experience.

These tools make it possible for a less-skilled administrator, who does not have a deep knowledge of permissions assignments in the NTFS file system, to carry out administration tasks quickly and easily.

In other words, these tools make it possible for the administrator to have a life without worries, since he/she will no longer need to spend a lot of time administrating groups in the AD and does not have to work on the permissions in the file system again and again.

Instead, the administrator will be able to allot additional time to more meaningful tasks.

Security Analysis and Reporting

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-11.png

When the assignment of groups to folders has been done, it is possible, with some effort, to do manual analyses of the effective permission holders.

Everyone who is a member of a certain group will have a specific access permission to a specific object and, if necessary, its child objects. That means that the access possibilities in each area can be shown by a simple analysis of group memberships.

Here is an example of a simple PowerShell script that lists who can access “Accounting” and which permissions each of them have.

The same is true for persons (Individual Active Directory accounts). An employee is a member of certain access groups.

Because of the uniqueness of the membership, it is possible to show immediately which objects the employee can access and what permissions he/she has.

But what if the security groups are nested? For instance, what if a group is itself a member of another group, whose members have access to a specific folder.

In such a case, the analysis will be more time-consuming and prone to errors, as it is easy to lose track of things in more complex contexts.

As already mentioned, professional tools offer far more possibilities and a more comfortable user interface. In addition, such tools do not require coding expertise and can be provided to the data owner or even directly to users.

Documentation

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-06.png

Surveys show that only about half of all IT administrators document their work. Thus, many are not documenting how the administration of permissions is taken care of or who, why, when, and where permission was gained or revoked and by whom.

If there is a data security breach or audit, this lack of planning can have serious consequences.

As an administrator, you should ensure you keep updated and audited reports of folder permissions; otherwise, the security consequences could be difficult to contain.

No Tools for Managing Security Rights

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\transparency index03-01.png

Without any tools to manage security rights, you will lack control over your critical infrastructure.

The complexity of IT is constantly increasing. This applies not only to applications, networks, data quantities, and possibilities, but also to globalisation and the use of resources that are not on-site or that have been leased.

Administrators are being confronted with increasing demands and are frequently overburdened and unable to cover the breadth of all of their activities.

Because of that, it is imperative to deploy tools to make the work easier, reduce the effort required, generate automatic documentation, and maintain the integrity of all processes.

Download Checklist

Click here to download a checklist that will assist you with implementing proper tooling and reporting

Conclusion

For the previous couple of articles, we’ve talked about the following five steps to managing access on Windows fileservers effectively:

We hope you’ll make use of the steps to take your data access management to the next level.

Do you have any comments or questions?

Please post them below.

Managing Data Access on Windows Fileservers: Assignment of Users

Step 4: Assignment of Users

Assignment of Users to Active Directory Security Groups

The fourth step in managing data access on Windows fileservers is properly assigning users to active directory security groups. If this is not done correctly, it can lead to unauthorised access to shared data and critical losses to your IT infrastructure

Security should be implemented through well-defined groups. Users should be assigned to groups and the groups granted the rights to access the folders.

This way, the users enjoy access to the folders based on the group privileges. Since it’s easier to maintain the integrity of your systems by managing groups than individual users, users should never be granted access rights to folders directly.

In most cases, ordinary users should not be assigned Full Control permissions. This permission level is a huge security risk because users can misuse it. Worse still, if it gets into the hands of attackers, it can lead to heinous consequences.

It is recommended to implement a least privilege permission level and minimise the permissions required to allow access. Usually, Read and Write permissions are sufficient to allow users to complete most tasks.

The basis for the assignment of users to folders is a rather complex question and answer game.

For each folder that needs to be protected with permissions, ask the person responsible for the data which users should receive which access rights. Please follow the processes described in the previous chapter.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-08.png

You can use a permissions matrix to help in gathering necessary data and providing documentation for the permissions assigned to users. These matrixes can easily be made using an Excel table.

For each folder that needs its own permissions, make a row. In the columns, the users that have access to the folder will be recorded. The necessary permissions can be specified with a “W” for “Write” permissions and an “R” for “Read” permissions.

With this matrix as a starting point, you can plan and create security groups within the Active Directory and assign users to the appropriate groups.

These tables should ideally be administrated directly by the person responsible for the data in question (the data owner).

A matrix should be created and maintained for each department. Otherwise, a very large matrix should be used to administrate the permissions for all departments, in which case other persons should not be allowed to change the content of cells.

Importantly, once the matrix has been created, it is essential to implement a continuous authorisation process in which the assigned permissions are audited. This way, the data permission integrity will not be compromised.

If an authorisation process is not adopted, it can make the permissions to revert to their previously chaotic state and cause security risks, such as privilege creep.

Example:

An employee from Human Resources needs to read the vacation lists from Sales. This is stored in: “\\Department\sales\planning”

So that the HR employee does not gain access to the entire “Sales” folder and subfolders, he/she must first be put into the LIST Group for that folder. By using this step, the HR employee can open the “Sales” folder, but cannot read or change data. At that point, the HR employee must be assigned to the group “FG Sales Planning R”, which granted them “Read” permission for the subfolder. That employee will then be able to access the subfolder planning and read the data within.

In short, this “LIST” permission allows someone to “take a walk” through a closed area.

No Assignment of Individual Permissions

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02_Artboard 4.png

As earlier mentioned, you should never assign individual permissions to users. Using security groups to control access to critical data minimises the risks of direct permissions and ensures easy management.

However, the permission structure is not always as simple as the company structure. Often, it will be necessary to create permissions that originate outside of the data area.

For instance, it might be necessary for an HR employee to have access to the company’s personnel planning table, which is located in the data area of “Sales”.

In this case where sensitive information should only be accessed by a specific individual, the IT administrator should not assign the HR employee to the Sales group. Instead, the administrator should provide that employee with permissions for this folder as an individual or even provide only the permission for a single file.

Failing to assign rights well will have fatal consequences:

  • If a search is to be done to find out where an uncooperative user has access permissions, it would have to be conducted on all servers, which is a difficult and demanding task.
  • If an employee changes their area of work or department, it is no longer easy to know which permissions must be changed. If there is no documentation, no one will know what permissions that employee had.
  • If an employee leaves the company and their account is deleted, then an “SSID corpse” (an unreadable identification code no longer be associated with a person) will remain in the ACL list of the folder.

Download Checklist

Click here to download a checklist that will assist you with assigning users to active directory security groups.

Next…

In the next step, we’ll talk about implementing proper tooling and reporting.

Managing Data Access on Windows Fileservers: Assignment of Groups

 Step 3: Assignment of Groups

Assignment of Users to IT-Objects (Folders)

The third step in properly managing data access on Windows fileservers is to use security groups for assigning permissions.

A group consists of a set of users who have been granted certain permissions. This way, implementing and managing permissions become easier rather than assigning permissions to individual users.

To give users access to data (whether the data consists of email distribution lists, file structures on file servers, or SharePoint spaces), administrators can create groups and assign them the necessary permissions.

For example:

You can give an employee from the Sales Team direct access to the folder “\\departments\sales” with “Full Control” permission. Doing so will allow the user to read the data and make changes to it. But what else will that user be able to do? With “Full Control” permission, that employee can also assign permissions and revoke them. Potentially, he/she could revoke access permissions for all other users, including administrators. Therefore, assigning such individual permissions is not considered a best practice and can lead to administrative nightmares. It is recommended to assign permissions via Active Directory groups. What if this user only needs permission to read data? Should this access be the same for each individual member of the sales team?

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-08.png

Assignment of General Security Groups to IT-Objects (Folders)

The usual, though incorrect, approach for creating permission structures is as follows:

A permission group is created for a department (e.g. Sales). At the same time, data areas will be created (e.g. file services, SharePoint spaces, and mail distributions).

The group “Sales” will then be assigned to these data areas. For example, this group gets “Write Access” permission for the file server folder “Sales” and “Read” permission on the web server. The mail distribution group is also taken care of using this authorisation group.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-03.png

Next, we are faced with the following challenges:

  • The managing director would like to have access to “Sales”, but does not want to receive email from that group. Should the managing director be automatically put into the “Sales” group?
  • A trainee starts in “Sales”. He does not need access to mail distribution, but only requires “Read” access to the data areas. What permissions should he be given?
  • An employee from Human Resources needs “Read” access to a subset of the data area, but not to the web server. How will we proceed in this case?

In all the above cases, the simplest approach is no longer viable due to the following dilemma:

The permission groups should be constructed on the basis of the organisation’s structure, not on the demands and requirements of the data objects.

Permission Groups vs. Secure Objects (Folders)

The solution for the problem described above is as follows:

For each IT object, (in our example, each folder in the file system), access requirements must be defined. For all underlying objects, (in this case, more folders and files), this will be done implicitly through inheritance of permissions. This principle means that at least one security group must be created within the Active Directory for each object requiring permission (e.g. each folder).

This assignment of dedicated permission groups to each folder with permissions has all the desired benefits for daily operations and reports.

For each folder, it is possible to say exactly who has which permissions and access to the data in said folder, such as the users who are members of these particular permission groups.

Furthermore, we know what a user’s permissions will be thanks to the uniqueness of the assignment of an object (folder) to a permission group.

It is important to give the security groups succinct and intuitive names. With a proper naming approach, the permissions can easily be associated with their specific groups, making administration easier.

You can also nest security groups (add groups to other groups) to lower the number of permissions that are required to be awarded to users or groups individually.

It can be said that a 1:1 relationship exists between the objects (our folders) and the groups within the Active Directory, while a many:many relationship exists between the users and permission groups.

For the moment, we will ignore the fact that different groups are created for “Read” and “Write” permissions.

The below diagram shows how this works:

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index01-01.png

Different Permission Groups for One Folder

For our example, we will create three security groups within the Active Directory for each folder that requires permissions:

  • A group for the award of LIST permissions
  • A group for the award of READ Permissions
  • A group for the award of WRITE Permissions

The below screenshot shows the three permission groups for the folder “\\departments\Sales”:

“Read” permissions are assigned when a user only needs to read files within a folder. For example, all public information about a project in the folder “Project Office” or all lists with sales prices in the folder “\\departments\Sales\Items” would be covered under “Read” permissions.

“Write” permissions will be awarded only if a user needs to alter files. It is important to keep in mind that assigning “Write” permissions also gives the user the permission to delete.

In the two examples above, “Write” permissions would be assigned to the staff members in project management or the project office who create and maintain information, as well as the staff members from the sales team who specify the sales prices based on internal calculations.

List permissions are required when a user needs rights to the folders deeper down in the file tree, but he does not have “Read” or “Write” permissions for all the folders on the levels above.

This will ensure that the user can access the folder to which he/she has received permissions.

With Excel and some knowledge of scripting, it is possible to construct a simple way to create and administrate these security groups with folder permissions.

Restriction of Folder Permissions and Assignment of Permissions to Permission Groups

After all the necessary security groups have been created within the Active Directory, it is necessary to give these groups permissions for all appropriate folders. One should start with the highest folder in the hierarchy. In our example, that would be the “Sales” folder.

The process of allocation of folder permissions is done in three steps:

i). In the first step, any existing inherited permissions must be deactivated or revoked.

This will ensure that the folder will only have explicitly assigned permissions. If you deactivate the permissions, you should also delete the associated user account(s) from the Active Directory so that the user(s) no longer enjoy access.

ii). In the second step, the permissions for the administrator group must be created. The following best practices are worth taking note of:

  1. The built-in account “system” receives “Full Control” permission. This is important since the operating system uses this account for certain services and processes. Thus, you should ensure that this permission is always granted.
  2. The local group “Administrators” will likewise receive “Full Control”. This ensures that the server administrators always have access to the necessary data and permissions. In addition, some backup programs also need these permissions to function correctly.
  3. Furthermore, you should create a security group for operators and administrators with “Full Control”. This guarantees that the IT administrators have the necessary permissions for the daily operation of the file server.

iii). In the third step, the security groups created for each folder must be assigned to the folder. The awarded permissions will be assigned as follows:

Awarding Additional Permissions for Deep Data Sub-Structures

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-07.png

You should avoid setting the level for managed folders to go very deeply within your folder structure. You can limit your folder structure to go not more than the fifth level.

If there are no restrictions on the number of levels in the file structure for the assignment of permissions, the complexity of the administration tasks increases exponentially. Suppose that the average number of subfolders in a file system is 10.

The complexity of the administration and documentation of the highest-level folder will be 10. If a second level is included, the complexity will increase to 10×10 or 100.

If we further assume that the average folder depth is 10 and that there are no restrictions on folder authorisations, the management complexity will be 10 billion.

That means an IT administrator may theoretically be required to manage 10 billion permissions. This further complicates documentation, reporting, and changes.

Avoid “Deny” Permissions

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-09.png

The need to deny a user access to a specific folder does not mean that you should use the “Deny” permission, as doing so increases the complexity of administration, documentation, and reporting by an unnecessarily large magnitude.

For example, during each assignment of permissions, all “deny” groups within the parent data areas must be checked.

When planning the folder structure, one must always keep this consideration in mind and structure the files with their permission groups in such a way that the “Deny” permission is not used at all.

In practice, this is easily possible if you present the users with a folder structure and do not capitulate to the requests of every staff member.

Do Not Use the “Share” Permission

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-10.png

When creating shares within a file system, it is possible to restrict access to the shares to which “Share” permissions have been given.

This unnecessarily doubles the complexity of administration. Instead, one should generally assign a “Write” permission.

Furthermore, to avoid unwanted attempts to gain access, one can hide the shares (by putting a $ sign at the end of the share name).

In Windows Server 2012, the “access-based enumeration” setting has the effect that a user will only be able to see a folder if he/she has a permission to see it.

Download Checklist

Click here to download a checklist that will assist you with using security groups for assigning permissions .

Next…

In the next step, we’ll talk about assigning users to active directory security groups.

Managing Data Access on Windows Fileservers: Processes and Responsibilities

Step 2: Processes and Responsibilities

Definition of Business Processes and Responsibilities

The second step in properly managing data access on Windows fileservers is to clearly define business processes and responsibilities.

Each user has a specific responsibility within the business premise. To carry out the various processes and realise the business’ goals, every user should be granted the privileges to access certain resources and undertake particular tasks.

However, allowing users uncensored access to system and network resources within the organisation can weaken its security and stability.

Importantly, access to computer or network access should be restricted based on the responsibilities of individual users within the organisation.

If a user is not responsible for a particular business process, there is no need of granting him or her permissions to perform the task.

Since controlling access to business data is the foundation of data security and, in some cases, of data privacy, universally applicable, mandatory processes must be defined together with someone from senior management.

The process of defining processes and responsibilities should be based on a comprehensive assessment of how a business operates, and should include input from the management.

The management must also be willing to give its full support to the implementation and enforcement of the role-based access control (RBAC) rules.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-08.png

What are Business Processes?

Business processes define work flows and responsibilities. In addition, processes can also outline the tools required or recommended for the execution of said processes.

Some examples of processes:

  • Data requests
    • Requesting permissions
    • Changing permissions
    • Withdrawing permissions
  • Creating new objects
  • Assignment of and changes to responsibilities
  • Assignment and modification of owners
  • Expansion of storage requirements

Processes are often presented in the form of diagrams. Below, you will find a simple example of an assignment of permissions.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index01-01.png

Compliance with these processes must be mandatory.

To ensure mandatory compliance, one must have the support of senior management or IT management, who must then communicate the necessary access control rules to all employees.

What are Responsibilities?

Responsibilities are defined based on the user’s competency, functions, and authority.

In an organisation, responsibilities can be created, changed, or discontinued depending on the prevailing needs and goals to be accomplished.

Responsibilities describe the types of processes that users are allowed to accomplish within the organisation.

Through assigning responsibilities to users, the management can ensure various processes are completed based on the intended goals to be achieved.

The IT department should work together with the management to ensure that users do not have access to resources beyond their stipulated responsibilities or level of control.

In case of changes in responsibility, the access level for that user should be adjusted as soon as possible. If a user has unnecessary access to a particular system, it can hamper the smooth running of the business process.

The following scenario illustrates how responsibility can be managed:

Irene works in the Marketing department and requires to view—but not create or modify—certain files from the Finance department. The Finance department, which is fully responsible for these files, utilises access control to restrict the users allowed to have Read-only, Write, or Modify access to them.

Irene is granted Read-only permissions to the Finance files. Likewise, the IT department resolves that preventing users such as Irene from creating changes to their systems can assist processes within the company run smoothly and enhance security.

Consequently, IT moves Irene and other users to the Users group, which restricts their actions to their assigned responsibilities and prevents them from making any reconfigurations to the system.

As a result, Irene has access to the resources she needs to undertake her responsibilities, the security of the processes within the organisation are improved, and stability of the network is solidified.

Responsibility of the Executive Board or Management

Administrators are responsible for the management of IT infrastructure, but they are not responsible for file structures or business processes concerning the assignment of permissions to data or other IT objects.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index03-02.png

Often there will be few or no documented IT processes, which indicates that documentation is not being done well enough.

Unfortunately, senior management will often place the responsibility for permissions in the hands of the IT administrator.

This is not a good idea. For instance, decisions regarding whether an employee shall have access to sales data will time and again prove to be poor decisions, especially if the “applicant” has better argumentation skills than the IT staff member or is located in another level of the company hierarchy.

In other words, if the head of the “service” department wants his employees to receive permission to access data in the “sales” department, the decision should only be made by the head of the “sales” department.

Managing Changes in Responsibilities

The responsibilities of users should be aligned with their data access privileges. In case of changes in responsibilities, the previously allowed rights should be revoked and proper adjustments made.

For example, giving new staff members with new responsibilities a handbook that describes the IT environment of the company and all of the company’s IT processes has been proved to be extremely beneficial in managing changes in organisations.

If a new employee requests for access rights, the data access privileges should only be awarded when the mandatory approval process has been successfully carried out – without exception.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-08.png

To demonstrate the execution of the individual steps in a process, it is necessary to have so-called “Use Cases”. Use Cases are step-by-step explanations of how an administrator (for example) creates a new file folder with individual permissions, especially when users change roles in an organisation.

Further examples are:

  • Awarding a new user permission to access a particular data area
  • Revocation of an old user’s permission to access a particular data area

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-07.png

Lack of Compliance with Business Processes and Requirements

Employees will frequently attempt to circumvent business processes. A typical example of this would be a call to the IT department, without filling out the required permission forms, to gain certain permissions.

This will typically be justified by arguments like “it’s important”, “it’s urgent”, “I forgot to fill out the forms, but the new staff member is already here”, “I have specific instructions from the boss”, “if I don’t get the permissions immediately, then….”

In such cases, the IT staff member will normally fail to document the assignment of permissions.

The reason that there was “not enough time” will often be used to circumvent clear instructions regarding file folder structures or permission concepts.

The following scenario is a good illustration of this:

There is a requirement that access permissions for a file server may only be given on the file folder level. Despite this, the department head makes a request to receive the necessary permissions to access a specific file.

To resolve this conflict, the IT administrator will have to create a new file folder and put the file into it. It would then be necessary to create and assign all permissions for this file folder.

Instead of doing that, IT administrators will frequently try to save time and give the department head the requisite permissions for the file as a “one-off” exception.

Best Practices

Here are some practices you should follow to ensure proper management of processes and responsibilities:

  • Implement the principle of least privilege, where users are granted the minimum access rights to carry out their responsibilities. This assists to ensure that if a user’s account is hacked, the consequences to the business processes are minimized by the limited rights the user possesses.
  • Periodically audit the responsibilities within the organisation to ensure they are aligned with the stipulated processes. If not, revoke the unnecessary permissions and make proper adjustments.
  • Do not give in to the temptation of creating exceptions for circumventing the already assigned responsibilities and rules. If you do this, you will be avoiding complying with business processes and requirements, and endangering the security of the organisation.
  • Recognise that not every employee requires a starring role, and properly grant access rights based on the stipulated responsibilities, and nothing more.
  • Ensure that the IT department works together with the senior management so that employees’ access privileges are properly aligned with their responsibilities within the organisation.

Download Checklist

Click here to download a checklist that will assist you with defining business processes and responsibilities.

Next…

In the next step, we’ll talk about using security groups for assigning permissions.

Managing Data Access on Windows Fileservers: Planning

 Step 1: Planning

Designing Folder Structure and Policies for Permission Assignment

Foremost, to successfully manage data access on Windows fileservers, sufficient planning is necessary—or failure could ensue.

Comprehensively planning the designing of folder structures and policies for permission assignment will greatly minimise administrative headaches and maximise productivity.

Planning how to set up folder structure for deployment to your team is indispensable. In the absence of planning, all your efforts to manage data access may fail to yield the desired results.

Incorporating some planning can transform your shared-folder environment into the land flowing with milk and honey.

To successfully and efficiently operate a complex Windows Folder Structure without any hassles or security leaks, you have to take the following points into consideration:

  • Plan a folder structure to store the users’ data files (documents, slides, graphics, drawings, etc.)
  • Plan the shares
  • Plan the Active Directory security groups
  • Plan the permissions

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-08.png

Why is Planning the Design of Folder Structure Important?

If there is a lack of definition for any of the above topics or if substantial mistakes are made in the planning phase, the problems that occur during operation will increase with each day.

Thus, you will require more time for operations, analysing problems will become more difficult, and the necessary enhancements will require far more effort to archive.

Most of the time, the only solution will be to plan and create a completely new Windows filesystem environment, which will include a time-intensive data migration into the new folder structure.

The first step is to setup a folder structure and assign the appropriate permissions to that structure. The next step is the long-term daily management and operation of that environment.

Below are some of the real-life situations that a Windows administrator could have a hard time dealing with if a proper folder structure is not designed from the start:

  • The project manager urgently needs a new folder added to the project share with permissions set for only the project office.
  • The employees in the accounting department change so often that, every day, a new employee needs to have permission assignments while exiting teammates need their permissions removed.
  • The boss of the legal department has doubts that his data is secure and requests a list of the data trustees for his folders.

Huge mistakes will make the administrator’s job far more stressful and will force them to do many routine operations and tedious tasks. Such wasted time can be invested in much more useful technologies.

What’s the importance of planning for authorisation concept?

A solid, comprehensive plan will help avoid problems! The key to a secure and stable Windows Share and Folder environment is a solid authorisation concept. If this is in place, you can trust in the security of your data!

It is important to plan for an access authorisation concept before your IT administrators create new data structures within your system, no matter if those structures are for file data, web pages (Microsoft SharePoint), databases (MS SQL Server), applications, mailing lists, or folders (Microsoft Exchange).

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-09.png

If this authorisation concept is missing on all levels, especially for:

a) use cases, such as:

  • Permission assignments for users
  • Withdrawal of permissions for individual users in individual access areas
  • Simple reporting of access rights

b) and business processes, such as:

  • Approval processes for data access
  • Approval processes for the creation of new objects in the data structure

then, the tasks of day-to-day management and medium-term reporting will no longer be easily implementable.

These tasks will grow increasingly time-intensive as more uncertainties and security risks manifest.

This is a nightmare for every IT administrator and security officer. Therefore, proper planning beforehand is essential.

Creation of a Windows Folder Structure

What kind of plan should you have for smooth daily operations?

The needs of your organisation will likely determine the way you plan for the creation of a Windows folder structure.

If you have a plan that allows for a folder structure that is intuitive and easy to navigate, it will greatly smooth daily operations and maximise productivity.

You should ensure that poor practices and inefficient workflows are not included in your planning.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-03.png

Here are some questions to consider when planning your structures:

  • How should data files get organised? Are users allowed to create folders on their own?
  • Who is responsible for moving, owning, and maintaining the data? Whom do I speak to if an employee from one department requests permissions for a folder in a different department?
  • How should the shares be designed? For instance, does every department need its own share? Is one share per business domain enough?
  • How should the structure for the folders in the Active Directory be built? How should the Active Directory security groups be designed?
  • How should I name the shares, folders, and Active Directory security groups?
  • Should folder depth be limited? Is it efficient to manage the permissions of folders five levels deep?
  • How should users who are assigned to specific folders gain access? Why shouldn’t users be directly assigned to those folders? Do users need different levels of access or are groups suitable?
  • How should the files and folders be backed up? How do I guarantee the software will be able to access all the data within the structure?
  • Are there any specific security concerns around your shared content?

Do your administrators require full access to users’ content?

To answer these questions, you’ll need to define some policies for permissions assignment:

  • Policies for file and folder structures
  • Policies for every data owner; that is, who is responsible for which folder
  • Policies for shares
  • Policies for security groups in the Active Directory
  • Policies for naming conventions for shares, folders, and groups
  • Policies for folder nesting depth limits
  • Policies for permission assignments of users to gain access
  • Policies for permission assignments for backup service accounts, operators, and administrators

Some Suggestions

Here are some real-life examples of defined policies:

  • Shares: The amount of shares is not limited.
  • Shares: The names should not be longer than 10 characters. Special characters are not allowed.
  • Folders: The amount of folders is not limited.
  • Folders with Permissions: The name of a folder should not exceed 15 characters. Special characters (_ and ,) are not allowed.
  • Permissions: Permissions are assigned to folders, never to shares or files. Only permissions of type “Allow” are allowed. Never assign permissions of type “Deny”.
  • Folder Nesting: Only assign security groups permissions to folders in the first or second hierarchy level. Child folders do inherit the permissions of their parent folders.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index02-04.png

  • Security Groups: For every folder with necessary permissions, an appropriate security group is created in the Active Directory.
  • Naming Convention: Name security groups like this: FS_<sharename>_<foldername>[_<foldername>]_<permissions>
  • Quota: Every folder with permissions will get a default quota of 100 GB. Enhancements should be requested by the data owner.
  • Responsibility: For every folder with permissions, a responsible individual must be defined to manage said permissions. This person will decide who gets which kind of access permissions or quota enhancements.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index03-02.png

When your IT team takes all these policies and rules into consideration, you will be able to avoid most of the problems mentioned earlier.

Best Practices

Here are some practices you should follow to ensure quality planning when setting up your structures:

  • Define your policies and rules in detail. This step will help you ensure simple administration and smooth daily operations.
  • Exceptions must always be documented.
  • Never assign permissions to shares. Only assign permissions to the underlying folders!
  • Never assign full control to shares or folders. This could lead to administrators accidentally being locked out by users.
  • Remove “creator” and “owner” permissions. Having such permissions could lead to lock outs.
  • Only assign full control to the folders within the internal system account.
  • Plan for your sensitive, confidential data to live towards the top of your structure (at a higher folder level). This way, you can easily restrict unauthorised access.
  • To enhance efficiency, ensure the folder structure is as flat as possible. A quick rule of thumb is to set the limit for managed folders to go as far as the third level within your structure. Beyond this level, if users create more folders based on their needs, those folders will not have any permissions assigned to them.
  • The IT department should never be the data owners. Any data owners must be an employee of an appropriate department.
  • Observe clear, consistent naming conventions for folders. This way, a user can easily search for content without losing focus.
  • For external collaboration, create separate and clearly labeled folders. For example, you can create a separate root level folder for communicating with third parties.
  • Plan to actively police permissions by frequently cleaning out unnecessary and un-audited permissions.

Download Checklist

Click here to download a checklist that will assist you with planning on how to manage data access on Windows fileservers effectively.

Next…

In the next step, we’ll talk about defining business processes and responsibilities.

Active Directory Security – Best Practices

Active Directory (AD) is the heart of the Windows Server System. The Active Directory is a repository for essential features and services core to the Windows environment.

It’s in the AD that users, values, groups, organizational units, objects such as printers and computers, and group policies are installed and configured.

Think of the Active Directory as a contact list on your smartphone. The ‘contacts’ app would be the AD, whilst the names would be the ‘objects’, and phone numbers and email addresses would be the values.

IT administrators rely on the AD to structure the organization’s users, groups, and objects in a hierarchical order, as well as configure group policies and settings such as wallpapers and users’ profile pictures.

It’s therefore prudent to ensure the security of your Active Directory.

Why is it crucial to secure the Active Directory?

Since the Active Directory is a critical component in structuring and authorizing users and applications within an organization, it is a potential target for cyber-attacks.

If hackers can penetrate the Active Directory, they can pose an enormous risk. They can access all the user accounts, groups, applications, groups policies, databases, alongside a host of other very crucial information, which should be a reserve of the IT administrators.

If attackers can obtain login credentials, they can penetrate your system and escalate privileges, giving them access to the resources they require.

Without proper security measures and Active Directory audit controls, attackers can easily infiltrate your system and steal valuable information.

It’s therefore important to ensure that security compromises are picked up or detected and remediated in good time before hackers can intrude your system and wreak havoc to your Active Domain Forest, making it very difficult to recover.

Active Directory security vulnerabilities

Let’s now look at some of the potential threats that can leave your AD vulnerable to attacks.

1. Relaxed password policies

A password essentially acts as a lock to your account, keeping outsiders and attackers at bay.

Many users prefer using simple passwords, which can be vulnerable to attacks because of containing few characters, the users’ names or date of birth details, or words that can easily be guessed.

In other cases, users may form a habit of writing down their passwords on a piece of paper, or even sharing them with other users.

Such habits usually leave the users’ accounts vulnerable to hackers through brute force attacks or social engineering attacks.

Password policies in an organization should be stringent and followed to the latter. Strong passwords usually have a combination of uppercase, lowercase, numeric, and special characters, and should be no less than 8-12 characters.

Users should also be encouraged to change their passwords regularly and memorize them, instead of writing them down.

2. Unpatched vulnerabilities in the server

Each successive release of the Windows Server system comes with new security updates and features to address existing vulnerabilities and flaws.

It implies that older versions pose potential security threats that need to be regularly patched with the latest security updates before hackers can exploit the vulnerabilities.

Additionally, all software applications should be regularly updated to fix any security flaws that hackers can leverage.

3. Broad access to the Active Directory Server

Having a long list of Active Directory users who enjoy administrative privileges predisposes your system to privilege abuse, which is a major cause of information leakages.

4. Overreliance on default security settings of the Domain Controller

Most organizations prefer maintaining the default security settings that come with the Windows Server system.

While that may work well, hackers are well acquainted with the default security features and may use that knowledge to infiltrate your system.

It is therefore recommended for IT administrators to make a few tweaks to fortify the security of their Active Directory.

5. Overreliance on Kerberos authentication protocol

An attacker can decrypt data and expose an account’s password where the Kerberos authentication protocol is extensively used.

Active Directory Security Best Practices

After seeing some of the potential vulnerabilities that may expose your Active Directory to security breaches, let’s now focus on some of the best practices you can use to ensure its optimal security.

1. Employ the least privilege administration model

What this means is that all users should login into the system using the least or minimum permissions necessary to execute their tasks.

Additionally, it’s recommended that you should only create two login accounts to the AD: an admin user account and a regular user account. Then, you can use the regular user account for undertaking day-to-day normal tasks, such as browsing the Internet, printing, and so on.

The admin user account should only be used for administrative tasks, such as creating new users, creating groups organizational units, installing roles and features, and configuring the network.

A better option can be to delegate some administration tasks to secondary users. Some of these tasks may include:

  • Managing DHCP and DNS
  • Accessing Active Directory users and computers
  • Managing administration rights on servers and workstations

2. Secure the default domain administrator account

Normally, a built-in domain administrator account is set up by default when a Windows Server system is installed. NOBODY, other than the IT administrator, should know the default built-in administrator’s password.

Additionally, the account should only be used for setting up the domain and for disaster recovery purposes. If there are users that need administrative rights to access the AD or the server, then they should request the IT admin to grant their accounts admin privileges, but not use the built-in account.

In addition, the built-in administrator account should be set up using a very strong password. A minimum password length of 8-12 characters—which includes uppercase, lowercase, numeric, and special characters—is recommended.

3. Maintain constant monitoring of the Active Directory

The active directory needs to be constantly monitored for signs of abnormal or unusual activities.

Some of the events you should pay attention to when monitoring the AD include:

  • Account lockouts
  • The use of administrator accounts
  • A spike in the frequency of incorrect password attempts
  • A rise in the number of locked out accounts
  • Disabled antivirus software
  • Logon and logoff events
  • All activities performed by privileged account users

So, how can you monitor events in the Active Directory?

The best way of monitoring events in the AD is by using a log analyzing software application that generates AD reports.

Some of the best software tools for log analysis include:

4. Enforce complex passwords and passphrases

IT administrators should encourage their users to use passwords with a length of at least 8-12 characters with a combination of uppercase, lowercase, numeric, and special characters.

Moreover, users should be encouraged to use random passphrases as passwords. Also, a strong password policy should include account lockout after 3 failed login attempts.

Here are some good examples of strong passwords:

M@gnum@2030!TkrY

#Pros$YuOT29$7%

5. Delete old and unused AD user accounts

You should develop a procedure for cleaning old and unused user accounts sitting in the AD. Hackers can use such idle accounts to infiltrate your system.

6. Practice patch management and vulnerability scanning

Hackers can leverage known vulnerabilities to breach your system. The earlier these vulnerabilities are discovered, the better.

It is prudent to periodically scan the Domain Controller for any vulnerabilities and update all the software applications. You can also use third-party applications to detect loopholes and vulnerabilities.

Additionally, it’s a good practice to regularly update software applications on your server and fix flaws addressed in the latest versions.

7. Desist from installing additional software or roles on the Domain Controller

To minimize risks of potential attacks, Domain Controllers should have as few software applications as possible.

Attackers can leverage preexisting vulnerabilities in the applications and use the flaws to gain entry and escalate privileges.

It is recommended to use the Windows Server core since it has no GUI and comes with a small footprint. Domain controllers should be kept as lean as possible.

8. Use security groups to determine which users have certain privileges

It is recommended for IT administrators to create custom security groups to determine the users having access rights and special privileges. This should also be documented to keep tabs of the users assigned to different privileges.

Using security groups can assist in managing access privileges and preventing unauthorized access to sensitive data.

Wrapping up

Those are the best practices for maintaining the security of your Active Directory.

Is there something we’ve missed in this article?

Or, do you have a comment or a question?

Please post them below.

Protect yourself and discover all permissions owner on your Windows fileservers!

Pass your next security audit without worrying about security leaks!

Get your free trial of the easiest and fastest NTFS Permission Reporter now!

How To Generate All Domain Controllers in Active Directory

In this article, we’ll describe how to generate all Domain Controllers in the Active Directory Sites and Services tool.

Active Directory Sites and Services can be seen as an administrative tool used to manage sites and the related components on Microsoft Server systems.

It contains a list of all Domain Controllers (DCs) connected to the system, regardless of their number.

In some situations, admins can notice more than one DC listed under Windows NT Directory Services (NTDS) settings.

What are these other DCs, and how can they be generated automatically?

KCC

Those DCs are called KCCs (Knowledge Consistency Checkers). They are nominated bridgehead servers per site that handle replication tasks between specific sites.

A bridgehead server is responsible for replicating any changes to all remaining DCs in its site.

In simple words, KCCs take care of replication by generating DCs, which communicate with other DCs and KCCs—consequently, the auto-generated domain controllers take care of the replication.

How to create automatically generated Domain Controllers

There are instances, such as during server moves or adding new organizational Domain Controllers, when   Active Directory is unable to create ‘Automatically Generated’ connections with the root Domain Controller.

In such a situation, the Domain Controller can be seen, but not on the “real” Domain Controller list.

There is more than one solution to this problem.

Let’s talk about two of the most used and tested solutions.

1. Manually forcing auto generation

This first method, although it can get in the quick “workaround” category,  involves manually forcing auto-generation.

It can be done by right clicking on the NTDS Settings option and then choosing ‘All Tasks and Check Replication Topology’ in the end.

That should force trigger auto-generation of all Domain Controllers, and your Domain Controllers should now be visible on the list.

2. Repadmin

Repadmin is a command line tool used for diagnosing and repairing replication problems.

It can be used from an elevated command prompt by typing ntdsutil.

Then, entering this command:

repadmin / showrepl*

To create an output that replicates the state of all DCs in the system, enter this command:

Repadmin/replicate

As a result, force replication will be started. This command forces replication and generates all Domain Controllers on the Sites and Services list.

Conclusion

It is usually not necessary to create manual connections when the KCC is being used to generate automatic connections; if any conditions change, the KCC automatically reconfigures the connections.

Adding manual connections when the KCC is employed can potentially increase replication traffic and conflicts with optimal settings stipulated by KCC.

If a connection is not working due to a failed domain controller, the KCC automatically builds temporary connections to other replication sites (if the damage is not too big) to ensure that replication occurs.

If all the domain controllers in a site are unavailable, KCC automatically creates replication connections between domain controllers from another site.

It is not recommended to manually modify this, unless you have a very specific use case.

As long as these records are auto-generated, they can survive a Domain Controller failure, as the KCC/ISTG will automatically create a new connection.

However, if you manually create a connection or specify a bridgehead server, and that server goes offline, KCC will not create a new connection and replication between the affected sites will stall.

Active Directory Domain Services Overview

Active Directory (AD) is a Microsoft-developed technology that consists of a set of processes for managing domains centrally, managing access privileges to networked resources, and managing other directory-related identity-based services. 

While AD consists of multiple directory services, the one that performs the core activities is Active Directory Domain Services (usually abbreviated as AD DS). Essentially, AD DS keeps information about the resources in the domain, authenticates their permissions, and determines their access rights. 

In this article, we’ll give an overview about the AD Domain Services.

Advantages of AD DS

The Active Directory Domain Services offer a wide range of advantages to the management of computing resources.

Here are some of them:

  • A directory is often implemented by building structures that store data based on the logical and hierarchical organization of information. The data stored in the directory usually has all the information about the various Active Directory objects, such as network printers, servers, shared volumes, and individual computer accounts. Consequently, this allows for data to be organized based on the users’ needs and preferences. 
  • AD DS provides multi-master replication and multi-master authentication capabilities. This allows an administrator to manage the entire directory from any location on the network.
  • AD DS comes with built-in redundancy capabilities. As such, if the performance of one Domain Controller (DC) fails, another DC takes over the load.
  • AD DS uses policy-based administration to make the work of system administrators easy, especially in a complex network infrastructure. Every access to network resources occurs through AD DS, which ensures the access rights are managed centrally. 

Common terminologies and concepts in AD DS

Let’s define some terminologies and concepts that are commonly used in Active Directory Domain Services.

  • Schema: It is a set of rules used to define objects and attributes within the directory. Schemas also define the limits on instances and how they are represented in the directory. A schema is preferably stored in its own partition within the directory and replicated among all existing domains in the forest.
  • Global Catalog: It contains all the information about every object defined in the directory, enabling both users and administrators to locate directory information easily—even if the data is on a different domain.
  • Query and Index Mechanism: Query indexing enables users and applications to locate objects and their properties within the directory. This feature comes in handy when looking for specific information in the directory structure.
  • Replication Service: This dedicated service distributes data all over the network; it’s what ensures that every DC contains the same Schema and Global Catalog. All changes made in the Active Directory Domain Services are usually replicated to every DC in the domain. The DCs usually track any changes made and only implement the updates that have taken place since the last replication. The update tracker has two roles: first, it changes what has not been received or need to be replicated at the destination; second, it resolves conflicts arising from simultaneous changes to an object.
  • Lightweight Directory Access Protocol (LDAP): It’s the protocol responsible for providing a common language for interaction between clients and servers across platforms. 

Role of Domain Controllers with AD DS

The servers running the Active Directory Domain Services are called Domain Controllers (DC). Every DC responds to requests for authentication and stores the AD Domain Services data.

Furthermore, the DCs host other essential services, which are complementary to the functions of the AD Domain Services.

Here are some of them:

  • NetLogon: A service that incessantly runs in the background to authenticate users and other services available in a domain. 
  • Kerberos Key Distribution Center (KDC): A service that validates the Kerberos tickets that the Active Directory Domain Services utilize for authentication. 
  • Intersite Messaging (IsmServ): A service that enables Domain Controllers to interact with one another for replication and site-routing purposes.

Every Active Directory should have at least a single DC. The Domain Controllers serve as containers for the domains. Furthermore, every domain is a component of an Active Directory forest, which consists of at least a single domain that is categorized in organizational units.

It’s the Active Directory Domain Services that manage trusts amongst various domains, allowing users to be granted access rights and communication privileges. So, while AD DS is the basis for domain management, DC is the computer that is used to access the Active Directory. 

Conclusion

An Active Directory network infrastructure provides a centralized storage and management of objects. It allows the system administrator, through group policies, to manage the access and availability of shared network resources securely.

An Active Directory Domain Service acts as a foundation for identifying users and also provides a central basis for authenticating and authorizing all the server roles in a typical Windows Server Operating System.

Some of the distinct features found in the latest Active Directory configurations include system auditing, password and account lockout policies, read-only domain controllers, ability to restart domain services, and an Active Directory Database Mounting Tool.