If you have ever tried to remotely connect to another computer via SSH, RDP or most any other protocol, you might have wondered why your local system account can’t just automatically be trusted by the remote system and give you access. Or what if you want to share some content from your system and have to manually create local accounts for your friends on your system so they can log in? Windows Active Directory solves problems like this by providing a framework for central authentication and managing permissions.
Managing with PowerShell
Active Directory itself may be complex, but Microsoft helpfully provides PowerShell cmdlets with modern Windows versions to simplify administration. These cmdlets are not installed on client versions of Windows by default and if you are going to be remotely administrating an Active Directory domain from your workstation, it is a good idea to install them!
To see the list of packages available to the local system, run:
Get-WindowsCapability -Name RSAT* -Online
Then, if you want to install all of them, you can simply pipe the objects from that command into Add-WindowsCapability:
Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability -Online
You can install specific modules by specifying the name like RSAT.WSUS.Tools.
Joining a Windows System to Domain
To join a system to the domain, you will first need to make sure that it is appropriately licensed. All Windows Server versions are able to join as well as professional or enterprise-licensed client versions but Home or Personal versions are not.
Next, you will need a local administrator account on the system being joined as it is effectively becoming subservient to the domain permission scheme.
Finally, you will need an account with permissions to create a new AD object or set the machine password for an existing object. For small Active Directory deployments, using the domain administrator account directly is common, but for larger enterprise deployments this can become a security risk as such accounts are considerably overprivileged for domain joining. One way to handle this is by pre-creating computer objects in the domain and then setting the owner to a lesser-privileged account (e.g. a helpdesk user) which can then be used for the actual join.
If you are logged into a system as a local administrator, you can use the following Powershell command to join it to the domain:
Add-Computer -DomainName my.domain -Credential my.domain\admin -Restart -Force
NOTE! You will be prompted for the admin password when you run it. If you have a remote network connection to the server you want to join, you can connect to it and join it in one command:
Add-Computer -ComputerName <ip or domain name> -LocalCredential localadmin -DomainName my.domain -Credential my.domain\admin -DomainName -Restart -Force
NOTE! Again, you will be prompted for both passwords when you run it.
Central User and Group Identities
A key benefit of Active Directory is the centralization of user accounts and permission groups which means they don’t have to be manually defined for each member computer. This allows for a single record of users and groups in an organization that can be referenced across any system in the domain.
The key PowerShell commands to create users and groups are:
New-ADUser -Name user
New-ADGroup -Name group -GroupScope DomainLocal
You can also add users to a group with:
Add-ADGroupMember -Identity 'group' -Members user1,user2
Local vs Domain Authentication Scope
With standalone systems, user management can be burdensome, but it is straightforward to understand that each account is local to each system and not shared with any others. Active Directory provides a unified namespace (or identity provider) for user accounts across the member systems, but this can sometimes be confusing since local systems retain their own local namespaces. The two main ways that Windows shows user account context are namespace\user and user@namespace.
These two forms are mostly interchangeable, though the backslash method is more common. In the case of a local account, computername\account is a local user which can helpfully be abbreviated with .\account. If you use this form, Windows will attempt to authenticate and authorize the specified user against the local system specified or implicitly wherever the command is being run.
In a domain setting, domainname\account is a domain user and Windows will attempt to contact a domain controller to verify things before logging on and authorizing some action.
Permissions
Any combination of local and domain users and groups can be added to Windows ACLs. This includes local files, folders and other resources but is typically used with network-accessible resources like file shares and web pages where the full advantage of central authentication can be realized.
This can be seen by creating a file share with:
New-SmbShare -Name share -Path C:\Shares\share -FullAccess "domain\dba" -ReadAccess "domain\domain users", "localsystem\user"
In this case, we have given full file share access (read and write) to the domain group dba and read-only access to all domain users as well as a user on the local system.
Domain users can also be added to local groups; notably the “Domain Admins” group is automatically added to the local “Administrators” group on each member server.
Group Policy Objects
One of the key features of Active Directory is the concept of Group Policy Objects. These are collections of system settings, application settings, and security policies which can be configured and then applied to sets of computers in the domain. These computers will then match their local settings to those in the applied GPO(s) allowing for simplified central management.
The Group Policy refresh time defaults to 90 minutes (+/- 0-30 minutes) but can also be manually configured to be under 1 minute, though this is not recommended for large deployments as it creates a heavy load on the domain controller.
Creating GPOs
Windows GPOs are usually created and edited through the Group Policy Management console. This can be launched from the Start Menu under Windows Administrative Tools or by entering gpmc.msc from the Run prompt.
Within the management console, you can navigate through the domain elements on the tree on the left to the Group Policy Objects container.
Here you can right-click on the container itself to open a dialog box to create a new GPO. To set GPO policy itself, right-click on the new object and select Edit to open up the Group Policy Management Editor. This window allows you to traverse all available group policy settings including descriptions of what they are and how they need to be set. All settings default to ‘Not Configured’ which means that only options specified will be appled to computers and anythng left unset will be left alone.
Applying GPOs
Once configured, Group Policy Objects need to be applied to computer(s) within the domain. They are linked directly to Organizational Units which contain a set of users or computers. This can be done in the Group Policy Management console by selecting the appropriate OU container, right-clicking and selecting Link an Existing GPO. Applied GPOs will take effect according to the refresh time, or can be manually triggered on a target system by running gpupdate /force.
Trust Between Systems
To circle back on the original question of simplifying remote access, Windows will automatically use machine identities with an authentication scheme called Kerberos to create a secure tunnel for authentication.
Assuming your current account has remote access privileges on a remote, domain-joined system, you can simply open an interactive session with:
Enter-PSSession remotecomputer
The remote system’s identity will be validated and you will be automatically authenticated on it in a secure and convenient manner!
Windows Event Collector
One of the many other ways the Active Directory authentication can help is with secure tunnels for Windows log forwarding. Windows event logs can be sent between systems using the Windows Event Collector service which has both source-initated and collector-initated options and Active Directory will use kerberos to authenticate and encrypt sessions automatically if both source and collector are in the same domain.
The log collector service is generally interacted with using wecutil. You can do a quick config to set it up with:
wecutil qc
Subscriptions are defined either through the Windows Event Viewer subscriptions view, or on the CLI with XML files to define the settings. XML subscription files can be loaded with:
wecutil cs file.xml
Conclusion
You now should have a good overview of the purpose and capabilities provided by Microsoft Active Directory. Through its unified management you can have confidence in secure communications between trusted hosts as well as consistent security and system policies.
