If you have Active Directory, you can test for membership in an Active Directory Group:

public bool IsInADGroup(string ADGroupName)
    {
        bool result = false;
        List<string> myGroups = new List<string>();

        using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, SystemInformation.UserDomainName))
        {
            using (PrincipalSearchResult<Principal> src = UserPrincipal.FindByIdentity(pc, SystemInformation.UserName).GetGroups(pc))
            {
                src.ToList().ForEach(sr => myGroups.Add(sr.SamAccountName));
            }
        }
        result = myGroups.Contains(ADGroupName);
        return result;
    }

The manager is right about the password getting out. Its not a matter of if, but when.

Since Active Directory isn’t an option for some users, you could create a signed text file with a list of windows login names that are allowed super user access. This assumes that people are not sharing computers or logins.

The user names would just go in an easily distributed text file that would be put in the application’s folder. The important part is to sign the list of user names. Keep it very simple. One user name per row and put the hash on the last line. Embed some sort of secret key in your program binary and hash it with the usernames. The secret key will prevent people from modifying the file and then calculating the hash themselves (which is probably far-fetched to start with).

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

This, of course, requires someone somewhere to act as the admin of the list of authorized users. The admin should have a program (written by you!) that generates the file and hash. If nothing else, it could just take an text file of user names and add the hash.

In the interest of being thorough, someone who has been revoked access could grab the copy of the file that still has their login name in it. Whenever they wanted access, they could just put their copy in place. Probably not something to worry about, though.

Since Active Directory is not an option, I would hash the current date. Use elements with the most entropy first (day of month) and those with least entropy last (year). If need be, add a domain-specific salt (a customer ID, company name, etc. since it is used outside your company). This should produce a very different password each day that is practically impossible for end users to guess, and it can be different for different companies that use the software.

This is essentially a chicken and egg problem since the software needs to be able to authenticate the user without phoning home. So make an egg with a really obscure cracking mechanism: while security through obscurity is not real security, this is the best you have given the parameters of your problem.

This is also better than placing a text file somewhere: that is no better than a static password because once the secret gets out, game over.

Use Access Control Lists.

The quick and dirty way to do this is to remove all permissions from the application directory (including read permission), then add these permissions for any users who are permitted to run the application. Of course, a user with permission could just as easily copy the application directory to a public location, but this is unlikely to happen accidentally, whereas password sharing can easily happen accidentally.

This assumes, of course, that the computers involved are secured (hopefully with active directory).

My preference is as @Dan suggested – use active directory. If this is not possible, then a password generator based on time can be useful. In a similar situation, (very distant past) one my company I worked for used 9999-MMDD. This did get out after a couple of years. If you threw in hhmm and mixed it up a bit you might get a year or two out of it before someone lets the cat out the bag.

You could always write a program that generates a password using a similar, but more complex strategy. Throw in the used name an machine name as well. You manager can run that program to get the current password for just that machine. Store some information in the file so its not valid if copied to another machine or if a different user is logged in. Its then up to you manager to keep the program secure and if the cat gets out, its his fault.

This scheme is considered weak and unreliable from a cyrpto perspective, but is adequate for the problem you have.