Skip to main content

Server Provisioning Overview

A plain-language description of what our ansible server provisioning tool does to a new Red Hat Enterprise Linux (RHEL) or Ubuntu server, and which Texas A&M Information Security Controls each step helps meet.

Summary​

Provisioning starts with a freshly installed, minimal operating system. In a single unattended run, it turns that system into a supported Academic Operations (AO) server: up to date, joined to university login, locked down, monitored, and recorded in our inventory. It runs after the Init Nautobot and Hostdoc and Checklist job, which creates the server's records before anything is installed.

Control IDs in brackets, such as AC-8, link to the matching entry in the Texas A&M Controls Catalog.

Before Any Changes Are Made​

  • Confirms the name is correct. Checks that the server name follows the AO naming standard and belongs to a valid department.
  • Confirms the owner. If a resource owner is named, checks that their NetID exists in university Active Directory.
  • Secures the administrator password first. Creates a new, unique root password and stores it in the team password manager (1Password) before making any change. That way the password can't be lost partway through.

What Happens to the Server​

Name and identity​

  • Sets the server's official name.
  • CM-8

Accurate time​

  • Sets the time zone to US Central and keeps the clock synchronized to the Technology Services campus time servers.
  • This keeps log timestamps trustworthy.
  • AU-8

Updates and standard software​

  • Registers the server with AO's Foreman service, which supplies tested operating system updates and software from AO-managed repositories. RHEL servers are also registered with Red Hat Insights.
  • Installs every available operating system update.
  • Installs our standard support tools.
  • Restarts the server if an update requires it.
  • SI-2, CM-1, SI-3

Who can log in​

  • Connects the server to university login (AUTH.TAMU.EDU), so people sign in with their NetID and no shared local accounts are needed.
  • Creates two Active Directory groups for the server: one for people who may log in and one for people who may administer it. If an owner is named, their NetID is added to the login group.
  • Only those groups, plus AO and college Linux administrators, can log in. Everyone else is denied.
  • Disabled university accounts can't log in.
  • AC-2, AC-3, IA-2, IA-4

Administrator rights​

  • Only the server's administrator group and the AO and college Linux administrators get administrator (sudo) rights. They must re-enter their password to use them.
  • Regular users get no administrator rights.
  • AC-6, AC-5

Remote access​

  • Allows remote access only through SSH, encrypted with strong, approved ciphers.
  • Shows the university's required warning banner before login. The banner cites the Acceptable Use SAP 29.01.03.M0.02.
  • Closes SSH connections that stop responding.
  • As the last step, turns off all root login over SSH.
  • AC-17, AC-8, SC-8, SC-13

Passwords and lockouts​

  • Requires local passwords to be at least 16 characters.
  • Locks an account for 15 minutes after 10 failed login attempts.
  • AC-2, IA-5, AC-7

Network protection​

  • Turns on the server's firewall. It blocks all incoming connections except SSH.
  • Automatically blocks, for one hour, any address that keeps failing to log in.
  • SC-7, SC-5, SI-3

Accountability​

  • Records a date and time with every command an administrator runs as root.
  • Blocks TikTok/ByteDance sites, as required by State of Texas directive.
  • AU-3

Required security agents​

These are the agents that Texas A&M's Required Security Agent Decision Workflow requires on servers:

  • Elastic Defend. Malware protection and endpoint detection, plus forwarding of system logs to the university's central security logging.
  • Tenable Nessus. Regular vulnerability scanning, run by the university security team. Provisioning always places the server in the private (campus) scanning group. A server that will be reachable from the internet is moved to the public group afterward, with separate tooling.

AO also installs:

  • Zabbix. Monitors the server's health, availability, and compliance settings, and alerts our team to problems. If an owner is named, they get a read-only view of their server.

Stability under heavy use​

  • Keeps user programs, together, from using all of the server's memory and CPU.
  • Protects the security agents and login services, so they keep running even when the server is under heavy load.
  • SC-5, SC-39

Optional, depending on the server​

  • Network storage. Prepares the server to connect to campus network file shares.
  • Owner access to home folders. If an owner is named, gives them access to the home folders on the server. This lets them manage data their group stores there. AC-3
  • GPU support. If the server has an NVIDIA GPU, installs the graphics driver and CUDA toolkit.

Records and documentation​

  • Records the server in our inventory (Nautobot): its owner, department, provision date, and an Active status.
  • Updates the server's host documentation and onboarding checklist, and logs the related ticket numbers.
  • Adds the server to the automation platform's inventory, so ongoing maintenance and compliance jobs can reach it.
  • CM-8, CM-2, CM-3

Final hardening​

  • Restarts the server so every change takes effect.
  • Sets the new root password from the password manager.
  • Removes the default and installer accounts that come with the operating system (for example, ubuntu, rhel, and temporary setup accounts).
  • Turns off root login over SSH.
  • CM-1 (implementation 4), AC-2, IA-5

What Provisioning Does Not Do​

  • No backups. It does not back up the server or its data.
  • No research or application software. Software beyond the standard support tools is installed separately.
  • No data classification. The resource owner is still responsible for classifying the data on the server (see Data Classification). Some controls are stricter for Confidential (DC-5) or Critical (DC-6) data.
  • No automatic or unattended patching. Provisioning installs updates once, at build time. After that, the server is patched by the Monthly Maintenance - Linux AAP workflows, which run on the third Thursday of every month. Critical patches and urgent vulnerabilities are applied between cycles, as needed, by an administrator using the AAP CVE tools. The operating system's own automatic updates are turned off on purpose, so patches are tested and rolled out on a set schedule.
  • No exceptions. If a requirement can't be met, the owner must request an exception under SAP 29.01.03.M0.03.

References​

University policy and controls: