Forge Home

Modules

Puppet

Resources

PuppetEcosystemPuppet CommunityUpdates

windows_account_names

Custom fact that shows the name of the Administrator and Guest account.
Project URLRSS FeedReport issues

7,501 downloads

110 latest version

5.0 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 3.0.0 (latest)
  • 2.0.0
  • 1.0.2
  • 1.0.1
  • 0.1.0
released Apr 24th 2024
This version is compatible with:
  • Puppet Enterprise 2023.8.x, 2023.7.x, 2023.6.x, 2023.5.x, 2023.4.x, 2023.3.x, 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x
  • Puppet >= 7.0.0 < 9.0.0
  • Windows

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'nate-windows_account_names', '3.0.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add nate-windows_account_names
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install nate-windows_account_names --version 3.0.0

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download
Tags: fact, accounts, custom-facts, local-accounts, administrator

Documentation

nate/windows_account_names — version 3.0.0 Apr 24th 2024

Puppet Forge Build Status

Windows Accounts Fact

This Puppet module adds a custom fact called windows_accounts that shows the current name of the Administrator and Guest users on Windows.

This is useful for those that change or randomize these built-in accounts then need to know what the name is. Or, when you need to know what the current name is to trigger the renaming.

For example, this shows that we've renamed the Administrator account to Kermit on this machine:

ps> facter -p windows_accounts

{
  Administrator => 'Kermit',
  Guest => 'Guest'
}

Example 1

Say that we want to rename the Administrator account to abcdefg, we could use this fact to check if we need to change it:

# Save the current Administrator account name to a shorter variable.
$current_admin = $facts['windows_accounts']['Administrator']

if $current_admin != 'abcdefg' {
  exec { 'Rename Administrator':
    command  => "$(Get-WMIObject Win32_UserAccount -Filter 'Name=\"${current_admin}\"').Rename('abcdefg')",
    provider => powershell,
  }
}

Note that this is a bit of a contrived example as it'd probably be better to use an unless attribute with some PowerShell to make the exec idempotent.

Example 2

Say that we wanted to query PuppetDB for the name of the Administrator account on all of our nodes.

ps> puppet query 'fact_contents[certname,value] { path ~> ["windows_accounts", "Administrator"] }'
[
  {
    "certname": "win-appx-web.corp.net",
    "value": "Administrator"
  },
  {
    "certname": "win-appx-db.corp.net",
    "value": "xadmin"
  }
]

We can see that the win-appx-db node's administrator account is called xadmin.

How this works

Windows uses well-known SID's to identify its built-in accounts: http://support.microsoft.com/kb/243330

This fact enumerates all local users and looks for the SID's that match the pattern for the Administrator and Guest accounts.

Account SID Pattern
Administrator /^S-1-5-21.*-500$/
Guest /^S-1-5-21.*-501$/

Contributing and Development

Pull requests are always welcomed!

This module uses the Puppet Development Kit for validation. All pull requests must pass the GitHub Actions checks before they can be merged.

For local development, here's the workflow I use and what I recommend you use as well:

  1. Create a feature branch.
  2. Make your changes.
  3. Update any docs or README's if user-facing things change.
  4. Run: pdk validate
  5. Push up your branch to your fork and make a Pull Request.