New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

windows_ad_join resource fails to join #7715

Closed
gsreynolds opened this Issue Oct 3, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@gsreynolds
Member

gsreynolds commented Oct 3, 2018

Description

windows_ad_join fails with Add-Computer : Computer 'HOSTNAMEHERE' failed to join domain 'DOMAINHERE' from its current workgroup 'WORKGROUP' with following error message: Unable to update the password. The value provided as the current password is incorrect.

Manually (via GUI or PS) joining the domain on the same machine with the same creds & domain FQDN works successfully.

Chef Version

14.5.33

Platform Version

Windows Server 2012R2

Replication Case

windows_ad_join 'Join Domain' do
  action           :join
  domain_user      advault['username']
  domain_password  advault['password']
  domain_name      node['domainfqdn']
  ou_path          node['oupath']
  reboot           :delayed
  sensitive        true
end

After CCR fails, RDP'ing to the system and either using the Windows GUI or using PowerShell to join the domain with the same creds from the advault item and the domainfqdn in that environment's attributes works successfully. Replicated this on two 2k12R2 systems.

Client Output

Recipe: basenode::windows
  * windows_ad_join[Join Domain] action join[2018-10-03T12:33:19+01:00] INFO: Processing windows_ad_join[Join Domain] action join (basenode::windows line 8)

    ================================================================================
    Error executing action `join` on resource 'windows_ad_join[Join Domain]'
    ================================================================================

    RuntimeError
    ------------
    Failed to join the domain DOMAINHERE: Add-Computer : Computer 'HOSTNAMEHERE' failed to join domain
    'DOMAINHERE' from its current workgroup 'WORKGROUP' with following
    error message: Unable to update the password. The value provided as the
    current password is incorrect.

    At line:1 char:164
    + $pswd = ConvertTo-SecureString 'PASSWORDHERE' -AsPlainText
    -Force;$credential =  ...

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OperationStopped: (HOSTNAMEHERE:String) [Add-C
       omputer], InvalidOperationException
        + FullyQualifiedErrorId : FailToJoinDomainFromWorkgroup,Microsoft.PowerShe
       ll.Commands.AddComputerCommand
    }


    Resource Declaration:
    ---------------------
    suppressed sensitive resource output

    Compiled Resource:
    ------------------
    suppressed sensitive resource output


    System Info:
    ------------

    chef_version=14.5.33
    platform=windows
    platform_version=6.3.9600
    ruby=ruby 2.5.1p57 (2018-03-29 revision 63029) [x64-mingw32]
    program_name=C:/opscode/chef/bin/chef-client
    executable=C:/opscode/chef/bin/chef-client


[2018-10-03T12:33:22+01:00] INFO: Running queued delayed notifications before re-raising exception
Running handlers:
[2018-10-03T12:33:22+01:00] ERROR: Running exception handlers
Running handlers complete
[2018-10-03T12:33:22+01:00] ERROR: Exception handlers complete
Chef Client failed. 8 resources updated in 48 seconds
@Happycoil

This comment has been minimized.

Contributor

Happycoil commented Oct 4, 2018

Does advault['username'] contain DOMAIN\samaccountname or just samaccountname? I seem to remember some funky stuff about interactive vs noninteractive when it comes to Add-Computer.

@gsreynolds

This comment has been minimized.

Member

gsreynolds commented Oct 4, 2018

Good shout, I’ll pass that suggestion on; thanks for the PowerShell-fu @Happycoil ! It had a few of us stumped pulling apart the recipe and the resource and the next step with them was to capture the powershell_script to compare.

@Happycoil Happycoil referenced this issue Oct 4, 2018

Closed

windows_ad_join: validate ad user format #7718

0 of 4 tasks complete
@gsreynolds

This comment has been minimized.

Member

gsreynolds commented Oct 4, 2018

Just to update, using DOMAIN\username with the resource does work and fixed the problem. We should probably decide on a validation strategy and documentation change here and in #7718

@stuartpreston

This comment has been minimized.

Member

stuartpreston commented Oct 4, 2018

I think it may depend on whether the DNS domain name was used as the name of the domain to join. As per #7718 I have success using the DNS domain name.

@Happycoil

This comment has been minimized.

Contributor

Happycoil commented Oct 9, 2018

@gsreynolds does using the DNS domain name as the resource name work as well? Are we seeing different behaviours because of different windows server versions and AD functional levels perhaps?

@gsreynolds

This comment has been minimized.

Member

gsreynolds commented Oct 9, 2018

@Happycoil in this case the property domain_name was the FQDN of the domain to join, and as that's the name property of the resource that's what was used. The fix was to prefix the domain_user with DOMAIN\ but there definitely seems to be some different behaviours out there - this was 2012R2 with PS5.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment