Requesting Administrative Access for Your Customers

On this page:

Disclaimer

The purpose of this document is to support compliance with the UB Minimum Security Standards for Desktops, Laptops, Mobile, and Other Endpoint Devices, section 2.7 Limit Administrative Account Privileges.

Each request for administrative privileges reflects a unique set of circumstances including, but not limited to:

  1. Classification of data available to the individual and/or classification of data on the device or machine
  2. Compensating controls
  3. Research, business, or operational purpose
  4. Device or machine specifications

Therefore, this document should be used as a guideline. It does not constitute official university policy.

Requests for administrative privileges that are likely to be approved

  • Old software that requires administrative privileges, especially found in programs that interface with an external device. In such cases we recommend running with a local admin account and/or with the computer off the network, if possible
  • Non-commonly installed software, or software required for research/teaching
  • Admin privs for interactive software development where researchers or companies they are working with are developing and installing new versions of software in system directories as part of their work
  • Admin privs for systems used for teaching students in how to install operating systems, install software, or system administration tasks
  • Software such as Symantec's real-time virus scanning might need to be disabled on systems doing real-time data acquisition due to interfering with timing
  • Automated patch management may need to be deferred to a manual process on systems where long-running tasks should not be interrupted by unexpected reboots after patching
  • A piece of hardware attached to a computer where the software/hardware need full administrative rights to work properly
  • Traveling to do research/field work (temporary admin rights can be given, removed when they return)
  • Traveling to a conference (temporary admin rights can be given, removed when they return)
  • Doing real-time research/teaching that requires software to be run as admin - for example, teaching an IT security course that is using penetration testing software
  • Some custom programming and testing of programs may need administrative rights

Using file/directory ownership or group permissions instead

People can sometimes update add-ons to software through creative use of file and directory ownership and group permissions. Examples include:

  • Installing LaTeX stylesheets by giving write access to the stylesheet directory to the people who need to use it
  • Installing add-on modules for languages such as Python or Perl by either granting write privileges to the directories where they are installed, or by educating them in how to install them in their personal spaces if these modules do not need to be shared by multiple people who use the system

Related documents

Still need help?

Contact the UBIT Help Center.