Active Directory Account Lockout: Best Practices

September 21, 2018/0 Comments/in Active Directory, Planning /by Carsten

Windows account lockout policies are useful when you want to limit the attempts made by people who try to access your network by guessing passwords.

The policies are also good for enforcing strong password guidelines. When an account lockout policy is in place, it limits the number of times a person can consecutively make login attempts within a set period.

However, to reduce the frequent calls to the customer desk office, you need a lockout policy with increased account lockout duration, decreased lockout threshold, and increased reset lockout counter.

Robust Windows account lockout policies are defined by three independent policies:

Reset account lockout policy
Account lockout duration
Account lockout threshold

Generally, the account lockout policy is configured in the Group Policy Management Console.

Here is the path to the console:

Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy

This article reviews some of the best practices that can be used to disable a user account if a wrong password is issued within a specified period.

Here are some of the best practices for Active Directory account lockout, as used in a typical Windows environment.

1. Create an Account Lockout Policy

You need to create a lockout policy GPO that can be edited through the following path:

Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy

For example, the default parameters for account lockout duration can be:

1440 minutes for lockout duration;
10 invalid logins for account threshold;
0 minutes for reset account counter to ensure the account does not unlock itself.

Once the account is locked, the administrator should determine the lockout period before intervening.

Any settings between 1 and 99,999 minutes will automatically unlock the account. The policy must be set to be equal to or greater than reset account lockout counter.

The value for account threshold is the number of attempts an account can sustain when a wrong password is used.

The reset counter prompts Windows to look for consecutive failed attempts, and counterchecks if it needs the reset account lockout after the threshold is met.

2. Review Account Lockouts

Account lockout investigations will be successful only through captured logs that can be used to trace where the breach is coming from.

The administrator can take the following steps:

enable auditing of login events;
enable the logging of Netlogon events;
Kerberos auditing should also be logged.

After looking at the data coming from the enabled features above, the administrator should analyze security event log files and net login files to find out the origin of the lockouts, and why it is taking place.

Once they have identified the machine with login errors, its event logs can be analyzed to determine the cause.

3. Use Account Lockout and Management Tools

Some Microsoft and third-party tools can be used to investigate account lockouts to help determine the cause. These tools send an alert in real time; thus, giving the help desk an easy time when asked to resolve them.

a. Netwrix Account Lockout Examiner

This tool helps the system administrator to know of an account lockout. It is a freeware that helps to identify the root cause of persistent lockouts.

System administrators can access the troublesome accounts from the console. This account tool and examiner reduces the strain on the service desk who are alerted even before the user makes the call for help.

A working Netwrix Account Lockout Examiner is enough evidence that the Active Directory Account Lockout policy complies with set standards.

Netwrix Account Lockout is a tool Administrators can use to identify malicious attacks from viruses leading to multiple lockouts.

b. The AD Lockouts and Bad Password Detection

The tool is used to track the origin of lockouts in the Active Directory due to bad password attempts. The utility is useful in large organizations running multiple domains.

The system administrator can use this tool to:

search the domain for bad password attempts against a particular account(s);
analyze any events related to failed login attempts on each domain controller by tracing the possible origin of the lockout.

Furthermore, the event logs from every machine in the network can be used to determine if the following common causes of account lockout are present:

mapped drives with open permissions;
old and possibly running Login and RDP sessions;
tasks and services running on old credentials.

c. Microsoft Account Lockout Status Tools

This account lockout tool is available from Microsoft and can be downloaded to increase the functionality of the Active Directory.

Microsoft recommends using this tool alongside the Account Passwords and Policies white paper.

The primary functions of this tool are:

helps in isolating and troubleshooting locked accounts by changing user password on the domain controller; it automatically adds property pages to the user account in the Active Directory Users and computer’s management console;
on the client side, the tool determines what processes or applications are sending the wrong signals or credentials;
you can use the tool to display account names and age of respective passwords;
it can be used as a startup script by allowing Kerberos to run on clients using Windows 2000 and later;
it collects events from event logs of all machines to a central location;
the tool also identifies all domain controllers involved in a lockout by way of gathering all logs; the output is generated and saved as a .CSV file whose content can be sorted if needed;
the lockout tool can be used to extract and display specific entries from the Netlogon log files.

Please Note: Microsoft account lockout status tools should not be used on a server hosting network application and services as it may prevent some critical services from loading.

4. Know The Causes of Account Lockouts

Knowing the reasons that cause Active Directory accounts to be locked out can assist you in establishing robust security policies.

Here are some reasons that may cause account lockouts:

when the port 3389 used by the RDP is open, and brute force applied;
replication in the Active Directory;
programs running with cached user credentials;
service accounts with expired or changed passwords;
low password threshold settings;
shared drive mappings;
disconnected terminal sessions;
mobile access to the exchange server via IIS;
user logging on multiple computers;
saved account credentials with redundant passwords and usernames.

Conclusion

An account lockout policy is usually placed to disable users with bad passwords from accessing the system.

This policy is enforced after several attempts have been made within a specified period. Using such a policy, and with the help of third-party tools and utilities, can prevent malicious intrusions and reduce successful attacks on a network.

The user can access the affected account after the system administrator has reset the password or after the specified lockout period has lapsed.

Protect yourself and discover all permissions owners 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!

Best Practices for Designing Share Sizes

September 18, 2018/0 Comments/in Planning, Shares /by Carsten

Relying on Microsoft to find a way to define share sizes for your server may not be that easy. There’s no clear definition as to how Administrators should handle share sizes by following a set standard. In the server environment, it takes a personal intuition to develop some of the best practices that can be implemented when defining shares over a network.

Most, if not all, network shares are deployed on NTFS file system that enables Administrators to set permissions that affect local users and all network users based on access rights granted to each one of them at the login session. Regardless of the situation, system administrators can control access to shared resources as part of system security. File shares are commonly used and thus very vulnerable if you are unsure of what to do. To protect your data, you need to adopt the best practices that determine the security of file shares.

1. Have Standard Permissions

Every user or group members in a network should be assigned customized permissions according to theory individual requirements. It is therefore wise to have a standard set of permissions to all shared location. In a typical setup, the standard permissions are the Administrators and System-Full Control settings. You can use the Global Deny Group that defines all “Deny” permissions.

2. Use Simplified Permissions Structure

Managing and installing a simple share structure is the dream of any System Administrator. A simplified structure gives confidence to the owners of the share concerning data security. Pressure from the management could force you to set up unrealistic or complicated share structure that can only lead to poor share management for both the IT staff and management. Sometimes, a better solution should always include integrating staff training when new share policies are implemented.

3. Share with Security Groups

Instead of assigning shares to individual accounts, Microsoft recommends the use of security groups when assigning permissions. Giving share rights to individual users becomes and administration headache when additional users require the same permissions and end up duplicating or cloning permissions. This can be avoided by assigning permissions at the top group level.

4. Use Ideal Share Names

Making use of names that define the kind of permissions assigned to a group is highly recommended. This approach makes it easier for other administrators to map share locations when new employees are added to the network. Use of shares names with less than 20 characters with no special signs and Symbols is encouraged. This naming structure allows for easy manipulation of shares when using the command prompt.

5. Share Permission Should Reflect the Department or Nature of Work

When defining share permissions and the creation of top-level groups, you can add groups that have user accounts named according to the department or work they are assigned to do. For example, you can have the IT Administrators group with all the names of individual IT staff accounts. By doing so, it gives the Administrators the flexibility of changing the individual access permissions simply and accurately. Changing user permission becomes as easy as changing the user group (moving users to a group with the required permissions).

6. Define Effective Permissions

When effective share permissions are not done correctly, a user will see “Access Denied” errors when trying to access files assigned to them. On the other hand, poor design of effective permissions may lead to loose access. There are three levels of effective share permissions — the Loose, Loose, and Tight.

The first Loose refers to the folder permission which applies to the root folder with the share permissions. This Loose here defined the Read/List permission everyone in that group has.
The second Loose is the share permissions which is assigned to a user with different share permissions. For example, a user that requires both Read and Change permissions will be granted the less restrictive Change permission.
The Tight, effective permission combines folder and share permission. For example, a user with a Read permission at the NTFS level and Change permission at the share level, the effective permissions should be restrictive and in this case, Read.

7. Avoid Using the Everyone Group

The best design share approach is to limit NTFS permissions to the root level folder that is created by administrators. Within the Read-only root level folder, you are allowed to create 3 to 10 logical folders to accommodate user data and assign change permission either on the logical folders or sub-folders.

8. Constantly Review Permission Changes

As time goes by, new users join the network as additional tweaking are done to reflect new changes. Lack of a proper follow up from the System Administrators may result to giving many users Full Control rights to the share volumes. Therefore, exposing the network by the creation of security holes and possibly lock out authorized users.

9. Have A Central Management and Response System

The best way to reduce server attacks is to create local shortcuts pointing out to share resource locations. They deployment of such shortcuts via Group Policy minimized the risk of users spreading the virus to mapped network drives.

CONCLUSION

When setting up file shares, Administrators adopted the limitation of Storage Area Network (SAN) volumes and shares to 2TB to enhance performance, restore time, and snapshots. According to the Microsoft website, you can go as far as 16TB to 256TB depending on your cluster size.

The best practice is to use 2TB, which translates to easier, and faster cloning, quick backups and restore. Using the Distributed File System (DFS) gives more room for those who want to use share volumes across multiple servers and still give the users an impression of using one large share volume.

Some of the best practices when designing share sizes depend on the organizations structure and their needs. Another approach is to re-evaluate the need for a large share volume given the increasing internet speeds and increased bandwidths. Administrators can also use reasonable space and enforce policies that restrict users on the type of files that can be stores on the server and when to store files. This prevents dumping of files that may be irrelevant after a few days.

Do you have unclear NTFS Permissions assignments?
Do you have too many special permissions set on your fileservers?
Or blocked NTFS Permission Inheritance?

Protect yourself and your clients against security leaks and get your free trial of the easiest and fastest NTFS Permission Reporter now!

Planning before implementing NTFS Permissions

May 29, 2018/0 Comments/in HowTo, ManagingDataAccess, NTFS, Planning /by Carsten

If you’re a Windows Administrator, you’ve probably experienced the nightmares in managing folder permissions. This is common in large or even small environment where no proper planning is made before giving the permissions. Such negligence could lead to complication and exposes the environment to security risk. Below are some examples:

Users or groups having access to folders not intended for them (e.g., Sales Group can view Management’s folders)
Applications fail to run because of lack of permission (e.g., Backup Software unable to perform tasks on specific folders)
Or just too convoluted folder permission that Admins are better off doing them from scratch.

Why Planning is a Crucial Step Before Implementing NTFS Permissions

All above examples are all due to incorrect planning (or the lack of it) before the implementation of NTFS permissions. One may point out that it can also be due incompetency of the person doing the task. I agree that could also happen, but if there is proper planning, documentation, and layout, these problems can be avoided even if you let your junior admin do the task.

As part of the Planning phase, here are some of the things an Admin can do:

Design a Folder Structure

Before creating the actual folders, you must know what folders are to be created. Whether you prefer digital or physical board, list the shares that will be created for each department or group. Work with the knowledge you already have of your current environment. There will be changes along the way (e.g. new department or new projects) but this would be a good start.

Identify who has access

After listing the shares to be created, map out the users or groups that have access to specific folders. You may List down the users or groups and draw a line to connect them to the appropriate shares. How ever you want this done, make sure to have fun doing it!

Plan the Permissions

This one is critical so take your time going through the shares and groups and write down the appropriate permission. If you use naming conventions such as R for Read-only or F for Full Control, make sure to be consistent to avoid confusion along the way.

Proper Documentation

A good planning always has good documentation. It’s always good to have something to go back to when you forget. This not only serves as your guide but something you can pass down to your junior staff or even to your boss. With that said, documentation must be clear and concise. Also, changes in the organization are inevitable so whatever method you used to document, make sure it can easily be modified and expanded.

Being an Admin can be stressful, but if you have proper planning, implementation, and clear documentation, it smoothens administration and helps you focus on other areas.

A more detailed guide on Planning and Managing NTFS Permissions can be found here (no signup, incl. free eBook):

Archive for category: Planning