Windows: Fails to create sensu user

[dzeleski]

@jaxxstorm Issue found after resolving this issue: #569

Not getting that error after a restart but now its failing on either creating the sensu user, or if I disable manage user it cannot find the sensu user or use the built in administrator user.

With manage_user set to false:

Error: Could not find user Sensu
Error: /Stage[main]/Sensu::Package/File[C:/opt/sensu/conf.d]/owner: change from BUILTIN\Administrators to Sensu failed:
Could not find user Sensu

true:

Error: User update failed: (in OLE method `SetInfo': )
    OLE error code:800708C5 in Active Directory
      The password does not meet the password policy requirements. Check the minimum password length, password complexit
y and password history requirements.

    HRESULT error code:0x80020009
      Exception occurred.
Wrapped exception:
(in OLE method `SetInfo': )
    OLE error code:800708C5 in Active Directory
      The password does not meet the password policy requirements. Check the minimum password length, password complexit
y and password history requirements.

    HRESULT error code:0x80020009
      Exception occurred.
Error: /Stage[main]/Sensu::Package/User[Sensu]/ensure: change from absent to present failed: User update failed: (in OLE
 method `SetInfo': )
    OLE error code:800708C5 in Active Directory
      The password does not meet the password policy requirements. Check the minimum password length, password complexit
y and password history requirements.

    HRESULT error code:0x80020009
      Exception occurred.

The biggest issue is that I cannot find any documentation on how to setup a windows client via the sensu puppet module, I also dug through some of the code and I dont see any parameters on setting the sensu user/password for the service account. I can obviously create a sensu user but I feel like the sensu module should be able to handle that no?

Also my module that I wrote to get around this issue registers the sensu service as local system, is there any reason why this shouldnt be done? Most solutions I see on windows should be totally happy as a local system service.

  exec {'create_sensu_client_service':
    command  => 'new-service -name sensu-client -BinaryPathName "c:\\opt\\sensu\\bin\\sensu-client.exe" -DisplayName "Sensu Client"',
    unless   => 'if (Get-Service sensu-client -ErrorAction SilentlyContinue) {exit 0} else {exit 1}',
    provider => powershell,
    require  => Dsc_package["sensu-${sensu_version}.msi"],
  }

[dschaaff]

I'm also having this issue. I currently use my own manifest to setup windows clients and have sensu running as a local system service. The module should support this. If I have time I'll dig through the code and see about a pull request.

[jaxxstorm]

Would be appreciated, I don't use windows so no idea how to fix.

[dzeleski]

@jaxxstorm @dschaaff We wrote our own to at least get this POCd on windows. I can post up some of the code if that helps but in order to shorten dev time we took some shortcuts on things like the client and transport json files, they are built with erb templates. We also use DSC to install sensu via the msi from our internal repo which does require a system reboot.

Depending on timing I could help as well but we are mid sprint right now for a fairly major effort :/

[dzeleski]

Dug a bit deeper here:

in init.pp (https://github.com/sensu/sensu-puppet/blob/master/manifests/init.pp#L541):

    'windows': {
      $etc_dir = 'C:/opt/sensu'
      $conf_dir = "${etc_dir}/conf.d"
      $user = 'Sensu'
      $group = 'Users'
      $home_dir = $etc_dir
      $shell = undef
      $dir_mode = undef
      $file_mode = undef
}

Looks like the service is installed using the system service: https://github.com/sensu/sensu-puppet/blob/master/manifests/client/service.pp#L41

But then the conf dirs are being set as the sensu user and group from the above case (https://github.com/sensu/sensu-puppet/blob/master/manifests/package.pp#L104)

  file { [ $sensu::conf_dir, "${sensu::conf_dir}/handlers", "${sensu::conf_dir}/checks", "${sensu::conf_dir}/filters", "${sensu::conf_dir}/extensions", "${sensu::conf_dir}/mutators" ]:
    ensure  => directory,
    owner   => $sensu::user,
    group   => $sensu::group,
    mode    => $sensu::dir_mode,
    purge   => $sensu::_purge_config,
    recurse => true,
    force   => true,
    require => Package[$pkg_name],
}

Since this is a local service we should actually just be able to leave the file permissions as default (I think), or we can restrict it to the local system user itself, but either way this shouldn't be THAT hard to fix. Ill see if I can spare some time today to pull this and make that fix.

@jaxxstorm Thoughts on adding logic to support other users other then the local system service in case people do want a dedicated sensu user? It would require windows specific params for the client in init.pp

Edit: looks like we can set the user to NT Authority\SYSTEM and the group to Administrators. I still think an override for both is appropriate, but maybe we just say in the docs if you want to use another account its up to you to create it on the system?

[dzeleski]

Sorry for spamming:

This is specifically what is not compatible with windows(https://github.com/sensu/sensu-puppet/blob/master/manifests/package.pp#L165):

  if $sensu::manage_user {
    user { $sensu::user:
      ensure  => 'present',
      system  => true,
      home    => $sensu::home_dir,
      shell   => $sensu::shell,
      require => Group[$sensu::group],
      comment => 'Sensu Monitoring Framework',
    }

    group { $sensu::group:
      ensure => 'present',
      system => true,
    }
}

[dzeleski]

Ok created a pull for this: #588

@jaxxstorm @dschaaff Let me know your thoughts and if you can test I would appreciate it.

[dschaaff]

I'll see if I can give it a go tomorrow. Thanks!

[cdenneen]

@dzeleski Can I ask why this was done exactly?
The issue requires a password for the windows user that meets complexity standards given by the Group Policy. Therefore wouldn't it be better to have the windows_password as a parameter so it can be set in those cases where people need to specify a complex one? So the default for sensu::user_password could be undef by default and the user resource would have a password => $sensu::user_password parameter which is undef by default but set in cases like yours.

@dschaaff
@cwjohnston

[dzeleski]

Sure:

• Group policy is different for every org.
• The local NT System account exists on all windows systems.
• Setting a user in windows means they can log into the system, unlike on linux, especially if admin rights are needed (lots of powershell needs UAC even for read access to objects).
• Local users also need login as a service rights if its enabled in group policy which means the service will start once and never again if it wasnt added or isnt a local admin on the box.
• If local admin is required for checks/metrics you now have an account on all N number of systems in the environment with the same password and full admin rights.

This wouldnt fly for any enterprise environment that cared about security. The local system account is the safest option to get admin rights and not open any doors. Most windows services that only need access to the system itself run as a local service, there is usually no reason to not use it unless you needed access to things outside of the system (ie UNC paths).

When you install the Windows MSI from Sensu themselves it installs as Local System, which is also why I did that as it keeps the install consistent from what Sensu does/expects.

[cdenneen]

@dzeleski I think if using local system account is best solution then the disabling of windows user creation is the best solution overall.. so the PR #628 should solve this and warning is there.