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