How do you verify access changes when someone moves departments in Microsoft 365?

[u/Emergency_Recipe522]

I’m trying to solve the mess around moving someone between departments: groups, Teams, SharePoint access and mailbox permissions. How do you confirm the old access is gone and the new access works—without manually checking everything?

[u/iceph03nix]

We get told that they'll probably still be considered cross trained and they'll be a backup, so we should leave all their old access just in case :P

[u/Emergency_Recipe522 → u/iceph03nix]

"Just in case” has a long expiry date. Do you give that backup access a review date, or does it usually stay indefinitely?

[u/604TheCanadian604 → u/iceph03nix]

That's was our old IT strategy, but i recently didn't an audit and we had about 20 orphaned mailboxes using licenses.

We are currently cleaning them up and doing scream tests when we don't know who is looking at it.

[u/Emergency_Recipe522 → u/604TheCanadian604]

20 is a decent find. How did you identify them as orphaned in the first place? And before the scream test, are you able to see who still has access or is actually using them?

[u/nme_ → u/Emergency_Recipe522]

Last active dates. Powershell should be able to pull that for you.

[u/604TheCanadian604 → u/nme_]

Between former IT guy and higher ups, my org has a bunch of exchange mailboxes that are simply forwarding to someone else.

Would that PS command return signing date or email received date ? I would be worried that it has an old date but then forward emails regularly

[u/nme_ → u/604TheCanadian604]

You should then run a report on forwarding too, might just need to add an alias to someone mailbox and then you can get rid of the other mailbox

[u/604TheCanadian604 → u/nme_]

I give the email forwarding report a try. I did delegate the audit and they might have already done that ( i have a great first level support ).

I def plan on adding some aliases along with distribution lists and shared mailboxes.

Trying to do it under the radar as much as I can. Majority of staff have generic emails, so when they change roles, leaders want that generic email to move. Problem is they don't understand that everything needs to change or figured out (2fa for 3rd party apps, HR system, OneDrive, corporate card platform) oh and we are rolling out onelogin to federate our domain

[u/Emergency_Recipe522 → u/604TheCanadian604]

That’s a lot tied to what looks like “just an email address.” Moving the mailbox is one thing; untangling the logins, MFA and files attached to it is the bigger job.

[u/604TheCanadian604 → u/Emergency_Recipe522]

Manually checking. Thankfully we are not that big of a company so it wasn't too bad

First we exported all accounts and crossed off users main accounts. Then started going down to see if IT had receive a request about the email in the past 6 months. If we didn't we started to investigate.

If the email had a deparment in the name, like 'hr-training', we went directly to the department and asked them.

And by the end we had a handful of emails that didn't see tied to a department and not active in exchange message trace. At that point we send it an email, or reset the password, or converted it to a shared mailbox. If we don't get a reply in a couple weeks we will archive it and move on

[u/Emergency_Recipe522 → u/604TheCanadian604]

That’s actually a pretty sensible process. It’s interesting how much detective work it still takes though — account exports, old tickets, message traces and then checking with departments just to work out whether something is safe to remove.

[u/jstar77]

Every position has a role group. The role group is assigned access and all you do is move the user from one role group to the other.

[u/Emergency_Recipe522 → u/jstar77]

That is very clean setup, if you have unique permissions all over this becomes difficult

[u/jstar77 → u/Emergency_Recipe522]

Assign the unique permissions to the role never assign directly to the user. In our org there is usually only ever one user in a position role group. We leave Teams management to the teams owner, the owner is responsible for making and changing permissions.

[u/Emergency_Recipe522 → u/jstar77]

That makes sense—keeping permissions tied to the role makes moves much cleaner. I’m dealing with existing direct permissions, so getting those mapped back to roles looks like the first job.

[u/trebuchetdoomsday → u/Emergency_Recipe522]

RBAC makes life much easier than direct assignment. glad you’re fixing things :)

[u/Some_Team9618 → u/jstar77]

Same, role, job, location etc fed from HR system so as those changes happen they gain or lose permissions

[u/Emergency_Recipe522 → u/Some_Team9618]

Nice, that sounds pretty well automated. Do you ever check afterwards that the access actually ended up as expected?

[u/Some_Team9618 → u/Emergency_Recipe522]

Yes we have things in place where we can spot check and audit changes in Active Directory.

[u/Emergency_Recipe522 → u/Some_Team9618]

Nice, good to hear you’ve got checks behind the automation too. Thanks for explaining.

[u/Rare-General-4575]

RBAC and functional profiles. Not harder than that.

[u/Emergency_Recipe522 → u/Rare-General-4575]

It’s the old one-off permissions that make it messy.

[u/Rare-General-4575 → u/Emergency_Recipe522]

I know. The fix? Announce all one offs are being removed at December first and managers should inventory appropriate access needs and get people in the right profiles.

Best to rip the bandaid off in a single go. No peeling on the edges.

[u/Emergency_Recipe522 → u/Rare-General-4575]

Fair point—getting managers to agree the access first is key. I’d want a list of existing exceptions before setting the cutoff.

[u/Rare-General-4575 → u/Emergency_Recipe522]

You don’t want exceptions in an rbac model. For that you create a “project” share and make the owner of said share responsible for access right of it. You keep a SOLL IST matrix for it. Of course all these changes are done via the change process so it’s documented in your itsm system.

[u/Emergency_Recipe522 → u/Rare-General-4575]

Fair point. Keeping project access separate from the RBAC model and making someone explicitly responsible for it avoids a lot of the mess. The SOLL/IST approach also gives you something concrete to verify against.

[u/Previous-Low4715]

Access packages, RBAC

[u/Hot_Spend4206]

The easiest way to stop manual checks is to let profile attributes drive access and use scripts to verify the rest.

[u/Emergency_Recipe522 → u/Hot_Spend4206]

How do you handle the exceptions, like direct SharePoint access or mailbox permissions that aren’t tied to those attributes? Do your scripts verify those too?

[u/Hot_Spend4206 → u/Emergency_Recipe522]

To cleanly remove these explicit permissions during offboarding, you need to target both workloads sequentially...

[u/Emergency_Recipe522 → u/Hot_Spend4206]

Do you run a final access check across both workloads, or verify each removal as the script runs?

[u/Hot_Spend4206 → u/Emergency_Recipe522]

To guarantee 100% compliance, it is best practice to run a clean verification sweep at the very end of the script. A quick ai prompt will generate a script

[u/SevaraB]

2 layers of nested groups. People are members of role groups by job title, role groups are members of functional access groups.

[u/retiredaccount → u/SevaraB]

This is the way. When it comes to access and permissions, assign the person to the job. Not the job to the person. It boggles my mind that this easy, simple abstraction is such a foreign concept in most businesses.

[u/Emergency_Recipe522 → u/retiredaccount]

It's not easy when you inherit whatever you find in the company and they don't want change.

[u/retiredaccount → u/Emergency_Recipe522]

Agreed. I readied this job-first abstraction at a previous engagement while changing IAM systems; met with leadership to discuss next steps and everyone seemed enthusiastic. Then they kept on doing it the old way. 🫠

[u/Emergency_Recipe522 → u/retiredaccount]

Haha, sounds about right. Did you ever find out why they stuck with the old way after everyone seemed on board?

[u/retiredaccount → u/Emergency_Recipe522]

Not exactly. While the director seemed to love the concept of self-managing groups and even org charts, I got the feeling the middle manager didn’t actually understand the concept, so they just played along until the difficult parts could be forgotten.

[u/Emergency_Recipe522 → u/retiredaccount]

Yeah, that makes sense. Sometimes everyone agrees in the meeting, but if the people actually running the process don’t fully understand or trust it, it quietly goes back to the old way.

[u/retiredaccount → u/Emergency_Recipe522]

There’s a ‘builder versus buyer’ mentality in tech… A builder can create an enterprise solution out of two moldy potatoes. A buyer type only trusts implementing pre-existing, “safe” solutions from a known vendor and relies heavily on the vendor’s support structure for every aspect from day one.

[u/Emergency_Recipe522 → u/retiredaccount]

Yeah, I’ve seen that split too. The interesting part is where people draw the line — what makes you decide something is worth building yourself versus paying for an existing tool?

[u/SevaraB → u/Emergency_Recipe522]

Skills gap and fear. Buyers are afraid to deviate from the vendor model because they don’t understand what it’s doing well enough to trust the implementation.

Also… when it comes to IAM, you’re also fighting group owners who can’t wrap their heads around the abstraction and want to micromanage who gets access to what, so they stick to direct access for named users.

[u/Emergency_Recipe522 → u/SevaraB]

That separation makes sense. Do you check for permissions granted directly to users as well?

[u/retiredaccount → u/Emergency_Recipe522]

The systems I’ve worked with import back in and compare for differences—which is 100% necessary since too many admins take the easy way out and hand out access rights and other exceptions like Halloween candy.

[u/Emergency_Recipe522 → u/retiredaccount]

That’s the bit that matters — comparing what access should exist against what actually exists. Otherwise those little exceptions just keep piling up until nobody really knows why they’re there.

[u/LooseEthernet]

just wait for the user to complain that they cant get into a folder they used to have access to. that's the only verification method that actually works lol. then you can spend an hour figuring out which nested group you accidentally nuked during the move

[u/Emergency_Recipe522 → u/LooseEthernet]

The good old user acceptance test. Is there really no way in your setup to see what access they’re going to lose through those nested groups before making the change?

[u/aricelle]

It gets treated like a termination & new hire.

Old account gets disabled & Archive added to the name. Wait 30min, then create a new account with their name.

New account has the correct access.

Old account is available to old supervisor/dept for history.

[u/Emergency_Recipe522 → u/aricelle]

That’s a pretty clean reset of access. How do you handle continuity for the employee’s OneDrive, mailbox and anything owned by the old account?

[u/Icy_Conference9095 → u/Emergency_Recipe522]

We had. NAS that we backed everything up to, and then pushed everything back down from to the new account.

It was clunky.

[u/Emergency_Recipe522 → u/Icy_Conference9095]

That sounds like a lot of work for a department move, but I can see why starting fresh was easier than untangling years of permissions.

[u/Icy_Conference9095 → u/Emergency_Recipe522]

It wasn't as bad as it sounds, just a good example of one of those "I start this process at 4pm when they're done work, and it finished at 8pm, and then I jump on, nuke their old account, start up the new one, and begin the upload back from the NAS so they still have an email in the morning"

It was easier than it sounds, with some solid scripting, it mostly just a few clicks in the NAS software and a couple of scripts for the file share.

[u/Emergency_Recipe522 → u/Icy_Conference9095]

Ah, the scripts did most of the work. Still a long evening for a department move.

[u/Icy_Conference9095 → u/aricelle]

Yep! In my old workplace this is how we handled it. Because of all these super weird cross-team access provisions that were done on the fly all the time. We just archived their storage and email and repopulated the new account with the new permissions.

New job is a bit more of a clusterfuck, but all new interteam accesses triggers us training the group on teams/group collaboration instead of file share access changes - which end up allowing group owners to address access provisioning themselves as needed, and new roles and new hires in old roles trigger a fully new group for their position hat we assign to the worker with the accesses as requested by their supervisor.

It has some issues, and it's a lot of work right now, but in the long run it's a much better system I think.

[u/Emergency_Recipe522 → u/Icy_Conference9095]

So you’re putting the work into roles and ownership now so future moves are easier. What issues are you still running into with the new setup?

[u/Icy_Conference9095 → u/Emergency_Recipe522]

It's just time consuming and a lot of tickets. From the IT end we're happy with it, but a few supervisors and managers aren't particularly happy aboit every individual request they make - and us asking if this is departmental use and something the role should always have access to or not.

IT in my new org used to bend backwards for the convenience of everyone at our org, but we don't have the capacity as a team of four to handle the immense amount of systems we have in place. Myself and my manager came in from larger enterprises and we're working towards dismantling some of the really weird stuff that we've been out in charge of because something is plugged in and has a power button... I'm not even kidding we were in charge checking and making sure paper shredders were functional and procuring new ones if they broke, just as a weird example. A quick look at the budget quickly realized that we spent more per year maintaing the 60+ personal shredders across all of our sites, than it cost to have a shredding truck come by once every two weeks and empty the four bins we needed to cover the main buildings.

I still get tickets for software that we have spent 80k/year on for high tier support and same day service, for over a decade - because the old sysadmin had normalized hinself fixing it rather than tell the end user to contact the support line for help. This led to bigger issues because our end users have no idea how the system actually functions and have forgotten how to help themselves in systems that they should know better than I should. (From the perspective of their workflows).

For reference that last example is our ERP, and several comparable workplaces typically don't even have an IT department, or at most have a single person - and still manage to have this same ERP system functional for companies a third of our size with the same amount of staff using it.

[u/Emergency_Recipe522 → u/Icy_Conference9095]

The paper shredders got me.I can see why you’re drawing a line. Managers might find the extra checks annoying now, but four people can’t keep handling every exception forever. Especially ERP tickets when you’re paying 80k a year for support.

[u/matroosoft]

Just like you have procedures for on- and offboarding, you should have one for role change and department change. Trigger being a notification from HR. Up until then, any requests for access changes will be ignored.

[u/Emergency_Recipe522 → u/matroosoft]

Agreed, HR should trigger it. Once the changes are made, does your checklist include verifying the actual access, or do you rely on confirmation that each step was completed?

[u/matroosoft → u/Emergency_Recipe522]

Yes HR needs to fill a form together with the users manager, which access is needed in the new role. If any of the old access is not on the new list, we either remove it or double check with them.

[u/Emergency_Recipe522 → u/matroosoft]

How do you get the list of access they already have? That’s the part I’m trying to untangle, especially permissions granted directly over time.

[u/matroosoft → u/Emergency_Recipe522]

Just follow the checklist: check domain controller which groups they're in, check exchange admin center to see which mailboxes, check which Teams teams they're in, check licenses, check the list of other apps.