Within access there are several ways
first off currentuser() returns the userid of the current (Access) user, which is OK as long as everyone opens their instance of Access with their own user account
then environ("username") which should return the logon of the user on the network
then use the API calls' documented by Dev Ashish amongst others (google dev ashish api)
of the 3 the latter is more robust, less exposed to problems
currentuser only returns the userid that someone used to open the copy. if they haven't opened access with a logon then the user is admin. there is no security policy imnplemnted (ie more than one person could logon at the same time. you have to enforce policies to change passwords and password security yourself.
environ can be spoofed. it may actually be an API call under the bonnet (or hood for those speaking English as a foreign language) however it can be spoofed... Ive seen it done.
so for me use the API call to retrieve the network logon every time. Ive not done any security stuff from A2010 when the original Access concept of usergroups / userID's known as workgroup security was changed so Im not too certain how modern Access implements security. But What I used to do was:-
rely on the network policies for user logon / admin, always allow an Access app to start, but grab the network logon. use manual computer use policies and netrwrok administrtative tools to handle the actual security side (ie authentication, what resources they can or cant see. hide Access apps / files using network tools.
add the network logon to the access application workgroup security file (*.MDW), assigning to relevant usergroup(s)
when you want to authenticate a user request what permissions that user has from the security file and take appropriate action
you can add shortcuts to the desktop for that
I'd rather be riding on the Tiger 800 or the Norton