Ask questions like "How many Global Administrators do I have?" or "Export all PIM role assignments" and get instant answers. No PowerShell scripting, no Graph API syntax, no context switching.

Why This Matters

The Model Context Protocol lets AI assistants connect to enterprise data sources. Microsoft's MCP server for Microsoft 365 bridges GitHub Copilot to Microsoft Graph API.

Traditional auditing means jumping between Azure Portal, Graph Explorer, PowerShell, and Excel. With MCP, you work entirely in VS Code and ask questions in plain English.

What used to take 30 minutes of scripting now takes 30 seconds.

Get It Running

I created an automated setup script that configures everything in about 10 minutes.

Get it here: github.com/earlbellen/MSEnterpriseMCPServer

Includes setup script, VS Code configs, sample queries, and troubleshooting guide.

What You Can Audit

Users: Password age, account status, licenses, MFA enablement

Groups: Types, memberships, sync status, expiration Roles: Directory assignments, PIM schedules, service principal privileges

Governance: Access reviews, Conditional Access, administrative units

Ask questions, get answers, export to CSV. Done.

Security Risks

Natural language makes auditing easy but also makes reconnaissance easy. If an attacker compromises an admin account, they can map your entire security posture in seconds.

Mitigate with: Dedicated admin workstations only Conditional Access for privileged accounts PIM for just-in-time access Monitor Graph API audit logs Secure cached authentication tokens

This tool is powerful. Use it responsibly.

Use Cases

Incident Response: "Which accounts have Global Admin right now?"

Compliance: "List privileged users and their last sign-in"

Hygiene: "Show service principals with expired credentials"

PIM Tracking: "What percentage of roles are eligible vs permanent?"

Next step: Extend this to Azure RBAC for subscription-level role auditing across your entire Azure estate.

Bottom Line

Auditing Entra ID no longer requires PowerShell expertise or Graph API memorization. MCP and GitHub Copilot make it conversational.

But power requires responsibility. The same queries that help you audit can help attackers reconnaissance. Use proper controls: PAWs, Conditional Access, PIM, and audit monitoring.

Try it: github.com/earlbellen/MSEnterpriseMCPServer

Dave Bellen
Connect: GitHub | LinkedIn

Tech for Good.

Resources

Microsoft Learn: Get started with the MCP server for Microsoft Graph

Microsoft Entra ID Privileged Identity Management

Model Context Protocol

My GitHub Repository

As a capstone activity, I built an AI-powered Slack chatbot that integrates with Google Sheets. The chatbot works as an intelligent assistant, retrieving and referencing records from a spreadsheet while interacting naturally with users inside Slack.

What is n8n?

n8n is an open-source workflow automation platform that allows users to connect applications, APIs, and AI models together with low-code workflows. It can be run in the cloud, on-premises, or locally for full control.

More than a simple connector, n8n enables the creation of AI agents that understand natural language, interact with external data sources, and execute automated tasks. This flexibility makes it suitable for both simple automations and more advanced AI-driven solutions.

Key Learnings from the Course

The course covered a range of concepts and practical applications, including:

• Understanding n8n: How it functions as a workflow automation tool.

• Creating workflows: Designing processes with standard integrations in the low-code interface.

• Building AI-powered agents: Using AI models from major vendors to process natural language inputs.

• Custom MCP servers: Extending automation capabilities through multi-agent tool use and coordination.

These learnings provided me with both the foundation and practical steps needed to design a working AI assistant.

Technologies Used

• n8n – The automation engine for building and running workflows.

• Google Sheets – The structured data source for storing and retrieving records.

• Slack – The communication platform where users interact with the assistant.

• AI Models – For natural language understanding and task execution.

• MCP Server – To enable multi-agent tool use and extend the functionality of the workflow.

The Solution: Slack Chatbot with Google Sheets Integration

The project output is a Slack chatbot that assists team members in accessing spreadsheet records quickly and accurately. The workflow operates as follows:

1. A user sends a query in Slack.

2. The chatbot processes the input with an AI model.

3. n8n connects to Google Sheets to retrieve the requested information.

4. The MCP Server manages communication between tools for enhanced agent capabilities.

5. The chatbot responds in Slack with structured and clear information.

This automation eliminates the manual step of opening and searching spreadsheets. Instead, users can rely on a natural conversation with the Slack bot to get the data they need.

Why This Matters

The project demonstrates how AI, workflow automation, and MCP servers can be combined to solve practical problems. Many organizations use Slack for communication and Google Sheets for data management. By integrating the two with an AI-powered agent, repetitive tasks like lookups and record checks become faster and more efficient.

During this process, I also discovered that n8n has a built-in connector for Microsoft Entra. As someone who works with identity and access management, this excites me because it opens opportunities to create automations that directly integrate with Entra workflows.

Final Thoughts

Completing this course gave me both the confidence and practical skills to start building AI-powered automations with n8n. The Slack chatbot integrated with Google Sheets, enhanced by an MCP server, is just one example of what is possible with this toolset.

This learning journey reinforced the importance of designing workflows that are simple for users while leveraging AI and automation to handle the complexity in the background. With the discovery of Entra integration in n8n, I look forward to pushing these experiments further into the identity and access management space.

Tech for Good.

“You often integrate SSO in Entra ID, right? But do you actually know what happens behind the scenes in SAML or OIDC?”

That question made me pause. I knew how to add the application, configure the IdP, exchange certificates, assign roles, and test the login. But if I’m being honest, I hadn’t really thought deeply about how these protocols actually worked once the user clicked “Sign in.”

So I decided to dig in. And here’s what I learned about SAML and OIDC—two of the most widely used Single Sign-On (SSO) protocols.

Why SSO Matters

SSO exists to make life easier: users log in once, and they gain access to multiple apps without typing their password again and again (Microsoft Learn – SSO basics).

In Entra ID, this looks seamless. But underneath that convenience are protocols handling trust, tokens, and identity exchange.

The two most common protocols? SAML (older, XML-based) and OIDC (newer, JSON-based, built on OAuth 2.0).

The High-Level Flow

No matter which protocol you use, the flow has the same main actors:

• User – the person trying to log in.

• Identity Provider (IdP) – the trusted authority (like Entra ID).

• Service Provider (SP) or Relying Party (RP) – the application the user wants to access.

The flow looks like this:

1. The user requests access to an app.

2. The app redirects them to the IdP.

3. The IdP verifies the user and issues a token or assertion.

4. The app validates it.

5. The user is logged in.

Simple on the surface, but the details differ between SAML and OIDC.

Deep Dive: SAML

SAML (Security Assertion Markup Language) is XML-based and has been around since the early 2000s. It shines in enterprise environments with legacy apps (Microsoft SAML docs).

• The IdP sends an Assertion (in XML) containing who the user is and sometimes their role or group membership.

• The Service Provider validates the Assertion using the configured certificate.

• If it checks out, the user is authenticated.

Think of it as: “Here’s a signed document proving this person is who they say they are.”

Deep Dive: OIDC

OIDC (OpenID Connect) is the modern cousin. Built on top of OAuth 2.0, it uses JSON Web Tokens (JWTs) (Microsoft OIDC docs).

• The IdP issues an ID Token (JWT) after the user signs in.

• The token is compact, base64-encoded, and easier for developers to work with.

• Apps can also request Access Tokens to call APIs.

Think of it as: “Here’s a lightweight badge with your photo and details, easy for apps and APIs to scan.”

Comparing SAML and OIDC

Here’s a quick side-by-side:

A nice overview of how these protocols compare is also available in Auth0’s Identity Protocols Explained.

The Risks of Mishandling

This is where it gets serious. If you misconfigure or mishandle SSO, the impact is huge: one compromise could open doors to multiple apps.

• SAML Risks

  • Assertion replay attacks if assertions aren’t time-bound.

  • Forgetting to validate digital signatures.

  • Poor certificate management.

• OIDC Risks

  • Treating ID Tokens as proof of authorization (they’re not).

  • Not validating signatures, issuers, or expiration times.

  • Storing tokens insecurely (e.g., localStorage → XSS risk).

• Common Risks

  • Weak security at the IdP = compromise everywhere.

  • Insecure redirect URIs → attackers hijack sessions.

  • Over-permissioned apps trusting SSO blindly.

Many of these pitfalls are also highlighted in the OWASP Authentication Cheat Sheet, which is a must-read if you work with identity.

In other words: SSO doesn’t remove risk, it centralizes it.

Closing Thoughts

That question—“Do you actually know what happens behind the scenes?” was a wake-up call.

Integrating SSO in Entra ID is easy. But understanding what’s going on with SAML and OIDC helps me appreciate both the power and the responsibility that comes with it.

These protocols are the silent backbone of modern authentication. And as identity professionals, it’s not enough to just wire them up. We need to know the risks, validate tokens properly, and configure them securely.

Because when SSO breaks, it’s not just one app at risk.

References

• Microsoft Learn – SSO basics

• Microsoft Learn – SAML protocol

• Microsoft Learn – OIDC protocol

• Auth0 – Identity Protocols Explained

• OWASP – Authentication Cheat Sheet