Adding Multiple Users to a Group in Active Directory Using PowerShell and CSV

Today I picked up a request from an owner of a shared drive asking for a list of her colleagues to be given access to the drive. This required finding the right group in Active Directory and making each person a member of the group.

With a total of 25 people in the list I knocked up a PowerShell script to make things a little easier for myself. The idea was to import a list of login id’s (samAccountNames) from a CSV file and add them to the required group programmatically.

I started with a simple CSV file in Excel as below:

And the script itself is only a few lines of code:

# Import active directory module for running AD cmdlets
Import-module ActiveDirectory

#Store the data from UserList.csv in the $List variable
$List = Import-CSV .\UserList.csv

#Loop through user in the CSV
ForEach ($User in $List)
{

#Add the user to the TestGroup1 group in AD
Add-ADGroupMember -Identity TestGroup1 -Member $User.username
}

Delegating Control of an OU in Active Directory – Part 2

In part 1, we used the Delegation of Control Wizard to allow our helpdesk_team group to change the password for the “IT_Services” OU, shown here below.

We had a delegation scenario where we wanted our helpdesk_team to reset passwords for everyone in “IT_Services” except “Network_Admins”. Having delegated the permission to the “IT_Services” OU, however, means the permission will be inherited by the sub-OUs including “Network_Admins” which is not what we want, of course.

In this post we will set an Explicit Deny permission on the “Network_Admins” OU to prevent the helpdesk_team group from being able to change the password for users in this OU.

Right-click on the Network_Admins OU and select Properties

Delegating Control of an OU in Active Directory – Part 1

While there’s more than one way to delegate control of an Organisational Unit in Active Directory this post will be looking at the Delegation of Control Wizard for delegation purposes.

(Designing and implementing a strategy for the delegation of administration is not something to be taken lightly; it needs careful planning and consideration and is beyond the scope of this simple two part series aimed at beginners).

I’ll start off with a simple OU delegation scenario to be implemented and then follow it up with how to implement the delegation in Active Directory using the Delegation of Control Wizard. Our scenario also requires us to set an explicit deny permission but that’ll be covered in part 2.

An Example Delegation Scenario

Let’s say we have an IT Services OU in our structure with sub-OUs called Helpdesk, Technicians and Network Admins, as illustrated in the diagram below.

Importing Users into Active Directory from a CSV File Using PowerShell

There are two aspects to this post – first is the CSV file with the user data and then there’s the PowerShell script to import the data into Active Directory. As an example, this how-to post will only set the first name, last name, username and password values for our user objects.

Preparing the CSV file

A template of the CSV file with sample data can be downloaded here (save it with a .csv extension). Here’s what it looks like:

Populate the CSV file with the user data, making sure you enter the Distinguished Name of the Organisational Unit in the OU field.

Follow these instructions to check the format of an OU’s distinguished name:

• Launch the Active Directory Users and Computers console
• Select Advanced Features from the View menu
• Right click on an OU and select Properties
• Look for distinguishedName in the Attribute Editor tab

Importing using PowerShell

The PowerShell script is my own work, written by myself. As always, I’ve included comments to explain the code to help understand it better.

Download the PowerShell script and modify it to suit any changes you may have made to the CSV file and save it with a .ps1 extension.

Make sure you have the CSV file and the script in the same directory to begin with. To run the script simply right-click on it and select “Run with PowerShell”. Launch Active Directory Users and Computers console to check if the import was successful.

Follow Me, Myself and IT on Twitter:

Follow @emeneye

The OU Structure for emeneye.ac.uk

Here’s a look at the Active Directory OU Structure I designed for the emeneye.ac.uk domain in my lab. As I explained before it is intended for a fictional university which is modeled along the lines of my previous work place.

And here’s the OU structure in Active Directory Users and Computers

The three principles that helped in designing the structure are Group Policy, delegation and object administration.

A few notes with regards to the structure:

• I came across this really good tip online about creating a master OU in AD and creating the OU structure and sub-OUs below the Master OU, which makes the structure a lot cleaner and easier on the eyes
• A wide but shallow structure means log on times should be faster due to the fact that fewer group policies will need to be processed as opposed to a deep structure
• Some OU names have been shortened into abbreviations – SoA, for example, is “School of Arts”
• The structure supports GPO inheritance
• Is designed to be flexible – I only have just the one server, the domain controller, at the moment, but will expand with NAS and WSUS in future, hence the sub-OUs under Servers
• Desktops and laptops have been separated into their own OUs to enable me to apply different settings on them without needing WMI scripts/queries to determine the form factor of the computers

Exporting and Importing an OU Structure using LDIFDE.exe

As I explained in a previous post I had to demote my Active Directory domain at home which effectively destroyed the domain and the OU structure with it. Fortunately, with a bit of advanced planning I managed to retain the structure by exporting the OU structure and then importing it into the new domain.

I briefly covered how I done this earlier in that post but that was more in note form. Hence, I wanted to write a quick how-to post on this subject separately, which uses the ldifde.exe tool for the export and import task.

Exporting the OU Structure

ldifde.exe is a simple command line tool which can export the OU structure in a text file., which needs to be run on the actual domain controller.

As an example, this is how the export command should look like:

ldifde -f c:\ExportOU.ldf -s winserverdc.emeneye.co.uk -d "dc=emeneye,dc=co,dc=uk" -p subtree -r "(objectcategory=organizationalUnit)" -l "cn,objectclass,ou"

Change the following in the above example to suit your environment:

• The location and name of the export file (C:\ExportOU.ldf)
• The domain name Name of the domain controller in which the command is being run on (Winserverdc.emeneye.co.uk)
• The domain name (“dc=emeneye,dc=co,dc=uk”)

You can execute the command as a Run Command or in a batch file, which will produce an ExportOU.ldf file (in the root of the C: drive in our example above).

Back up the ExportOU.ldf and store it in a safe place. You’ll need this later on when you’re ready to import the OU structure in a new domain.

 

Importing the OU Structure

You will need to edit the ExportOU.ldf file before you can import the OU structure in the new domain, as follows.

• Remove the first entry which references the domain name. We need to remove this because the domain name cannot be imported and without removing it the import command will fail
• Replace all occurrences of the old domain name with the new domain name

When that’s done you’re ready to import the OU structure in your new domain.

Again, an example of how the import command should look like is provided below:

ldifde -i -f "C:\ExportOU.ldf" -s winserverdc

As before, change the following to suit your environment

• The location and name of the export file (C:\ExportOU.ldf)
• The hostname of the domain controller in which the command is being run on (winserverdc)

If all goes well the command will have successfully imported the OU structure in the new domain. Launch the Active Directory Users and Computers console to verify.

Renaming the Active Directory Domain

I believe we learn as much from our mistakes as we do from our conscious learning efforts, if not more. We sometimes end up learning a lot more in the process that ensues to right our wrongs and mistakes. This post is about one of those times.

When I initially configured the domain in my network I chose emeneye.co.uk as the domain name. I say “chose” but I didn’t really give it much thought at the time, which turned into a learning opportunity for me as I went about renaming the domain name.

To provide brief background information, the Active Directory domain in my Lab is part of a broader hands-on learning project which includes improving my working knowledge of Active Directory and Windows server administration. When it came to designing the OU structure I thought it best to use an educational setting as the domain environment to guide my design decisions. My IT support experience has largely been in an educational environment so I thought it best to stick to what I know best. With that in mind, the .co.uk in the domain name didn’t seem suitable. So the task at hand was to change the name to emeneye.ac.uk.

Allowing Active Directory Domain Users to Authenticate in the MDT Deployment Wizard

When you’ve done a fresh MDT 2010/2012 installation you will notice that by default only you can authenticate past the login screen in the Deployment Wizard. That’s because when the deployment share (DeploymentShare$) is initially created when installing MDT only the user who’s installing it is given security permissions to access the share.

In a working environment with an Active Directory domain, however, you will typically want to allow a group of your IT support staff (IT Technicians, maybe?) to carry out deployment duties and refresh Windows computers as and when required.

This can be accomplished by making the relevant IT support staff user accounts members of an Active Directory group (which we’ll call DeploymentAdmins) and giving the group read and write security permissions to the  deployment share. That way any user who is a member of the DeploymentAdmins group can successfully authenticate themselves in the Deployment Wizard log in screen.

Here are some instructions:

Create a security group object in Active Directory (I called my group “DeploymentAdmins”)

Make all the relevant IT users members of the DeploymentAdmins group

Give the DeploymentAdmins group access to the DeploymentShare$ share with full read and write security permissions

It’s as easy as that.

Bear in mind if you’re doing this AFTER installing a MDT database you will need to give the DeploymentAdmins group access to the MDT database as well. There’s an excellent post over at WindowsNetworking.net with instructions on how to give a Windows domain user access to the MDT database using the SQL Server Management Studio. When following the instructions simply replace the user account in the post with the name of your security group object.

I was already working with the MDT database when I started thinking about how deployment would/should work in a domain environment. After having given the DeploymentAdmins group access to the deployment share I found none of my database settings where being applied when deployment was initiated by a member of the DeploymentAdmins group. It was then I had to use the SQL Server Management Studio to solve this as explained above.

Active Directory Design and Administration

In my previous post titled “Update 2: MDT 2010 and Windows Server 2008 R2” I briefly mentioned how my interests in Windows deployment converged with my interests in Active Directory.

Active Directory has always featured prominently in my list of technologies I wanted to explore within my Lab environment. Specifically it’s designing an AD infrastructure and server-side administration that I’m interested in.

I’ve already started the process and made the decision to design my Active Directory domain from the ground up, using an educational setting as the environment to guide my design decisions. I’m thinking of it as a practical task – to design a domain environment and OU structure based on a given scenario. The scenario is in this case is a higher education environment.

I’ve been doing a lot of reading and research online on best practices and methods for designing an Active Directory infrastructure. Some of the design considerations that I’ve been looking into are:

• Designing an OU structure
• Delegating OU administration
• Designing a Group Policy infrastructure

Once the design stage is complete and I’m happy with the OU structure I will move on to completing the network with user, computer and group objects and applying group policy settings to user and computer objects. I foresee spending a lot of my time with Group Policy and applying the policies to the user and computer objects. Computers in the domain will mostly be Virtual Machines in addition to both the test computers in my Lab. This will allow me to experiment with group policy settings for computers as well as users in the domain. Where possible I’ll be looking into using PowerShell to automate admin tasks as well.

As before I’ll be making notes on my progress as I go along which will be adapted into blog posts in due course. I can’t promise when that will be as I’ve still got a backlog of posts I need to write on MDT 2010/12. I need to get those out of the way first which will then leave me with plenty of time to spend in the Lab working on Active Directory.

PS. Wow. I must’ve mentioned the word “design” a hundred times there. Too much? :)

Installing Active Directory on Windows Server 2008 R2

I’ve put together a couple of how-to instructions intended as a guide to install Active Directory on a Windows Server 2008 R2 server from scratch – that is installing a first domain in a new forest.

Make sure you have a static IP address on your server machine before proceeding with these instructions.

Part 1 – Installing Active Directory Domain Services, along with a DNS Server

Part 2 – Installing and Configuring a DHCP Server

The first part is to install the Active Directory Doman Services role, and to then promote the server to a Domain Controller. This ‘promotion’ phase is where you actually install configure an Active domain along with a DNS server. You can’t continue with installing an Active Directory domain without a compatible DNS server. Since we’re starting from scratch we don’t have a DNS server (one that is compatible with Active Directory), we get to install both in one step.

The second part will install the DHCP server role on the Domain Controller and configure a DHCP scope, i.e. the range of IP addresses the server will lease to clients connected to your network.