I’ve read article from the blog and I’ve tried to understand it, but I’m still confued. Probably due to low level of win knowledge…
Could you try to help me and try to answer to my questions in simple words(?)
My scenario: I’ve several dozen win VMs deployed for my team, we thought that the good idea is to use Ansible to confiure and customize them for our purposes inlcuding network drive mapping (later using it as a repo with apps/scripts which we want to install/use on VMs using Ansible). VMs are deployed by internal network team and what we get is a clean windows VM with domain username and pass. Mapped drive should be visible for mentioned domain user after logon to VM using RDP. Ansible has been instaled and configure succesfully - connection with VMs working well. Due to some ‘probably’ security policy and network configuration only one way of auth option was to use NTLM.
Of course, it’s possible to map network drive on every VM using RDP with mentioned domain user.
to use Ansible to map this network drive automatically in all VMs for the domain user (mapped drive should be visible after VM reboots, during every RDP sessions using this credentials?
to use this mapped drive as a ‘repo place’ for future purposes - to copy scrips, apps from this drive to VMs using Ansible?
Hi, the blog is still accepting comments, I just need to approve them so it doesn’t get spammed.
As for your issue at hand.
to use Ansible to map this network drive automatically in all VMs for the domain user (mapped drive should be visible after VM reboots, during every RDP sessions using this credentials?
You should be using the win_mapped_drive to create the mapping for the user you want. This should be as simple as
Because you are using NTLM authentication, the task will not be able to access the network path so become is being used to bypass that limitation. If you are connecting with Ansible to one account but want the mapped drive for another, change the become user/pass vars to the account in question. What this task will do is create the mapped drive Z for the become user and that drive will appear when they log on locally. When they try and access it locally it will use their logon credentials to access the UNC path.
If you need to connect to the UNC path with custom credentials you can add the following task before the win_mapped_drive one.
This task creates a credential for that host in the become user’s credential manager and it is used for any outbound authentication attempts on that particular host. This enables you to save a credential for a network host and then use that credential for the mapped drive. Once again become is important for this task to work as the credential manager can only be accessed through become when using WinRM. The win_credential module is pretty much a wrapper for the same functionality that cmdkey.exe offers [1].
to use this mapped drive as a ‘repo place’ for future purposes - to copy scrips, apps from this drive to VMs using Ansible?
This is not possible, ultimately it is next to impossible to do. A network logon like WinRM will not mount the network mounts for you so even with become it won’t appear in Ansible. Technically it is possible to create a “global” mapped drive which always appears but credential management in this scenario is not ideal. I would highly recommend you don’t create a global mount at all, the blog post does mention how it can be possible though.
For your problem, you should always use the full UNC path in your Ansible scripts. This is beneficial for a few reasons
You are not relying on the host to be setup in a particular method for your Ansible scripts to work
The Ansible playbook is self documenting as to where it is referencing a file rather than something trying to figure out ‘M:\path’ refers to this network host
Mapped drives are a pain and are really only designed for interactive setups, which Ansible is not
If you just don’t want to type out the full path for each task, use an Ansible fact/variable that references the UNC path for you. If you are having trouble trying to connect to a UNC path that’s probably due to the double hop problem with WinRM. See our documentation for more info on how to overcome the double hop problem [2].
Having a file server mounted on lots of windows client pcs is a common pattern in windows shops but I decided to use a web server and make the windows client machines collect the apps they need using win_get_url module.
First of all big thanks for your reply, I’m really surprised how efficiently this community works.
So, let’s cut to the chase. I focused on your first hint and according to it, I’ve corrected my playbook: (for others info: there was a ‘typo’ - name instead of letter)
`
name: Mount Z drive
win_mapped_drive:
letter: Z
path: \bellagio.infra.vegas.net\how\the\hell\to\solve\this\issue
state: present
become: yes
become_method: runas
vars:
ansible_become_user: ‘{{ ansible_user }}’
ansible_become_pass: ‘{{ ansible_password }}’
`
Playbook has been executed successfully:
`
TASK [Mount Z drive] ****************************************************************************************************************************************************************************************
task path: /etc/ansible/playbooks/test.yml:13
Using module file /usr/lib/python2.7/dist-packages/ansible/modules/windows/win_mapped_drive.ps1
Pipelining is enabled.
<99.88.77.60> ESTABLISH WINRM CONNECTION FOR USER: elvis@INTRA.VEGAS.NET on PORT 5986 TO 99.88.77.66
EXEC (via pipeline wrapper)
changed: [99.88.77.66] => {
“changed”: true,
“invocation”: {
“module_args”: {
“letter”: “Z”,
“password”: null,
“path”: “\\bellagio.infra.vegas.net\how\the\hell\to\solve\this\issue”,
“state”: “present”,
“username”: null
}
}
}
META: ran handlers
META: ran handlers
Sorry about the option name mismatch but glad you found the correct one.
Your task seems to be correct so it’s curious as to why it isn’t showing up. What I recommend you look at;
See if the key ‘HKCU:\Network\Z’ is present and if the entries match what you set
Run the command ‘net use’ on both a normal and elevated (Run as administrator) and see if any of them show the Z drive
If they do, see what the status is for it- Look at the security event logs for both the server you are RDP’ing to as well as the target UNC server (bellagio).
It turned out that this issue is somehow related to permissions/security settings - any suggestions? I asked our internal IT team to check security event log:
Please, look what I’ve found:
***** RDP login, user: elvis *****
I’ve mounted drive under Z: letter, Z: drive is visible.
Computer\HKEY_CURRENT_USER\Network\Z (Default): REG_SZ (value not set) ConnectFlags: REG_DWORD 0x00000000 ConnectionType: REG_DWORD 0x00000001 DeferFlags: REG_DWORD 0x00000004 ProviderName: REG_SZ Microsoft Windows Network ProviderType: REG_DWORD 0x00020000 RemotePath: REG_SZ \\bellagio.intra.vegas.net\how\the\hell\to\solve\this\issue UserName REG_SZ
I’ve disconnected Z: drive, Z: drive disappeared.
Computer\HKEY_CURRENT_USER\Network - there is no Z:
That is very curious, typically the opposite is the case where the standard (limited) process is able to see the mapped drive but the admin process is not. We can see that in both scenarios net use can see that there is a valid configuration for the mapped drive but it is only successfully connecting under the administrative process. We can also see that the registry settings are exactly the same compared to when you map it manually and when Ansible does it for you.
This pretty much means there’s some sort of credential/authentication issue that occurs with your limited process compared to the admin process.
What is the full command you run to map the drive normally (outside of Ansible).
If you manually map it through the GUI are you connecting with explicit credentials?
When you map it manually and there is a mapped drive in the GUI, what is the output for ‘cmdkey.exe /list’, is there an entry for ‘bellagio.intra.vegas.net’?
If the answer to the last 2 (or even 1) is with an explicit credential you will have to do the same thing with Ansible with the win_credential module. Having a credential present for the server specified will mean that credential is used for outbound authentication.
Unfortunately I cannot explain this at all, a couple of final question/clarifications
When you map it manually with net use, can you log off and back on and the drive still remains connected and visible in Windows Explorer?
The output for ‘net use’ on a limited process is showing that the Z map is configured but is unavailable, does the drive show up in Windows Explorer, maybe with a red X
If yes to the above, what happens when you try and open it up or just navigate to Z
Can you use Ansible to map a shared path on any other server
In your limited/admin processes you ran the tests on, are they the same account or is your admin account a completely separate account
The only extra thing you can do is enable file share audit logs on the UNC target and attempt to audit why the connections are failing. I don’t know of any way to audit the LANMan Redirector locally to see why it failed to map the drive when you log in after Ansible is run.
When you map it manually with net use, can you log off and back on and the drive still remains connected and visible in Windows Explorer?
Yes
The output for ‘net use’ on a limited process is showing that the Z map is configured but is unavailable, does the drive show up in Windows Explorer, maybe with a red X?
No, there is no Z: drive
If yes to the above, what happens when you try and open it up or just navigate to Z?
N/A
Can you use Ansible to map a shared path on any other server?
The same situation on other VMs in the same domain
In your limited/admin processes you ran the tests on, are they the same account or is your admin account a completely separate account?
I’m not sure if I understood your question correctly, wro4gtp is not an admin account, i ran only powershell app in ‘as administrator’ mode (all the time I use elvis account)
This is unfortunately outside of what I know and I can’t really offer and more help. From what I can see the registry settings are the same when Ansible creates the drive vs when it’s created with net use, even net use sees the drive, it’s just not available. What you need to do now is enable file share auditing [1] on the target to try and track down why the drive is unavailable and what error is being reported by SMB that explains the failure a bit more.
