A Supply Chain Software Vendor Mirrors Hundreds of Entra ID Groups Into Files.com While Provisioning Just a Few Dozen Accounts

A European supply chain software vendor covers the path from demand planning and purchasing through warehousing to the point of sale for retail, logistics, and industrial companies. Much of that software runs installed in its customers' own environments, and the vendor does not just ship it. For hundreds of installed ERP and POS sites, support routinely means pulling a customer's own database backup into the vendor's environment for debugging and analysis.

That makes the vendor's file exchange platform the place where its customers' production data sits while the vendor works on it, held in-region to meet national data residency requirements. Which employee can reach which customer's data is a serious governance question. On the legacy exchange stack, that question was answered inside the file platform itself: accounts and permissions were administered in the platform's own settings, separate from the corporate directory that already defined exactly who belonged to which team.

A Directory With Hundreds of Groups and a File Platform That Ignored It

The vendor's Entra ID directory describes the company in detail, in hundreds of groups. The legacy file exchange knew none of it. Every grant and every revocation was a change made in the file platform, separately from the directory. The vendor wanted the authoritative answer to who could reach a customer's data to live in the directory of record, with the file platform enforcing it. The requirement was simple: the directory and the file platform had to speak.

Every Group as a Permission, Almost No One as a User

The obvious fix, syncing the directory into the platform, collided with least privilege. Folder permissions only meant something company-wide if every group existed on the platform: a rule like "development can reach this folder" needed a development group to point at. But most members of those groups had no business holding an account on a platform full of customer databases. A team of twenty might contain five people who actually needed to touch it. Directory integrations ordinarily treated the two questions as one decision, where assigning a group to an application turned its members into users. The vendor needed the opposite: the whole group structure available for authorization, while a single deliberate decision controlled who received an account.

As the vendor retired its legacy exchange stack, it set the standard for whatever came next: access would be inherited from the directory, not administered on the platform. The replacement had to mirror every Entra ID group as a permission object, create accounts only for a controlled population, and take every grant and revocation from the directory. The vendor selected Files.com as its customer file exchange platform and led the deployment with identity: before the first customer workflow moved, folder access had to answer to Entra ID.

One Group for Provisioning, Every Other Group for Authorization

Files.com became the point where the directory's authority over file access is enforced. The company's group structure became the permission model without ever becoming the user list.

Files.com's SCIM provisioning supported scope filtering, and the vendor initially used it to split provisioning from authorization. One designated Entra ID group controlled provisioning: membership there, and only there, created a Files.com account. Nearly every group in the directory synced into Files.com purely as authorization objects, with no accounts riding along. Folder permissions were assigned to those department groups, so a folder grant was a statement about a team, whether or not every member of that team existed on the platform. The initial identity architecture went from a standing start to production in about three months.

For the users who do exist, sign-in runs through Entra ID single sign-on, with per-user two-factor authentication and shortened session lifetimes. That posture fits a staff that regularly logs in from customer premises. The vendor later consolidated the design onto a single Files.com integration that reads users and group memberships from its directory over LDAP while Entra ID continues to handle authentication, with on-demand syncs keeping memberships current.

Access Granted in Entra ID, Enforced by Files.com

With that architecture in production, the vendor replaced platform-administered access with access inherited from the directory.

• Granting or revoking access is a group change in Entra ID. Nobody creates accounts or edits permissions by hand on the platform, and a person removed in the directory loses their Files.com access along with everything else.
• The account population stays deliberately small, a few dozen people on a platform holding customer production databases, while every department in the company remains available as a permission boundary.

The compounding result is that the model maintains itself. A new team or a reorganization arrives from the directory on the next sync, and extending governance to it means granting a folder to a group that is already there.

Governed by the Directory

Today, the answer to who at the vendor can reach a customer's data is the same as the answer to what team they are on. It used to live in a file platform's own settings, administered separately from the directory. Now Files.com enforces what Entra ID declares, and the vendor's IT team governs file access by maintaining the directory, which it was doing anyway. The lesson in the vendor's architecture is that directory-governed file exchange never required provisioning the directory. Mirror every group for authorization, and let one group decide who exists at all.