Work Experience Highlights

The Challenge

User unable to connect to corporate VPN. Error message indicated "Umbrella inactive" but standard troubleshooting (network diagnostics, VPN client reinstall) showed no connectivity issues. This required deeper investigation at the service level.

My Approach

1. Identified this as a potential service-level failure requiring privileged access to diagnose
2. Used CyberArk to request temporary administrative credentials
3. Encountered permission configuration issue - CyberArk role wasn't properly selected
4. Cleared browser cache and reselected correct privileged access role in CyberArk
5. Successfully retrieved LAPS password from Entra ID (Azure AD)
6. Accessed Windows services console (services.msc) with admin credentials
7. Discovered Cisco Secure Client VPN services were stopped
8. Restarted required services and validated VPN connectivity

Outcome

User was back online within 15 minutes. This case demonstrated understanding that VPN connectivity issues aren't always network problems - sometimes they're endpoint service failures that require elevated troubleshooting with proper privileged access management workflows.

Skills Demonstrated

• CyberArk PAM
• LAPS
• Entra ID
• Windows Service Management
• VPN Troubleshooting
• Systematic Diagnostics

The Challenge

User requested access to a network file share for a project they were joining. This required following proper approval workflows and implementing least-privilege security principles while ensuring the user could work immediately after approval.

My Approach

1. Accessed Active Directory Users and Computers (ADUC) to identify the security group controlling folder access
2. Reviewed NTFS permissions on the network share to confirm which AD group provided appropriate access level
3. Identified the group owner (department manager) responsible for access approvals
4. Contacted data owner via Teams to explain user's business need and requested approval for read/write access
5. After receiving approval, added user to appropriate security group in ADUC
6. Instructed user to restart their computer to refresh their access token with new group membership
7. Validated user could access the share with proper permissions

Outcome

User had functional access to required resources within 10 minutes of approval. More importantly, the process followed least-privilege principles - user received only the specific access level needed (read/write to one folder) rather than broader permissions. This approach maintains security while enabling productivity.

Skills Demonstrated

• Active Directory
• ADUC
• Security Groups
• NTFS Permissions
• Least-Privilege Security
• Business Communication
• Access Token Concepts

The Challenge

User needed Microsoft Teams access on their personal mobile device to stay connected with work communications. Company policy requires all mobile devices accessing corporate resources to be managed through Intune MDM with security policies enforced, making this more complex than simply downloading an app from the store.

My Approach

1. Configured user's Entra ID profile with required group memberships for mobile access
2. Added user to SecureW2 security group for certificate-based authentication
3. Assigned appropriate MDM profile for corporate device management policies
4. Walked user through downloading Microsoft Company Portal app on their device
5. Guided user through sign-in process with MFA approval (authentication app verification)
6. Validated device enrolled successfully in Intune and appeared as compliant
7. Instructed user to download Teams through Company Portal (not App Store) to ensure managed app deployment
8. Confirmed Teams launched with corporate policies applied (PIN requirement, no screenshot capability, etc.)

Outcome

User successfully gained secure access to Microsoft Teams on their mobile device with all corporate security policies enforced. Device appeared in Intune management console as compliant, enabling access to Conditional Access-protected resources. This approach balances user productivity (mobile access) with security requirements (managed devices, MFA, policy enforcement).

Skills Demonstrated

• Entra ID / Azure AD
• Intune MDM
• SecureW2
• Company Portal
• MFA
• Mobile Security Policies
• End-User Training

The Challenge

End user reported their newly assigned Windows 365 Cloud PC license was not provisioning and the Cloud PC was unavailable. The user had a valid license assigned but the provisioning workflow never initiated, leaving them without access to their virtual workspace.

My Approach

1. Confirmed the correct Windows 365 Cloud PC license was assigned to the user account
2. User followed up — Cloud PC still not provisioning despite valid license, escalating investigation
3. Located mirrored user objects in Entra ID (Azure AD) and added user to the required MDM device management group — issue persisted
4. Identified in the user properties that this was a Cloud PC provisioning issue, not standard Azure Virtual Desktop
5. Navigated to Intune → Devices → Windows 365 → Provisioning Policies and located the relevant CloudPC provisioning policy
6. Found the policy was scoped only to a specific Windows 365 provisioning group — user was missing from this group
7. Added user to the correct Windows 365 provisioning policy group
8. Provisioning workflow triggered successfully and Cloud PC became available

Root Cause

For a Windows 365 Cloud PC to provision successfully, a user needs both the correct license and membership in the provisioning policy group scoped in Intune. The user had the license but was missing from the provisioning policy group. A license alone is insufficient — Intune's provisioning policy must also target the user for the workflow to initiate.

Outcome

Cloud PC provisioning initiated as expected and the issue was fully resolved. This ticket required understanding the full dependency chain across the Microsoft cloud stack: license assignment in M365 admin, group membership in Entra ID, and provisioning policy scope in Intune — not just surface-level license verification.

Skills Demonstrated

• Windows 365
• Microsoft Intune
• Entra ID / Azure AD
• Provisioning Policy Management
• M365 License Management
• Systematic Troubleshooting

The Challenge

A user was unable to connect to their Windows 365 Cloud PC via the Remote Desktop app (msrdc.exe). The connection failed with an HTTP 400 error during the authentication flow, and Remote Desktop would not complete the login sequence. A 400 (Bad Request) on an RDP auth flow doesn't point to an obvious cause at the surface level — it looked like it could be a network issue, a license issue, or a client version problem before digging into logs.

My Approach

1. Confirmed the user was running msrdc.exe (Win32 Remote Desktop), not the Microsoft Store version — relevant because the Store app has a different reset path, and the Store is blocked in this environment
2. Verified Remote Desktop cache folders — no MS Store package folder present, ruling out a Store app cache issue
3. Navigated to Event Viewer → Applications and Services Logs → Microsoft → Windows → AAD → Operational on the local device
4. Found multiple entries for Event IDs 1097 and 1241 (AADTokenBrokerPlugin), indicating stale or mismatched Azure AD authentication context
5. Logs confirmed TokenBroker was attempting partial resets of its auth state, and that msrdc was querying a Microsoft login endpoint with a stale or invalid resource tenant value — producing the 400
6. Determined that clearing the TokenBroker cache contents (not the folder itself) was safe and aligned with Microsoft support procedures for repairing broken AAD authentication states
7. Cleared all contents inside %localappdata%\Microsoft\TokenBroker\Cache without deleting the folder
8. Initiated reboot so Windows could rebuild a clean authentication state on next login

Root Cause

The user had corrupted or stale TokenBroker cached tokens (.TBRES files) in the local AAD/WAM token metadata cache. When msrdc attempted to authenticate, it used these stale tokens to query a Microsoft login endpoint, which returned HTTP 400 because the resource tenant value was no longer valid. The fix required clearing the cache so Windows could regenerate fresh WAM/AAD tokens on reboot — not a network issue, not a license issue, and not visible without knowing to look in the AAD Operational event log on the local device.

Outcome

After reboot, the user confirmed no issues connecting to their Cloud PC. Windows regenerated fresh WAM/AAD tokens, msrdc successfully requested new access and refresh tokens, and the authentication endpoint resolved correctly with no further 400 errors. Event IDs 1097/1241 stopped appearing in the AAD Operational log.

Skills Demonstrated

• Windows 365
• Entra ID / Azure AD
• Event Viewer (AAD Operational)
• WAM / TokenBroker
• msrdc / Remote Desktop
• AAD Authentication Forensics
• Systematic Troubleshooting

The Challenge

After a coworker departed and their access was revoked, the connection between Apple Business Manager (ABM) and our Addigy MDM platform broke completely. Zero-touch enrollment stopped working for all Apple devices across multiple client organizations. New devices purchased from Apple weren't populating in ABM, and the automated device enrollment (ADE) workflow that clients depended on was completely broken. The departing admin had been the only ABM administrator, creating a single point of failure for a system managing 200+ devices.

My Approach

1. Discovered the issue when checking Addigy and noticing devices weren't appearing as expected
2. Traced the problem to the ABM-Addigy token connection, which had been tied to the departed admin's access
3. Escalated to obtain ABM admin access since the previous admin was the only one with privileges
4. Once granted access, downloaded new MDM public key certificate from Addigy
5. Authenticated to ABM using Managed Apple ID and navigated to MDM server preferences
6. Replaced the expired/broken certificate with the updated public key
7. Downloaded new MDM server token from ABM and uploaded to Addigy to complete the connection
8. Reviewed and reconfigured tenant-specific enrollment profiles that had configuration issues
9. Verified the fix by testing the full ADE workflow with a demo device
10. Created comprehensive Scribe documentation with annotated screenshots for future annual renewals
11. Walked colleagues through the process using test devices to ensure knowledge transfer
12. Ensured multiple admins had ABM access to prevent future single points of failure

Root Cause

The MDM token that connects ABM to Addigy was tied to the departed administrator's access. When their account was revoked, the token became invalid, breaking the entire automated enrollment pipeline. The organization had only one ABM admin, which created the single point of failure that allowed this disruption to occur.

Outcome

Restored zero-touch enrollment for 200+ Apple devices across all client tenants with zero permanent data loss or extended downtime. Devices purchased from Apple now properly populate in ABM and automatically enroll through Addigy when users sign in. The Scribe documentation I created enabled other technicians to perform future annual renewals independently, reducing dependency on any single person. By ensuring multiple admins had ABM access, I eliminated the single point of failure that caused the original incident.

Skills Demonstrated

• Apple Business Manager (ABM)
• Addigy MDM Platform
• Mobile Device Management
• Automated Device Enrollment (ADE)
• Token/Certificate Management
• Incident Recovery
• Process Documentation (Scribe)
• Knowledge Transfer

The Challenge

Deploying network printers to end-user devices across multiple medical office locations was a repetitive, time-consuming process. Each printer addition required opening File Explorer, typing the full network path to the print server, scrolling through the printer list, and adding printers one at a time. With 30-40+ printers spread across 4-5 doctor's office locations, this manual process was eating significant time on routine tickets.

My Approach

1. Identified the repetitive workflow: network path entry, scroll, select, repeat
2. Wrote a PowerShell script that queries available printers and presents a numbered menu
3. Added location-based filtering so technicians see only relevant printers for each site
4. Built in verification step that runs Get-Printer after installation to confirm success
5. Tested across different Windows versions to ensure compatibility

The Script Logic

The script connects to the print server, retrieves the printer list, and displays each printer with a number. The technician types the number (or multiple numbers separated by commas), the script installs each selected printer, then automatically runs Get-Printer to verify the installation succeeded. No more manually navigating network paths or hoping the printer actually added.

Outcome

Reduced per-device printer setup time from 5+ minutes to under 1 minute. What used to be a tedious click-through process became a quick numbered selection. The verification step eliminated the "did it actually add?" uncertainty. Other technicians on the team started using the script, reducing printer-related ticket time across the board.

Skills Demonstrated

• PowerShell Scripting
• Process Automation
• Print Server Management
• User Experience Design
• Tool Development

The Challenge

15-20 remote users suddenly unable to authenticate to VPN, all receiving "invalid credentials" errors despite entering correct passwords. Users were verified active in Active Directory, and local VPN client configurations hadn't changed. The issue appeared to affect all remote users simultaneously, suggesting an infrastructure problem rather than individual account issues.

My Approach

1. Verified affected user accounts were active and not locked in Active Directory
2. Confirmed VPN client configurations were unchanged on multiple affected devices
3. Ruled out local issues since the problem affected all remote users simultaneously
4. Began tracing the authentication flow: VPN client connects, sends credentials, something validates them
5. Examined VPN authentication configuration and noticed it was using LDAP to validate against Active Directory
6. Discovered the environment had multiple domain controllers, and the VPN was configured to authenticate against a specific LDAP server
7. Identified that the targeted DC may have had issues, causing all LDAP auth requests to fail
8. Escalated finding to infrastructure team with specific recommendation to check DC health or retarget LDAP

Root Cause

The VPN's LDAP authentication was hardcoded to a specific domain controller that was experiencing issues. When that DC couldn't process LDAP bind requests properly, every VPN authentication attempt failed with "invalid credentials" even though the credentials were correct. The error message was misleading because the actual problem was the LDAP server, not the credentials themselves.

Outcome

Infrastructure team confirmed the diagnosis and updated the VPN configuration to target a healthy domain controller. VPN authentication was restored same-day rather than waiting for the next maintenance window. The key insight was recognizing that "invalid credentials" doesn't always mean the credentials are wrong; it can mean the authentication backend failed to validate them.

Skills Demonstrated

• VPN Troubleshooting
• LDAP Authentication
• Active Directory
• Root Cause Analysis
• Cross-Team Collaboration
• Infrastructure Debugging

The Challenge

Received a Huntress security alert indicating a potential man-in-the-middle (MITM) attack affecting a client endpoint. The alert showed indicators of a compromised session where an attacker may have been intercepting or manipulating network traffic.

My Approach

1. Reviewed the Huntress alert details to understand the nature and scope of the threat
2. Identified the affected endpoint and user session
3. Assessed the risk of lateral movement if the compromised session remained active
4. Revoked access for the compromised session immediately to prevent further exploitation
5. Documented the incident and response actions taken

Outcome

Successfully mitigated the threat by revoking access before any lateral movement could occur. The quick response prevented the attacker from using the compromised session to access additional systems or data. While the detection came from Huntress, recognizing the severity and responding quickly was critical to containing the incident.

Skills Demonstrated

• Huntress
• Security Monitoring
• Incident Response
• Threat Mitigation
• Access Revocation