01 — Identity and Access Management (IAM) — Local User Provisioning & Least Privilege - rafaelribeiro-s/it-support-sysadmin-portfolio GitHub Wiki

📋 Case Study: Identity & Access Management (IAM) — Local User Provisioning & Least Privilege

🏢 Enterprise Environment Context

  • Company Name: NexaCorp Solutions Ltd.
  • Industry: Cloud Financial Services
  • Ticket ID: INC-804291
  • Department: Marketing & Growth
  • Requester: HR Operations Team

👤 Employee Profile

  • Full Name: Sarah Jenkins
  • Username: s.jenkins
  • Employee ID: NX-7742
  • Job Title: Senior Digital Marketing Specialist
  • Department: Marketing & Growth
  • Direct Supervisor: Operational Marketing Lead

🛠️ IT Support Assignment

  • Assigned Analyst: Rafael Ribeiro
  • Role: IT Support & Systems Administrator

Security Objectives

The workstation must follow the organization's least-privilege requirements.

Sarah requires access to:

  • Standard Windows applications
  • Work-related files
  • Approved marketing applications
  • Her local user profile

Sarah does not require:

  • Local administrator privileges
  • System configuration privileges
  • Installation of unauthorized software
  • Access to administrative system functions

📩 Help Desk Ticket Description (Original Request)

  • Ticket: INC-804291
  • Subject: New Employee Onboarding — Sarah Jenkins

Request:

HR Operations has requested the provisioning of a Windows workstation for Sarah Jenkins, a new Senior Digital Marketing Specialist joining the Marketing & Growth department.

The employee requires access to standard Windows applications, work-related files, and approved marketing software.

In accordance with the organization's least-privilege policy, Sarah must not receive local administrator privileges.

The workstation must be configured with a dedicated local Windows user account and the minimum privileges required to perform her job responsibilities.

🎯 Key Technical Objectives for the Lab

The purpose of this lab is to demonstrate the provisioning of a local Windows user account while applying the principle of least privilege.

The following objectives must be completed:

  1. Create a local Windows user account named s.jenkins.
  2. Configure the user's display name as Sarah Jenkins.
  3. Configure the account as a Standard User.
  4. Ensure the account is not a member of the local Administrators group.
  5. Configure an appropriate password for the local user account according to the lab's credential requirements.
  6. Review Windows privacy and application permissions.
  7. Verify that administrative operations require appropriate elevation.
  8. Document the configuration and verification evidence.

🧪 Lab Environment

The lab was implemented using a virtualized Windows 11 Enterprise Evaluation workstation.

Component Configuration
Virtualization Platform Oracle VirtualBox
Guest Operating System Windows 11 Enterprise Evaluation 25H2
Architecture x64
CPU 4 vCPUs
Memory 8 GB
Storage 80 GB VDI
Firmware UEFI
Secure Boot Enabled
TPM 2.0
Network NAT
Workstation name NX-WS-MKT04
Administrative Account NexaAdmin

Step - By - Step

Step 1: Create a standard user account.

  1. Open Start > Settings > Accounts > Other Users
  1. Select Add another user > Add account.
  1. Select I don't have this person's sign-in information.
  1. Select Add a user without a Microsoft account.
  1. Enter a username and create a strong password. It's a good idea to use a password manager.
  1. Click Next and complete all additional prompts.

Step 2: Set user account permissions

  1. Go back to Settings > Accounts > Other Users.

  2. Locate the newly created account in the "Other Users" section and select it.

  3. Select Change Account Type.

  1. Under Account Type, select Standard User from the drop-down menu.

  2. Select OK to confirm.

🔧 Implementation

1. Workstation Identity

The Windows workstation was initially installed using the Windows 11 Enterprise installation media.

After installation, Windows had generated a default computer name. The workstation was renamed according to the simulated enterprise naming convention:

NX-WS-MKT04

The final hostname was validated using:

hostname

Expected result:

NX-WS-MKT04

Evidence:

Figure — Workstation hostname validation.

2. Administrative Account

A dedicated local administrative account named NexaAdmin was created during Windows setup.

This account is intended for administrative operations and is separate from the standard employee account created for the simulated onboarding request.

The employee account was intentionally not granted local administrator privileges.

3. Local user Provisioning

A dedicated local Windows account was created for the simulated employee:

Attribute Configuration
Employee Sarah Jenkins
Username s.jenkins
Account Type Standard User
Account Scope Local Windows Account

The account was configured as a Standard User to follow the least-privilege requirement defined in the onboarding request.

Evidence:

Figure — Local Windows user provisioning.

4. Account Type Validation

The account configuration was reviewed through Windows account management settings to verify that s.jenkins was configured as a Standard User.

The employee account was not configured as a local administrator.

Evidence:

Figure — Standard User account validation.

5. Local Group Membership Validation

The local group membership of s.jenkins was validated using:

net user s.jenkins

The resulting configuration showed the account associated with the local Users group.

This provided command-line confirmation of the account's local group membership.

Evidence:

Figure — Local group membership validation for s.jenkins.

6. Local Administrators Group Validation

The local Administrators group was inspected using:

net localgroup Administrators

The validation showed NexaAdmin as the administrative account and did not show s.jenkins as a member of the local Administrators group.

This provides direct evidence that the simulated employee account was not granted local administrator membership.

Evidence:

Figure — Local Administrators group membership validation.

🔐 Security Validation

7. Security Validation

The logged-in user identity was validated using:

whoami

This command was used to confirm the Windows identity associated with the current session.

Evidence:

Figure — Windows security group context validation.

8. Security Group Context

The security group context of the logged-in account was inspected using:

whoami /groups

This provided an additional command-line validation of the security groups associated with the user session.

9. Administrative Privilege Boundary

The standard-user session was tested by launching Device Manager.

Windows displayed a notification indicating that the current session was logged on as a standard user and that administrator credentials were required to make changes.

Device Manager could still be opened for viewing, but administrative modifications required elevated privileges.

This behavior provides supplementary evidence of the separation between standard user activity and administrative system changes.

Evidence:

Figure — Administrative privilege boundary observed from the Standard User session.

🔒 Privacy & Security Review

Windows Privacy & Security settings were reviewed as part of the endpoint configuration process.

Location access was disabled through an administrative configuration because location services were not required for the simulated employee's role.

The Windows diagnostic data configuration was set to the required-only level during the initial Windows setup.

Camera, microphone, and other application permissions were reviewed separately according to the Windows privacy permission model. No unnecessary application permissions were granted solely for the purpose of this lab.

Privacy & Security Overview

Evidence:

Figure — Windows Privacy & Security configuration review.

🛠️ Troubleshooting

UEFI Boot Issue

Issue: The virtual machine initially returned to the UEFI firmware interface instead of starting Windows Setup.

Cause: The Windows installation ISO was not being booted from the optical device.

Resolution: The Windows 11 Enterprise ISO was selected as the optical boot media and configured as the appropriate boot device.

Result: Windows Setup started successfully.

Default Hostname

Issue: Windows generated the default computer name DESKTOP-UPMUHL4 during installation.

Requirement: The workstation needed to follow the simulated enterprise naming convention NX-WS-MKT04.

Resolution: The computer name was changed through Windows Settings.

Result: The hostname was validated using the hostname command and returned NX-WS-MKT04.

🧠 Lessons Learned

This lab reinforced several practical concepts related to endpoint identity and access management:

  • User account type and group membership should be validated independently rather than relying only on the graphical interface.
  • Standard user accounts provide a clear separation between normal employee activity and administrative operations.
  • Administrative privileges should be granted only when required.
  • Privacy settings should be reviewed according to business requirements rather than applying unnecessary blanket restrictions.
  • Technical evidence should demonstrate the actual configuration and validation performed.
  • Troubleshooting should be documented as part of the implementation process.

✅ Final Result

The lab successfully demonstrated local Windows identity provisioning and endpoint-level privilege management for a simulated enterprise employee.

The s.jenkins account was provisioned as a Standard User, validated as a member of the local Users group, and confirmed as absent from the local Administrators group.

Administrative privilege boundaries were additionally validated through Windows administrative behavior, while Windows Privacy & Security settings were reviewed as part of the endpoint configuration process.

The resulting workstation configuration provides a practical demonstration of least-privilege implementation, account validation, privacy review, troubleshooting, and technical evidence collection in a Windows endpoint environment.