Active-Directory on Neale's Corner

Modifying cross forest members of Active Directory groups

Mon, 11 Mar 2019 00:00:00 +0000

Adding users to groups within the same domain using Powershell is quite simple - there is a cmdlet Add-ADGroupMember (and removing them is just as easy !), but how we accomplish when one domain contains groups and has a one way trust with a domain in another forest that contains the users ?

This is a rhetorical question ;) Assuming we are running from the domain containing the groups, the other domain needs to be mapped to a PSDrive. Once done we can search for the user and use the Add-ADGroupMember cmdlet to add them.

Removing users is nearly as straight forward, though I only had success using Remove-ADPrincipalGroupMembership to remove the remote user.

We will need to know:

The name of the remote domain.
A credential for the remote domain.
The name of the group.
The samaccountname of the users to add or remove.

I’ve written a script below, which is able to add and remove users to a group in single call. There is no need to specify the domain controller for the remote user domain as this can be discovered (I’m assuming your DNS is configured correctly and healthy !). However this has not been tested:

In a two-way trust.
Running in the user domain/forest.

param([Parameter(Mandatory=$true)][string] $GroupName = $(Read-Host -Prompt "Please enter a group name"),
      [string[]] $Add = $(Read-Host -Prompt "(optional) Please enter the names of any users to add to the group"),
      [string[]] $Remove = $(Read-Host -Prompt "(optional) Please enter the names of any users to remove from the group"),
      [Parameter(Mandatory=$true)][string] $RemoteDomainName = $(Read-Host -Prompt "Please enter the remote domain name"),
      [Parameter(Mandatory=$true)][PSCredential] $RemoteCredential = $(Get-Credential),
      [string] $RemoteDC,
      [switch] $Confirm)

# Ensure that this is loaded. Fail if not.
if ($null -eq $(Get-Module ActiveDirectory)) {
	Write-Host "Attempting to load ActiveDirectory module.";
	try {
		Import-Module ActiveDirectory;
		Write-Host "Loaded ActiveDirectory module." -ForegroundColor Green;
	} catch {
		Write-Host "Could not load ActiveDirectory module" -Foreground Red;
		exit;
	}
}

# Try and connect to the remote domain.
$domain = Get-ADDomain $RemoteDomainName -Credential $RemoteCredential -ErrorAction SilentlyContinue;
if ($null -eq $domain) {
    Write-Host "There was an error retrieving domain information for $RemoteDomainName" -ForegroundColor Red;
    exit;
}

# Get the group in the local domain.
$group = Get-ADGroup $GroupName -ErrorAction SilentlyContinue -Properties *
if ($null -eq $group) {
    exit;
}

if ($group.GroupScope -ne "DomainLocal") {
    Write-Host "The group $($group.Name) has scope $($group.GroupScope)";
    Write-Host "The group is not configured to contain remote users." -ForegroundColor Red;
    exit;
}

# Get the remote domain details.
$RemoteNetBIOS = $domain.NetBIOSName;
$RemoteDN = "//RootDSE/$($domain.DistinguishedName)";

if ($null -eq $RemoteDC -Or $RemoteDC.Length -eq 0) {
    $dc = Get-ADDomainController -Discover -DomainName $RemoteNetBIOS
    $RemoteDC = $dc.HostName;
}

# Try and map the remote domain to a PS drive.
try {
    New-PSDrive -Name $RemoteNetBIOS -Credential $RemoteCredential -Root $RemoteDN -PSProvider ActiveDirectory -Server $RemoteDC | out-null

} catch {
    Write-Host "There was an error connecting to the $RemoteDomainName domain." -ForegroundColor Red;
    exit;
}

foreach ($username in $Add) {
    if ($null -eq $username -Or $username.Length -eq 0) {
        continue;
    }

    # Get the user and add to the group.
    $user = Get-ADUser -Filter {SamAccountName -eq $username} -Server $RemoteNetBIOS -Credential $RemoteCredential;
    if ($null -ne $user) {           
        $group | Add-ADGroupMember -Members $user;
        Write-Host "$username was added to the group '$GroupName' successfully." -ForegroundColor Green;

    } else {
        Write-Host "Could not find a user with the username '$username'" -ForegroundColor Red;

    }
}

foreach ($username in $Remove) {
    if ($null -eq $username -Or $username.Length -eq 0) {
        continue;
    }

    $user = Get-ADUser -Filter {SamAccountName -eq $username} -Server $RemoteNetBIOS -Credential $RemoteCredential;
    if ($null -ne $user) {
        Remove-ADPrincipalGroupMembership -Server $RemoteNetBIOS -Credential $RemoteCredential $user -MemberOf $group -Confirm:$Confirm;
        Write-Host "$username was successfully removed from the group '$GroupName'" -ForegroundColor Green;

    } else {
        Write-Host "Could not find a user with the username '$username'" -ForegroundColor Red;

    }
}

# Unmap the remote domain
if ($null -ne $(Get-PSDrive -Name $RemoteNetBIOS -ErrorAction SilentlyContinue)) {
    Remove-PSDrive $RemoteNetBIOS;
}

The script doesn’t take into account if the user is already a member of the group - the way to do this is to retrieve the groups “member” property and use the SID to check against the user.

As usual, let me know if this is useful or you have any other corrections/comments. I’ve put this into a simple script located here as the script “Set-ADGroupTrustedForestMembership.ps1”.

DHCP authorisation for subdomains

Tue, 23 Oct 2012 00:00:00 +0000

While setting up multi-forest, multi-domain environment to test an Exchange 2010 deployment I decided to do something that I hadn’t done when setting up these tests before - I implemented DHCP on one of the domains - all so I could bring up clients as required.

Installing the DHCP service was as easy as usual. Then I came to authorising the server in my child active directory domain.

Lucky I found a MS article on it -Â http://support.microsoft.com/kb/303351. I logged onto a first-forest-domain as an enterprise administrator and ran the command:

netsh dhcp add server

And then to verify that it worked:

netsh dhcp show server

No need for GUI tools, always a good thing :). But whenÂ I went back to my DHCP server it was still showing as unauthorised - after a quick restart of the service everything was working as it should.

NTFS permissions to modify files but not folder structure

Sat, 03 Mar 2012 00:00:00 +0000

I had a request a little while ago where an end-user wanted a set of users to be able to fully manage the folder structure below a certain folder in share, and for another set of users to be able to create/modify/delete files anywhere within that structure, but be unable to change the structure itself. Sounds very straight forward, but there’s slightly more to it than meets the eye

\[especially if you're used to applying one ACE (Access Control Entry) per security group/user\]

I’ve created three security groups and am setting permissions on the folder in the share that will contain the managed structure. The groups are:

Root Owners Root Contributers Root Â Viewers

Root Viewers is purely good practice for limiting access to shares - this could be left out and be replaced with domain users or authenticated users if you wish.

Root Owners have the standard “just less than full administrator” permissions - they do not have Full Control on the parent folder, and are also missing delete, change permissions and take ownership. This ACE is applied to the parent folder, it’s subfolders and files.

It’s the ACE for the Contributers that is where it’s at. Or more importantly, the two ACE’s - one for browsing folders and creating files, and another for modify access on the files.

Let’s start with the files ACE first. Here’s what it looks like:

This is fairly straight forward - it applies to Files Only and contains the permissions to read/write and delete. The important distinction comes from the permissions with two explanations listed:

Traverse Folder / Execute File List Folder / Read Data Create Files / Write Data Create Folders / Append Data

The first items listed are the permissions if the ACE was applied to a folder - the second if the ACE is applied to files. Typically the ACE is applied to “This folder, subfolders and files” so there is no need to separate them out. Since this ACE is being applied to files and we want the security group to be able to save files, we tick the permissions for “Write Data” and “Append Data”. This will not grant this security group the right to create files or folders and the ACE will apply to all files (even ones within subfolders) below the folder where the ACE is applied.

Bearing in mind that the following article applies to Windows 2000 -Â http://support.microsoft.com/kb/220167Â - there is the following stated regarding applying to files only:

“Files only” Apply Onto value, (IO), (OI) ACE flags: ACE does not apply to this container, but propagates to the files it contains. Subfolders do not receive this ACE.

If you were to examine a subfolder you would see that the ACE is received by it and it applies to the files contained within. The same article states the meanings of OI and OI, and it is OI that defines this behaviour:

IO: Inherit Only - This flag indicates that this ACE does not apply to the current object. CI: Container Inherit - This flag indicates that subordinate containers will inherit this ACE. OI: Object Inherit - This flag indicates that subordinate files will inherit the ACE. NP: Non-Propagate - This flag indicates that the subordinate object will not propagate the inherited ACE any further.

The ACE onto folders is somewhat simpler:

We want users in the group to be able to traverse the folder, read data and to be able to create files within subfolders - thus all the relevant boxes are ticked as per the image above - just ensure that this ACE only applies to the main folder and subfolder though.

And that’s it - creating an ACE for read access to the folder is simple enough - but through these two main ACE’s you can deny user’s the ability to alter the folder structure but still allow them to create all the files they like. Quotas notwithstanding of course, but that’s a different matter ;)