Automating Identity at SeattleU – My IAM Journey

Authored by A. Manzi | Written With AI assistance | Edited by Manzi & Friends

What Does an IAM Engineer Do

A software engineer friend once asked me what I do for work. My simplest answer was that I am the person you hate that enforces the fact that when you need to use a resource that your boss might have access to but you do not. You have to go through me before you can use it.

---

IAM in Higher Education

I worked as an Integration Engineer at Seattle University for two years, focusing on automating scripts to make sure the right people had the right access to the right systems.

In higher education, it is nuanced. We have students, faculty, and staff, and the roles overlap like regularly. A student can also be a staff member. A staff member can also be a student. A faculty member might have been a student before. Roles change all the time.

I joined in 2022 when the team was expanding. At the time, I was a project manager, so they needed someone who understood how IT and the school worked, who knew how these groups fit together, and who also had a background in software engineering and scripting.

COVID had already sped up our move from on-prem Active Directory to cloud-based Active Directory. We were creating new RBAC( role-based access control) systems and moving old ones. My job was to help make that migration happen.

---

On-Prem versus Cloud ADs

At SeattleU, we ran a hybrid setup. Before I joined, we relied a lot on on-prem.

On-Prem
This handled things like password resets, group assignments, and device-based access. Adobe and certain licenses lived here too. Our main data source, Colleague, was accessed through SQL Server Management Studio, also on-prem.

Cloud (Azure AD)
Azure was mostly for cloud licensing, especially for Microsoft 365. A few other licenses lived here, but not many.

The Shift to Cloud
Over time, we moved more stuff to Azure. Group assignments moved because the cloud processed them faster. Now, we are working on moving from Colleague to Workday, which will make us more cloud-reliant and cleaner overall.

---

My Projects

Microsoft License Assignment Automation
The first big project I worked on was automating Microsoft license assignments. Before, we assigned licenses after creating accounts using on-prem tools. It was slow, inconsistent, and full of errors.

When I was assigned this, I based it mainly on role-based access control (RBAC), but the whole thing ran on group assignments. If someone was a student, they got A5 for students. If someone was staff, they got A5 for staff. For overlaps, we had to decide which one took precedence. Staff was more privileged, so we built something like privilege tiers. If someone was in both groups, the script would check the tiers and assign the right license.

I built PowerShell scripts using Microsoft Graph and Azure AD to push this to the cloud. It also had Joiner-Mover-Leaver logic so the script could update licenses when someone’s group changed. Least privilege was the rule. Alumni did not need A5 licenses that cost $100 a year.

The result: we automated all 44,000+ accounts, found over 5,000 that had licenses they should not, and saved the university thousands every year. It also sped up onboarding, kept permissions consistent, and improved compliance.

Student Employee Deprovisioning
Student employees get separate accounts so their work access stays safe from phishing. These accounts have privileges you do not want in the wrong hands.

The problem was they often stayed active long after the student left. Supervisors told us when hiring but not when someone quit. Students also moved between departments, keeping licenses they no longer needed.

When I was running this, we implemented joiners, movers, and leavers using what I call tellers. First, we compared the student employee account to the regular student account to see if the person had graduated, withdrawn, or transferred. If they were no longer a student, we did not need to keep the employee account. Another teller was the last time they were paid. If they had not been paid in six months, we would reach out to the department to confirm. If they did not respond, which happened a lot, we terminated the account. And for movers, we made sure a student employee account could not be in more than one department group at the same time.

I built PowerShell scripts to disable accounts, remove licenses, and revoke access when a student was terminated, moved, or took a break. It used JML plus Privileged Access Management principles to make sure accounts had only what they needed.

We reviewed over 8,000 accounts, making sure they were active, properly licensed, and secure. This closed gaps, saved license money, and reduced manual work.

---

Separate Accounts as a Security Practice
We do not use Just in Time access much. We use separate accounts as our bread and butter for security. We have privileged accounts, elevated user accounts, and student employee accounts.

This became huge after three major phishing attacks in three years, each hitting over a hundred accounts. Many started from sleeper accounts—like alumni from 20 years ago—tricked into giving an attacker an authentication code. That attacker could then email active staff, maybe the one executive assistant who clicks without thinking, and boom, chain reaction.

Separate privileged accounts break that chain. A department head can install software without risking their main email. Privileged accounts cannot send or receive email, which cuts phishing chances.

---

Campus Wide MFA Implementation
Part of my job was rolling out MFA across campus in Azure AD. We set conditional access policies to require MFA based on risk and made sure people had strong authentication methods. This covered over 30,000 accounts.

We used the Authenticator app, SMS codes, and even calls as second factors. Registering everyone was not fun. People fought it even though it made them safer.

We pushed MFA because phishing and scams were becoming too common, especially among non-technical users and older alumni. Without it, giving away an email and password was enough to lose an account.

---

Challenges and Lessons Learned

Challenges

• Hybrid IAM complexity: Balancing on-prem AD for password resets, printers, and group assignments with Azure AD for cloud licensing, all while syncing Colleague data. It took time and patience, which is why we kept moving toward the cloud and Workday.

• Legacy dependencies: Even with the cloud push, some licenses and device assignments still needed on-prem. That slowed us down.

• Security gaps in manual processes: People do not tell you when they stop using an account. If it is not costing their department, they will not rush. You find out yourself.

• MFA adoption challenges: Teaching people why MFA matters and how to use it was harder than it should have been.

Lessons Learned

• Automate as much as you can. Does not need explaining.

• Balance on-prem and cloud. Cloud is great, but on-prem runs many resources well. If it works, keep it.

• Documentation is unmatched. You might not have a fix yet, but write it down. Document as much as you can. Document as much as you can. Document as much as you can.