User Provisioning and De-provisioning

User provisioning is the process of creating, maintaining, and managing user identities and their access rights within an organization's IT systems. De-provisioning is the reverse: revoking access and removing accounts when they are no longer needed, such as when an employee leaves or changes roles. These processes are foundational to identity and access management (IAM) and are critical for enforcing the principle of least privilege.

The threat addressed is unauthorized access through orphaned accounts—accounts that remain active after a user's departure. Attackers often target these accounts because they may have elevated privileges and are less likely to be monitored. In the 2021 SolarWinds attack, attackers exploited orphaned accounts to maintain persistence. Proper de-provisioning eliminates this attack vector.

Provisioning typically follows a workflow triggered by an authoritative source, such as an HR system. When a new employee is hired, HR enters their details (name, role, department). The provisioning system then:

In a typical Windows environment, the process might use PowerShell cmdlets like:

New-ADUser -Name "John Doe" -SamAccountName "jdoe" -UserPrincipalName "jdoe@company.com" -Enabled $true -AccountPassword (ConvertTo-SecureString "TempPass123!" -AsPlainText -Force)
Add-ADGroupMember -Identity "Finance" -Members "jdoe"

For cloud environments, Azure AD or AWS IAM roles are used. Provisioning can be automated via SCIM (System for Cross-domain Identity Management, RFC 7644), which standardizes user schema and REST API endpoints.

De-provisioning is triggered by HR events: termination, resignation, or role change. The process should be immediate and automated to minimize the window of exposure. Steps include:

In Active Directory, disabling an account is done with:

Disable-ADAccount -Identity "jdoe"

In Azure AD, you can block sign-in:

Set-AzureADUser -ObjectId "jdoe@company.com" -AccountEnabled $false

Attackers look for orphaned accounts—accounts that remain active after a user leaves. They may discover them through: - Password spraying: Trying common passwords against known usernames. - Dumpster diving: Finding old credentials in public breach databases. - Insider threat: A departing employee retains access intentionally.

Once accessed, the attacker can use the account to move laterally, exfiltrate data, or escalate privileges. For example, if a terminated sysadmin's account is not disabled, an attacker who obtains the password can gain domain admin rights.

Defenders implement automated de-provisioning workflows integrated with HR systems. Key practices include: - Immediate account disablement upon termination. - Regular audits of active accounts against HR records. - User access reviews every 90 days. - Separation of duties: The HR team initiates, IT executes.

Tools like Microsoft Identity Manager, Okta, or SailPoint automate these processes. On Linux, you might use:

# Lock a user account
passwd -l username
# Remove the user
userdel -r username

Windows Active Directory:

# Create user
New-ADUser -Name "Jane Smith" -GivenName Jane -Surname Smith -SamAccountName jsmith -UserPrincipalName jsmith@domain.com -Path "OU=Users,DC=domain,DC=com" -AccountPassword (Read-Host -AsSecureString "Initial Password") -Enabled $true

# Disable user
Disable-ADAccount -Identity jsmith

# Delete user after retention
Remove-ADUser -Identity jsmith -Confirm:$false

Linux/Unix:

# Add user
useradd -m -G developers jdoe
passwd jdoe

# Lock account
usermod -L jdoe

# Delete user and home directory
userdel -r jdoe

Cloud (AWS IAM):

# Create user
aws iam create-user --user-name jdoe
aws iam attach-user-policy --user-name jdoe --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Disable access keys
aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name jdoe

# Delete user
aws iam delete-user --user-name jdoe

SY0-701 tests the concept of the identity lifecycle and the importance of timely de-provisioning. Be prepared to identify scenarios where an attacker exploits an orphaned account. Know that SCIM is the standard for automating provisioning in cloud apps. Understand that RBAC simplifies provisioning by assigning permissions based on roles, not individuals.

A large financial institution terminated a senior database administrator (DBA) but failed to disable his account in the legacy CRM system. The CRM was not connected to the central provisioning system. Six months later, an attacker obtained the DBA's password from a prior data breach and used it to log into the CRM, which still had full administrative privileges. The attacker exported customer records containing PII. The SOC detected unusual data transfer via DLP alerts, but the response was delayed because the account appeared legitimate. The correct response would have been to immediately disable the account and revoke all sessions upon termination. The mistake was relying on manual de-provisioning for the CRM. A common error is assuming that disabling the account in Active Directory automatically propagates to all systems—this is false unless integrations exist.

A technology firm hired a contractor for a six-month project. The contractor was given access to the development environment, source code repositories, and a VPN. When the project ended, the manager forgot to notify IT. The contractor's accounts remained active. Two months later, the contractor's VPN credentials were used to access the network from an unrecognized IP. The SOC received an alert for anomalous VPN login (geolocation mismatch). Upon investigation, they found the contractor's account was still enabled. The correct response was to disable the account, terminate the VPN session, and review access logs for any data exfiltration. The mistake was not having an automated de-provisioning trigger linked to the contract end date in the HR system. A common error is assuming that contractors are handled the same as employees—they often have different offboarding procedures.

An employee was promoted from sales to marketing. The provisioning system added new group memberships for marketing but did not remove the old sales groups. The employee retained access to the sales CRM, which contained sensitive client data. This violates least privilege. The SOC discovered this during a quarterly user access review when comparing group memberships to job roles. The correct response was to remove the sales group membership and audit the employee's activity in the sales CRM. The mistake was assuming that role changes only require adding permissions, not removing old ones. A common error is to focus only on provisioning and neglect de-provisioning for role changes.