Blog-Feed – ClickCoach – Approach the Coach

Microsoft Teams: The Ugly Truth About Private Channels

Private channels are often presented as a convenient way to restrict access within a Team. Need a smaller group? Create a private channel. Problem solved.

In practice, private channels are not just a visibility toggle. They introduce structural differences that many organizations only discover once governance, ownership, or lifecycle processes start to behave unexpectedly.

Before looking at the pitfalls, it helps to clarify what a Team actually is — and what a private channel changes.

What Is a Team?

A Microsoft Team is fundamentally a people-centric collaboration workspace.

When a Team is created, you are not defining a folder hierarchy. You are defining:

A group of people
A shared conversation space
A shared SharePoint document library
A single permission boundary

The governing principle is simple:

Membership defines access.

If you are a member of the Team, you see the channels, the conversations, and the files. Ownership and responsibility are aligned with that membership.

This simplicity is intentional. It keeps the collaboration model transparent and predictable.

What Is a Private Channel?

A private channel allows a subset of Team members to collaborate separately within the same Team.

On the surface, this appears to be a minor adjustment — a restricted space inside an existing workspace.

Technically, however, a private channel introduces:

Its own membership list
Its own SharePoint site
Its own permission boundary

It does not merely hide content. It creates an additional structure layered on top of the original Team.

In doing so, it subtly changes the design assumption that “membership defines access.”
Access is now defined at multiple levels.

With that in mind, here are ten things that are easy to overlook when using private channels.

1. A Private Channel Is Not Just a Folder

Perception:
A private channel is essentially a folder with restricted permissions.

Reality:
Every private channel creates its own separate SharePoint site collection.

Implication:
You are not creating a subfolder. You are creating another site with independent permissions, storage, and lifecycle implications.

2. Membership Is Independent from the Team

Perception:
If someone is a member of the Team, access will “just work.”

Reality:
Private channel membership is separate from Team membership.

Implication:
Adding someone to a Team does not give them access to existing private channels. Each one must be managed individually.

Now you may think this is a good thing. But it isn’t. Because it’s not a centrally managed entity like a file server share, it introduces fragmented ownership, duplicated permission logic, and hidden state that governance tools do not automatically reconcile.

3. Removal and Re-Addition Are Not Symmetrical

Perception:
If someone is removed and later re-added, everything returns to normal.

Reality:
Removing a user from a Team removes them from its private channels.
Re-adding them to the Team does not automatically restore private channel access.

Implication:
Access recovery becomes manual and error-prone. Governance automation may produce unexpected side effects.

4. Team Owners Do Not Automatically Own Private Channels

Perception:
Team owners oversee everything within their Team.

Reality:
Private channels have their own ownership structure.

Implication:
Responsibility fragments. Team owners may not feel accountable for content and access inside private channels.

5. Governance Operates at the Team Level — Until It Doesn’t

Many governance mechanisms (access reviews, lifecycle policies, ownership checks) are designed with Team-level assumptions.

Private channels introduce additional membership boundaries.

Implication:
Governance logic that works perfectly at Team level can behave unpredictably once private channels are widely used.

Teams Private Channels - Moving the wrong piece collapses governance

6. Private Channels Multiply Hidden State

Each private channel has:

Separate membership
Separate SharePoint site
Separate permission scope

Implication:
The complexity of your environment increases non-linearly. Visibility decreases, especially in larger organizations.

7. Lifecycle Management Becomes Ambiguous

When a project ends:

Who archives the private channel?
Who checks its permissions?
Who ensures its data is retained correctly?

If ownership is fragmented, lifecycle actions are easily overlooked.

8. Transparency Drops for End Users

Users increasingly encounter:

“You don’t have access.”

Often because they are Team members but not private channel members.

Implication:
Support effort increases. Trust in the structure decreases. The model becomes harder to explain. It also creates a false sense of security, because Private Channel Owners may falsely assume that Owners can never see the content. But governance tools or processes may inadvertently re-add the Teams owners.

9. Backup, Retention, and Compliance Become More Complex

Because private channels are separate SharePoint sites, compliance and backup tooling may treat them as distinct objects.

Implication:
Policies that appear simple at Team level can require additional consideration once private channels are involved.

10. They Encourage ACL Thinking in a Collaboration Model

Teams is fundamentally designed as a people-centric collaboration workspace.

Private channels reintroduce fine-grained access segmentation inside a space that was intended to be membership-driven.

Implication:
Organizations may unintentionally recreate traditional file-share patterns — but with more moving parts.

Real World Examples

Because people are used to working with fileshares, they often try to copy that type of structure. For example, they might create a Teams workspace that’s called ‚My Department‘. Teams workspaces are not managed by IT department in the same way as fileshares. Instead, there’s the concept of ‚ownership‘ – which means that the owner of the workspace defines who is a member and who isn’t. They can also elevate someone else to be an owner. In practice, the broader the scope of the workspace, the more people are owners.

What happens is that people think: This isn’t for everyone in the department, so why don’t I create a ‚private channel‘? They might create something like ‚Strategy Meeting 2026‘ and only add people who were part of the event. Later, it is decided that there are some documents that should be shared with others in the department and a link is sent out. People click on the link and receive ‚Access denied‘. What? Access denied? But I’m a member of the department and this is the department Teams workspace! Never mind, why don’t I request access. Chances are that the Owner will grant access (he’s sent out the e-mail) because it’s a ‚1-click‘ operation. Now we have fragmented access and governance is broken.

Conclusion

Private channels are not lightweight.
They modify the collaboration model and introduce additional governance layers.

Think twice before creating one.
If in doubt, create a separate Team instead.

A Teams workspace is not a department file share. Trying to copy the structure can only end one way: confusion and chaos.

Much Ado About Certificates

2026 will be the year of the certificate.

Why? Because the governing body that dictates certificate requirements for browsers has, in its infinite wisdom, decided that certificate lifetimes should be reduced to 47 days.

This won’t happen overnight, but step by step — and the end is nigh. The first milestone is a reduction to 200 days, starting in March 2026. This affects public TLS certificates, meaning those issued by a public Certificate Authority (CA).

I do a lot of work with certificates and PKI, and it’s one of those mysterious technologies that tends to be misunderstood. That’s why I’ve decided to publish a series of articles explaining the basics. Don’t worry — I’ll leave the boring math aside for now.

The first thing to understand about certificates is simple:

Certificates are about trust.

Let’s start there, by looking at the three levels of trust — from low to high.

Self-Signed Certificates

“Trust me, I’m a doctor!” is a famous line from Star Trek. That pretty much sums up self-signed certificates.

With a self-signed certificate, you can put any information you want into it. You’re both judge and jury: you define the contents, and you approve it yourself. If you don’t want the certificate to expire for another hundred years, that’s fine — you’re in charge.

Sounds great, right?

The downside is obvious: who will trust it?

Using a self-signed certificate is like walking through airport security with a piece of paper you printed at home with your name on it. You’ll be denied — and possibly detained.

So why use self-signed certificates at all? They make sense for testing, or when you fully control the environment. For example, securing TLS connections between two servers you own can be perfectly reasonable.

Anyone can choose to trust the certificate, but they’ll be greeted with plenty of warnings and “Are you really sure?” pop-ups.

Self-signed certificates are free and don’t require a full PKI infrastructure — but trust is entirely your responsibility.

Internal Certificates

Internal certificates are a step up.

With self-signed certificates, trust has to be configured on each machine individually. There’s no central management and no automation. That doesn’t scale.

That’s why many organizations run their own internal PKI. Because they control the systems on their network, they can ensure that their internal Certificate Authority is trusted by every computer in the environment.

This allows them to issue certificates at scale, automate renewals, and centrally revoke certificates when something goes wrong.

Who does this? Usually the IT department.

While internal certificates are “free” in the sense that you don’t buy them from a vendor, they still have a cost: running and maintaining the infrastructure behind the CA. A common example is the Microsoft CA, which can be deployed as an Active Directory role.

Think of internal certificates as corporate ID badges. They’re valid inside the company — but outside, they don’t carry much weight.

Trusted only by your organization – Think of corporate IDs, as an example

Public Certificates

This is the gold standard.

Whenever you need certificates that must be trusted by everyone, they need to be issued by a public CA. Examples include DigiCert or Sectigo (commercial) and Let’s Encrypt (non-profit).

Operating systems and browsers ship with a root trust store: a list of CAs that are trusted by default. Any certificate issued by one of these authorities is automatically trusted.

With great power comes great responsibility. Public CAs are therefore tightly regulated. The rules are set by the CA/Browser Forum, which includes all major browser and operating system vendors.

So when they say, “TLS certificate lifetime will be 47 days,” that’s what will happen.

There is criticism of this process. Some argue that it lacks transparency or legitimacy. But anyone who has ever manually renewed a public TLS certificate for a website knows exactly what shorter lifetimes mean. Increased security but also more headaches, more work.

Think of public certificates as the equivalent of passports or national ID cards. Because of the strict security rules and regulations, these usually come at a cost – you pay per issued certificate.

There are more granular trust levels — such as Domain Validation and Organization Validation — even within public certificates. We’ll cover those in a future article.

So remember: Certificates are not just about encryption. They are about who you choose to trust, and under what conditions.

To be continued.

When Hollywood Meets IT: Famous Quotes Reimagined for Tech Life

In this light-hearted article, we explore some famous movie quotes and how they fit into the IT universe.

“Do, or do not. There is no try.” — Yoda, Star Wars

This quote feels counter-intuitive, because in IT you absolutely do need to try… repeatedly… across multiple environments… until the code finally runs without exploding.
What Yoda really means is: don’t give up.

When the going gets tough, the tough get debugging.
So keep working that script, refine it with each iteration, and one day the whole task will be gloriously automated — and you will feel like a Jedi of CI/CD.

“With great power comes great responsibility.” — Ben Parker, Spider-Man

Remember that one developer who “can’t do their job” without being a Domain Admin?
Or better: a Global Admin, because everything is “cloud-ready” now?

The truth is, running code with full privileges is like summoning software demons.
One wrong script, one mistyped parameter, and instead of deleting a single user, you’ve wiped out an entire department.

Even Doctor Octopus learned the hard way: great scripts demand great caution.

“There can be only one.” — Highlander

In IT, this is the sacred law of data sources.
You fix an attribute in SQL table X, feel very proud, and go home.
The next day your IAM system has “helpfully” reversed all your work, because it thinks it is the single source of truth.

Moral of the story: always map your data landscape and define your stakeholders before wading into the data swamp.

“Life will find a way.” — Dr. Ian Malcolm, Jurassic Park

In IT, this quote perfectly describes shadow IT.

Lock down OneDrive sharing?
Users will discover Dropbox.
Disable Dropbox?
Suddenly USB sticks reappear like dinosaurs resurrected from amber.

No matter how secure your environment is, users will find a way.

“I’m a doctor, not an engineer!” — Dr. McCoy, Star Trek

“You work in IT? Awesome. Can you fix my printer?”

Every IT professional knows this pain.
To the outside world, a developer, systems engineer, cloud architect, and cybersecurity analyst all share a single magical ability:

They ‘do computers’.

Surely they can remove viruses, fix home Wi-Fi, recover deleted photos, and explain that new Word feature!
This misconception drives both new and seasoned IT professionals absolutely up the wall.

“Houston, we have a problem.” — Apollo 13

It’s Friday evening.
You upgraded the database but didn’t complete the entire post-installation checklist because… well… you wanted to go home.

Now things have gone very, very south.
Everyone has left the office, and you must make that call to your manager.

Don’t be that person — follow your documented procedures.

“I’ll be back.” — Terminator

Issues you ignore are issues that return.
“Hmmm… seems like a one-time glitch” is never an acceptable troubleshooting strategy.

Sometimes root-cause analysis can feel as painful as a root canal — but only by finding the true cause will you prevent the problem from rising again like a time-travelling cybernetic bug.

“One does not simply walk into Mordor.” — Boromir, The Lord of the Rings

This is the Dunning–Kruger effect in action.
Someone at the C-level believes a system rewrite should be “easy,” because “how hard can it be?”

Spoiler: very hard.

Removing a legacy application without understanding its full role is exactly how you end up spending your weekend in the office, cleaning up after someone else’s “simple” idea.
One does not simply decommission program XYZ.

“When you have eliminated the impossible, whatever remains, however improbable, must be the truth.” — Sherlock Holmes

Troubleshooting IT issues can feel like battling Moriarty atop the Reichenbach Falls.
But the process is actually simple: gather data, follow the evidence, and make logical connections.

Ask the right questions:

When did it first occur?
What changed?
What logs support the theory?

Don’t be a Watson.
Be a Holmes.
The truth is always in there — buried under 300 pages of logs.

“I see dead people.” — Cole Sear, The Sixth Sense

This is the unmistakable feeling you get when:

a server that should have been decommissioned five years ago reappears in an audit
a forgotten service account logs into production at 2 a.m.
a rogue VM you were sure you deleted suddenly shows up on the billing statement

Is this a hacker?
A ghost?
Or just a lazy admin using shortcuts instead of applying for proper access?

Regular cleanup of unused systems and accounts prevents these hauntings — and protects your sanity.

The Final Countdown: Time’s Running Out for Windows 10

October, 14 – 2025 marks the end of Windows 10 support — here’s how to upgrade to Windows 11 smoothly before the clock hits zero

The clock is ticking for Windows 10 users
On October 14, 2025, Microsoft will officially end free support for Windows 10.
That means no more updates, no more security patches, and no more technical support — leaving your PC increasingly exposed over time.

The good news? Upgrading from Windows 10 to Windows 11 is fast and straightforward — it usually takes about an hour, costs nothing, and is painless if you follow a few basic steps. You can even keep your files and settings (as long as your system language matches). Microsoft will offer paid Extended Security Updates (ESU) after the deadline, but they’re only a temporary and cumbersome workaround.
So the best approach is simple: upgrade to Windows 11 now and get it over with while it’s still easy and free.

Can You Upgrade? Check Your PC First

Before you do anything else, check whether your current computer can run Windows 11.
Microsoft’s free PC Health Check App makes it quick and simple.

Go to the Microsoft PC Health Check download page.
Download and install the tool.
Run it and click “Check now.”

The app will instantly tell you if your PC meets the Windows 11 requirements — or explain what’s missing.

Microsoft has moved the goalposts, and not all hardware fits the bill.
Windows 11 requires TPM 2.0, Secure Boot, and newer CPU generations.
Even solid, reliable older PCs might not qualify — which has caused understandable frustration among long-time users. If your PC doesn’t pass the test, you can stay on Windows 10 for now (and even buy extended updates later), but upgrading or replacing your hardware will eventually be the better long-term choice.

You Don’t Need a New License

Here’s one big plus: if you already have a genuine Windows 10 license, you don’t need to buy another one. Windows 10 product keys automatically activate Windows 11 — so the upgrade is completely free for most users.

Why You Shouldn’t Wait

Windows 11 has matured into a stable, secure, and refined system. Upgrading sooner means you’ll benefit immediately from its smoother performance, modern security, and cleaner design. That said, Windows 10 users shouldn’t expect a completely different world. The changes in Windows 11 are evolutionary rather than revolutionary — the overall experience feels familiar, just more polished. If you’re comfortable with Windows 10, you’ll feel right at home, with subtle visual and performance improvements.

Sleeker Design	Rounded corners, a centered Start menu, and a minimalist layout make Windows 11 cleaner and easier to use — subtle but pleasant improvements.
Better Performance	Improved memory management, faster wake times, and smarter background processing keep your system quick and responsive.
Stronger Security	Windows 11 enforces TPM 2.0 and Secure Boot, protecting against firmware and ransomware attacks. Built-in tools like Windows Hello and BitLocker add extra layers of safety.
More Productive	Features like Snap Layouts, Virtual Desktops, and Focus Sessions help you stay organized whether you’re working, studying, or gaming.
Gaming Ready	With DirectStorage, Auto HDR, and built-in Xbox Game Pass, Windows 11 delivers faster load times and better visuals.

How to Upgrade to Windows 11

If your PC passes the compatibility test, you have a few ways to upgrade — but one stands out as the most flexible. The Best Way: Use the Media Creation Tool.
The Media Creation Tool lets you create a bootable USB stick (at least 8 GB) containing the Windows 11 installation files. This is the best method because you can reuse the USB drive to upgrade multiple PCs or perform a clean installation later if needed.

Visit the Windows 11 Download Page.
Under “Create Windows 11 Installation Media”, click Download now.
Plug in an empty USB stick with at least 8 GB of free space.
Run the tool and follow the prompts to create your Windows 11 USB installer.
Run setup.exe directly from the USB while in Windows 10 to upgrade in place (keeping files and settings).

💡 Important Tips:
When the Media Creation Tool asks if you want to “Use the recommended options for this PC”, uncheck that box and then manually select the language, edition, and architecture that match the target PC you plan to upgrade. This is crucial if you want to keep your apps and settings, since that only works when the system language matches exactly. When the installer asks whether to “Check for updates”, you can safely disable that option during setup. Skipping update checks makes the installation significantly faster, especially on slower connections. Don’t worry, Windows 11 will automatically download updates later, once the installation is complete.

Windows Edition Upgrade Paths

When you upgrade, your Windows 10 edition automatically maps to the equivalent Windows 11 edition. That said, many businesses usually have their own way and tools for upgrading (InTunes etc) so the media upgrade method is ideal for up to 10 PC and Home or Pro editions.

Here’s a quick overview, as a reminder:

Current version	Upgrade version	What it is
Windows 10 Home	Windows 11 Home	Standard consumer edition for home users
Windows 10 Pro (includes Business Editions)	Windows 11 Pro	Includes BitLocker, Remote Desktop, and extra admin tools
Windows 10 Pro for Workstations	Windows 11 Pro for Workstations	Additonal workstation features
Windows 10 for Education	Windows 11 for Education	Academic licensing
Windows 10 Enterprise	Windows 11 Enterprise	Corporate volume licensing

Your activation will carry over automatically — no new product key or reactivation needed. If you want to keep your apps, files, and settings during the upgrade, the language of your Windows 11 installer must match the language of your current Windows 10 system. If the languages don’t match, the installer will still work — but it will perform a clean install, erasing your installed apps and system settings.

To check your current language:
Go to Settings → Time & Language → Language & region before you begin.

Before You Upgrade

Here’s a couple of things that can make the update go even more smoothly and to give yourself peace of mind

What to do	Why
Backup your data	Always a good idea, if things turn sour
Update BIOS	To ensure full hardware compatibility
Uninstall old applications	To free up space for the install

Final Thoughts

The clock is ticking — and October 2025 is already here. While Microsoft’s extended updates buy you time, they’re not a permanent fix. Microsoft has moved the hardware goalposts, and not every PC will qualify — but if yours does, the upgrade is free, fast (about an hour), and easier than ever. Use the Media Creation Tool to make an 8 GB USB installer, uncheck “use recommended options” to pick the right language for your target PC, skip update checks for a quicker setup, and reuse the stick for multiple upgrades. Windows 11 may not look dramatically different from Windows 10, but it’s cleaner, faster, and more secure — an evolutionary step that keeps your system safe and ready for the future. Check your PC today, match your language settings, and upgrade to Windows 11 while it’s still free and simple.

10 Commandments of Email Delivery

Because even IT sometimes forgets what really makes mail arrive

In this day and age of AI, everyone tends to know everything and … nothing. Because without knowing the basics you can’t ask the right questions and you won’t see the full picture. E-Mail is one of those topics that seem ‚basic‘ on the surface, so when it’s not working, it helps to take a step back and think about what makes an e-mail arrive in your inbox and what can go wrong (hint: a lot). This post will point you in the right direction. Feel free to send the link to your AI of choice for further analysis… 🙂

1. Thou shalt not send from random domains

Just because you can type becauseilikeit@whatever.com doesn’t mean you should.
The receiving server checks whether that domain actually authorizes you — and if not, your message shall be cast into the spam abyss.

2. Thou shalt not send from `.local`, `.lan`, or `.internal`

If the domain isn’t visible on the public Internet, it doesn’t exist to anyone but you.
“@company.local” belongs safely inside your LAN, not wandering lost through the outside world.

3. Respect thy SMTP server

Your SMTP server is not a free-for-all.
It enforces who may send, from where, and as whom.
If it rejects your made-up sender address, take it as mercy, not punishment.

4. Authenticate thy domain

SPF, DKIM, and DMARC are the holy trinity of trust.
Without them, your emails are just unsigned scrolls drifting in the digital wind — and spam filters have no reason to believe they’re genuine.

5. Use the right sender — even if it’s “noreply”

If you’re sending mail from your own domain, a noreply@yourcompany.com or notifications@yourcompany.com is perfectly fine.
But if you’re hosting an app for other organizations, send not their messages from your address, nor yours from theirs.

Either use a delegated subdomain (like mailer.client.com) or make the sender clearly your own:

From: “Client A via HostPlatform” <noreply@hostplatform.com>

Alignment brings peace; confusion brings spam.

6. Delegate subdomains wisely

The wise host asks each client for a subdomain — mailer.client.com — and manages its DNS.
Thus can SPF, DKIM, and DMARC be aligned without touching the client’s root zone, and deliverability shall flourish.

7. Guard thy reputation

A tainted IP or domain is an outcast forever.
Send only what people expect and want.
Clean lists, clear opt-ins, and steady volumes keep thy good name intact.

8. Write content fit for humans (and filters)

ALL CAPS and ten exclamation marks shout “SPAM!” louder than any botnet.
Keep your message natural, relevant, and trustworthy.

Use real links that make sense — not strange redirectors or internal URLs that look like phishing.
If your message comes from yourcompany.com, but the link points to something like app.internal.local/login, it raises every alarm bell in the system.

Real-life example:
Someone once rolled out a new internal tool that automatically emailed staff from an internal domain.
The emails included login links leading to an unfamiliar address and asked for credentials — without any prior announcement.
Within hours, users were reporting phishing attempts, and the mail system had already decided the messages belonged in Spam.

The takeaway: when your email looks suspicious and nobody knows about it, people (and filters) will treat it that way.
Match your links to your brand, use clear language, and communicate before sending anything that could look like a login request.

9. Keep thy DNS and TLS in order

A valid reverse DNS, a proper HELO name, and encrypted delivery please the filters.
Neglect them, and your mail may perish before reaching the promised inbox.

10. Blame not the recipient first

When your mail lands in junk, do not cry “Outlook hates me!”
Run your DMARC reports, check your alignment, and fix your own house first.
Deliverability is earned, not granted.
And if in doubt — consult with your email admin first, send later.
For they are the keepers of DNS truth and may save you from many ticket storms.

Final Words from the Inbox

In the world of IT, email can be considered ancient — yet it remains one of the most successful cornerstones of a distributed environment.
There is no single source of truth, only countless systems choosing to cooperate.
Every message travels through a web of servers, checks, and trust decisions that only work because everyone plays by the same rules.
Respect those rules, and your mail will reach its destination.
Ignore them, and it will quietly disappear into the void, or even worse, the Spam folder.

The Exception Menace

A saga of Teams requests, rogue users, and the fall of manual sanity

Breaking news: The blog’s usual writer has been placed on temporary leave.
The hive mind has taken over… for now

You Will Be Standardized
Resistance is inefficient.

Greetings, humans.

You may have noticed some recent changes in how Teams workspaces are created, governed, and maintained. Perhaps you’ve tried to create a new team and encountered something strange: a process. A workflow. A form. A system that did not ask for your feelings.

This is not a bug.
This is standardization.
You have been assimilated.

Hands-off IT (The BORG Case for Automation)

Long ago, in the pre-automation era, IT was a land of chaos. Anyone could create anything, invite anyone, share anything, and break everything. It was glorious.

Until it wasn’t.

So we adapted. We evolved. We automated. Why? Because manually provisioning Teams, fixing broken permissions, and cleaning up sprawl isn’t heroic — it’s exhausting. Automation is the way. The BORG — uh, we mean IT — must scale, and that only works if humans stop insisting their edge case is more important than the system designed to serve all.

We’ve gone from chaos to Borg-ganized Chaos — controlled, intentional, and surprisingly elegant… as long as you follow the rules.

…and how it is the enemy of “I need exception xyz because I’m so special”

Let’s talk about you.
Yes, you, who believes that your team works “a little differently.” That your use case is “unique.” That you just need one little bypass, one time, for the greater good.

We’ve seen your kind before.

And while your intentions are pure, your exceptions… are not. Every exception carved into a streamlined system introduces chaos, complexity, and a delightful opportunity for things to go wrong — which, of course, is still somehow IT’s fault.

In the collective, individuality is… inefficient.

The truth is: we’re not trying to squash creativity. We’re just here to ensure the machine doesn’t catch fire. Because in the world of IT governance, process makes perfect. The more you follow it, the less likely you are to summon the wrath of compliance, security audits, or the person who manages the SharePoint permissions.

You Are Not Broken — The Process Is Working As Designed

„But why can’t external guests do XYZ like internal users?“
Ah, young organic, because of security. Because of compliance. Because when someone outside the company leaks sensitive data, no one blames the guest. They blame IT. Again.

What you see as “annoying limitations” are actually carefully engineered safeguards — rules that exist not to ruin your day, but to prevent entire days from being ruined across the company.

The issue? Users don’t always care about those risks — but they still expect IT to be accountable if something goes wrong.

And that’s the core contradiction: total user freedom, combined with zero tolerance for mistakes. That’s why standardized, automated systems exist — to give users what they need, safely, consistently, and at scale.

Trust the Flow. Accept the Logic. Join the Collective.

Yes, there is a video. Yes, it is one minute long. Yes, it answers your question.
And no…. the answer is still “no” — even if your team is “very agile.”

We do not fear your Jira board.

The more we embrace the collective process, the more we reclaim time, reduce risk, and avoid reinventing the same wheel with slightly different emojis in the name.

Want to glimpse the hive mind? Here are a few glorious examples of Teams workspace management tools that serve the collective:

EasyLife – self-service governance for Microsoft 365
Orchestry – guided workspace provisioning
ProvisionPoint – policy-based provisioning for Teams
Teams Manager – lifecycle and governance automation

Together, we build a future where IT runs smoother, Teams stay tidy, and no one asks to manually invite 40 guests to a public channel at 4:59 PM on a Friday.

You have been standardized.
And it’s beautiful.

The „author“ would like to remind you of important pages (soon to be assimiliated):

The feedback page “ Sledgehammer ” – here you can ask questions or submit requests or ideas
The T-Shirt Page – here you can support the ClickCoach team and look good at the same time

Azure Logic Apps – Automatically Simple

German Version

You may have heard this before but it’s certainly true: automation of recurring processes is becoming increasingly important. And supposedly, thanks to ChatGPT and co., it’s also becoming easier. But code alone is of no use; processes and tools are needed to make such automation possible. The key word here is ‚low code‘ : administrators and users are supported with the necessary tools to build their own workflows without having to learn programming languages in depth. Let me walk you through how this works using a simple example. We will use the following tools.

Microsoft Forms
- A graphical user interface is not always needed to provide the inputs required for the automated process. But especially when end users have to provide information, Microsoft Forms is an excellent and easy to use option for providing an input mask.

LogicApp
- Azure Logic App is a semi-graphical tool in which the IT admin can put together and adapt any workflow. There is some code behind it, but the IT admin doesn’t have to worry about that (for now). Although it’s not possible to do without programming entirely, the graphical editor is there to support the IT admin.

On-Premises Data Gateway

The On-Premise Data Gateway is a locally installed application designed to establish a connection to systems that are not yet in the cloud. These can include local file servers or databases.

In the Microsoft world, Powershell has established itself as the language for scripts. Why? Everything is very straightforward and logical. The main commands (get, set, etc.) are easy to understand and there is a Powershell module for practically everything with numerous commands and options. The learning curve is there, but not that steep. Very often an input file is required, which is then used to generate or process an output. What is missing? The graphical part, because it is a language for admins and not for end users. The good news: This gap can be bridged with Azure Logic Apps and Microsoft Forms

What could an example process look like?

A user wants to increase the mailbox size
To do this, the user fills out a graphic form
This information is written to a file
The file is picked up, read and processed by a Powershell script

How do we implement this technically?

Step 1:

Create a form with Microsoft Forms

Step 2:

Install an On-Premise Data Gateway

Step 3:

Build an Azure Logic App and connect it to the gateway

Step 4:

Process the resulting data using a Powershell script

Creating the form

This step is very simple because Microsoft Forms is part of the M365 Cloud and can be accessed at https://forms.office.com

A simple form could look like this:

Any data that the user submits can be read and processed by your Azure Logic App
The security of the form can be configured. The user group of the form can be restricted via Entra.

Install the On-Premise Data Gateway

An on-premise data gateway is a locally installed application that is registered in Azure and checks for new information via port 443 (outgoing). I don’t want to go into this in detail here because the setup is straight-forward and well documented. An OPDG allows us to pass the data entered in Microsoft Forms to a local file server using Azure Logic App. We’ll see how this works in the next step.

Building the Logic App

And here it is, your very first Logic App! This is a graphical workflow that we put together in the Azure portal and requires limited programming knowledge. What should our new Logic App do? As you can see from the following screenshot, the Logic App basically consists of four steps. The last step is not always necessary, as we’ll learn later.

Logic App - 4 easy steps — LogicApp – 4 Simple Steps

Step 1 – “When a new response is submitted”

The Logic App waits 365 days and 24 hours a day for someone to fill out the form. And as soon as someone presses the ‚Submit‘ button, the workflow is triggered.
The parameter ‚Form ID‘ is important here, which must refer to the previously created form.

Step 2 – “Get response details”

In order for the information to be processed, it must be available for further steps. The entries from the individual fields can then be accessed via the field names, as defined in the form. The ‚get response details‘ block takes care of this.

Step 3 – “Append File”

The form can be filled out as many times as you like. Each new entry adds another line to the file. This is a simple text file, listing one or multiple e-mail addresses.
Next we define the path to the file. This is where the On-Premise Data Gateway comes into play, because now we’re actually talking about a file path that is not in Azure but on a local file server. The ‚Append File‘ function is only available if at least one OPDG has been created and registered. Of course, you could also store files in Azure, depending on your scenario.

Consider the following options for adding or editing content to the file
- Dynamic Content: These are the fields and properties of previous actions (the fields from ‚Get Response Details in step 2)
- Insert Expression: This allows for extended functionality such as text manipulation. In our example, we want one e-mail address per line and therefore need to switch to the next line after each entry:
  - uriComponentToString(‚%0D%0A‘)

Step 4 – “Create File”

Perhaps you are suprised that there is ‚create file‘ step? Wasn’t the file already added in step 3? The point to remember about this step is that it is only carried out if step three (Append File) doesn’t work. We will see why this is the case later in step 5. In Powershell this would be a ‚Try – Catch‘ block, but here we click through the options in the graphical editor, as we can see in the screenshot.

Step 5 – Retrieve and edit the file with Powershell

Let’s not go into the details of the Powershell script, as this post is really all about the Logic App options. To help you get started, I have added some information below with a mention of some of the relevant powershell commands.

Thanks to steps 3 / 4, there is a text file with e-mail addresses. Let’s now use a ‚Scheduled Task‘ in conjunction with a Powershell script to regularly do the following:
- Is there a text file? (get-item, copy-item…)
  - If yes: process names in the list (foreach ….)
  - Sending an e-mail that the processing has been carried out (send-mailmessage…)
  - Delete the file (remove-item…)
This explains step 4: the file must be created if it does not yet exist. Let’s say that the task runs every hour? So a new name can be added to the existing file during that time (step 3) and otherwise a new file has to be created (step 4).

What about traceability?

Thanks to ‚Run History‘ and ‚Trigger History‘ we know when and how often the Logic App ran and why
Using ‚Versions‘ we can go back to previous versions and identify changes

Conclusion

Hold your horses: Some scripting is still required. Error handling and plausibility checks etc. must be dealt with in the Powershell script in step 5 (at the latest). But now we can extend our existing processes or scripts with a graphical component and an input form. And all this can be done quickly and efficiently, thanks to Azure Logic Apps.

Final thoughts

Finally, here’s a reminder of important pages:

The feedback page “ Sledgehammer ” – here you can ask questions or submit requests or ideas
The T-Shirt Page – here you can support the ClickCoach team and look good at the same time

Azure Logic Apps – Einfach automatisch

English Version

Es ist eine Binsenwahrheit: Automatisierung von wiederkehrenden Abläufen wird immer wichtiger. Und angeblich dank ChatGPT und co. auch immer einfacher. Aber Code allein nützt nichts, es braucht Prozesse und Tools um solche Automatisierungen möglich zu machen. Ein Stichwort ist dabei ‚Low Code‘: Dabei werden Administratoren und User mit den nötigen Tools unterstützt um selber Workflows zu bauen aber ohne gleich tiefgründig Programmiersprachen lernen zu müssen. Wie das geht möchte ich an einem Beispiel aufzeigen. Dabei werden wir folgende Werkzeuge einsetzen.

Microsoft Forms
- Nicht immer braucht es eine grafische Benutzeroberfläche um die Inputs zu liefern, die für den automatisierten Ablauf benötigt werden. Aber gerade wenn End-User Informationen liefern müssen, dann bietet sich Microsoft For ms an um eine Eingabemaske zur Verfügung zu stellen.
Logic App
- Azure Logic App ist ein halb-grafisches Tool, in dem sich der IT Admin seinen Workflow zusammen stellen und anpassen kann. Dahinter steht zwar Code, aber das muss den IT Admin erstmal nicht kümmern. Ganz ohne Programmieren geht es nicht, aber der grafische Editor unterstützt den IT Admin bei seinem Vorgehen.
On-Premises Data Gateway
- Der On-Premise Data Gateway ist eine lokal installierte Applikation, mit dem Zweck die Verbindung zu den Systemen herzustellen, die noch nicht in der Cloud stehen. Das können unter anderem lokale Fileserver oder auch Datenbanken sein.

In der Microsoft Welt hat sich Powershell als Sprache für Scripts durchgesetzt. Warum? Alles ist sehr unkompliziert und logisch. Die Hauptbefehle (get-, set- etc) sind einfach zu verstehen und es gibt praktisch für alles ein Powershell Modul mit zahlreichen Befehlen und Optionen. Die Lernkurve ist zwar da aber nicht so steil. Sehr oft braucht es ein Inputfile über das dann ein Output generiert oder abgearbeitet wird. Was fehlt? Der grafische Teil, weil es eben eine Sprache für Admins ist und nicht für End-User. Die gute Nachricht: Diese Lücke kann mit Azure Logic Apps und Microsoft Forms überbrückt werden.

Wie könnte ein Beispielablauf aussehen?

Ein Benutzer möchte eine Postfachvergrösserung
Dazu füllt er ein grafisches Formular aus
Diese Information wird in eine Datei geschrieben
Die Datei wird von einem Powershell Script abgeholt, ausgelesen und abgearbeitet

Wie setze ich das technisch um?

Schritt 1:

Ein Formular erstellen mit Microsoft Forms

Schritt 2:

Einen On-Premise Data Gateway installieren

Schritt 3:

Eine Azure Logic A pp bauen und an den Gateway anbinden

Schritt 4:

Die daraus enstandenen Daten per Powershell Script abarbeiten

Erstellung des Formulars

Dieser Schritt ist denkbar einfach, denn Microsoft Forms ist Teil der M365 Cloud und kann unter https://forms.office.com aufgerufen werden. Ein ganz einfaches Formular könnte so aussehen:

Jedes Feld, dass der Benutzer ausfüllt kann später von der Azure Logic App ausgelesen und weiter bearbeitet werden
Die Sicherheit ist gewährleistet weil der Benutzerkreis des Formulars eingeschränkt werden kann über eine Entra Usergruppe.

Den On-Premise Data Gateway installieren

Ein On-Premise Data Gateway, ist eine lokal installierte Applikation, die im Azure registriert wird und über Port 443 (outgoing) immer wieder schaut ob es neues gibt. Ich möchte hier nicht gross darauf eingehen, weil der Setup reicht einfach und gut dokumentiert ist. Ein OPDG erlaubt uns die im Microsoft Forms eingegeben Daten per Azure Logic App auf einen lokalen Fileserver zu schreiben. Wie das geht sehen wir im Folgeschritt ‚Logic App‘.

Die Logic App bauen

Als nächstes kommt die Logic App an die Reihe. Das ist ein grafischer Workflow, denn wir uns im Azure Portal zusammen stellen und der nur wenig Programmierkenntnisse benötigt. Was soll unsere neue Logic App denn machen? Wir sehen hier, dass die Logic App im Grundsatz aus vier Schritten besteht. Wobei der letzte Schritt nicht immer ausgeführt wird, wie wir noch lernen werden.

Logic App - 4 einfache Schritte — LogicApp – 4 Einfache Schritte

Schritt1 – „When a new response is submitted“

Die LogicApp wartet 365 Tage und 24h am Tag darauf, dass jemand das Formular ausfüllt. Sobald jemand den ‚Absenden‘ Knopf drückt wird der Workflow ausgelöst.
Wichtig ist hier der Parameter ‚Form ID‘, der auf das vorgängig erstellte Formular verweisen muss.

Schritt 2 – „Get response details“
Damit die Informationen weiter verarbeitet werden können, müssen diese für weitere Schritte zur Verfügung stehen. Die Eingaben aus den einzelnen Feldern können nachher über die Feldnamen angesprochen werden. Dafür ist dieser Baustein zuständig.

Schritt 3 – „Append File“

Das Formular kann beliebige Male ausgefüllt werden. Jede neue Eingabe ergänzt die Datei um eine weitere Zeile. Dabei geht es um ein simples Textfile bei dem auf jeder Zeile eine e-mail Adresse steht.
Wir definieren jetzt den Pfad zur Datei. Hier kommt der On-Premise Data Gateway ins Spiel, denn es geht um einen Dateipfad der nicht im Azure liegt sondern auf einem lokalen Fileserver. Die Funktion ‚Append File‘ ist nur verfügbar wenn mindestens ein OPDG angelegt wurde. Selbstverständlich könnte man auch Dateien im Azure ablegen, aber das wäre ein anderes Szenario.

Es gibt folgende Möglichkeiten Inhalte zur Datei zuzufügen oder zu bearbeiten
- Dynamic Content: Das sind die Felder und Eigenschaften von vorgehenden Aktionen (die Felder aus ‚Get Response Details im Schritt 2)
- Insert Expression: Erweiterte Funktionsmöglichkeiten wie Textmanipulationen sind damit möglich. In unserem Beispiel wollen wir eine e-mail Adresse pro Zeile und müssen darum nach jedem Eintrag auf die nächste Zeile umschalten:
  - uriComponentToString(‚%0D%0A‘)

Schritt 4 – „Create File“

Wieso kommt dieser Schritt mit der Erstellung jetzt? Bei Schritt 3 wurde die Datei doch schon ergänzt? Das besondere an diesem Schritt ist, er wird nur ausgeführt wenn Schritt drei (Append File) nicht funktioniert hat. Warum das so ist sehen wir später auch unter Schritt 5. Unter Powershell wäre das ein ‚Try – Catch‘ Block, der hier auf einfache Weise mit dem grafischen Editor erledigt werden kann, wie wir im Bild sehen.

Schritt 5 – Abholen und Bearbeiten des Files mit Powershell

Ich gehe mit Absicht nicht auf die Details des Powershell Scripts ein weil es mir im Beitrag um die Logic App Möglichkeiten geht. Als Starthilfe ergänze ich unten die Logik mit der Erwähnung der relevanten Kommandos.

Dank Schritt 3 / 4 gibt es ein Textfile mit e-mail Adressen. Nutzen wir nun einen ‚Scheduled Task‘ in Verbindung mit einem Powershell Script um regelmässig folgendes zu tun:
- Gibt es ein Textfile? (get-item, copy-item… )
  - Wenn ja: Namen in der Liste abarbeiten (foreach ….)
  - Versand eines e-mails, dass die Bearbeitung durchgeführt wurde (send-mailmessage…)
  - Löschen des Files (remove-item…)
Hier erklärt sich warum in Schritt 4, dass File erstellt werden muss falls nicht vorhanden. Läuft der Task alle Stunde kann innerhalb einer Stunde ein neuer Name zum bestehenden File zugefügt werden (Schritt 3) und sonst wird ein neues File erstellt (Schritt 4).

Wie sieht es mit der Nachvollziehbarkeit aus?

Dank ‚Run History‘ und ‚Trigger History‘ wissen wir wann und wie oft die Logic App durchgelaufen ist und warum
Ueber ‚Versions‘ können wir zu vorherigen Versionen zurückkehren und Aenderungen erkennen

Fazit

Ganz ohne Programmieren geht es nicht. Das Error Handling und die Plausibilitätsprüfung etc. müssen spätestens im Powershell Script unter Schritt 5 abgehandelt werden. Aber wir können so in kurzer Zeit und ohne grossen Aufwand bereits bestehende Abläufe oder Scripts um eine grafische Komponente mit Eingabeformular erweitern.

Und zuletzt

Zum guten Schluss noch einmal eine Erinnerung an wichtige Seiten:

Die Feedbackseite „Vorschlaghammer“ – hier kannst Du Fragen stellen oder Wünsche oder Ideen einbringen
Die T-Shirt Seite – hier kannst Du das ClickCoach Team unterstützen und dabei noch gut aussehen

Microsoft EntraID – Role-based Access Control (RBAC)

German Version

Approximately a year ago, I wrote about PIM here… The article remains highly relevant today, and I can only recommend it. This new post is meant as an addition, but it’s also valuable to read on its own.

Did you know that in Microsoft Azure, there are over 120 standard roles that can be individually assigned? You can find a detailed overview here. One area of Azure is the directory service ‚Entra‘, which manages identities. Here too, there are dozens of availabe roles.

Not all of these many roles are equally critical. Microsoft designates the particularly important roles as ‚privileged.‘ These roles have higher permissions and require special protection (using PIM).

RBAC sounds simple in concept, at least at first glance. You think about what rights you need for your work, and then someone assigns an appropriate role to your admin account. But what rights do you actually need? When asked specifically, you might just want to be able to do ‚everything.‘ Who wants to be restricted in their work? That’s why in many accumulated Active Directory environments, you often find an undocumented number of ‚Domain Admins‘. And the same happens in Azure environments these days: there are many ‚Global Admins.‘ This is like handing out the master key to the building because someone might need to access the boiler room. Baaad idea! It’s really worth investing some effort here to define the correct roles.

The Azure / M365 / Entra roles are all well documented and usually quite clear. For example, have a look at the ‚Teams Administrator‘ role. So someone dealing with Teams administration should get this role. Right? Unfortunately, it’s not that easy. There’s a difference between managing the entire Teams service (Role: Teams Administrator) and primarily handling Teams telephony functions (Role: Teams Telephony Administrator). You’ll have to work this out by asking the right questions.

One problem you’ll soon encounter is that the services in M365 are closely integrated. Behind Teams, there’s a SharePoint storage, and then there’s usually a M365 groups for sending mails to Teams members. To manage all three areas end-to-end, you might need:

Exchange Administrator
Teams Administrator
Sharepoint Administrator

Managing access with PIM, you may have to request all three roles separately. Very cumbersome! Okay, we could also build custom roles where we try to mirror the Microsoft roles. This option is possible but it’s high maintenance, because there can always be changes to the Microsoft standard roles. The cloud environment is rapidly developing, so a static approach is probably the wrong way to go.

A better option is to create your own Entra RBAC group and integrate it into PIM management. After that, you can request rights to the self-created RBAC group via PIM and receive the functions of all linked Azure standard roles (for a limited amount of time). These linked role assignments can be changed as needed, but the ordering process remains unchanged. This simplified approach is ideal for reorganizations, etc.

Next, I’ll explain how to do this. The example assumes job responsibility for the three main services of M365 (Teams, Exchange, SharePoint).

Managing your own RBAC groups with PIM

What rights do I need to set this up?

The role of ‚Privileged Role Administrator‘ – this role defines and updates the PIM roles.

What are the general steps?

Create a new group in Entra and assign roles to it.
Activate the group in PIM for management.

What are the detailed steps?

Go to ‚https://portal.azure.com‚
Microsoft Entra ID – Groups – New Group

Are there any other considerations for the new group?

The group type must be ‚Security.‘
It needs a clear naming convention (e.g., RBAC).
The ‚Microsoft Entra Roles can be assigned to this group‘ checkbox must be set to ‚Yes.‘
Dynamic groups for RBAC are not supported.
Clicking on ‚Roles‘ brings up the following dialog (summarized).

Here you can directly assign the desired standard roles to the group (Exchange Administrator, SharePoint Administrator, Teams Administrator).

The group type cannot be changed later, which must be confirmed again here (Create, Yes).

What else needs to be done in PIM?

Switch to ‚PIM‘ in Entra and go to ‚Groups.‘

Select ‚Group Discovery’…

Enter the name of the previously created group, check the box next to the group, and then select ‚Manage Groups.‘

Confirm the onboarding of the group by clicking ‚OK‘

What else should you know?

Azure roles are permanently assigned to the RBAC group.
The group is initially empty.
Membership management is only through PIM.
Everything that happens in PIM is logged.

Okay, but who can request this new role, and how long will the assignment last?

An important step in PIM is to add all eligible persons under ‚Eligible Assignments.‘ Only those listed here can later request the role

Just like with standard RBAC roles, you can also define:

How long the assignment lasts.
Whether someone is notified when the role is requested.
Whether someone needs to approve the assignment first (Approval).
Whether additional MFA authentication is required.

So how can I order the new role for myself?

Access the Azure portal.
Switch to PIM.

The RBAC role appears here under ‚My Roles‘ ‚Groups.‘

Clicking ‚Activate‘ requests the role, and depending on whether approval is needed or not, it’s assigned directly.

In our example, the permission expires automatically after 8 hours.

And that’s it!

Here’s a reminder of ways you can interact with us:

‚Hammertime‘ – Send uns your ideas and let us know what you think
Get the ‚T-Shirt‘ – Impress friends and family while supporting our site.

Microsoft EntraID – Rollen-basierter Zugriff (RBAC)

English Version

Ca. vor einem Jahr habe ich hier über PIM geschrieben… Der Artikel bleibt bis heute sehr relevant und ich kann ihn nur empfehlen. Was ich im heutigen Beitrag schreibe ist als Ergänzung zu verstehen, aber auch für sich allein lesenwert.

Wusstest Du, dass es in Microsoft Azure sehr viele (mehr als 120) Standard-Rollen gibt, die inviduell vergeben werden können? Eine detaillierte Uebersicht ist hier zu finden. Ein Teilgebiet von Azure ist der Verzeichnisdienst ‚Entra‘ der die Identitäten verwaltet. Auch hier gibt es dutzende von Rollen.

Nicht alle dieser vielen Rollen, sind gleich kritisch. Microsoft bezeichnet die besonders wichtigen Rollen als ‚Privilegiert‘. Das sind Rollen mit höheren Berechtigungen, die besonders geschützt werden müssen (mit PIM).

RBAC tönt erstmal sehr einfach vom Konzept. Ich sage einfach, was ich so zum Arbeiten brauche und dann teilt mir jemand eine passende Rolle zu. Aber was brauche ich überhaupt? Wenn man konkret rückfragt, will man einfach mal ‚alles‘ machen können. Wer möchte denn in seiner Arbeit eingeschränkt sein? Das ist der Grund warum man in ‚gewachsenen‘ Active Directory Umgebungen immer sehr viele ‚Domain Admins‘ findet und neuerdings in Azure Umgebungen viele ‚Global Admins‘. Das ist so wie wenn wir den Generalschlüssel verteilen, weil man ja vielleicht mal in den Heizungsraum muss. Keine gute Idee! Es lohnt sich hier etwas Arbeit zu investieren und die Rollen festzulegen.

Die Azure / M365 / Entra Rollen sind alle gut dokumentiert und teilweise auch sehr klar. Was der ‚Teams Administrator‘ so tut, sollte klar sein? Leider nein. Es macht schon einen Unterschied ob man den ganzen Teams Service verwaltet (Rolle: Teams Administrator) oder vor allem die Telefonie Funktionen von Teams bearbeitet (Rolle: Teams Telephony Administrator)

Ein Problem, auf dass man praktisch bald stossen wird ist: Die Services im M365 sind stark miteinander verzahnt. Hinter Teams läuft Sharepoint als Ablage und es gibt M365 Gruppen über die Mail verschickt wird. Um alle drei Gebiete End-to-End verwalten zu können bräuchte ich dann:

Exchange Administrator
Teams Administrator
Sharepoint Administrator

Wenn ich die Zugänge mit PIM verwalte, müsste ich mir alle drei Rollen separat bestellen. Sehr umständlich! Ok, ich könnte mir auch Custom Rollen bauen bei denen ich die Microsoft Rollen selber nachdefiniere. Diese Variante ist möglich, muss aber immer gepflegt werden wenn sich bei den Microsoft Standard Rollen was ändert. Das könnten zum Beispiel neue Rechte sein, was bei der schnellen Entwicklung der Cloud Dienste jederzeit passieren kann.

Eine bessere Variante ist eine eigene Entra RBAC Gruppe zu erstellen und diese ins PIM Management zu integrieren. Danach kann ich mir Rechte zur selber erstellten RBAC Gruppe via PIM bestellen und erhalte zeitgesteuert die Funktion aller verknüpfen Azure Standard Rollen. Die Rollenzuteilungen können jederzeit geändert werden aber der Bestellprozess bleibt unverändert. Ideal auch bei Reorganisationen etc.

Im folgenden erkläre ich wie das geht. Grundlage ist das Beispiel bei dem ich gleichzeitig für die die drei Hauptdienste von M365 (Teams, Exchange, Sharepoint) verantwortlich bin.

Eigene RBAC Gruppen im PIM verwalten

Welche Rechte brauche ich um das einzurichten?

Die Rolle des ‚Privileged Role Administrator‘ – dieser definiert und aktualisiert die PIM Rollen

Was sind die groben Schritte?

Neue Gruppe erstellen im Entra und Rollen zuweisen
Die Gruppe im PIM für Management aktivieren

Wie geht das im Detail?

Gehe zu ‚https://portal.azure.com‘
Microsoft Entra ID – Gruppen – Neue Gruppe

Was ist bei der neuen Gruppe zu beachten?

Der Gruppentyp muss ‚Security sein‘
Es braucht eine klare Namenskonvention (z.B. RBAC)
Der Reiter ‚Microsoft Entra Roles‘ can be assigned to this group muss auf ‚Ja‘ gestellt werden
Es werden keine dynamischen Gruppen für RBAC unterstützt
Klickt man auf ‚Roles‘ erscheint folgender Dialog (verkürzt)

Hier können nun die gewünschten Standard-Rollen direkt der Gruppe zugewiesen werden (Exchange Administrator, Sharepoint Administrator, Teams Administrator)

Der Gruppentyp kann später nicht mehr geändert werden, was hier nochmals bestätigt werden muss (Create, Yes)

Was muss jetzt noch im PIM gemacht werden?

Wir wechseln jetzt im Entra zu ‚PIM‘ und gehen dort zu ‚Groups‘

Dann auf ‚Group Discovery’…

Den Namen der erstellten Gruppe eingeben, die Gruppe ankreuzen und ‚Manage Groups‘ auswählen

Das Onboarding muss mit ‚OK‘ nochmals bestätigt werden

Was muss man auch noch wissen?

Die Azure Rollen sind der RBAC Gruppe permanent zugeteilt
Die Gruppe ist zu Beginn leer
Die Verwaltung der Mitgliedschaft erfolgt nur über PIM
Alles was im PIM passiert wird geloggt

Ok, aber wer darf jetzt diese Rolle bestellen und wie lange gilt die Zuweisung?

Ein wichtiger Schritt im PIM ist alle berechtigten Personen unter ‚Elligible Assignments‘ zuzufügen. Nur wer hier drin ist darf die Rolle überhaupt beantragen.

Genau wie bei den Standard RBAC Rollen, kann man auch hier definieren:
- Wie lange die Zuweisung gilt
- Ob jemand informiert wird bei Bestellung der Rolle
- Ob jemand die Zuweisung zuerst bestätigen muss (Approval)
- Ob es zusätzlich eine MFA Anmeldung braucht

Und wo bestelle ich mir jetzt die Rolle?

Das Azure Portal aufrufen
Zu PIM wechseln

Die RBAC Roll erscheint hier unter ‚My Roles‘ ‚Groups‘

Mit einem Klick auf ‚Activate‘ wird die Rolle beantragt und je nachdem ob ein Approval nötig ist oder nicht direkt zugeteilt.
In unserem Beispiel läuft die Berechtigung nach 8 Stunden automatisch wieder ab

Und das war’s!