OnCrypt Enterprise

Problem

OnCrypt Enterprise is the on-premises edition of OnCrypt for companies. A Windows server application connects to the company’s Active Directory. Each employee’s PC runs a client app, and people log in with smart cards. Two needs were open:

• Approvals. Customer records created or edited from the client went live without any review or audit trail.
• Sharing outside the licence. Employees could share encrypted files only with licensed users, but companies also needed to share with other staff in their directory.

My role

I joined this codebase in June 2026 with no knowledge of how users flow from Active Directory into the app. In my first week I cleared a batch of nine QA bugs while learning the code. After that, I built most of two features end to end, from the database tables through the Web API to the WinForms screens:

• the customer approval workflow
• non-license users, so employees can share files with staff who have no licence

I also split the stories into sub-tasks and worked alongside a colleague’s parallel branch.

How I built it

• Customer approvals. A customer created by an admin on the server is approved straight away. One created from the client starts as pending, and an edit from the client becomes an edit approval request. I added the request type by extending the existing approval-status values instead of adding a database column, so no schema change was needed. Every step goes to the audit log, which has filters.
• Choosing eligible users. A list of Active Directory users who are not in the licensed group and not already app users. It’s built as an LDAP query and checked against the server’s user list.
• Creating them safely. A licensed user must authenticate with a smart card first. The new user starts as pending and becomes active or locked later, shown with colour-coded statuses.
• Sharing and taking access back. File-share screens, plus a maintenance backend with three new Web API routes: list shared files, list recipients, and revoke access. A revoke needs a smart card, is a soft delete, and is written to a history log.
• Audit logs everywhere. Create, unlock, share and revoke all write the same standard activity log as the rest of the product, on both the client and the server.
• Two databases. SQL Server on the server and SQL Server Compact on the client, each with an Entity Framework 6 model. Every new table had to exist in both.
• Web portal. A sliding profile panel in the .NET 8 Blazor portal that shows the user’s Active Directory details without leaving the page.

Challenges

“Why does the list show 1,006 users?”

My first eligible-users list showed the whole directory. The configured “licensed users” group had been set to the default domain group, which never appears in a user’s group list, so the filter excluded nobody. Also, the client’s local database held only 3 app users, because the full list lives on the server. I rebuilt the filter as an LDAP query that excludes real members of the licensed group, checked against the server’s user list.

The portal broke after publishing

After publishing, the Blazor portal’s login page returned an HTTP 400 error. It looked like a login bug, but the page wasn’t interactive at all. The publish step had created an empty compressed copy of the largest framework file, so the browser’s integrity check failed and the WebAssembly app never started. I added a build step that removes empty compressed files after every publish, so this can’t happen again.

Error messages that pointed the wrong way

The client showed messages like “check the network path” when the network was fine. The real errors were in the web service’s IIS logs: a column name in the EF model that no longer matched the database, and a configuration that the service caches at start-up. I fixed each cause and wrote notes for the team: check the IIS logs first, and recycle the app pool after configuration changes.

A route that compiled but would have failed

A customer endpoint’s route didn’t match the address the client posts to. It compiled cleanly, but would have returned “not found” at run time. In this codebase, four places must agree on a route, and the compiler checks only one pair. Checking all four is now part of my routine.

Result

• Customer changes from the client are now reviewed before they go live, and every approval is in the audit trail.
• Companies can share encrypted files with staff who have no licence, and take that access back, with a smart card required for each sensitive step.
• The eligible-users list shows only the people who should be offered.
• The publishing problem is fixed for good by a build step.