[ansible-project] Re: Windows mapped drives – what the hell is going on?
Hi Jordan, 1) 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 2) 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 3) If yes to the above, what happens when you try and open it up or just navigate to Z? - N/A 4) Can you use Ansible to map a shared path on any other server? - The same situation on other VMs in the same domain :( 5) 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) On Thursday, January 16, 2020 at 12:51:50 AM UTC+1, Jordan Borean wrote: > > 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. > > Thanks > > Jordan > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/88e7a8bf-d8cc-44dc-ae63-0d55ce5c5039%40googlegroups.com.
[ansible-project] Re: Windows mapped drives – what the hell is going on?
1) What is the full command you run to map the drive normally (outside of Ansible)? - net use z: \\bellagio.intra.vegas.net\how\the\hell\to\solve\this\issue /persistent:yes' 2) If you manually map it through the GUI are you connecting with explicit credentials? - I'm connecting using mRemote, RDP protocol with the same credentials as configured in Ansible: username:elvis ; domain:bellagio ; password:elvis123 3) a) after mapping via Ansible, nonAdministrator: PS C:\Users\elvis> cmdkey.exe /list Currently stored credentials: Target: MicrosoftAccount:target=SSO_POP_Device Type: Generic User: 02yahgcuuqfcntfq Saved for this logon only Target: WindowsLive:target=virtualapp/didlogical Type: Generic User: 02yahgcuuqfcntfq Local machine persistence b) after mapping via Ansible, Administrator: PS C:\Windows\system32> cmdkey.exe /list Currently stored credentials: Target: MicrosoftAccount:target=SSO_POP_Device Type: Generic User: 02yahgcuuqfcntfq Saved for this logon only Target: WindowsLive:target=virtualapp/didlogical Type: Generic User: 02yahgcuuqfcntfq Local machine persistence c) after manual map, nonAdministrator: PS C:\Users\elvis> cmdkey.exe /list Currently stored credentials: Target: MicrosoftAccount:target=SSO_POP_Device Type: Generic User: 02yahgcuuqfcntfq Saved for this logon only Target: WindowsLive:target=virtualapp/didlogical Type: Generic User: 02yahgcuuqfcntfq Local machine persistence On Wednesday, January 15, 2020 at 12:25:46 PM UTC+1, Jordan Borean wrote: > 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. > > Thanks > > Jordan > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b171ef85-9aa6-4c98-b4df-71f8bd71b610%40googlegroups.com.
[ansible-project] Re: Windows mapped drives – what the hell is going on?
1) What is the full command you run to map the drive normally (outside of Ansible)? - net use z: \\burak2.intra.noklab.net\Global_veryfication\[4]_TP\Ansible /persistent:yes' 2) If you manually map it through the GUI are you connecting with explicit credentials? - I'm connection using mRemote, RDP protocol with the same credentials as configured in Ansible: username:elvis ; domain:bellagio ; password:elvis123 3) a) after mapping via Ansible, nonAdministrator: PS C:\Users\elvis> cmdkey.exe /list Currently stored credentials: Target: MicrosoftAccount:target=SSO_POP_Device Type: Generic User: 02yahgcuuqfcntfq Saved for this logon only Target: WindowsLive:target=virtualapp/didlogical Type: Generic User: 02yahgcuuqfcntfq Local machine persistence b) after mapping via Ansible, Administrator: PS C:\Windows\system32> cmdkey.exe /list Currently stored credentials: Target: MicrosoftAccount:target=SSO_POP_Device Type: Generic User: 02yahgcuuqfcntfq Saved for this logon only Target: WindowsLive:target=virtualapp/didlogical Type: Generic User: 02yahgcuuqfcntfq Local machine persistence c) after manual map, nonAdministrator: PS C:\Users\elvis> cmdkey.exe /list Currently stored credentials: Target: MicrosoftAccount:target=SSO_POP_Device Type: Generic User: 02yahgcuuqfcntfq Saved for this logon only Target: WindowsLive:target=virtualapp/didlogical Type: Generic User: 02yahgcuuqfcntfq Local machine persistence On Wednesday, January 15, 2020 at 12:25:46 PM UTC+1, Jordan Borean wrote: > > 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. > > Thanks > > Jordan > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/f6964258-2d11-45c5-a7a6-0135071d0058%40googlegroups.com.
[ansible-project] Re: Windows mapped drives – what the hell is going on?
EDIT: 2) PowerShell as Administrator: PS C:\Windows\system32> gdr -PSProvider 'FileSystem' > > > Name Used (GB) Free (GB) Provider Root > CurrentLocation > - - > --- > A FileSystemA:\ > C 17.67 81.79 FileSystemC:\ > Windows\system32 > D FileSystemD:\ > E 0.14 99.86 FileSystemE:\ > Z 465267.94 178455.74 FileSystem\bellagio.intra.vegas > .net\how... > > PS C:\Windows\system32> net use > New connections will be remembered. > > Status Local RemoteNetwork > > --- > OK Z:\\bellagio.intra.vegas.net\how\the\hell\to\solve\ > this\issue > Microsoft Windows Network >\\TSCLIENT\C Microsoft Terminal > Services >\\TSCLIENT\S Microsoft Terminal > Services >\\TSCLIENT\V Microsoft Terminal > Services >\\TSCLIENT\W Microsoft Terminal > Services >\\TSCLIENT\X Microsoft Terminal > Services >\\TSCLIENT\Y Microsoft Terminal > Services >\\TSCLIENT\Z Microsoft Terminal > Services > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/5d74539d-3f16-4124-ac47-989bda2e0ebd%40googlegroups.com.
[ansible-project] Re: Windows mapped drives – what the hell is going on?
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 0x ConnectionType: REG_DWORD 0x0001 DeferFlags: REG_DWORD 0x0004 ProviderName: REG_SZ Microsoft Windows Network ProviderType: REG_DWORD 0x0002 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: * Ansible, ansible_user=el...@intra.vegas.net * I've executed playbook, Z: drive isn't visible in GUI. Computer\HKEY_CURRENT_USER\Network\Z (Default): REG_SZ (value not set) ConnectFlags: REG_DWORD 0x ConnectionType: REG_DWORD 0x0001 DeferFlags: REG_DWORD 0x0004 ProviderName: REG_SZ Microsoft Windows Network ProviderType: REG_DWORD 0x0002 RemotePath: REG_SZ \\bellagio.intra.vegas.net\how\the\hell\to\solve\this\ issue UserName REG_SZ 1) PowerShell normal: PS C:\Users\elvis> gdr -PSProvider 'FileSystem' Name Used (GB) Free (GB) Provider Root CurrentLocation - - --- A FileSystemA:\ C 17.67 81.79 FileSystemC:\ Users\elvis D FileSystemD:\ E 0.14 99.86 FileSystemE:\ PS C:\Users\elvis> net use New connections will be remembered. Status Local RemoteNetwork --- Unavailable Z:\\bellagio.intra.vegas.net\how\the\hell\to\solve\this \issue Microsoft Windows Network \\TSCLIENT\C Microsoft Terminal Services \\TSCLIENT\S Microsoft Terminal Services \\TSCLIENT\V Microsoft Terminal Services \\TSCLIENT\W Microsoft Terminal Services \\TSCLIENT\X Microsoft Terminal Services \\TSCLIENT\Y Microsoft Terminal Services \\TSCLIENT\Z Microsoft Terminal Services The command completed successfully. 2) PowerShell as Administrator: PS C:\Windows\system32> gdr -PSProvider 'FileSystem' Name Used (GB) Free (GB) Provider Root CurrentLocation - - --- A FileSystemA:\ C 17.67 81.79 FileSystemC:\ Windows\system32 D FileSystemD:\ E 0.14 99.86 FileSystemE:\ Z 465267.94 178455.74 FileSystem\bellagio.intra.vegas. net\how... PS C:\Windows\system32> net use New connections will be remembered. Status Local RemoteNetwork --- OK Z:\\bellagio.intra.vegas.net\how\the\hell\to\solve\this \issue Microsoft Windows Network \\TSCLIENT\C Microsoft Terminal Services \\TSCLIENT\S Microsoft Terminal Services \\TSCLIENT\V Microsoft Terminal Services \\TSCLIENT\W Microsoft Terminal Services \\TSCLIENT\X Microsoft Terminal Services \\TSCLIENT\Y Microsoft Terminal Services \\TSCLIENT\Z Microsoft Terminal Services The command completed successfully. On Wednesday, January 15, 2020 at 10:25:54 AM UTC+1, Jordan Borean wrote: > > 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 bo
[ansible-project] Re: Windows mapped drives – what the hell is going on?
Hi Jordan,
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: el...@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
PLAY RECAP
**
10.42.197.227 : ok=2changed=1unreachable=0failed=0
skipped=0rescued=0ignored=0
but after I logon using RDP:
domain: INTRA.VEGAS.NET
login: elvis
pass: elvis123
there is still no Z: hard drive mounted.
PS C:\Users\elvis> gdr -PSProvider 'FileSystem'
Name Used (GB) Free (GB) Provider Root
CurrentLocation
- -
---
A FileSystemA:\
C 17.67 81.80 FileSystemC:\
Users\elvis
D FileSystemD:\
E 0.14 99.86 FileSystemE:\
Is it still my wrong understanding of some issue with env? Could you be so
kind to share with me how to investigate this issue?
On Tuesday, January 14, 2020 at 8:39:08 PM UTC+1, Jordan Borean wrote:
>
> 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.
>
> 1) 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
>
> - win_mapped_drive:
> name: 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 }}'
>
> 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.
>
> - win_credential:
> name: bellagio.infra.vegas.net
> type: domain_password
> username: custom user
> secret: password
> state: present
> become: yes
> become_method: runas
> vars:
> ansible_become_user: '{{ ansible_user }}'
> ansible_become_pass: '{{ ansible_password }}'
>
> 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
[ansible-project] Re: Windows mapped drives – what the hell is going on?
Hi Jordan,
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.
<10.42.197.227> ESTABLISH WINRM CONNECTION FOR USER: wro4...@intra.noklab.net
on PORT 5986 TO 10.42.197.227
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
PLAY RECAP
**
10.42.197.227 : ok=2changed=1unreachable=0failed=0
skipped=0rescued=0ignored=0
but after I logon using RDP:
domain: INTRA.VEGAS.NET
login: elvis
pass: elvis123
there is still no Z: hard drive mounted.
PS C:\Users\elvis> gdr -PSProvider 'FileSystem'
Name Used (GB) Free (GB) Provider Root
CurrentLocation
- -
---
A FileSystemA:\
C 17.67 81.80 FileSystemC:\
Users\elvis
D FileSystemD:\
E 0.14 99.86 FileSystemE:\
Is it still my wrong understanding of some issue with env? Could you be so
kind to share with me how to
On Tuesday, January 14, 2020 at 8:39:08 PM UTC+1, Jordan Borean wrote:
>
> 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.
>
> 1) 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
>
> - win_mapped_drive:
> name: 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 }}'
>
> 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.
>
> - win_credential:
> name: bellagio.infra.vegas.net
> type: domain_password
> username: custom user
> secret: password
> state: present
> become: yes
> become_method: runas
> vars:
> ansible_become_user: '{{ ansible_user }}'
> ansible_become_pass: '{{ ansible_password }}'
>
> 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.ex
[ansible-project] Windows mapped drives – what the hell is going on?
Hello experts, I was trying to reach Jordan on his blog: http://www.bloggingforlogging.com/2018/11/22/windows-mapped-drives-what-the-hell-is-going-on/#comment-178 ,but I see that comments are closed, so maybe here someone can help me with my issue: 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. --- Network drive --- \\bellagio.intra.vegas.net\how\the\hell\to\solve\this\issue --- Ansible hosts --- [winhost] 99.88.77.66 99.88.77.65 [winhost:vars] ansible_user=el...@intra.vegas.net ansible_password=elvis123 ansible_connection=winrm ansible_winrm_transport=ntlm ansible_winrm_message_encryption=always ansible_winrm_server_cert_validation=ignore Is it possible: 1) 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? 2) to use this mapped drive as a 'repo place' for future purposes - to copy scrips, apps from this drive to VMs using Ansible? Best regards, Peter -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/32d271cd-1f22-4bee-9e90-4744db31ee94%40googlegroups.com.
