IT workers fill a number of roles every day: user, admin, super-admin, and sometimes investigator. Each of these roles has different responsibilities and requires different rights on the systems involved. In order to practice good security and adhere to the principle of “least rights”, each of these roles should really use a different account. Let’s take a look at each of these roles and why they should each have a unique identity:
User
At the end of the day, in spite of being “smarter than the average bear” regarding technology, the IT worker is also a “normal” user. They log on to a primary workstation (or two), check e-mail, and message colleagues the same as anyone else. At Duke, this is done with what’s called a “person account”. This identity is the first that an employee is given at Duke and will follow them through their entire Duke career. Any other accounts an employee might have are considered “non-person accounts” and should either be tied to their person account or a Support Group of which they’re a member.
The User account is meant for doing personal work that affects only the account owner and their own device(s). Granting the User account additional (Admin) rights opens up the possibility that a personal action–intended to affect only the owner’s data or device(s)–has a wider effect than expected. An example of this would include searching for and deleting certain documents from a departmental directory on a file share only to find out that the action was done for the entire share and not just the one directory, inadvertently deleting files for other departments as well.
The User account is also the most frequently used and, as a consequence, the account most frequently compromised as a result of malware and phishing attacks. When an “elevated” User account is compromised, far more than the one individual’s data is potentially exposed.
Overall, it is much more secure to limit the User account to access only that which is necessary at an individual level.
Admin
As part of their responsibilities, almost all IT workers exercise some level of management over at least one other system that is used by at least one other person. Generally, this management is best performed via a tool of some sort. Patch management, software management, configuration management, etc., all have tools that can make the task much easier, whether it’s for managing one device or thousands. When operating at this level, the IT worker is no longer a “normal” user…they’re an administrative user, or “Admin”.
Access to actions performed on multiple devices used by multiple users should be limited to an Admin account. User accounts should not be granted the necessary rights to perform such actions.
Many IT workers–those without responsibility to directly manage other users’ devices or the tools that do so–will only need this one additional account.
Super-Admin
For all of the management tools mentioned above, someone needs to manage the tools themselves. Through the management of these tools, some IT workers have access to much more than just the devices for which they are responsible; they have access to everything. This is not to imply that they’re responsible for everything, but that they have to be very careful when using these tools lest they affect far more than they intended.
Management of these tools should be limited to a Super-Admin account. Generally, management of such a tool involves either configuration changes to the tool itself (requiring no access to managed devices) or the development and testing of content to be deployed by the tool (requiring access to only a few test devices). To prevent events like the accidental distribution of software or settings to every device in the infrastructure, the Super-Admin account should–while having greater access to the tool than other Admin accounts–have lesser access to devices managed by the tool.
It can also be very useful for those Super-Admins without direct device management responsibilities to have an additional limited Admin account in order to see the system and its options as other Admins do. In addition, some systems may be important or sensitive enough that they should have their own individual credentials for access, requiring some IT workers to have multiple Super-Admin accounts.
Investigator
Many IT workers–primarily those providing end-user support–are called to log on to systems that aren’t their own and/or are in an unknown state. When logging on to an end-user’s computer, it’s generally because there’s something wrong, possibly due to some form of malware. Just as “analog” investigators often wear gloves, goggles, or other gear to protect themselves from harm, having a separate account for logging on to devices in an unknown state can protect your other accounts from being exposed to malware on the unknown device.
As an alternative to an individual account, an Investigator account could also be a shared local administrator account. In addition to protecting the IT workers other accounts, the use of a local account also protects network resources that a network account would also have access to. Ideally, such an account would have a password that is unique to the device and changes on a regular basis via Microsoft’s LAPS or a similar solution.
Next Steps
So, how many accounts do you have? Chances are that, if you’re an IT worker at Duke and fulfill more than one of the roles mentioned above, the answer you gave is one or two accounts fewer than it should be. If this is the case, members of a Support Group can request a new “non-person” accounts at the Duke Sponsored Accounts page:
- Under “Non-person Accounts”, select the “Sponsor a Test or Service account” option.
- If you are a member of multiple Support Groups, you will be required to select one of these groups to be the initial Owner of this account. (If necessary, you can later change the owner to yourself for accounts that are for only your own use.)
- Under “Select Account Type”, select “Test” for accounts that will be used in the fashion mentioned above. “Service” accounts are generally not used in this way.
- Under “Select Non-person Account Preferences”, enter the appropriate information for this account. While you can be somewhat creative with the “First Name”, you’ll probably want to use your own “Last Name” to help with recognition.
- Under “Select Non-person Account Services”, select “NetID” and provide a NetID for the new account. This will ensure that you can use this account with just about any campus system (particularly those requiring MFA).
While you can generally use anything you like as the NetID for this account, most Duke IT workers have simply added an appropriate suffix to their own NetID. Examples of common suffixes include: “-admin”, “-ad”, “-sa” (for “system admin” or “super admin”), “-wks” (for “workstation”, used for “investigator” accounts), and departmental abbreviations (“-aas”, “-bio”, “-cdss”, “-div”, “-eng”, etc.). Whether you use a hyphen or an underscore is up to you (or your departmental policy), but you should be consistent (for your own memory’s sake).
- Also under “Select Non-person Account Services”, if personal network storage will also be required for this account, select “CIFS” as well.
- When all that is complete, select “Submit” and your request will be on its way!
If your new Non-person Account will require MFA (which it should, but that’s another article), you’ll need to take a few extra steps:
- Go to the Duke Multi-Factor Authentication page.
- To enable MFA for a Non-person Account using a device:
- Under “View Devices”, select the appropriate device.
- Add the Non-person Account to the field under “Advanced users”.
- Select “Continue” to save your changes.
- To enable MFA for a Non-person Account using a Yubikey:
- Under “Manage Devices” –> “Advanced options”, select your token.
- Add the Non-person Account to the field under “Update your hardware token”.
- Select “Submit” to save your changes.
The Hard Part
Unfortunately, creating the extra account(s) is the easy part. Now, it’s up to you to make sure the services you interact with are configured to use the proper accounts in the proper way. However, the added protection you’ll have by doing so is worth it in the long run for both yourself and for all of Duke. If you have any questions or difficulty with figuring out this part (which could be different for each service), please don’t hesitate to ask the Endpoint Management community for assistance by joining and sending a message to endpoints@duke.edu.