Modifying cross forest members of Active Directory groups

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.

DHCP authorisation for subdomains

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 – I logged onto a first-forest-domain as an enterprise administrator and ran the command:

netsh dhcp add server <fqdn of dhcp server> <ip of dhcp 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

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].