Archive
Quick Post: Find Group with ManagedBy Set
I recently ran into an issue where the description of an AD group said “Can manage membership of groups listed in notes”. Unfortunately, the notes field was blank. To find what, if any group(s) could be managed by this group just takes a few simple lines of PowerShell.
The code is posted on my GitHub page.
Users not receiving email about an expiring password
WARNING – This post deals with making bulk changes to Active Directory. Proceed at your own risk.
I’ve been using the script (with a few tweaks) from http://rlmueller.net/PasswordExpires.htm to send users an email notification when they are within the configured Prompt user to change password before expiration policy. It works great but every once in a while a user would call because their password had expired & they did not receive the email. Over time occasionally that same user or a few other ones would call with the same issue.
Finally, one day another user called describing the same thing. Time to get to bottom of this one. I took a look at the user’s Active Directory account & sure enough the pwdLastSet attribute was over 90 days old. I took my script & modified it so I could just see the results without sending any emails. Your results with the original script may vary but at a minimum comment out the line that sends the email & instead pipe the output to the console.
# SendEmail $Mail $Notice
Write-Host $Name”,”$PwdExpiresDays
Sure enough when I ran it the user reporting the issue was not showing up in the results.
The script filters the results a little as noted below.
$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `
+ “(pwdLastSet>=” + $($64Bit1) + “)” `
+ “(pwdLastSet<=” + $($64Bit2) + “)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=65536)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=32)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=48))”
So I modified the filter (see below) to just show all users & ran it again. This time the user having the issue showed up.
$Searcher.Filter = “(&(objectCategory=person)(objectClass=user))”
So at least now I know the script is working but for some reason the user is being filtered out. I add each filter back one at a time to figure out which one is causing the user to be excluded. I skip over the two pwdLastSet filters because the account is already at 0 so that could cause it to not show up. So now my filter looks like this:
$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=2))”
The user still shows up. On to the next one.
$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=65536))”
Still there…next.
$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=65536)” `
+ “(!userAccountControl:1.2.840.113556.1.4.803:=32))”
Bingo! The user isn’t showing up. So I do a little checking & find that !userAccountControl:1.2.840.113556.1.4.803:=32 will exclude users that aren’t required to have a password. Huh? Now why would any of my user accounts be configured to NOT require a password? So that begs the question, how many users are configured like this? I run the following Powershell command. The results will vary depending on your environment but suffice to say you do not want a lot. (Hint hint some may legitimately need to be configured like this.)
Get-ADuser -LDAPFilter “(userAccountControl:1.2.840.113556.1.4.803:=32)” | Select-Object name
You can even see this by looking at the userAccountControl attribute in AD & see that it is set to PASSWD_NOTREQD | NORMAL_ACCOUNT.
In all my years I’ve never seen this before so I did a little digging & ran across this TechNet post.
Long story short, a long time ago when “someone” migrated user accounts they may have done it wrong.
But enough pointing fingers, how to fix it. Use the Set-ADUser command to set the user’s PasswordNotRequired flag to $false.
Set-ADUser -Identity jsmith -PasswordNotRequired $false
I’ll leave it up to you how you want to modify all the affected users. Just be careful as there may be a legitimate account that needs this setting. Again, proceed at your own risk. I just filtered based on OU.
Get-ADuser -LDAPFilter “(userAccountControl:1.2.840.113556.1.4.803:=32)” -SearchScope Subtree -SearchBase “OU=Company,DC=contoso,DC=com” | Set-ADUser -PasswordNotRequired $false
Quick Post: Get Login Script for Users
Get-ADUser -Filter * -SearchBase “DC=domainname,DC=com” -properties ScriptPath | select Name,ScriptPath
Quick Post: Count users in an OU structure in AD
Get-ADUser -Filter * -SearchBase “OU=Users,OU=Company,DC=domain,DC=com” | Measure
You’ll get something like this.
Count : 377
Average :
Sum :
Maximum :
Minimum :
Property :
Quick Post: Get a user’s group membership via PowerShell
Get-ADPrincipalGroupMembership -Identity USERNAME | select name
or
Get-ADUser -Identity USERNAME -Properties MemberOf | Select -ExpandProperty MemberOf
Change the Case of a User Logon Name
I need to change the case of a user’s logon name from TUser to tuser. Seems simple enough but turns out there’s a little trick.
I open up the properties of the user & select the Account tab.
I change both fields to tuser & click OK.
I open the properties again to double check & notice that the User logon name (pre-Windows 2000) changed but User logon name did not.
The trick is to rename the account without actually renaming it. Right click the account & select Rename.
Now retype the name exactly how it currently is & press Enter. So in my case I just type Test User & press Enter. That will bring up the Rename User dialog box. From there change the case in the User logon name textbox (& pre-Windows 2000 if not already done) & click OK.
Look at the properties of the account & the case had been changed.
Login Script Maintenance
Note – This post deals with making bulk changes to Active Directory. If you’re not careful you could really screw things up. Always test in a lab before making such changes in production.
In Active Directory all our users had a login script configured. We were needing to do some testing that required all those scripts to be removed. After testing was done we had to add all the scripts back. I sure don’t feel like typing all that manually so PowerShell to the rescue.
I’m using the Quest ActiveRoles Management Shell for Active Directory because they just rock. Modify the domain & OU structure to fit your environment.
First, export some data on every user that has a login script. If you want to be able to import the login scripts back then do not loose the CSV file!
Get-QADUser -SizeLimit 0 -SearchRoot 'abc.com/Company/Users' -ObjectAttributes @{scriptPath='*'} | select Name,sAMAccountName,scriptPath,DN | Export-Csv C:\Temp\LoginScript.csv
Next, remove the login script from everyone’s account.
Get-QADUser -SizeLimit 0 -SearchRoot 'abc.com/Company/Users' -ObjectAttributes @{scriptPath='*'} | %{Set-QADUser $_ -scriptPath ""}
Finally, add the login script back to each account based on the exported CSV file. This one is a two liner.
$File = "C:\Temp\LoginScript.csv"
Import-Csv $File | %{Set-QADUser -Identity $_.SamAccountName -scriptPath $_.scriptPath}
Quickpost: Users & Phone Numbers
Get-QADUser -SearchRoot "abc.com/Company/Users" | Select DisplayName,title,department,physicalDeliveryOfficeName,telephoneNumber | Export-Csv C:Tempphonebook.csv
No Certificate Templates Could Be Found Error
I was doing a little Active Directory Certificate Services (AD CS) testing in the lab. I came across the following error when browsing to the web enrollment page, “No certificate templates could be found. You do not have permission to request a certificate from this CA, or an error occurred while accessing the Active Directory.”
Searching around online I found plenty of articles & posts on this error but none of the solutions fixed my issue. After three days of troubleshooting here’s what worked for me.
Being a lab at some point I had changed the Authentication settings in IIS on both CertEnroll & CertSrv to Anonymous Authentication Enabled & Windows Authentication Disabled.
When I changed them back to the defaults which are Anonymous Authentication Disabled & Windows Authentication Enabled I stopped getting the error.
Update Fax Numbers in AD Using PowerShell
Just a quick post on how to change the fax number for several users who use 555-555-1234 to 555-555-4321.
Get-QADUser -SearchRoot "abc.com/ABC/Users" -LdapFilter '(facsimileTelephoneNumber=555-555-1234)' | Foreach-Object{Set-QADuser -Identity $_ -ObjectAttributes @{facsimileTelephoneNumber='555-555-4321'}}
Visitors
Patrick's Blog 