Ansible: user is not authenticating to network share

I’m having difficulty transferring files from a network share to a disk on the local server, via a remote connection. I am logging into the server: SERVER02, however, permission denied appears, using Wireshark collections on SERVER01, I found that user credentials and passwords are not arriving. It’s strange because doing the local robocopy command in PowerShell works correctly. Also, I’ve used Ansible modules and they didn’t work, this module ansible.windows.win_powershell was the one that gave me the most information. Below is the code that is executed and its output:

- name: Copy files from network share folder to Windows server
  hosts: "{{ host_group }}"
  gather_facts: no
  vars:
    ansible_connection: winrm
    ansible_user: "{{ vm_user }}"
    ansible_password: "{{ vm_pass }}"
    ansible_port: 5985
    ansible_winrm_transport: ntlm
    ansible_winrm_server_cert_validation: ignore

  tasks:
    - name: Copia arquivos
      ansible.windows.win_powershell: 
        script: |
          $Username = "{{ vm_user }}"
          $SecurePassword = ConvertTo-SecureString -String "{{ vm_pass }}" -AsPlainText -Force
          $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $Username, $SecurePassword
          Enter-PSSession -ComputerName "{{ host_group }}" -Credential $Credential
          robocopy \\SERVER01\I$\APP\MONITOR\ \\SERVER02\I$\JOBS\ /COPYALL /MT /E /b /W:5 /R:5

Output execution:

-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Started : terca-feira, 10 de outubro de 2023 10:14:27
   Source = \\SERVER01\I$\APP\MONITOR\
     Dest : \\SERVER02\I$\JOBS\

    Files : *.*

  Options : *.* /S /E /COPYALL /B /MT:8 /R:5 /W:5

------------------------------------------------------------------------------

NOTE : Security may not be copied - Source might not support persistent ACLs.

2023/10/10 10:14:27 ERROR 5 (0x00000005) Accessing Source Directory \\SERVER01\I$\APP\MONITOR\
Access is denied.

Hi,

I might be wrong but I’m pretty sure you can’t Enter-PSSession in your script block, as it’s effectively a double-hop.

Perhaps try Invoke-Command instead, or have a look to pssession_configuration module.

Replacing Enter-PSSession with Invoke-Command didn’t solve the problem

Yeah well, that was just a suggestion. It looks like Invoke-Command uses PSSession so that won’t cut it indeed.

You’ll have to find a way to create a PSSession elsewhere, and pass your commands through it, or proxy this session, though I’m not sure winrm have those capabilities.
I’m pretty sure you can get somewhere with pssesion_configuration module linked in my previous post, though you may have to hack your way through it.

If not, you could always circumvent your issue (if I’m right about double-hop) using ssh as transport protocol instead, which lets you ProxyJump.

Edit: Looking at your script block again, someone correct me if I’m wrong but you can’t Enter-PSSession then type command you want to run in the newly created session; that’s not how it works, and that’s why Invoke-Command is a thing. That being said, double-hop issue is still a problem you want tot address.
Just to contextualize a bit, did you try to run your commands directly (not through Ansible modules) from a ps1 script on intended target (so from "{{ host_group }}", according to your playbook) ?

Edit2: Linking it here, just in case: Making the second hop in PowerShell Remoting - PowerShell | Microsoft Learn

@ptn is correct, this would be a double-hop and those commands will not work. You’ll need to have the Ansible server connect directly to the server(s) in question. I have read that if you use CredSSP to authenticate you can do a double-hop but I haven’t used this.

Something like this may work or at least get you closer:

tasks:
    - name: Copia arquivos
      ansible.windows.win_copy:
        src: file/path/APP/MONITOR/
        dest: 'I:\JOBS\'

Note the src here is a file path local to the Ansible server. If you can map the SMB drive on the Ansible server you could also get this result, just replace file/path/ with the mount path.

Lastly, I know you mentioned you used the modules but did you may look at community.windows.win_robocopy as a possible solution as well. This one appears to use a src and dest both on the remote machine unlike the win_copy module.

1 Like

@bmbufalo,
I tested both of your suggestions, as follows:

	- name: robocopy
      community.windows.win_robocopy:
        src: \\SERVER01\I$\APP\MONITOR\
        dest: \\SERVER02\I$\JOBS\
        flags: /COPYALL /MT /E /b /W:5 /R:5

and

    - name: copy
      ansible.windows.win_copy:
        src: '\\SERVER01\I$\APP\MONITOR\'
        dest: '\\SERVER02\I$\JOBS\'
        remote_src: true

however, in both cases it causes a lack of access error

@ptn
yes, configuring a script.ps1 and running it from ansible, as follows:

     - name: Copia arquivos
       ansible.windows.win_powershell: 
         script: |
           I$\APP\MONITOR\script.ps1

also, executing a script.exe written in python, there was also a lack of access :confused:

You still have to provide credentials. Are they hardcoded in your script ? Can you output the script content, as well as the “lack of access” output you’re getting from Ansible ?

Also, did you try running your script manually from Powershell on your remote server ? What gives ?

Also sorry about that, but this is magical haha:

script.ps1

executing a script.exe

written in python

Nothing goes together ! :smile:

sorted out:

    - name: Copy
      ansible.windows.win_powershell: 
        script: |
          net use Z: \\SERVER01\I$ /user:domain\{{ vm_user }} {{ vm_pass }}
          net use Y: \\SERVER02\I$ /user:domain\{{ vm_user }} {{ vm_pass }}          

          robocopy Z:\APP\MONITOR\ Y:JOBS\ /COPYALL /MT /E /b /W:5 /R:5

          net use Z: /delete
          net use Y: /delete
          
      register: log
1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.