Create and manage AD DS users and groups
Provisioning and configuring Active Directory Domain Services (AD DS) users and groups involves creating accounts for users, services, and computers. These accounts are placed into logical containers called Organizational Units (OUs), which help apply group policies and delegate administrative tasks to specific parts of the directory. The main tools for this work are the graphical Active Directory Users and Computers or Active Directory Administrative Center, and PowerShell for automation. Administrators choose group scopes—global, domain local, or universal—and nest groups inside one another to simplify assigning access permissions. This structure of OUs and groups is key for enforcing role-based access in both on-premises AD DS and hybrid setups with Microsoft Entra ID.
Create and Manage OUs
Organizational Units group related objects like users, groups, and computers. In a managed domain synchronized with Microsoft Entra ID, there are two default OUs: AADDC Computers for domain-joined computers and AADDC Users for synchronized users and groups. Administrators can create custom OUs to match their own organizational structure. Only objects created directly within the managed domain can be moved into these custom OUs; objects that sync from the cloud remain in the default OUs.
The Active Directory Administrative Center provides a graphical interface for managing OUs, users, and groups. PowerShell automates these same tasks, such as creating a service principal with New-MgServicePrincipal or listing groups with Get-MgGroup. The choice of tool depends on the task: the Administrative Center is good for one-off changes, while PowerShell excels at bulk operations and scripting for consistency.
Delegation and Group Management
AD DS supports different group scopes that control where a group's permissions can be used. Global groups are used within the same domain, domain local groups apply to resources in their own domain, and universal groups work across domains in a forest. Nested group membership means adding one group as a member of another, which reduces the number of direct permission assignments you need to manage. Delegation models allow administrators to grant specific rights over an OU, like resetting passwords, without giving full administrative control over the entire domain.
Synchronization in Hybrid Environments
In a hybrid deployment, on-premises AD DS synchronizes with Microsoft Entra Domain Services. This synchronization must correctly match user attributes such as sAMAccountName and objectGUID. Administrators create service principals and administrative groups in the cloud to manage resources on both sides. Tools like Azure PowerShell and Microsoft Graph PowerShell handle this synchronization and management, ensuring consistency between the on-premises and cloud directories.
User Configuration
Configuring a user account involves several steps. First, the account is created using Active Directory Users and Computers or PowerShell. Next, roles are assigned through security groups, like the AAD DC Administrators group, which grants elevated permissions over the managed domain. Finally, password policies are managed to enforce complexity rules, expiration dates, and lockout rules after failed attempts. Organizing objects into OUs, delegating tasks appropriately, and choosing the correct group scopes and nesting keeps the directory secure and manageable.
Manage users and groups in multi-domain and multi-forest scenarios
In hybrid environments, separate Active Directory forests are often used to isolate resources or administrative control. A cross-forest trust is a relationship that allows users in one forest to securely access resources in another forest. These trusts can be one-way, where only one forest trusts the other, or two-way, where both forests trust each other.
Establishing Cross-Forest Trusts
You can create these trust relationships using the graphical Active Directory Domains and Trusts tool or PowerShell cmdlets like New-ADTrust. Before creating the trust, you must ensure that DNS resolution works between the forests, which usually involves setting up conditional forwarders. After creation, you must verify the secure channel—the encrypted connection used for authentication—is working correctly, which can be tested with commands like Test-ComputerSecureChannel.
Configuring Trust Settings
Two critical settings govern how a trust operates. SID filtering is a security feature that prevents a user from bringing potentially malicious security identifiers (SIDs) from one forest into another; it is usually enabled by default. Trust transitivity determines whether a trust can be extended through a third forest. For example, if Forest A trusts Forest B, and Forest B trusts Forest C, a transitive trust would allow Forest A to trust Forest C automatically. This is a key design decision when planning your forest relationships.
Troubleshooting Cross-Forest Trusts
Common problems include authentication failures and issues related to SID filtering. To troubleshoot, start by checking the Windows Security event logs on domain controllers for specific error codes. Next, verify the trust path and test the secure channel again. If SID filtering is blocking necessary access, such as during a user migration where SID history is required, you may need to adjust the SIDFilterQuarantine attribute cautiously due to security implications.
Verification and Maintenance
Once configured, validate that the trust works by having a test user from one forest attempt to access a shared resource in the other. Regular monitoring is important, as network changes or expired trust passwords can break the secure channel. Using tools to proactively check the health of the trust relationship helps maintain reliable access.
Choose a service account type
Differentiate Service Account Variants
When setting up services in Active Directory Domain Services (AD DS), administrators must choose the right type of service account to keep the system secure and easy to manage. The main goal is to follow least-privilege principles, meaning each service gets only the permissions it truly needs. This choice is especially important in hybrid environments spanning on-premises servers and Azure services.
Types of Service Accounts
Three main types of service accounts exist in Windows Server environments: Group Managed Service Accounts (gMSAs), Standalone Managed Service Accounts (sMSAs), and User Accounts (domain or local). Each serves different scenarios based on where the service runs, how many servers it uses, and the security features required.
Group Managed Service Accounts (gMSAs)
gMSAs work best when services run across multiple servers, like in a server farm or behind a load balancer. They provide a single identity all servers can use, simplifying management. Key benefits include automatic password management, where the Windows OS changes the password every 30 days without admin intervention, strong security from complex passwords, and deployment across multiple servers. Choose gMSAs when your service runs on more than one server or you want to reduce manual password work.
Standalone Managed Service Accounts (sMSAs)
sMSAs serve services that run on a single server. They offer the same automatic password management and security benefits as gMSAs but cannot be shared across multiple machines. Their scope is limited to one server. Use sMSAs when your service runs on a single server and you want the security benefits of managed passwords without gMSA complexity.
User Accounts
When managed service accounts are not supported, administrators use user accounts. Domain user accounts exist in AD DS and can access resources across the network, supporting Kerberos authentication. Local user accounts exist only on a specific computer and cannot participate in network authentication. Use domain user accounts when the service requires network access or when the application does not support managed accounts. Password management becomes manual, so clear naming conventions and scheduled updates are essential.
Evaluating Security and Management Requirements
When deciding which account type to use, ask key questions. How many servers will run this service? If more than one, gMSAs are best. Does the service support managed service accounts? If not, use a domain user account. How often can administrators update passwords? Managed accounts handle this automatically. What permissions does the service actually need? Always assign only the minimum required access.
StudyCerts
StudyCerts