Building a Microsoft 365 Identity management lab from scratch

Building a Microsoft 365 Identity management lab from scratch

As part of my transition into IT, I wanted practical, hands-on experience managing users, security controls, and administrative roles in a real cloud environment. Instead of relying solely on theory, I built a live sandbox using a trial of Microsoft 365 Business Standard (with Teams included).

My objective was to simulate real-world help desk and junior administrator responsibilities, including:

• User provisioning
• License assignment
• Password enforcement
• Multi-Factor Authentication (MFA)
• Account blocking and restoration
• Group and team management
• Identity lifecycle simulation

This project allowed me to experience identity administration from an operational and security-focused perspective.

Selecting the plan and creating tenant

Figure 1: Initiating a 30-day trial of Microsoft 365 business standard.

After researching Microsoft’s business offerings, I selected the Business Standard trial to simulate a realistic organizational environment.

During setup;

• Enter billing and business details
• Created a tenant domain
• Created the initial Global Administrator account

Figure 2: Creating tenant domain and initial Global Administrator account

This account became the primary administrative control point for the environment.

Initial User Provisioning

After tenant creation, I accessed the Microsoft 365 admin centre, which serves as the central management interface.

Figure 3: Setup wizard prompting intial user

The platform immediately guides administrators to begin onboarding users; this is to mirror real-world deployment processes.

Creating Users and Enforcing Password Policies

Continuing navigate admin centre, Active Users → Add User

Figure 4: Admin Centre

Figure 4.1: Creating a new user with enforced password change at first sign in.

While provisioning users, I:

• Manually configured secure passwords (8–256 characters, uppercase, lowercase, numbers, symbols)
• Enforced “Require user to change password at first sign-in”
• Assigned Microsoft 365 Business Standard licenses
• Assigned administrative roles to simulate Helpdesk responsibilities

When assigning access, I provided users with a Microsoft 365 Business Standard license. This license grants access to services such as email, collaboration tools, and productivity applications. However, I quickly realized that a license alone does not grant management capabilities within the tenant.

Administrative roles must be assigned separately.

For example, assigning a Helpdesk Administrator role allows a user to reset passwords and manage certain account settings. But it does not automatically grant access to additional Microsoft services. Conversely, assigning a license provides service access but does not grant elevated administrative control.

• Understanding this separation clarified a key identity governance principle:
• Access to services and authority to manage those services are intentionally decoupled.
• This design reduces risk by ensuring that service consumption and administrative privilege are independently controlled.
• Recognizing this architectural separation strengthened my understanding of role-based access control (RBAC) within cloud environments.

Admin Centre Overview & Management

The Microsoft 365 Admin Centre serves as the operational hub for this lab environment. From this interface, I was able to manage identity, access, and service configuration across the tenant.

Through the Admin Centre, I performed tasks including:

• User provisioning and deletion
• Password resets and enforcement policies
• License allocation and removal
• Account blocking and restoration
• Group and team configuration

Figure 5: Microsoft 365 Admin centre dashboard overview

The Admin Centre functions as a centralized control plane, allowing administrators to manage identity lifecycle, enforce policy, and maintain operational continuity within a single interface.

Working within this dashboard helped me understand how cloud-based identity platforms streamline administrative oversight while maintaining structured access control boundaries.

Secure Login Testing & MFA Configuration

To strengthen account security within the tenant, I implemented Multi-Factor Authentication (MFA) for test users.

To safely test user authentication without disrupting my admin session, I used an incognito browser window. This prevented cached credentials and session conflicts.

Upon signing in as the test user, I was prompted to configure additional authentication verification using the Microsoft Authenticator. I completed the registration process, linked the account to the mobile application, and verified successful sign-in using push-based approval.

Figure 6: screenshot of the prompt for activating MFA upon first time sign in

This process demonstrated how MFA introduces a second verification layer beyond passwords. Even if credentials are compromised, access cannot be granted without the additional authentication factor.

After configuring MFA, I tested:

• Successful login with correct credentials and authenticator approval
• Sign-in attempts after password reset
• Account access after temporarily blocking the user

These tests helped me understand how authentication flows change once MFA is enforced and how identity controls interact with user lifecycle actions.

Most importantly, this exercise reinforced that enabling MFA is not merely a checkbox security feature. It requires:

• Clear user communication
• Verified registration of authentication methods
• Recovery planning
• Controlled rollout to avoid accidental lockout

Implementing MFA strengthened my understanding of layered security controls and the balance between user accessibility and risk reduction.

Simulating Account Restrictions

To better understand how identity controls function during security incidents or employee offboarding, I simulated an account restriction scenario.

Using the Admin Centre, I blocked a user’s sign-in access to represent situations such as employment termination, suspicious login activity, or policy violations. Blocking sign-in is a common first response action in security and HR-driven workflows, as it immediately prevents access without permanently deleting the account.

Figure 7: Selecting block sign-in when selecting user from the active user list.

After applying the restriction, I attempted to log in as the affected user in an incognito session. The system returned an “account locked” message, confirming that access controls were enforced at the identity layer.

Figure 8: Shows account locked out.

This test allowed me to observe the restriction from both perspectives:

• The administrator applying the control
• The end user experiencing the access denial

To extend the exercise beyond configuration, I simulated a help desk workflow. I documented the scenario as if it were a support ticket, outlining:

• The reported issue
• The administrative action taken
• The verification steps
• The resolution outcome

This reinforced an important operational insight: identity management does not exist in isolation. Access restrictions, password resets, and MFA enforcement often originate from service desk tickets, HR requests, or security alerts.

Understanding both the technical control and the support workflow surrounding it is essential for effective IT operations. This connected identity management to service desk operations.

User Deletion, Restoration & Lifecycle Management

To better understand user lifecycle management, I simulated a common real-world scenario: an employee leaving an organization and later being reinstated.

First, I deleted a user account from the Microsoft 365 Admin Centre. Then I removed the associated license, where access to services such as email and collaboration tools is revoked once employment ends.

Figure 9: Deleted User

After deletion, I explored the restoration process. Microsoft 365 retains deleted users for a limited period, allowing administrators to recover accounts if needed. I restored the user within this retention window and reassigned the appropriate license to reactivate service access.

Figure 9.1: Restoring user you have the option to autogenerate a password or manually create one.

Because credentials may be considered compromised or outdated during reinstatement, I manually reset the user’s password and enforced a mandatory password change at the next sign-in. This ensured the account was secured before being returned to active use.

This exercise helped me understand that user lifecycle management is more than simply creating and deleting accounts. It requires:

• Coordinated license management
• Attention to security during reinstatement
• Awareness of retention policies
• Structured deprovisioning procedures

Improper offboarding can leave security gaps, while improper restoration can lead to access issues or compliance concerns. Managing the full identity lifecycle is a core administrative responsibility and directly impacts organisations security posture.

Administrative Lockout: A Critical Learning Experience

While testing authentication controls, I unintentionally locked myself out of the administrative environment.

After enabling Multi-Factor Authentication (MFA) across accounts and performing several password resets during testing, I attempted to sign back in as an administrator. I was prompted for verification through the Microsoft Authenticator app — but no approval request appeared. At the same time, I realized I had not properly configured backup authentication methods or fully documented updated credentials.

As a result, I no longer had access to the tenant.

The lockout was caused by a combination of:

• Incomplete registration of recovery authentication methods
• No secondary Global Administrator with validated MFA
• Inconsistent password tracking during repeated test resets

Although this was unintentional, it became the most impactful part of the project.

In real-world environments, administrative lockout can halt operations, delay support, and require escalation to vendor support teams. Experiencing this first hand reinforced a critical principle: security controls must always be implemented alongside recovery planning.

From this incident, I learned the importance of:

• Maintaining at least two properly configured Global Administrator accounts
• Registering multiple MFA methods (Authenticator app, phone, alternate email)
• Verifying recovery options before enforcing security policies
• Testing failover administrative access
• Treating identity configuration changes as high-impact operational actions

This experience shifted my perspective. Identity management is not just about strengthening access controls. Misconfiguration does not only reduce security; it can also reduce productivity.

What is next?

In my next article, I will document:

• The remediation process
• Rebuilding the tenant with improved governance controls
• Implementing recovery-first configuration
• Applying lessons learned from the lockout incident

This project marked a turning point in my understanding of identity management.