Khalil, this is an OVERVIEW and not intended at this time to be detailed. It will start you thinking about the problem perhaps in a different way than you seemed to be thinking before.
In MS Windows, you have several ways of logging in but they are not always equally secure. That means that using the user name isn't always the right answer even if you think that it is.
If you have a domain-based network in your organization, you log in to the domain using credentials that are harder to fake than if you have a simple stand-alone system that isn't based on domain-level access.
If your user's login name for the domain isn't what you wanted, then your NEXT issue is to determine whether the user must login using a two-part challenge - the username and password challenge for example. You can go through tons of iterations of this process, but eventually you must pick something as the "real" username and go with that. (This is why Uncle Gizmo was hitting so hard on the username.)
When your user uses a login name, there are ways to query the computer for that name involving the Environ function, which lets you look up the computer and user login name.
Next question: Where do you store this name - or any name - that is to be associated with the user for the session? Here is where life gets extremely complicated. Depending on which version of Access you are running, security can become a nasty problem because the older Access security modules based on the MDAC library are no longer in use. Which means if you want to protect your data from what an arbitrary user can do, you can NEVER EVER let the user see tables, queries, or other items in the various navigation panes.
This implies a switchboard or other similar type of opening form that hides everything for you and NEVER closes until the user clicks some sort of EXIT button that causes the application to close. If that is the way you handle it, then you have immediate access to VBA code on the switchboard form's ".FormOpen" event. That is where you can test the Environ function to get information about your environment. Online searches for MS Office and the Environ function should be helpful here.
As to where you store it, it is up to you. For my system, I took the approach of creating a general module dedicated to security functions and subroutines in which I added public variables in the module's declaration area. As long as the switchboard is open, your general modules should stay defined - provided that you are careful with trap handling. A failed trap handler might force you to do a RESET (from the toolbar or a debug dialog box), which would be very detrimental to keeping variables intact.
If you were going to demand a different username than the domain name, the code of the .FormOpen routine is a place where you could fire off an Input Box and put calls to whatever you were going to use to validate that password. (Note that the input box can be told to not echo the input or to echo the input as the * character in case you were using passwords.)
I'd suggest looking into encryption and variations on the Purdy algorithms - which you can lookup online using any intelligent web browser or search engine - because if you are going through the trouble of using some other username than the name used to get into the computer, you are setting yourself up for enhanced security requirements.
This should be enough to get you thinking about the process along the lines that apply to MS Access 2007 and later versions. If you have thought about this already, I'm sorry to have wasted your time - but your comments did not suggest that you had thought about it in this level of detail.
