Best Practices to Secure Active Directory

First of many questions of any server administrator is how to protect and make less vulnerable your Active Directory domain.

In this article, we will bring you the best practices for securing Active Directory domains from any type of attacks and for maximizing your server security.

Account Hierarchy

Hierarchy in every server system is one of the things worth thinking about. All of the users should have their roles and on top of all those roles is Administrator.

Users should not have any more rights than they need. And administrators should use their rights as fitted per situation.

It is recommended for Administrators or other staff with elevated privileges to use two accounts – one for logging in on their workstations when no admin tasks are needed and the other solely for admin work.

The way of account usage will lower the risks of any potential attacks (virus or account hacking).

Group Policies for Restricted Groups

Group policies is an outstanding tool choice for securing pretty much everything. For security practices, especially when users are local administrator of any organization’s computer, Group Policies should be used to keep them local admins, but restrict them from adding new users as admins.

It can be done by creating a “Restricted Group” and applying GPO on that group. You may do this by following these steps:

  • Edit the Group Policy applied to the scope of wanted computers.
  • In the Group Policy Management Editor, create a new Local Group by navigating to:
    • Computer
    • Configuration
    • Preferences
    • Control Panel Settings
    • Local Users and Groups
    • Select Administrator
  • Tick the box that says “Delete all member users” and “Delete all member groups” for all users.
  • Be sure you added back the Domain Admins and Local Admin Groups to prevent restricting yourself. If not, you can use the “Add Local Group Member” option and “BuiltIn\Administrator”.
  • Recommendation: Add DOMAINNAME\Domain Admins. It’s a good practice to have Domain Admin accounts in a local group which can be added through Domain Name variables.

Users can be added as usual and be seated as local admins but they will be restricted by GPO from adding other users as admins.

Server Login Limits

Logging directly to the server should not be common practice to anyone, even Administrators. Most of the administrative operations can be made through remote admin tools so the server can be reachable from a workstation or terminal server.

This can be achieved by applying GPO as following:

  • Access GPO in the console tree, which can be found on the path: Forest name/Domains/Domain name/Group Policy objects.
  • Click add in the Scope tab
  • Type the name of a group that needs security filter in “Enter the object name”.
  • Remove Authenticated Users in the Security Filtering section of the Scope tab.

The settings in a GPO will apply only to users and computers that are contained in the domain, unit, or organizational units where the GPO is linked to.

Domain Controllers Security

Security of servers can be disturbed both via software and hardware.

If the Domain Controller Servers are physical, it is strongly recommended to lock them away so no one can access them. If the Domain Controller Servers are remote, it is recommended to configure them as read-only domain controllers (RODC) and to set up the DCs as Core with GUI. Of course,

it is recommended to apply all practices mentioned as well as closing all unnecessary ports between DC and the workstation.

There are a lot more practices for keeping servers secure and it is a constant, on-going process and admins should always be on the watch. This article gives an overview of some major practices but threats, same as security practices are developing and changing day to day.

 

 

 

Secure Your Windows Folder, too!

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

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.

Performance Tuning for Windows Server Active Directory 2016

The Active Directory is a standardized and central database for Windows Server systems that houses user accounts used for authentication, file shares, printers, computers, and other settings such as security groups. The main purpose of Active Directory is to allow only authorized users to logon to the network and act as a central management for network resources.

Once you have set up a Windows Server in your environment, you might have business requirements that are not supported by your server’s default settings. For instance, you may desire to scale down on your power/energy consumption, maximize your server’s output and have the lowest server latency. It’s for this reason that we must always ensure that our AD is running optimally. And one way to ensure that is by performance tuning.

We are going to give you a few tips on how you can tweak your server settings and scale up your AD’s performance and energy efficiency, especially when you have varied workload.

For performance turning to reap maximum impact, tuning should be centered around server hardware, workload, energy budget, as well as performance objectives of the server. We are going to describe crucial tuning considerations that can yield improved systems’ performance coupled with optimal energy consumption.

We’ll break down each setting and outline its benefits to help you make an informed decision and achieve your goals as far as workload, system’s performance, and energy utilization is concerned.

Hardware Considerations

This encompasses the RAM, Processor, storage, and Network Card.

RAM

To increase scalability of the server, the least possible amount of required RAM is calculated as follows:

Current size of database + Total size of SYSVOL + Recommended RAM by OS + Vendor Recommendations

Any additional RAM can be added in anticipation of the database’s growth and workload in the server’s lifetime. For remote sites with few users, these requirements can be relaxed as they will not require much RAM to cache much information to service requests.

In virtualization scenarios, avoid committing too much memory to the host machine. In some cases, memory overcommit happens where more memory is allocated to the guest machines than the underlying host machine. This is not such a big deal, but it becomes a huge mountain if the total size of memory collectively allocated to guest machines exceeds that of the host machine and the host begins paging. Remember, the objective of RAM optimization is to minimize time required going back to the disk.

16GB RAM is a reasonable amount of memory for a physical server. For virtual machines, though, an estimated size of 12GB would be considered decent enough with anticipation of future upgrade and growth of the database and resources.

Cache Memory

This is a type of RAM that is easily and quickly accessible by the microprocessor more than the ordinary RAM. The cache performance of an Active Directory depends on the memory space allocated for caching. Data access done at the memory level is faster than access instructions on physical volumes.

To make this processing highly efficient, more memory must be added to minimize disk input / output requests. The viable option is to have enough RAM installed to handle all operations of the operating system and the installed applications. Therefore, system logs and databases should be placed on separate volumes to offer more flexibility in storage layout.

To improve the I/O request on a hard disk, the Active Directory should implement the following hardware configurations:

  1.     Use of RAID controllers
  2.     Increase the number of disks handling log files
  3.     Support write cache on disk controllers

The subsystem performance of each volume should be reviewed; the idea is to have enough room for sudden changes in load to avoid client request non-responsiveness. Data consistency will only be guaranteed when all changes are written to logs.

Non-critical tasks such as system scans, backups, and activities taking place when the system is not overloaded should be scheduled. Backup procedures and scanning programs with low I/O requests should be used because they reduce competition with critical services in the Active Directory.

Network

To investigate the degree of traffic which should be supported, it’s prudent to make a mention of 2 broad categories of network capacity planning for Active Directory Domain Services.

Firstly, we have replication traffic which passes back and forth across Domain controllers. Then, we have client-to-server network traffic also known as intra-site traffic. Client-server traffic is much simpler to plan for since it involves minimal client requests to the Active Directory in contrast to the huge volumes of data sent back by the Active Directory Domain Services.

A bandwidth of 100Mbps will be adequate in environments serving close to 5,000 users sharing a server. A 1GB Network Card is recommended for environments where users exceed 5,000 per server.

In virtualized environments, the network adapter should be in a position to support the Domain Controller load and the rest of the guests or virtual machines which are sharing the virtual switch which is attached to the physical network card.

Storage

Planning storage on the server entails two things: storage size and performance.

For Active Directory, sizing is only a consideration for large environments. This is because even for a 180GB hard drive, SYSVOL and NTDS.DIT can fit quite easily. It’s therefore not prudent to allocate so much disk space in this area.

However, you should ensure that 110% of the NTDS.DIT size is available for defragmentation. From there henceforth, one should plan for growth over a 3-to-5-year lifespan of the Hardware. An estimate of about 300% the size of NTDS.DIT database file will be satisfactory to accommodate growth over time and allow for offline defragmentation.

Processors

Processors with limited free cycles increase the wait times leading to execution. Server optimization should ensure that enough room is available to handle workload surges and in the long run minimize response time to client requests. Reducing the workload on the processors involve, selecting the best processors, directing client requests to available processors, and using processor information to gauge system performance.

Performance Tuning

Performance tuning on the Active Directory has two objectives:

  • The optimal configuration and performance of the Active Directory to balance the load efficiently
  • All work sent to the Active Directory have to be efficient

For the objectives above to work, three areas need to be looked at

Capacity Planning

This means having enough number of domains that can handle redundancy and client requests within a short time. All the server hardware must be able to handle existing load. Capacity planning involves scaling up operations across multiple servers. Adding more resources like RAM to the server is essential in preventing possible failures by ensuring that every aspect of the server is working as intended.

A typical capacity planning takes place in three stages:

  1.     Evaluating the existing environment by determining the current challenges.
  2.     Determining the hardware needed according to the findings in the step above.
  3.     Validating the employed system to ensure that it works within the defined specifications.

Server-side Tuning

The domain controllers in the Active Directory are configured to handle loads efficiently. The System Administrator is supposed to balance the demands of individual users against available resources. Add-on products that manage bandwidth and port usage may be implemented to restrict network resource uses.

Active Directory Client/Application Tuning

The Active Directory has to be set up so that the client and application requests use the Active Directory to achieve maximum efficiency.

Domain Controllers and Site Considerations

Placing domain controllers and site considerations revolve around optimization for referrals and optimizations with trusts in mind.

A well-defined site definition is central to the performance of servers. Clients not getting requested services may report poor performance when querying the Active Directory. Since client requests can come from IPv4 or IPv6, an Active Directory is supposed to be configured to get data from IPv6 addresses. By default, the operating system usually picks IPv6 over IPv4 if both are configured to send/receive data.

Most domain controllers use name resolution for reverse lookup when determining the client’s site. When this happens, delays in the thread pool are inevitable leading to unresponsiveness from the domain controller. By optimizing the name resolution framework, quick response is assured from the domain controllers.

An alternative is to locate read/written domain controllers where read-only domain controllers are used. Optimizing this scenario means:

  • Using an application code change to contact writable domain controllers when read-only domain controller would be sufficient.
  • Placing the read/write domain controller at the center of operations to reduce latency.

Optimization for Referrals

Referrals define how Lightweight Direct Access Protocol (LDAP) requests are processed when domain controllers do not have a copy of the requested partition. When the output of a referral request is found, it has the name of the partition, port number, and DNS name.

This information is used by the client to send requests to the server hosting the partition. The recommendation is to make sure that the Active Directory that has the site definitions and domain controllers are in place to reflect the client’s needs. Implementing domain controllers from multiple domains in a single site and relocation the applications may also help fine-tuning the domain controllers.

Optimization with Trusts in Mind

In a domain with multiple forests, trusts have to be defined depending on the domain hierarchy. All secure channels at the root of the forest may be overloaded due to increasing authentication requests between the domain controllers. This will cause delays in far-flung Active Directories and this overload in inter-forest and low-level trust scenarios. Some of the recommendations to help reduce forest trust overload.

  • Using MacConcurrentAPI to help distribute load across a secure channel.
  • Create shortcut links to trusts as needed depending on available load.
  • All domain controllers within a domain should be able to handle name resolutions and communicate trusted domain controllers.
  • All trust should be based on locality considerations.
  • Reduce the chances of running into MaxConcurrentAPI challenges by enabling Kerberos as needed as well as reducing the use of secure channels.

Name resolution taking place over firewalls takes a toll on the system and will, in turn, impact the clients negatively. To overcome this, access to trusted domains need to be optimized through the following steps:

  1.     The WINS and DNS should resolve names within the trusting domain controllers by listing the domains. This step is to counter the problem of static records which tend to cause connectivity problems over time. A manual maintenance of all the forwarders and secondary copies of the resource environment needed by the clients need to be maintained.
  2.     Converging all site names shared between trusted domains reflecting domain controllers that re on the same location by ensuring IP and subnet addresses are linked to sites within the forest.
  3.     Ensure all ports are open and firewalls configured to accommodate all trusts. Closed or restricted ports will lead to several failed communication attempts, forcing the client to experience timeouts and hung threads or applications.
  4.     Domain controllers forming a trusting domain should be installed on the same physical location.

When no domain is specified disabling trust checks on the availability domain, trust checks are recommended.

 

 

 

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!

Setting Up Honey Pots for Active Directory 

The world of computing is replete with threats which, at any time, can compromise the security of your system. Unauthorized users may try to gain access to client machines and perform malicious activities using existing loopholes. A honey pot is a decoy network. It masquerades itself as a real or genuine network.

Honey Pots are used to trick intruders and give them the impression that they are attacking the right network. The activity of the attacker is then logged and studied. In a nutshell, a honeypot protects your system.

A Honey Pot is a computer system set up to lure would-be attackers and deflect their attempts to gain unauthorized access to the network. It is a system installed on a computer in order to simulate the behavior of the real system. The decoy system is isolated and monitored by system administrators.

Setting Up the Honey Pot Account

Securing an Active Directory is an important organizational policy that helps system auditors track relevant events and changes taking place in the network. Everyday threats are becoming more elusive which calls for the need to have several security measures to better handle threats, including those coming from insider attacks.

One way of implementing this is through the use of Honey Pot accounts to trick the attacker that they have full access to the system.

Within the Active Directory context, a Honey Pot administrator account can be set up because most attackers look for this account. The administrator account gives them the impression of having uncontrolled access to all resources of the Active Directory.

Advanced hackers may not fall for this trick, but using Honey Pots in your network is the best way of detecting malicious activity. System administrators need to realize that Honey Pots are not foolproof because some hackers will immediately know the legitimacy of the Honey Pot account. For the Honey Pot account to thwart the most sophisticated attacks, here is what the administrator needs to do:

  • Renaming the Built-in Administrator Account
    This account has to be renamed and the default decryption removed. Naming the account means creating a username that matches the Active Directory naming conventions.
  • Create Another User Account with Username “Administrator”
    The default description for this account should be “Built-in account for registering the computer/domain”. The idea is to create a proxy Administrator with a similar description to the default account.
  • Enable Auditing
    Auditing for activities such as failed and successful Logon Attempts for the account just created in step two above. The configuration of Auditing may be used alongside a tool that enables searches and alerts whenever this account is accessed. The Microsoft built-in tool may not give details of searches and alerts promptly. Therefore, downloading third-party tools such as the Active Directory Audit Plus can be helpful in monitoring, searching, analyzing, and giving live alerts when a login attempt is made at the Honey Pot account.
  • Monitor the Honey Pot Activities
    Using an appropriate account auditing solution, all live activities on the account should be logged and monitored.

The four steps above should enable the Honey Pot account. It is also a good idea to have logging and monitoring activities on the renamed administrator account. The organization’s security policy should be that the renamed account should not be used unless it is a case of an emergency.

Tracking all Logon activities of all users is important in keeping the system security tight. The two accounts should now give an immediate alert when a Login attempt is made and thus the network is deemed secure and prepared for external intrusions.

Decisions to be Made When Deploying a Honey Pot

Before any consideration is made to deploy a Honey Pot account, here are some of the critical decisions system administrators are faced with:

  1. Reason of the Account
    Two primary reasons determine whether deploying a Honey Pot account is necessary. One of the need for an early security warning, the second reason being for forensic analysis. Honey Pots address both reasons by giving out the information needed for immediate follow-up.
  2. What Needs Protecting
    The most valuable objects in an Active Directory will determine the type of fake account to be used as a Honey Pot. In most cases, Honey Pot accounts are used to mimic web servers, file servers, application servers, database servers, and Logon servers. There is an option of deploying a Honey Pot that mimics open ports or having several ports with each one dedicated to a particular server type.
  3. The Active Directory Interaction Levels
    Three levels of interactions define Honey Pot accounts thus:
  • Low level
  • Medium level
  • High level

The low-level accounts give early warning signs of malicious activities; the medium level accounts may have basic file structures to give the hacker a “true” reflection of the system content, while the high-level accounts may contain a complete copy of the server they emulate.

  1. The Location of the Honey Pot
    Location of the Honey Pot should be near the resources that they are trying to protect. For example, a web server decoy account should share the same IP address where the real server is located.
  2. Real or Emulation Software
    Using real systems is a good idea because it becomes difficult for the most advanced hacker to know if they are dealing with a Honey Pot or not. Using an emulation software means having access to built-in signature detection tool useful for monitoring.
  3. Monitoring and Alert Tools to Use
    A Honey Pot will only be of value when logging takes place. The tool used for monitoring should be able to report on all activities in a real time.
  4. How to Administer the Honey Pot
    Once a Honey Pot account is set up, it should continue running throughout the life of the services it is mimicking. At least one person (or more if necessary) should be given control of the decoy accounts. His responsibility will be the installation, planning, configuration, monitoring, and updating the Honey Pot.

All communications coming through a Honey Pot are considered hostile. Therefore, the system administrators should use all these activities as an insight into the level and types of threats the network is prone to. A Honey Pot account should be treated as an added security setup and not a replacement of security measures already in place.

Active Directory Federation Services in Windows Server 2016 

.When we look at IT businesses today, the most common spoken word is the “cloud”. Cloud computing made a huge impact in a way of functioning and business organization. 

But with more possibilities, usually we get more problems. And one of biggest challenges with doing business in the cloud is security and access control, especially in organizations with the need of extranet access. 

With that in mind, Microsoft has introduced an improvement to the Microsoft Windows Server 2016 system. 

Active Directory Federation Services  (ADFS)  

Active Directory Federation Services (ADFS) provides access control and single sign-in across a wide variety of applications like Office 365, cloud-based SaaS applications, and other applications on the corporate network. 

It enables organizations to provide a sign-in and access control to both modern and legacy applications — on-premises and in the cloud — with the unified set of credentials and policies. 

ADFS was first presented as an additional download in Windows Server 2003 R2 edition. But in the Windows Server 2016 edition, it became one of the most significant components of the system. 

ADFS 2016 has numerous improvements to offer. But the two most important ones are the three new options for signing in without using passwords and support for any LDAPv3 directory. 

Azure Multi-Factor Authentication  

The first option is the use of the Azure Multi-Factor Authentication (MFA) adapter for ADFS. Azure MFA can be configured for intranet or extranet, or as part of any access control policy. 

In the past, the Azure MFA server on premise was the only way of eliminating passwords as authentication methods. Now, with a configuration on the MFA adapter, the primary authentication method is the username and the OTP (One Time Password) code from the Azure Authenticator app. 

With MFA as the additional authentication method, the user provides primary authentication credentials (using Windows Integrated Authentication — username and password, smart card, or user/device certificate), then comes a prompt for text, voice, or OTP based Azure MFA login. 

 Access from Compliant Devices

ADFS 2016 upgraded device registration capabilities and enabled sign-on and access control based on the device compliance status. Sign-in is now possible with device credentials. And if/when device attributes change, compliance is re-evaluated, which brings certainty in enforcing policies. 

This can be allowed by enabling the following policies:  

  • Enable Access only from devices that are managed and/or compliant. 
  • Enable Extranet Access only from devices that are managed and/or compliant.  
  • Multi-factor authentication for computers that are neither managed nor compliant.

Windows Hello for Business  

The Windows Hello for Business (formerly known as Microsoft Passport for Work) feature can replace passwords with strong two-factor authentication that combines an enrolled device with a PIN or biometric (fingerprint or facial recognition) user input to sign in. ADFS 2016 supports this way of authentication and enables user sign-in on all ADFS applications without the need for a password. 

LDAPv3 Support  

Another improvement in ADFS 2016 is support for a combination of Active Directory and third-party directories. With the addition of ADFS support for authenticating users stored in LDAP v3-compliant directories, ADFS can now be used for:  

  • Third party, LDAP v3-compliant directories.
  • Active Directory forests where an Active Directory two-way trust is not configured. 
  • Active Directory Lightweight Directory Services (AD LDS).

New and Improved Migration Procedure 

Earlier, this operation was pretty painful for administrators. It required building completely new parallel server farm and export of configuration from old one which will then be imported into a new one. 

In ADFS 2016, Microsoft took a different approach, and simplified the process by a lot.  

Now, moving from ADFS (on Windows Server 2012 R2) to ADFS 2016 requires adding new Windows Server 2016 to an existing Windows Server 2012 R2 farm. This will completely run as 2012 R2, but with adding more servers to the farm and removing old ones from the load balancer, the system will allow upgrade and usage of new features.  

More Features

Other than these, some more important new options and interesting features of ADFS 2016 are:

  • Supports the latest modern protocols which will provide a better user experience on the most relevant platforms (Windows, iOS, Android).
  • Ability to add industry standard OpenID Connect and OAuth 2.0-based authentication and authorization to applications in development.
  • A way to customize messages, images, logos, and web themes per application.
  • Streamlined auditing for easier administrative management and configuration to participate in confederations such as InCommon Federation and other implementations conforming to the eGov 2.0 standard. 

ADFS 2016 provided the best improvements in the development of the Windows Server systems, especially in the extranet access situation. Most experts agree that listening to user feedback made a significant impact.

New Active Directory Features in Windows Server 2016

Active Directory is an extensively-used service on many enterprise networks. Besides offering authentication and authorisation services in Windows domain-type networks, Active Directory supports several other capabilities, which makes it popular.

Windows Server 2016 Active Directory Improved Features

In Windows Server 2016, the Active Directory Domain Services (AD DS) received some enhancements intended to assist organisations realise optimised performance for their network resources.

In this article, we are going to talk about four significant features improved in AD DS.

Privileged Access Management (PAM)

Microsoft has introduced privileged access management (PAM) feature to assist in safeguarding AD DS from credential theft attacks. Examples of such types of attacks include spear phishing and pass-the-hash.

At its core, PAM depends on the Microsoft Identity Manager (MIM) as well as a domain functional level that is not below Windows Server 2012 R2.

The MIM is important for provisioning what is called the bastion Active Directory forest. Whenever PAM is configured, MIM generates a new Active Directory forest, which is segregated to be accessed by privileged accounts. The created Active Directory environment is freed from any illicit activities.

With the creation of the trusted Active Directory environment, MIM can now determine the assigning of permissions to users.

MIM offers workflows for granting administrative privileges, which is based on the type of requests approved. If users are given extra administrative privileges, they are also given memberships in the shadow security groups found in the created secure forest.

What’s more, membership to the groups is time-bound. MIM has an expiring links feature which allows memberships to be revoked after the allocated time period elapses. Users are given just enough time to complete the allocated administrative duties. This time-controlled membership is defined as a time-to-live variable.

If a user enjoys time-controlled membership in several security groups, Microsoft has included improvements in Kerberos Key Distribution Center (KDC) to take care of such a situation by restricting his or her Kerberos ticket lifetime to the lowest attainable time-to-live value.

Furthermore, PAM also provides improved monitoring tools. As such, it makes it easy to quickly establish the users who requested access permissions, the level of access that was given, and the type of tasks that were completed.

Azure Active Directory Join

With the Azure Active Directory Join feature, you can deploy your identity management tasks to the cloud and benefit from centralised management for your corporate and personal devices.

The main objective of the Azure Active Directory Join is to offer the advantages of an on-premise Active Directory environment without much hassles to the users.

This new feature enables users to access Oxygen Services without the need of a Microsoft account. Oxygen Services, with its various features and settings, will be available on devices that are connected to on-premise Windows domain as well as devices connected to the Azure Active Directory account.

Azure Active Directory Join also allows devices, whether they are corporate-owned or BYOD, to benefit from single-sign on web applications. It also allows those devices to be managed using the Mobile Device Management (MDM) integration tool, even if they are not in the Windows intune tool.

It is also possible to use the feature to configure “Kiosk” mode for shared corporate and personal devices. There are also some developer improvements that enhance the process of creating applications for both enterprise and personal uses.

Microsoft Passport

The use of weak credentials is one of the major security issues facing the IT industry today. Most users do not care about their password security and engage in insecure habits like using the same password in numerous places, using poorly crafted passwords, and using simple passwords that are easy to guess.

Fortunately, Microsoft Passport intends to provide a solution to this issue. It incorporates two-factor authentication techniques that enhance the security of users’ passwords without needing the traditional, complex methods like physical smart cards.

Microsoft Passport is created to work together with Windows Hello (the in-built biometric sign-in for the Windows operating system).

Its two-factor authentication technique utilises the credentials available to the user together with the precise credentials of the device the user is accessing. Every user accessing a device is given a precise authenticator (referred to as hello) or a PIN, which verifies the identity of the user before being allowed access.

Microsoft is calling this new Passport feature “password-less authentication”, which can be deployed to safeguard traditional on-premise Active Directory environments and Azure Active Directory environments.

Additionally, the Passport feature can also be used in FIDO (Fast Identity Online) accounts. With the FIDO capabilities, Passport can be used in extensive array of platforms and devices, eliminating the need to remember multiple passwords.

Deprecated features

There are a few features that are no longer supported in Windows Server 2016. For example, the old File Replication Service (FRS), which was utilised to replicate folder data between servers, has now been exclusively replaced with Distributed File Service (DFS) Replication. DFS is useful in replicating SYSVOL.

Furthermore, the Windows Server 2003 functional levels are not recognised in Windows Server 2016. Consequently, to achieve increased reliability and performance, all domain controllers still depending on Windows Server 2003 are required to be taken out from the domain.

Therefore, it is recommended for companies to increase their functional level to Windows Server 2008 (or even to a higher level). Shifting to the higher functional levels guarantees optimal SYSVOL replication compatibility as well as faster support for enhanced performance.

Conclusion

Each of the above Active Directory features are intended to enhance the experience of the large community of Windows Server 2016 users.

PAM offers a technique for preventing credential theft when data is being exchanged in very sensitive environments.

Azure Active Directory Join functionalities allow users to benefit from the advantages of on-premise Active Directory without much hassles. Microsoft Passport aims to revolutionise the way authentication takes place.

Finally, the deprecated features points to Microsoft’s commitment to eliminate flaws and inconsistencies in Windows Server 2016.

Useful Resources

Here is a guide how to set up Active Directory in Windows Server 2016: https://blogs.technet.microsoft.com/canitpro/2017/02/22/step-by-step-setting-up-active-directory-in-windows-server-2016/

 

 

Report NTFS Permissions in 60 Seconds!

Download your Free Edition of the easiest and fastest NTFS Permission Reporter now!