[SOLVED] Problem with NewPSDrive

[erict]

Hello,

WAPT version: 1.3.13.
Server running Debian.
Development machine running Windows 10.

I use a PowerShell script in one of my packages. I need to connect a network drive initially, and I'm using the NewPSDrive command.

This script works perfectly when I run it manually in a PowerShell console, but crashes when I run it from WAPT.
The command is quite basic:

New-PSDrive -Name Z -Root "\\server.domain.fr\myfolder$" -PSProvider Filesystem.
However, when run via WAPT, I get an error message: New-PSDrive: The specified drive root "\\server.domain.fr\myfolder$" does not exist or is not a folder.

I've tried to understand the differences between running the script in a console and running it via WAPT. I've checked with a test-connection: the share is responding correctly. I also added a test that checks if there's already a mapped Z: drive, which isn't the case.

The only difference I see is when I have it display the username: it's MyPC\administrator when I launch it manually, and NT AUTHORITY\System when it's launched via WAPT. I don't know, however, if the problem could be related to that.

After posting quite a few messages on PowerShell forums, without any response so far, I thought that perhaps other WAPT users have already encountered this problem.

PS: The setup.py file of the package in question (although there's not much there that should be relevant):
def install():
print('installing cdburnerXP')
run_powershell(r'./cdburn.ps1')

Thanks in advance
.

[sfonteneau]

Hello,

Wapt is designed not to rely on external sources (such as a network drive).
Indeed, in this case, the security of the Wapt package is compromised. Also, if the network is unavailable during installation, the installation will fail (during a WaptExit, for example).
Wapt was not designed for this.

Why not include the software source code directly in the Wapt package?

Especially for CDBurner!

I encourage you to reread the Wapt package creation documentation:
https://www.wapt.fr/fr/doc/CreationPaquets/index.html

[erict]

Hello,

I understand what WAPT is for and how to use it in "normal" mode. I'm already doing that, and everything is fine on that front, don't worry.
But we already have an infrastructure for automatically installing software, used by other software (mdt, etc.).
Our idea is to avoid having to maintain multiple repositories for each update.
classic WAPT usage scenario. I suspect that a cdburnerxp package already exists in the WAPT repositories, but it doesn't meet our needs in the case of this software.

the

[dcardon]

Hello Eric,

I understand what Wapt is for and how to use it in "normal" mode. I'm already doing it, and everything is fine on that front, rest assured.
But we already have an infrastructure for the automatic installation of software, used by other software (mdt...).

The correct way to integrate WAPT and MDT is to package normally in the WAPT way, install the waptagent at the end of the MDT procedure and call a wapt-get install of its machine package directly afterwards.

Our idea is to avoid having to maintain multiple repositories for each update.
In short, it corresponds to a local need, even if it's true that we're not in the classic WAPT usage scenario. I'm well aware that a cdburnerxp package already exists on the WAPT repositories.

I hate to put it so bluntly, but this is a really, really bad idea. The availability of a network share at the time of the WAPT installation is not guaranteed (e.g., waptexit doesn't check this).

, but it does not meet our needs, in the case of this software.

The use of WAPT "self-contained" packages is an essential condition to guarantee a successful deployment rate...

To answer your specific question (though I'm probably just helping you create more problems for yourself...), the account used when mounting a network as a LocalSystem account (NT Authority\System) is the machine's Kerberos account (e.g., MYCOMPUTER$). Therefore, you need to grant read permissions to the "domain computers" group on the share containing the installers. This is a purely Windows issue; it's strange that no one has been able to answer it on your PowerShell forum... (okay, I'm just teasing a little)

But anyway, I repeat, it's really not a good idea. I'll repeat it one more time, so I'm not accused of encouraging people to harm themselves: it's really not a good idea!

Just because we don't have the solution doesn't mean we encourage you to make WAPT packages correctly, it's just that if it's to launch a powershell script that needs to do a network mount, in that case you might as well use GPOs, it will bug just as much (or other deployment tools that bug just as much by following the same model).

That said, if your problem is with Python and creating setup.py files for WAPT, you have dozens of packages to look at for inspiration. And if you want to progress faster and become third-degree black belt packagers in WAPT, Alexandre and Simon offer fast and effective training!

Denis

[erict]

Thank you very much for your comprehensive response.
I've taken note of everything you said about using WAPT. We're actually testing its capabilities to see how we could use it in relation to GPOs, MDT, and the system we currently use for deploying systems and software to workstations, as well as for updates.
We have to proceed gradually, as we can't change everything at once, and many questions have arisen.
WAPT seems promising, easier to make available to colleagues than, for example, opening up the possibility of creating GPOs for everyone.
In short, we're in the testing and planning phase for how to integrate it gradually, either alongside or as a replacement for some of our existing tools. The chosen approach is to integrate it into the current infrastructure and expand its use as needed if it proves useful or makes sense.
The flexibility of your product allows for this, and that's precisely one of the reasons we chose it.

Thank you again for your help and work on this tool
.

[dcardon]

Hello Eric,

Thank you very much for your very thorough reply.
I've taken note of everything you said about using WAPT. We're actually testing its capabilities to see how we could use it in relation to GPOs, MDT, and the system we currently use for deploying systems and software to workstations, as well as for updates.
We have to proceed gradually, as we can't change everything at once, and a lot of questions are arising.
WAPT seems promising, easier to make available to colleagues than opening up the possibility of creating GPOs to everyone, for example.
In short, we are currently testing and considering how to gradually integrate it alongside and/or as a replacement for some of our existing tools. Our chosen approach is to integrate it into our current infrastructure and expand its use as needed if it proves useful or makes sense.
The flexibility of your product allows for this, and that's precisely one of the reasons we chose it.

If the goal is simply to install an MSI or EXE that runs correctly and silently, just run the following command with the package, then perform a build-upload (two minutes max for a small package)...

Code: Select all

wapt-get make-template moninstalleur.msi

The workload increase from having both systems running in parallel during the testing period shouldn't be too significant...

Denis

[erict]

Hi again,

Thanks for the info.
Even though it's not part of "normal" WAPT usage, I'm posting the solution here in case it's helpful to someone:
There was indeed a credential issue for the system user. Our share doesn't require authentication (it's read-only), but you still need to provide a username/password, even if it's fake.

Regarding our potential transition method between our current system and WAPT, we have good reasons for doing things the way we do, which would be too lengthy to detail here (and not very interesting anyway).

Thanks again.
Best regards,

ET

[dcardon]

Re,

Thanks for the info.
Even though it's not part of "normal" WAPT usage, I'm posting the solution here, in case it's useful to someone:
There was indeed a credential issue for the system user. Our share doesn't require authentication (it's read-only), but you still need to provide a username/password, even if it's fake.

Regarding our potential transition method between our current system and WAPT, we have good reasons for doing things this way, which would be too lengthy to detail here (and not very interesting anyway).

Thanks again.
Best regards,

ET

I apologize for being so insistent, but for those who will read this post: We must not follow this example!

If you have a network share without authentication, a simple man-in-the-middle attack with a bit of ARP/DNS/NetBIOS spoofing will redirect user workstations to a compromised share, and everything executed will run under a LocalSystem account, bypassing most standard security checks. Basically, unless you have 802.1x, pVLANs, and ARP cache poisoning protection across your entire network, and you don't have any laptops, you're creating a massive security vulnerability that will allow any script kiddie to take over the network!

The WAPT operating model is sound from a security standpoint. I would prefer that the WAPT name not be associated with such methods...

Furthermore, simple mutual authentication using Kerberos with the machine account would have at least prevented this MITM attack. I'm not a PowerShell expert, but a simple "net use" command as the LocalSystem account allows authentication and mapping a drive to a share with read permissions for "domain computers":

Code: Select all

psexec -i -s cmd
    whoami
    net use f:   \\mondomain.lan\sysvol
    dir f:

Sincerely,

Denis

[erict]

Hi again,

I don't have enough network/hacking knowledge to fully understand the implications of your comment, but I'll pass it on to the engineer who implemented this system to see what he thinks. That said, we do indeed have 802.1x, VLANs, and a whole host of pretty robust network protections... which isn't a reason to do just anything, we agree on that.

Indeed, for the moment, we're "twisting" WAPT to do things that weren't originally intended, and I understand that you prefer to be very clear about things.

Regarding `net use`, I think I tried it, and it didn't yield any more results than `New-PSDrive`, but I'll run the test again sometime (although fundamentally, if I understand correctly, it doesn't change much regarding the security issue mentioned).

Regards,
ET