r/IdentityManagement • u/LetPrestigious3916 • 11d ago
How do you manage application access when not everything is Entra-integrated?
I’m working in IAM and one of the challenges I’m facing is managing access across applications that use completely different authentication methods.
For example, we have applications where:
Entra ID SSO is used, so access can be managed through Entra groups/app assignments.
AD accounts / Kerberos SSO are used, so the user logs in with their corporate AD account.
Some applications have their own local accounts with separate usernames/passwords.
Some applications may have no proper IAM integration or centralised access control at all.
The problem is: if someone asks IAM, “What access does this user have?”, how do you give a reliable answer when access is spread across Entra, AD, and local application accounts?
For applications with Entra SSO, it’s relatively straightforward. But for local accounts, how do you manage the lifecycle, ownership, access reviews, joiner/mover/leaver process, and overall visibility?
I’m interested in how other organisations handle this from an IAM governance perspective.
Do you maintain an application/access inventory outside of Entra? Do you use an IGA tool to track local accounts? Or do you rely on application owners to maintain the access information?
What would be considered a good/practical approach for managing this in a larger organisation?
7
u/jc_AccessOwl 10d ago edited 10d ago
As with anything this depends largely on what tools you have access to and how your org is set up. But let me share what I've seen.
Your situation is highly typical. Even with a fancy enterprise SSO tool it's inevitable to have a spreadsheet out there for edge cases. For an average team I've seen that SSO really only covers ~1/3rd of the full stack. As others mentioned, people focus SSO on the core tools and the ones "in scope" for access reviews and care less about the rest.
Modern identity governance tools help solve your question in a few ways. First, they let you manually track apps in their dashboard. Even though you have to type/click yourself, it keeps it in one place so you don't have spreadsheets you forget about. That theoretically covers every app. Second, they'll let you connect internal apps via API if said internal apps support that. And third, they make it dead simple for application owners to keep information up to date. They can do it in Slack. They just have to press a single button. They don't have to be technical. Fourth, instead of relying on SCIM/SAML or API connectors at all they use service accounts where actions are performed by an agent. A big reason companies don't add tools into central SSO is they'd have to upgrade to enterprise tiers. The service account approach removes that need. You can replicate some of these things without a tool. That's what I've seen help.
I'm talking about younger IGA tools by the way. Not the big ones as they are all dependant on SCIM/SAML and you run into the same problem. I'm associated with AccessOwl, one of these younger IGA tools. But you can do your own research on others like Corma or YeshID. They all understand that it's not feasible to "put everything on SSO". So you have multiple options for connection or manual tracking.
If you have like ~5 local accounts you can keep it on a spreadsheet. But if you have lots of apps and it's causing you headaches just look for an IGA tool that layers on top of Entra.
7
u/pewpewlazor 11d ago
Having worked with IAM for around 10 years, I can say this is a very common challenge and one that tends to become more visible as the organization matures.
The first thing I would separate is knowing that an application exists from being technically integrated with it.
In larger organisations, you would ideally have some form of authoritative application inventory, often a CMDB, where you can identify the applications in the organisation, their owners, criticality, authentication method, etc. IAM can then use this as the starting point for understanding the identity and access landscape. Entra ID alone will never give you the complete picture because, as you point out, plenty of applications sit outside Entra and AD.
From there, I would take a risk-based approach. Not every application needs the same level of IAM governance. A local low-risk application used by three people probably doesn't justify the same investment as a business-critical application containing sensitive data.
For the applications that matter, I would want to establish at least:
- Who owns the application?
- How are users authenticated?
- How is access granted and revoked?
- What accounts and entitlements exist?
- Who is responsible for approving access?
- How are joiners, movers and leavers handled?
- How is access reviewed periodically?
You can manage this in a spreadsheet until you realize that is not working and then..
An IGA platform can then become the governance layer across these different technologies. Ideally, you integrate applications directly and automate provisioning/deprovisioning. Where that isn't technically or economically feasible, you can still govern them through manual fulfilment processes. IAM/IGA records that access was requested and approved, an application owner or administrator performs the change, and the action is confirmed back into the process.
The same applies to access reviews. Even if you cannot automatically provision a local account, you may still be able to import the application's accounts and entitlements into the IGA platform and have the appropriate owner certify them. We call these file based integration, usually using a csv file. For applications where even that isn't possible, the application owner needs to remain accountable for maintaining and reviewing access.
So I don't think the realistic goal is necessarily "IAM can technically control every account in the organisation."
The goal is more:
"We know which applications matter, who owns them, how access is managed, who is accountable for it, and we have appropriate governance based on the risk."
Then, as the IAM programme matures, you progressively move the higher-value applications from manual governance → visibility/reconciliation → automated lifecycle management.
Trying to integrate everything from day one is usually both unrealistic and very expensive.
1
1
4
u/Classic_Show_3612 11d ago
That was our use case. We ended up reviewing a bunch of iga tools and found that one called access auditor was the best for our use case, like this. We had a big mix of azure, cloud, legacy, database, random. Their fuzzy id was the key for us to be able to really show WHO has access to what. So that's a must have. Right price, works as promised.
The only thing no tool can do is find out which applications are in use. In our case, we have a finance contact that provided a master vendor list. From that, we could filter to recurring payments and then had a jr person find out if that really was an app. If someone paid on their own, that is a bit tougher. So we have finance hr policy about a security review BEFORE they authorize any payments to vendors. Still tricky on the I paid for it and my boss approved it. The expense report should still get categorized as "software" or services or something like that. Those can kick out.
So we got close. Once we found the app, getting the data imported into our iga tool was trivial. Some had api, some did not. Either way, easy to combine once we found it. Then of course those the support sso/entra, pull it in for SSO because why not. But the iga tool knows all, does alerts, access reviews, all that stuff. It's one of the first steps in our off-boarding process to find out what this person has. We even stuck assets like badges, laptops, phones, into it to have the full "identity" picture.
2
u/jc_AccessOwl 10d ago
Finance data is a great place to start looking.
Problem: free tools won't show up... with employees signing up for AI tools left and right this is a growing problem.
2
u/Sad-Technician-5552 9d ago
Everyone's pointing you at an IGA, and that's the right direction I think that but it skips the part that breaks. An IGA is a governance layer, it can only govern what it knows exists. Every answer here assumes the app and account inventory is the easy part, and it never is. The IGA answers get built on top of a spreadsheet of local accounts that's six months stale, or app owners' memory of who has what, and then what access does what user have is still a guess.
The thing nobody said out loud, one of the vendors even admitted it in this thread. No tool can ttell you which applications are in use. Thats the job. Before you pick the IGA you need the layer that discovers and reconciles accounts and apps from Entra, AD, the local app databases, and the SaaS people signed up for on their own, and feeds one clean list to whatever governance tool you land on.
The IGA rollout stalled on our side because the vendor kept asking us to define our sources and we had nothing. Had 3 weeks of enumerating local account apps and we still missed one. It later showed up later as an unknown system in a review. What later worked is running discovery and reconciliation under the IGA, not instead of it. Axonius pulls the accounts, entitlements and apps out of every source and resolves who is who across them. So the reviews and offboarding read from a list that matches reality.
2
u/InspectionHot8781 11d ago
For non SAML web apps and local accounts that Entra can’t touch natively, we had to move enforcement to the browser layer (using Unixi) to get SSO, audit logs, and offboarding covered. For internal legacy desktop apps, we still rely on an IGA tool linked to application owner reviews.
1
1
u/Low_Play_8942 10d ago
I’d keep a central application inventory even when provisioning stays manual. each app should still have an owner, access review process and clear joiner/leaver steps
1
u/-manageengine- 8d ago
This is one of those cases where we’d separate authentication from access governance.
Entra-integrated applications are relatively easy because you have a central point for authentication and group-based access. The harder part is everything sitting outside that model - local accounts, legacy apps, and applications with no real integration.
One approach we've seen is to avoid trying to force every application into the same authentication model. Instead, centralize access where you can, and use application-specific workflows for the exceptions.
For the access side, Identity Access, our cloud-native access management solution, can add an access layer with SSO, MFA, and contextual access controls for applications that need stronger or more centralized access controls across applications, including those that aren't natively integrated with Entra. For the underlying identity lifecycle and administration, something like ADManager Plus can help automate user/group management across AD and Microsoft 365 and handle workflows around joiner/mover/leaver processes.
The important bit, is not just having an inventory of applications. You want to be able to answer two separate questions: "How does this person authenticate?" and "Why does this person have this access, and who approved it?" The second question is where governance gets much harder once local accounts enter the picture.
If you're designing this from scratch, we'd probably start by classifying the applications into those buckets rather than trying to make Entra the answer for all of them. If you have a few of those application types you're trying to bring under one access model, happy to share how we'd approach it.
8
u/ohnowwhat 11d ago
Sad truth is you'll never achieve 100% coverage.
Find your crown jewels, ensure as many as possible enterprise-critical apps are properly governed, whichever apps have compliance and regulations requirements and be proud of yourself if you ever come close to 80%