Active Directory

In Active Directory, When we open properties of an user account, click the Account tab, and then either check or uncheck boxes in the Account options dialog box, numerical values are assigned to the UserAccountControl attribute. This UserAccountControl attribute determines the state of an account in the AD domain: active or locked, Password change at the next logon is enabled or not, if users can change their passwords and other options.

UserAccountControl Attribute in AD

To view user accounts,

1. Click Start –> Programs
2. Open Administrative Tools
3. Click Active Directory Users and Computers
   • Or run dsa.msc from run window
4. Search for a user and right-click and select Properties
5. Click on Account tab

The Account Options section has the following options,

• User must change password at next logon
• User cannot change password
• Password never expires
• Store password using reversible encryption
• Account is disabled
• Smart card is required for interactive logon
• Account is sensitive and cannot be delegated
• User Kerberos DES encryption types for this account
• This account supports Kerberos AES 128 bit encryption
• This account supports Kerberos AES 256 bit encryption
• Do not require Kerberos preauthentication

Each of these user account options is 1 (True) or 0 (False) and are not stored as separate AD attributes, instead the UserAccountControl attribute is used. The flags are cumulative. The total value of all options are stored in the value of UserAccountControl attribute.

To determine the current value of the attribute,

Using PowerShell,

$user = Read-Host "Enter user's logon"
Get-ADuser $user -properties * | Select name, UserAccountControl | ft

Using dsa.msc,

1. dsa.msc from Run window
2. Search for a user and right-click and select Properties
3. Click on Attribute Editor tab
   • If you are missing this tab, Click View in the Active Directory Users and Computers window and select Advanced Features

In this example, the value of the attribute is 0x200 (decimal value is 512).

The following table lists possible flags that can be assigned to an account. Each flag corresponds to a certain UserAccountControl bit, and UserAccountControl value equals the sum of all flags.

The userAccountControl value is calculated as,

NORMAL_ACCOUNT (512) + ACCOUNTDISABLE (2) = 514

NORMAL_ACCOUNT (512) + DONT_EXPIRE_PASSWORD (65536) + ACCOUNTDISABLE (2) = 66050

To list all active users,

Get-ADUser -Properties * -ldapFilter "(useraccountcontrol=512)" | Select UserPrincipalName,userAccountControl | ft

To list all disabled user accounts,

Get-ADUser -Properties * -ldapFilter "(useraccountcontrol=514)" | Select UserPrincipalName,userAccountControl | ft

To list accounts with a non-expiring password,

Get-ADUser -Properties * -ldapFilter "(useraccountcontrol=66048)" | Select UserPrincipalName,userAccountControl | ft

Here are the default UserAccountControl values for the certain objects:

• Typical user: 0x200 (512)
• Domain controller: 0x82000 (532480)
• Workstation/server: 0x1000 (4096)

Decode UserAccountControl Values

To fully decode UserAccountControl bit field we can use this PowerShell script,

Add-Type -TypeDefinition @'
[System.Flags]
public enum UserAccountControl{
	SCRIPT = 1,
	ACCOUNTDISABLE = 2,
	BIT_02 =  4,
	HOMEDIR_REQUIRED = 8,
	LOCKEDOUT = 16,
	PASSWD_NOTREQD = 32,
	PASSWD_CANT_CHANGE = 64,
	ENCRYPTED_TEXT_PWD_ALLOWED = 128,
	TEMP_DUPLICATE_ACCOUNT = 256,
	NORMAL_ACCOUNT = 512,
	BIT_10 = 1024,
	INTERDOMAIN_TRUST_ACCOUNT = 2048,
	WORKSTATION_TRUST_ACCOUNT = 4096,
	SERVER_TRUST_ACCOUNT = 8192,
	BIT_14 = 16384,
	BIT_15 = 32768,
	DONT_EXPIRE_PASSWORD = 65536,
	MNS_LOGON_ACCOUNT = 131072,
	SMARTCARD_REQUIRED = 262144,
	TRUSTED_FOR_DELEGATION = 524288,
	NOT_DELEGATED = 1048576,
	USE_DES_KEY_ONLY = 2097152,
	DONT_REQ_PREAUTH = 4194304,
	PASSWORD_EXPIRED = 8388608,
	TRUSTED_TO_AUTH_FOR_DELEGATION = 16777216,
	PARTIAL_SECRETS_ACCOUNT = 67108864
}
'@

Which can be used like this to decode the bits,

If you want to display all flags that are set in UAC,

Get-AdUser -Filter * -Properties UserAccountControl | select name, @{n='UAC';e={[UserAccountControl]$_.UserAccountControl}}

This script can also be used to determine UserAccountControl value for specific AD accounts,

$user = Read-Host "Enter user's logon"
Get-ADuser $user -properties * | select name,UserPrincipalName, @{n='UAC';e={[UserAccountControl]$_.UserAccountControl}}

Update UserAccoutControl Attribute in AD using PowerShell

To change UserAccountControl attribute in AD using PowerShell, we can use Set-ADUser, Set-ADComputer and Set-ADAccountControl cmdlets,

$user = Read-Host "Enter user's logon"
Set-ADAccountControl -Identity $user –CannotChangePassword:$true -PasswordNeverExpires:$true

or

$user = Read-Host "Enter user's logon"
Set-ADUser -Identity $user –CannotChangePassword:$true -PasswordNeverExpires:$true

Set a specified computer to be trusted for delegation,

$Computer = Read-Host "Enter computer or server name"
Set-ADAccountControl -Identity $Computer -TrustedForDelegation $True

or

$Computer = Read-Host "Enter computer or server name"
Set-ADComputer -Identity $Computer -TrustedForDelegation $True

The user account attribute can also be updated using the Set-ADUser cmdlet. In this below example, I’m enabling user account,

$user = Read-Host "Enter user's logon"
Set-ADUser $user -Replace @{UserAccountControl = 512}

Hope this post helped you get a better understanding of the UserAccountControl attribute.

Thank you for stopping by ✌

If you don’t have an AD user provisioning tool implemented in your environment, I’m sure most of your user provisioning and de-provisioning is done using PowerShell scripts which helps in reducing the amount of time consumed in this process.

You probably are bombarded with requests from various departments in your organization to provide them with a list of new users who were created for various reasons.

This script can be automated by securely storing the credentials and running a scheduled task that runs on a specific day. Don’t store your admin or any credentials in any of your scripts.

You can use ConvertFrom-SecureString command to get an encrypted standard string and ConvertTo-SecureString to simply reverse the process by importing the data from your file and then create a PSCredential object.

(Get-Credential).Password | ConvertFrom-SecureString | Out-File "C:\Temp\Password.txt"

$User = "AdminUser@acme.com"
$File = "C:\Temp\Password.txt"
$MyCredential=New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, (Get-Content $File | ConvertTo-SecureString)

In this above method, the point of converting password to a SecureString and storing it in a file is to keep it out of plain text in PS scripts so that it’s not as easily discovered. This can be easily decrypted and not recommended.

You can use the Microsoft.PowerShell.SecretManagement and Microsoft.PowerShell.SecretStore PS modules which I’ve covered in a later post.

​$Days = -7
$Maxdate = (Get-Date).addDays($Days) 
$CurrentWeekNumber = Get-Date -UFormat %V

$dateformat = "dddd MM/dd/yyyy"
$subjDate = Get-Date $Maxdate -Format $dateformat

$NewUsers = Get-ADUser -filter { whencreated -ge $Maxdate} -Properties EmailAddress, co, Description | Select-Object -Property GivenName, SurName, DisplayName, Description, co, EmailAddress # Gathering recent New AD Users

if ($NewUsers) # If there are more than one new user created in last $Days, prepare to send a mail
    {
    $MailBody = $NewUsers | ConvertTo-Html -Fragment
    
            $MailParams = @{Body       = $mailBody | Out-String
                            BodyAsHtml = $true
                            From       = "AD-Admin@acme.com"
                            To         = "jsmith@acme.com" # separate with comma for multiple users. "jdoe@acme.com", "jroe@acme.com"
                            SmtpServer = "smtp.acme.com"
                            Subject    = "New users for the week : $CurrentWeekNumber | Week Starting - $subjDate"
                            Encoding   = "UTF8"
                            Priority   = "Normal" # Accepted values: Normal, High, Low
                            #Port      = xxxx #If not 25
                            Credential = $(Get-Credential)
                            }
    Send-MailMessage @MailParams
    }

Hope this script was useful is generating weekly reports of newly created AD users.

Thank you for stopping by. ✌

I recently faced an issue where users are provisioned to AD using an user system/tool that applies the Country value to the user while creating the account but it doesn’t have the ability to update the countryCode and co attributes. And I had few thousand users with no value set in the co and countryCode attributes.

In this post, I’ll cover the details on how came up with a workaround for this issue.

The AD attributes we are dealing with here are,

• c (Country-Name): ISO-3166 2-digit string value
• countryCode (Country-Code): ISO-3166 Integer value
• co (Text-Country): Open string value

When we pick a country name from the drop-down in the Active Directory users and computers GUI, the c, co and countryCode attributes are automatically assigned.

With PowerShell, we can use the Set-ADUser to assign the c attribute to the user,

$user = Read-Host "Enter user's logon"
Set-ADUser -Identity $user -Country US

In this method, no values are assigned to the co and countryCode attributes automatically like how it happened while updating in the GUI. Below are the screenshots of the user properties after running the above cmdlet.

We can use this method to assign all three values for the user,

$user = Read-Host "Enter user's logon"
Set-ADUser -identity $user -Replace @{c="CN";co="United States";countryCode="840"}

In my scenario, the users provisioned by the tool already had the c attribute value set. I exported all users from the AD domain, determined the countries and then used the below script to update the co and countryCode attributes.

$users = Get-ADUser -LDAPFilter '(!userAccountControl:1.2.840.113556.1.4.803:=2)' -Properties * | Select cn, sAMAccountName, userPrincipalName, c

foreach ($User in $Users){
        if($user.c -eq 'AU') {
            Set-ADuser $user.sAMAccountName -Replace @{co="Australia";countrycode="36"}
        }
        elseif ($user.c -eq 'US') {
	        Set-ADuser $user.sAMAccountName -Replace @{co="United States";countrycode="840"}
        }
        elseif ($user.c -eq 'GB') {
	        Set-ADuser $user.sAMAccountName -Replace @{co="United Kingdom";countrycode="826"}
        }
        elseif ($user.c -eq 'CA') {
	    Set-ADuser $user.sAMAccountName -Replace @{co="Canada";countrycode="124"}
        }
        else {
            Write-Host $user.cn does not contain Country value
    }
}

This table at the end of this post provides all countries in the AD address tab Country/region drop-down list. You can use this to update the above script according to your needs. I also made this script to be run as a scheduled task to run once a week to update the new users created throughout the week. Not a perfect solution but replacing the user provisioning tool wasn’t an option in my case, hence I stuck with this method.

Hope this post helped you in better understanding the c, co and countryCode attributes in AD and an easier method to update it.

Thank you for stopping by ✌