Baseline group policies for a government agency

A minimum GPO profile must produce a verifiable result on every workstation, not merely create the appearance of security. For an ordinary government workstation, I include automatic locking, managed local administration, removable media controls, mandatory updates, and advanced auditing with enough log capacity. If even one of these controls exists only in a policy document, an inspector will find the gap between the document and the actual configuration.

This set does not replace a threat model, antivirus protection, a firewall, backups, or application control. It sets the lower boundary for domain joined Windows computers: clear settings, narrow exceptions, a pilot rollout, and evidence that the controls apply. Kazakhstan's Unified Requirements for ICT and Information Security provide the binding general context, but each organization must set a specific timeout and patch deadline in its internal documents, taking account of the system class, the room's access regime, and the update process.

The minimum should fit in one verifiable profile

Describe the baseline in one short profile where every control has a value, a scope, an owner, and expected evidence. This works better than a long list of ownerless settings: the engineer knows what to deploy, the security team knows what to test, and the process owner can see where an exception is needed.

• Session lock: 10 minutes of inactivity followed by mandatory sign-in. Evidence consists of gpresult, the effective timeout, and a lock test.
• Local administrators: the employee is not in Administrators, and Windows LAPS manages the built-in account password. Show the group membership, LAPS policy, and successful processing event.
• Removable media: writing is denied by default, while reading is allowed only under an approved process. Test the resultant policy with an allowed and a blocked device.
• Updates: automatic installation, a pilot ring, and a numeric deadline for quality updates. The report must include the latest patch date and client status.
• Audit: selected success and failure subcategories, a larger Security log, and centralized collection. Confirm the settings with auditpol, log properties, and events on the collector.

The profile needs a version. Record its approval date, owner, Windows scope, and the change number that put it into effect. If support staff cannot connect a computer to a specific version, comparison with the baseline becomes guesswork. The version also matters after administrative templates change, when an old setting name may disappear from the new editor even though clients still receive its registry value.

Do not edit Default Domain Policy for convenience. Reserve it for a small number of domain level settings, mainly account policy, and keep the workstation profile in separate named GPOs. A backup or rollback then affects workstations and nothing else. This also prevents removable media or audit settings from accidentally reaching domain controllers, which have different requirements and load limits.

Assign owners to the processes as well as the document. The security team approves the control and accepts risk, the Active Directory team delivers the GPO, support manages approved privilege elevation, and the update team owns approvals and deadlines. In a small organization one person may fill several roles, but the profile must still state the duties. Otherwise, after a failure everyone points to a green setting in their own console while the computer remains unpatched.

Ten minutes is not a magic number. A public reception desk or shared office may need a shorter interval, while a controlled technical room may justify another value. The approved value must match in the policy, the internal standard, and the inspection record.

Do not add dozens of settings to the baseline merely because a security template contains them. Every extra setting expands the failure surface and makes diagnosis harder. Separate GPOs for Microsoft Defender, the firewall, BitLocker, the browser, and application control are necessary, but their life cycles should not be hidden inside one monolith.

The screen must lock without user action

A workstation must lock its active session after the approved period with no input. A reminder asking users to press Win+L is useful, but it is not a technical control and cannot produce a repeatable result.

The main setting is at Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Machine inactivity limit. The value is in seconds, so enter 600 for ten minutes. Microsoft documents a range from 0 through 599940 seconds and states that zero disables the control. After changing the setting, schedule a restart of the pilot computers and perform a real test instead of stopping at the GPO editor.

On a mixed fleet I also enforce the user screen saver settings: enable the screen saver, protect it with a password, and use the same timeout. This removes differences between older builds and user profiles. The computer inactivity policy remains the source of truth because a user cannot bypass it as easily by changing personalization.

The test is simple. Sign in with an ordinary domain account, leave the computer without input, and record when the lock screen appears. Then confirm that moving the mouse does not reveal the desktop without authentication. Test videoconference rooms, presentation computers, medical consoles, and any other scenario where a display timeout can interrupt work. Give them a separate group and GPO instead of lengthening the timeout across the agency.

A typical failure looks harmless: the administrator enables Enable screen saver but leaves Password protect the screen saver undefined. Some profiles show an image and return to the session when the mouse moves. The report shows an applied policy, yet access control does not work. Test the whole behavior.

Remove the shared local administrator password

An ordinary employee must not belong to the local Administrators group, and the local administrative account must not share one password across the fleet. These conditions solve different problems: the first limits the user's daily actions, while the second prevents one exposed secret from opening neighboring computers.

Set local group membership through Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups or through Local Users and Groups in Group Policy Preferences. I prefer an explicitly defined support group and a separate emergency procedure. Do not add employee accounts through requests that have no expiry date. A temporary exception soon becomes a permanent route for installing any software.

Use Windows LAPS for passwords. Microsoft documentation says that the feature automatically manages the local administrator password and backs it up to Windows Server Active Directory or Microsoft Entra ID. In a domain environment the settings are under Computer Configuration > Policies > Administrative Templates > System > LAPS. To store passwords in local AD, set BackupDirectory=2, define password age and length, restrict read access to a dedicated support group, and enable password encryption when the domain meets the feature's requirements. The default length is 14 characters, but the internal standard may require more.

Do not specify the built-in account name unless you need to. Windows identifies it by its well-known RID even after someone renames it. If you choose a separate local account, arrange for its creation first because LAPS policy does not create that account. I have seen this small detail produce a completely green GPO project with no password actually under management.

After deployment, verify three facts: the computer has an active LAPS policy, the password reached the directory, and only approved roles can read it. Then retrieve the password with a support account, perform one authorized sign-in, and confirm that the configured post-authentication action changes the password within the specified period. A shared emergency password in a spreadsheet, even inside a restricted folder, is not a substitute for LAPS.

Media policy starts with separate read and write decisions

You cannot reduce removable media control to one Deny all classes switch. The organization first decides who needs read access, who needs write access, which media it accepts, and how files are inspected. Without those decisions, a hard ban creates workarounds while a soft ban leaves the exfiltration route open.

A safe baseline for most workstations denies writing to removable disks. The path is Computer Configuration > Policies > Administrative Templates > System > Removable Storage Access > Removable Disks: Deny write access. If the job does not require incoming data from external media, enable the read denial too. Apply All Removable Storage classes: Deny all access only to groups that need no exceptions because it has broader effects.

Where writing is approved, requiring protected media makes more sense than allowing every USB disk. The BitLocker policy Deny write access to removable drives not protected by BitLocker separates an encrypted corporate drive from a random flash drive. It does not inspect file content or replace antivirus scanning, DLP, or a media issue register.

Assign permissions to computer groups rather than individual users when the process belongs to a fixed location, such as an incoming correspondence station. The exception scope then remains visible. A particular specialist's mobile workstation may need a user group, but the request must record its owner, expiry, and justification.

Test at least four operations: reading an ordinary drive, writing to it, writing to an approved encrypted drive, and connecting a phone in file transfer mode. Windows uses different device classes, so a successful USB drive block does not prove that every route is closed. Enable PnP auditing: event 6416 helps reveal an external device connection. Removable storage access auditing generates events only with the appropriate subcategory and objects, so confirm in advance which events actually reach your collector.

Updates need a deadline and deployment rings

A policy that says Automatically download without a maximum deadline does not ensure timely patching. Users can postpone restarts, laptops can miss the internal server for weeks, and a workstation in the wrong WSUS group may receive no approvals at all.

Choose one managed source. With WSUS, set Specify intranet Microsoft update service location, enter the detection service and statistics server addresses, and enable Configure Automatic Updates. Microsoft documentation warns separately that blocking connections to Windows Update internet locations works only with an internal service and can affect Microsoft Store and Delivery Optimization. Do not enable it as a universal hardening measure without testing dependencies.

For Windows Update client policies, define deadlines for quality and feature updates, a grace period, and restart behavior. Microsoft recommends automatic download and installation, default notifications, and deadlines instead of a large collection of conflicting user-interface settings. That advice is sound: ten old restart policies often produce a less predictable result than a few current ones.

Split the fleet into at least two rings. The pilot should include different computer models, typical peripherals, and owners of important applications. After a successful observation period, the main group receives the update. Put a number on the time between rings and the maximum installation period in the internal standard. Words such as promptly and timely cannot be audited.

The report must show device state, not merely that a GPO was assigned: build number, date of the latest quality update, pending restart, scan source, and latest error code. Give laptops an update path outside the agency network or require a defined connection window. Otherwise the policy exists while remote computers remain a month behind.

Do not approve updates for the whole fleet at once to produce an attractive compliance percentage. The approach is popular because the report turns green quickly. It is wrong because one incompatible driver can stop a department, after which administrators disable updates altogether. A small but representative pilot ring preserves deployment speed and a route back.

Logging must answer specific questions

A baseline audit must let you establish who signed in, who received elevated rights, which process started, who changed policy, and which external device connected. Enabling every subcategory for both success and failure is easier, but a stream of low-use events soon pushes out the records you need.

Use Advanced Audit Policy Configuration at Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration. Workstations usually need logon and logoff, special logon, account management, audit policy change, process creation, PnP activity, system integrity, and log clearing. Enable file access only for objects with a configured SACL, or expected and actual events will differ.

Microsoft associates process creation with event 4688, special logon with 4672, PnP device connection with 6416, and Security log clearing with 1102. These identifiers are useful acceptance tests. They do not prove a violation on their own: event 4672 also appears during legitimate administrative work. Meaning comes from correlating the user, computer, time, and approved request.

Enable Audit: Force audit policy subcategory settings so that advanced policy takes precedence over legacy categories. Then set log sizes. For Security on an ordinary workstation, start at 256 MB and measure the actual fill rate during the pilot; noisier roles need more. Do not choose Do not overwrite events without a regular archive process. A full log can stop recording new events and deprive you of the exact data needed after an incident.

The local log must not be the only copy. Configure Windows Event Forwarding or the organization's central collection system, then check delivery delay and access permissions. Kazakhstan's Unified Requirements define event logging as recording information about events that occur in an informatization object, but a log file alone does not make the control work. You need retention, time synchronization, search, and an owner who reviews the results.

This short acceptance sequence works on a pilot computer. The commands do not change the configuration:

gpresult /scope computer /h C:\Temp\gpo.html
auditpol /get /category:*
Get-LocalGroupMember -Group Administrators
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688,4672,1102} -MaxEvents 20 |
  Select-Object TimeCreated, Id, ProviderName, Message

The first command creates an HTML report of resultant GPOs. auditpol lists subcategories and their Success, Failure, or No Auditing status. The third command shows actual local administrator membership. The last returns the time, identifier, source, and message for recent events, so an inspector sees data from the endpoint rather than a snapshot of the editor.

Separate the baseline, roles, and exceptions

One baseline GPO should apply to every managed workstation, while role GPOs should only tighten or justifiably change particular settings. This arrangement makes precedence visible and keeps diagnosis from becoming an excavation of inheritance.

Create a separate OU for pilot workstations or use a carefully controlled security group. Do not filter the baseline through dozens of groups: a year later nobody will be able to prove which computers dropped out of scope. Link the GPO to the workstation OU, retain read permission for Authenticated Users, and use application filtering only where it is genuinely needed.

A practical structure looks like this:

1. WS-BASE-Security contains the lock, local rights, and audit foundation.
2. WS-BASE-Updates contains the source, ring, and update deadlines.
3. WS-BASE-Removable denies writing or all access according to the baseline decision.
4. WS-ROLE-Removable-Approved gives a narrow exception to approved workstations.
5. WS-PILOT-* receives changes before the main OU.

Do not use Enforced and inheritance blocking to fix an order you do not understand. First inspect Group Policy Results, link order, and WMI filters. An enforced link is rarely appropriate, and its side effects tend to appear during the next project.

Every exception needs an owner, justification, scope, compensating control, and review date. An exception with no expiry silently changes the baseline while avoiding formal approval. An automatic report of exception-group membership is more useful than an annual manual check because it reveals new and expired entries before an inspection.

Deployment passes through a GPO backup, a pilot, event checks, and scope expansion. Test sign-in and sign-out, printing, specialist software, smart cards, digital signatures, and remote support as applicable to users. Test rollback too: a backup that nobody has restored in a lab remains an assumption.

An assigned policy and a working control are different things

GPMC shows the administrator's intent, while workstation inspection must show the resultant state. Between them sit the link scope, security filtering, inheritance, SYSVOL replication, client processing, ADMX version, and local conflicts.

Run a policy update on the selected computer and save the result:

gpupdate /force
gpresult /r /scope computer
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v InactivityTimeoutSecs
wevtutil gl Security

In a normal result, gpupdate reports successful computer policy refresh, gpresult lists applied GPOs, reg query shows InactivityTimeoutSecs as a REG_DWORD with your value, and wevtutil gl Security returns maxSize, retention, and autoBackup. Do not paste expected output into the acceptance record in advance. Attach output from a particular computer with its name, timestamp, and policy version.

Then perform functional tests: wait for the lock, try to write a file to blocked media, request local elevation as an ordinary user, start a test process and find event 4688, and confirm installation of an approved update in the pilot. Successful tests prove the control more effectively than screenshots of five GPMC windows.

If a setting did not apply, check the GPO scope and GroupPolicy processing event first, then domain controller access, replication, and conflicting policy. Do not start by editing the workstation registry manually. That hides the cause, disappears at the next refresh, and destroys repeatability.

GSE can supply workstations and integrate software infrastructure around a government organization's requirements, but the information-system owner must still approve the profile and exception process. A hardware manufacturer cannot decide for the customer who may use removable media or how many minutes an open session is acceptable.

An inspector needs an evidence package, not a GPO screenshot

Readiness for inspection requires a connected chain: an approved requirement, GPO setting, application scope, resultant endpoint configuration, event or test, and exception record. If one element is missing, the inspector cannot establish whether the measure works across the declared fleet.

For each baseline version, assemble a profile document with its owner and approval date, a GPO export or backup, linked OU list, filtering groups, pilot record, a gpresult sample, update report, proof of centralized event receipt, and exception register. Put the profile version in the backup name and change record. Keep editor screenshots as supporting material because they do not show inheritance or endpoint state.

Sample by role instead of choosing five identical computers at random. Include a fixed employee workstation, a laptop, a reception station, a computer with approved media, and a workstation with specialist software. If the organization claims a common baseline, approved role policies must explain the differences between these systems.

Once a quarter or after a significant change, compare actual values with the baseline. The check should find missing computers, an incorrect timeout, an extra local administrator, an overdue update, permitted removable-media writing, and a silent event source. Set the threshold and frequency in the internal standard, then send deviations to owners with a remediation date.

The minimum profile is not ready when someone clicks OK in GPMC. It is ready when a new domain workstation enters the correct OU, receives all five controls without manual configuration, appears in the reports, and leaves understandable evidence. Make that happen on a clean test computer, and the next inspection becomes an ordinary comparison rather than a search for excuses.