Quantcast
Channel: Hey, Scripting Guy! Blog
Viewing all articles
Browse latest Browse all 3333

Transforming the Active Directory Cmdlets: Part 2

$
0
0

Summary: Learn how to transcribe between ADSI, Quest, and Windows PowerShell cmdlets for creating users.

Hey, Scripting Guy! Question Hey, Scripting Guy!

I used to use the Quest cmdlets to create new users, but I need to rewrite some of my scripts to work with a legacy environment that can't use the .NET Framework. Can you help me?

—SH

Hey, Scripting Guy! Answer Hello SH,

Honorary Scripting Guy, Sean Kearney, is here again. We're going to go into a bit more about translating between the various ways of working with Active Directory and Windows PowerShell. This is the second post in a series. You might also enjoy reading Transforming to Active Directory Cmdlets: Part 1.

Yesterday, I was discussing with my old coworker how to unlock accounts with Windows PowerShell by using the [ADSI] accelerator, the Quest cmdlets, and the modern Windows PowerShell cmdlets for Active Directory.

Let's review when Kevin had to modify one of my scripts. I had a very simple script to create users by using the Quest cmdlets that looked like this:

$First=READ-HOST 'First Name'

$Last=READ-HOST 'Last name'

$Name=$Lastname+', '+$Firstname

$Prefix=$Firstname+'.'+$LastName

$Sam=$Prefix.padright(20).substring(0,20).trim()

$UPN=$Prefix+'@Contoso.local'

$Parent='OU=Grok,DC=Contoso,DC=Local'

$Password='B@dP@ssw0rd!'

NEW-QADUser –firstname $First –lastname $Last –name $Name –parentcontainer $Parent –samaccountname $Sam –upn $UPN –userpassword $Password

When we ran this script, it would simply prompt for the First and Last names and create a disabled user account in Active Directory. The challenge Kevin had was that he needed to work with a vendor appliance, and he could not add the .NET runtime. If he did, it would break its status as a validated environment.

So he needed to easily create multiple users in this environment after they were processed and authorized by the system owner.

So in many respects, most of the script would remain unchanged. We simply needed to modify it to leverage the [ADSI] accelerator instead.

First, we built the targeting link for the binding and specified the type of object we were creating in Active Directory:

$Connection=[ADSI}"LDAP://$Parent"

$Class="user"

Then we add a DisplayName value and add the CN= to the user name because this is required for the older [ADSI] accelerator:

$DisplayName=

$Name='CN=+'$Lastname+', '+$Firstname

With this in place, we can pull out the New-QADUser cmdlet—so the script looks like this:

$First=READ-HOST 'First Name'

$Last=READ-HOST 'Last name'

$DisplayName=$First+' '+$Last

$Name='CN='+$DisplayName

$Prefix=$First+'.'+$Last

$Sam=$Prefix.padright(20).substring(0,20).trim()

$UPN=$Prefix+'@Contoso.local'

$Parent='OU=Grok,DC=Contoso,DC=Local'

$Password='B@dP@ssw0rd!'

# In the following script, we are creating the user with the older [ADSI] accelerator.

$Class="user"

$Connection=[ADSI]"LDAP://$Parent"

$NewUser=$Connection.create($Class, $Name)

$NewUser.put("sAMAccountName",$Sam)

$NewUser.put("userprincipalname",$UPN)

$NewUser.put("Sn",$Last)

$NewUser.put("Givenname",$First)

$NewUser.put("DisplayName",$DisplayName)

$NewUser.setinfo()

$AccountControl=$NewUser.useraccountcontrol

$AccountControl –bxor 2

$NewUser.useraccountcontrol=$AccountControl

$NewUser.setpassword($Password)

$NewUser.setinfo()

Kevin tested the script in the lab to make sure it worked properly. Here is the result:

Image of command output

He then popped in to Active Directory to verify that the user and attributes were created:

Image of menu

"OK, so if I have most of the variables defined, I simply need to find the block of script that has the cmdlet and swap it with the older method," he noted. "So what would it take to make this with the cmdlets in the Active Directory module?"

"Pretty much the same thing," I answered, "except we need to convert the plain text password to a secure string for the Windows PowerShell cmdlets to use. We can use this one line to convert our older variable, $Password:

$SecurePassword=ConvertTo-SecureString $Password -AsPlainText –force

"When we use the Windows PowerShell cmdlets instead of the Quest cmdlets, the script looks like the following example. We simply remove all the code after the command and replace it with this:

New-ADUser -Name $DisplayName -DisplayName $DisplayName -GivenName $First -SamAccountName $Sam -UserPrincipalName $UPN -path $Parent

Get-ADUser -Identity $Sam | Set-ADAccountPassword $SecurePassword

GET-ADAccount -identity $sam | Enable-ADAccount

"This creates the account, sets the password, and then flips the account to active. Pretty nice, eh?"

Kevin nodded, seeing that translating back and forth between scripting styles wasn't tricky after we saw the basics of each cmdlet.

That is it until tomorrow when we will see what other crazy ideas Kevin comes up with!

I invite you to follow The Scripting Guys on Twitter and Facebook. If you have any questions, send an email to The Scripting Guys at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then remember eat your cmdlets each and every day with a dash of creativity.

Sean Kearney, Windows PowerShell MVP and Honorary Scripting Guy


Viewing all articles
Browse latest Browse all 3333

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>