Why is a shared local administrator password so dangerous?

Because one leaked password becomes access to all machines. An attacker doesn’t need to break into each device individually: they reuse the same credentials and get the same rights everywhere. Responsibility also disappears: when many people use a single account, it’s hard to quickly identify who changed settings or turned off protections.

Where should I start if I need to remove local admin rights from users without breaking work?

Start with an inventory: who is currently in local Administrators on workstations and where those rights are actually needed. You will usually find accounts granted "just in case." Then group devices by risk and criticality so you don’t apply the same restrictions to everything at once and disrupt work.

Which to choose: classic Microsoft LAPS or Windows LAPS?

If you have modern Windows versions and plan current policies, Windows LAPS is usually the better choice because it fits newer Windows mechanisms. Classic Microsoft LAPS is common in established Active Directory environments and can be convenient when you want to avoid bigger changes. The name matters less than the outcome: a unique password per PC and automatic rotation.

Where should local administrator passwords be stored after LAPS deployment?

Best practice is centralized storage with clear read-rights. That way passwords aren’t kept in chats, notes or files and don’t depend on one administrator’s memory. Decide in advance who may view a password and ensure access is logged so every retrieval can be audited.

Who should be allowed to view LAPS passwords?

Give read rights only to those who actually support specific PCs, and limit by scope. If "all admins" can view any password, you’ve just replaced a shared password with a shared ability to read it. Also enforce: view the password only during the work window and don’t save it outside the management system.

How often should the local admin password be changed and what to do if a leak is suspected?

Set an expiry and rotation policy so that a stolen password quickly becomes useless. For incidents, have a scenario to force a password reset instead of waiting for scheduled rotation. A practical rule: treat the password as "consumed" after the work and update it immediately or at the next scheduled rotation.

What about laptops and PCs that are often offline or rarely connect?

For devices that rarely connect to the domain or management, plan a synchronization window so they can receive policies and update passwords. Otherwise you’ll get "stale" configurations and unpredictable support. Use a separate policy group and a rule for when such devices must connect to sync password rotation and logging.

How to install drivers and update software if users no longer have permanent admin rights?

Permanent admin rights usually create risks. Better to grant elevated rights temporarily for a specific task and for a clearly defined period so access disappears automatically. If requests repeat, standardize: package software for centralized deployment, publish an approved software list, or enable installations without admin rights where possible.

What should be logged so audits are useful and not just noise?

Focus on events that actually change the system: installations, elevation to admin (Run as admin, UAC), changes to local group membership, and security setting changes. That’s usually enough to investigate incidents without recording everything. Prefer short trigger-based reports answering "who, where, when, what" rather than huge dump files no one reads.

What mistakes are commonly made when moving away from shared passwords and deploying LAPS?

Common mistakes: leaving an old local admin account enabled with the same password across machines; granting broad read rights to LAPS so many people can view passwords; not recording the ticket, reason and time when a password was used. A simple test for self-check: can you perform a typical task without a shared password and then trace who did what via tickets and logs?

Controlling Local Administrators on Workstations: LAPS, Policies, Audit

Why a shared local admin password is a problem

A local administrator on a workstation is an account with rights to change system settings, install or remove software, install drivers and manage services. It's needed for rare but important tasks: servicing a workstation, connecting new hardware, or fixing a failure after an update.

Risk appears when the same local admin password is used across many computers. One leaked password becomes a key to the entire fleet. It can be seen by others, accidentally sent in a chat, saved in notes, or leaked through an infected machine. After that an attacker doesn’t need to "break" each device: they log in with the same password and get the same rights everywhere.

A shared password also blurs responsibility. When many people use one login, it’s hard to determine who installed software, changed settings or disabled protection. As a result the IT team spends time investigating incidents instead of routine support.

Often security is broken by routine requests: installing drivers (printers, scanners, tokens, specialized equipment), installing or updating software "for five minutes", changing network settings (proxy, certificates), or disabling protection for compatibility.

A reasonable control level looks like this: permanent admin rights only for those who need them by role; passwords aren't reused between PCs; access is granted for a limited time and by request; and elevated actions can be quickly reviewed.

Where to start: a quick plan without big projects

You don’t have to start a large project to tidy up local admin rights. First, understand where the risks are, then introduce changes in small steps so users aren’t blocked.

Start with an inventory: list groups and accounts that already have local admin rights on workstations. Mark exceptions separately: accounting with specialized software, engineers with permanent drivers, machines with medical or industrial software. Often rights were given "just in case," not because they were necessary.

Next step — segmentation. Don’t try to apply one mode for all. Office PCs, critical workstations and servers should be governed by different rules and rolled out at different speeds.

A practical sequence usually looks like this:

In 1–2 days: find where local admins exist and who uses them.
In 1 week: group devices (office, critical, servers) and assign owners.
In 1 week: approve rules — who gets access, for how long, for what reason, and who approves.
Choose tools for your environment: AD GPO or Entra ID (Intune) for policies, Microsoft LAPS for passwords, event logs for recording actions.
Roll out in phases: pilot on 20–50 PCs, then expand in waves with a clear rollback plan.

To avoid overloading IT, define a "minimum set": temporary access instead of permanent rights, a single request channel and a mandatory reason for access.

Example: a user needs a printer driver. They get admin access for 30 minutes, the task is completed, and rights are removed automatically. No manual removals and no shared passwords across all machines.

How LAPS fixes the local admin password issue

LAPS closes the main hole of a shared admin password: each PC receives a unique local admin password that is rotated automatically. This quickly removes the situation where one password works for all workstations.

There are two variants: classic Microsoft LAPS (the older solution) and Windows LAPS (built into modern Windows versions). The idea is the same — automated issuance and rotation of passwords. Windows LAPS supports more scenarios, integrates more tightly with Windows and usually fits modern security requirements more easily.

Passwords are stored centrally rather than "in an admin's head" or in Excel. In a domain environment they are written to the directory (usually Active Directory) and only those explicitly granted rights can read them. Important: LAPS does not "give passwords to everyone" — it helps narrow the circle of access and leaves an audit trail of retrievals.

Rotation works automatically: you set the lifetime, and at the next appropriate event the password is updated. This is more reliable than "change once a year" because it reduces the window when a stolen password is still valid.

Before enabling LAPS check a few things: Windows versions on PCs (and Windows LAPS support if you choose it), presence of a domain and managed policies, roles (who reads passwords, who changes settings), and whether support is ready to operate under the new scheme.

The result is visible quickly: the shared password stops being a "master key," each PC gets its own secret, and access issuance becomes a process instead of password-sharing in chats.

Access rights to LAPS: minimize the circle of those in the know

After deploying LAPS the key question is who can view passwords. If many admins can read them, you’ve simply replaced a shared password with a shared ability to read it.

Who should and shouldn’t see passwords

Reading rights should be given only to those who actually service particular workstations. Others should use a clear request process.

A simple division usually works:

Workstation admins: read LAPS passwords only for their assigned PCs or units.
Service desk: does not read passwords but raises and documents a request with justification.
InfoSec: does not receive passwords "just in case," but retains control and audit rights.
Domain admins: avoid using LAPS in day-to-day operations so they don’t become universal superadmins.

Technically this is done by delegating rights on OUs and creating separate security groups. Principle: one group — one clear scope of responsibility (for example, "accounting PC admins"), avoid universal groups like "IT-Admins-All."

How to know who accessed a password and when

Password reads must leave traces. Configure logging so you can quickly answer: who viewed the password, for which PC and when.

Also enforce the rule: LAPS passwords are not copied into chats, notes or files. A simple policy statement works: "view only during work, do not save or forward." Add a short procedure:

access granted by request or ticket with a reason;
work performed within a limited window;
record the result and close the ticket;
if a password is suspected leaked, trigger a reset;
treat violations as incidents.

Example: the service desk gets a request "install a printer driver." They do not ask for the password in chat but open a task for the workstation admin. The admin reads the LAPS password for that PC, completes the work and closes the ticket. Access remains targeted, not permanent.

Step-by-step LAPS configuration via policies

Local Administrators Audit

We will check where shared passwords, excessive rights and bypass local admin accounts remain.

Request an audit

LAPS is easier to enable through Group Policy: behavior is consistent across PCs and management doesn’t turn into manual bookkeeping.

Preparation

First decide which computers should receive LAPS. It’s simpler to start from a separate OU or device group so critical workstations aren’t affected.

Then create (or copy) a GPO for LAPS and enable key settings: manage local administrator password for target PCs, password length and complexity (per corporate policy), rotation interval (for example, every 14–30 days), password lifetime after issuance (to keep access temporary), and which local account is managed (built-in or service account).

After that verify the policy is applied (gpupdate, check results on a PC) and that the device actually writes the password where you plan to store it (usually in the directory).

Rights and pilot verification

Grant read access to passwords only to the minimal set of people who actually perform support. Separately assign who can forcibly reset the password — a stronger privilege.

Run a pilot on 10–20 PCs from different departments and check:

the password rotates on schedule and after issuance;
support can retrieve passwords, while unauthorized people cannot;
no software breaks because it previously depended on a shared local password.

When the pilot is stable, expand by department and formalize the process: who requests access, who issues it, and where the reason is recorded. LAPS then becomes routine.

Temporary access instead of permanent admin rights

Permanent local admin rights for users are often given with good intentions: to avoid blocking work. In practice this makes many actions risky and investigation difficult.

The working model is temporary admin. Rights are granted for a specific task and for a limited time (30 minutes, 2 hours, until end of day). This is a JIT (just-in-time) approach: access appears only when needed and disappears automatically.

Start with simple options: temporary membership in the local Administrators group with auto-removal, a privileged account for role-based work, remote help (IT completes the task without giving rights to the user), or elevation for a single action according to procedure.

To avoid manual chaos, tie access issuance to the service desk as a normal service. A request should answer two questions: why and for how long.

Minimum fields that help:

reason (what is being installed or configured and why admin rights are needed);
access time (start and duration);
device and user;
approval by manager or system owner (for sensitive tasks);
result (what was done, success or failure).

If the same employee frequently needs admin access, this signals a process issue, not a user issue. Typical remedies: standardize and publish software in a corporate catalog, enable centralized deployment, grant narrower rights to a specific tool, or define a role with documented tasks.

Audit of actions: what to log so it helps, not hinders

Audit is not for total surveillance but to quickly answer: who received elevated rights, what they did, and whether it was approved. This is especially important when moving from shared passwords to temporary rights.

Actions to record first

Start with events that actually change the system or increase risk:

software installation and removal (including MSI and silent installers);
program launches with elevated rights (Run as admin, UAC);
changes to local group membership (who was added or removed from Administrators);
changes to policies and security settings on a PC;
requests and use of administrative credentials when using Microsoft LAPS (important to see who requested a password and when).

In Windows rely on the Security and System logs, installer events (MsiInstaller) and PowerShell logging if allowed. You don’t need to memorize event IDs — agree in advance what is critical.

Local logs or centralized collection

With 10–20 workstations you can start with local logs and spot checks. With more devices or compliance requirements, centralized collection is easier: logs won’t disappear after a reinstall and are easier to filter.

To keep audit readable, produce short trigger-based reports rather than everything:

only events that elevate privileges or change configuration;
report fields: who, which PC, when, what action, result;
threshold rules (for example, 3 installations in an hour or adding to Administrators outside a work window);
periodic summaries of deviations, not all events.

Example: an accountant needs a plugin. You grant temporary admin access. The report shows one installation, one elevated run and automatic removal of rights. If there’s an extra installation or a policy change attempt, it’s visible immediately.

Common mistakes when abandoning shared passwords

Risk-Free LAPS Pilot

We will roll out LAPS on 20–50 PCs and validate the temporary access process.

Discuss the pilot

A frequent scenario: "we deployed LAPS, so shared passwords are gone," but the old local admin account remains active on all PCs and was simply forgotten. That creates another bypass instead of a single controlled path.

Another common mistake is making LAPS password read access too broad. If many IT staff can view any password, control becomes formal and leakage risk rises.

Typical pitfalls:

leaving a fallback local admin account active with the same password on all workstations;
granting LAPS read rights to a broad group without role separation;
retrieving a password without recording the ticket, reason and time;
weakening or disabling rotation for convenience;
skipping a pilot and deploying fleet-wide immediately.

Often the process fails, not the technology. For example, an accountant calls support, obtains a temporary password, installs "one more thing," and the trace is lost. A week later there’s instability and you can’t tell what changed.

Simple rules help: disable and remove old local admin accounts, limit LAPS read access to a minimal circle, require a ticket (who, why, which PC, for how long), and start with a pilot of 20–50 devices. This will reveal bottlenecks and avoid a flood of similar requests.

Short self-check checklist

Once a month go through checkpoints to ensure rules aren’t kept only "in people’s heads."

Check:

each workstation has a unique local admin password that rotates automatically and isn’t stored in shared notes;
it’s clear who can view passwords and why: group lists are minimal and role-based;
accesses and privilege issuances are logged: you can quickly answer who requested, when, why and on which device;
software installations and setting changes follow a standard procedure: request, approval, time-limited access (or execution by IT), then closure and short result record;
there is an incident plan: how to urgently revoke access, forcibly change local passwords (for example via LAPS), who to notify and what logs to collect.

Practical check: ask a support colleague to install a typical program on a test PC without permanent admin rights. If they need to hunt for a shared password, grant rights permanently, or cannot reconstruct actions, the process needs improvement.

Real-world example: installing software without permanent admin rights

Temporary Rights Instead of Permanent

We will organize temporary admin access by request with clear time and reason.

Implement JIT

Accounting urgently needs an update for reporting software. Previously a shared password known to a few made installation trivial. Now the shared password is gone, which is correct, but IT shouldn’t become a constant helpdesk.

Process:

the accountant files a short request (what, which PC, when) and attaches installer name or version;
IT verifies whether admin rights are needed and if so grants temporary access.

Typical steps:

IT confirms the request and sets a work window (e.g. 30 minutes);
via LAPS obtains the unique local admin password for that PC;
provides the password only for the window and records issuance in the ticket or log;
after installation the password is considered "consumed": LAPS rotates it per policy or immediately by command.

For basic audit it’s enough to see that an installation and an elevated run happened in the same window. That gives control without recording every click.

What a manager sees: one closed ticket, who approved it, how long it took, and confirmation the password was changed afterwards. If the same PC requests admin access again soon, it’s a sign of a recurring problem.

To reduce such requests, IT usually does three things: add common updates to scheduled deployment, publish an approved software list, and check which apps can be installed without admin rights (via user installers or centralized deployment).

Next steps: embed the process and reduce IT load

After removing the shared password, deploying LAPS and designing temporary access, you need to make this the normal working process. Otherwise in a few months people will quietly revert to "give permanent admin, it’s faster."

Start with a pilot in 1–2 departments, clear timelines and one IT owner. At the same time define roles: who reads LAPS passwords, who grants temporary access, who reviews logs.

Don’t keep rules only in people’s heads — document them in a short 1–2 page instruction:

who may request temporary access and for what reasons;
how long access is granted and how to extend it;
what counts as a violation (for example, installing software "in advance");
where to request urgent access;
who reviews logs and password accesses.

Regularity helps: a short monthly 30–60 minute check using the same scenario. Between checks respond only to clear incidents so control doesn’t obstruct work.

Monthly review: who requested LAPS passwords and when, whether there were unscheduled admin sessions and why, which requests repeat, and which PCs require standardization.

The most reliable way to reduce admin requests is to standardize workstations: a uniform software set, predictable updates, typical drivers and clear images.

If you need help implementing at the "hardware plus processes" level, GSE.kz (gse.kz) as a local PC manufacturer and system integrator can help build workstations and infrastructure for your environment so rules are followed in daily operations.