The installation of Active Directory (AD) on Windows Server 2019 calls for a thorough understanding of technical nuances and a steadfast dedication to security best practices. This guide will walk you through the process of securely implementing Active Directory, ensuring the highest level of protection for the information and resources within your company.
Do your house guests still have access to your home after they’ve left, or overstayed their welcome? No, right? You would throw them out or take the keys back because they no longer require access. Guests in Azure are like house guests. Once they no longer need access, it's then time to take back the key so they no longer have access to the company's data and connected apps. Yet many organizations are inadvertently leaving themselves at risk of supply chain attacks.
In my days of AD administration, there was always a need for a select set of sysadmins to be granted high levels of permissions. In AD, this is typically a separate user admin account that is a member of the Domain Admins Active Directory group. There are a few other groups that are highly privileged(i.e. Enterprise Admins and Schema Admins) but the permissions required by these groups are generally more specific and therefore less populated.
Imagine being named XYZ in a crowd of other XYZs – a purposeless name that creates confusion and does not communicate a purpose, adding to the cognitive pile of everyone’s day-to-day tasks. Similarly, Active Directory groups created by users need to have logical names so that current and future users do not find themselves stuck in a pickle.
Administrators have several options for managing the properties of Active Directory users. The Active Directory Users and Computers (ADUC) console is convenient for making a few basic changes, such as modifying a user’s description or office location. For more functionality, however, consider using PowerShell. This article illustrates how you can address many common use cases with the PowerShell cmdlet Set-ADUser.
The PowerShell cmdlet Get-ChildItem obtains objects from one or more specified locations, such as a file system directory, registry hive or certificate store. These locations are exposed by PowerShell providers. If the location is a container, the cmdlet gets the child items in that container. The -Recurse parameter can be used to get items from all child containers, while the -Depth parameter can be used to limit how many levels to recurse to.
