Access Database Security After Migrating from .mdb to .accdb

If your .mdb database used user-level security — or any code that relied on CurrentUser() — migration to .accdb will break it. Not in a noisy, obvious way. In the quiet way where everything appears to work until you notice your audit log shows "Admin" for every single action since the conversion, or you realize that password-protected objects are suddenly accessible to everyone.

Here's what actually changes in the .mdb-to-.accdb migration from a security standpoint, and what to do about each piece.

What Was Removed: User-Level Security

User-level security (ULS) was the way older Access databases controlled who could open the database, which tables they could read, which queries they could run, and what forms they could access. It worked through a separate workgroup file — a .mdw file — that stored users, groups, and permissions. The database file itself held references to those permissions; the actual definitions lived in the workgroup.

Microsoft removed user-level security entirely when they introduced the .accdb format in Access 2007. Their reasoning: ULS was widely misunderstood, frequently misconfigured, and provided weak protection by modern standards. The implementation was removed from ACE (the engine behind .accdb), not just deprecated.

When you convert an .mdb to .accdb:

• All user and group accounts from the workgroup file are discarded
• All object-level permissions (table, query, form) are stripped
• The workgroup file association is ignored going forward
• Everyone who can open the .accdb file has full access to everything in it

This is not a migration error — it's the intended behavior. Access simply doesn't have a user-level security system to migrate to.

The CurrentUser() Problem

CurrentUser() was tightly coupled to the ULS system. It returned the username of the person logged into the workgroup — the Access user identity, not the Windows identity. In a properly configured ULS setup, this was a meaningful value you could use for logging, audit trails, or conditional logic.

In .accdb, CurrentUser() still exists and still compiles without error. It just always returns "Admin". There's no error, no warning. Your code runs. Your logging table fills up with "Admin" for every record. You may not notice for weeks.

Replace CurrentUser() with Windows identity

The right replacement depends on your environment:

Environ("USERNAME") — simplest, works everywhere:

Dim currentUser As String
currentUser = Environ("USERNAME")

Returns the Windows login name (e.g., jsmith). No references needed. This is the right answer for most single-domain environments.

WScript.Network — for domain-aware environments:

Dim wsh As Object
Set wsh = CreateObject("WScript.Network")
Dim currentUser As String
currentUser = wsh.UserName  ' Returns login name
' wsh.UserDomain returns the domain name

Windows API — most reliable, especially on Citrix/RDS:

Private Declare PtrSafe Function GetUserNameA Lib "advapi32.dll" _
    (ByVal lpBuffer As String, nSize As Long) As Long

Function GetCurrentWindowsUser() As String
    Dim buffer As String * 255
    Dim length As Long
    length = 255
    If GetUserNameA(buffer, length) Then
        GetCurrentWindowsUser = Left(buffer, length - 1)
    End If
End Function

After migration, search your entire codebase for CurrentUser() and replace each instance. If you have existing log data with "Admin" records that date to after the migration, document when the break occurred so you can account for it in any compliance or audit review.

Database Password Encryption: What Changed

If your .mdb was protected with a database password (set via Tools → Security → Set Database Password), that protection does not transfer to .accdb in a compatible way. The underlying encryption algorithms are completely different:

Format	Password Algorithm	Strength
.mdb (Jet)	RC4-based obfuscation	Weak — many free tools can recover it
.accdb (ACE)	AES encryption (AES-256 in Access 2010+)	Strong — computationally infeasible to brute-force

During conversion, Access will prompt you to enter the existing .mdb password (to open the source file), and then ask if you want to set a new password for the .accdb. If you skip setting a new password, the .accdb will be unprotected. The old password does not carry over.

This is actually an improvement — you're moving from weak RC4 obfuscation to real AES encryption — but you need to actively set the new password during conversion. Don't assume the protection transferred automatically.

Object-Level Permissions: You're Starting Over

In .mdb with ULS, you could grant user "Sales Team" read access to the Customers table but deny write access, and deny the Orders table entirely. These permissions were granular and table/query/form-specific.

In .accdb, this doesn't exist. Your options for restricting what users can see and do are:

Option 1: Network/file system permissions

Control who can open the .accdb file at the file system level. Users who don't have Windows read access to the file can't open it. This is coarse-grained (everyone who can open it has full access) but simple and doesn't require application-level changes.

Option 2: Split front-end/back-end with restricted back-end access

Keep the data tables in a back-end .accdb on a share with restricted NTFS permissions. Front-end users connect through linked tables but never have direct file access. Combined with a startup macro or AutoExec that hides the navigation pane and disables shift-bypass, this provides reasonable access control.

Option 3: Implement a custom login form

Build a login form that checks the user against a Users table in your database, sets a global variable for the current user role, and shows/hides UI elements based on that role. This is fully application-controlled — it can be bypassed by someone with direct database access, but for most internal-use databases it's appropriate. Store passwords as SHA-256 hashes using the CryptHashData API.

Option 4: Move to a real multi-user architecture

If your .mdb ULS was providing meaningful per-user access control (not just a speed bump), Access probably isn't the right long-term solution. A web application backed by PostgreSQL or SQL Server gives you row-level security, proper authentication, and audit logging without the Access limitations.

Trust Center and Macro Security

The Trust Center settings that governed macro execution in .mdb carry forward in a limited way. What you may notice after converting:

• Trusted Locations still work — if the .accdb lives in a folder already marked as trusted, macros will run without prompts.
• Digital signatures transfer — if the .mdb VBA project was signed, the signature remains valid in .accdb (assuming the signing certificate is still trusted).
• Startup bypass (Shift key) — the Shift key bypass works in both formats. To disable it programmatically, set the AllowBypassKey property to False via code.

Migration Security Checklist

Before and after migrating a security-sensitive .mdb:

1. Audit CurrentUser() usage — search all modules for CurrentUser() and plan replacements
2. Document all ULS permissions — screenshot or export the workgroup file settings before conversion; you'll need this to recreate any access control logic
3. Set a new database password during conversion — don't skip this step if the .mdb was password-protected
4. Decide on the replacement security model — file system permissions, front-end/back-end split, custom login, or modernization
5. Test with a non-admin account — after conversion, open the .accdb as a standard user and verify that access control is working as intended
6. Audit existing log data — identify how far back the "Admin" logging problem goes and document it

The security changes in .mdb-to-.accdb migration are not subtle. They require deliberate decisions about how access control will work going forward. For many Access databases that were using ULS as a light-touch way to show different menus to different users, the custom login form approach is a reasonable like-for-like replacement. For databases where the ULS was providing real security boundaries, modernization is worth seriously considering.

← Back to all posts