Deploying TD in a secure environment

Discussion forum about all things Gupta, OpenText and the community.
Igor Ivanovic
Site Admin
Site Admin
Croatia
Posts: 1365
Joined: 05 Mar 2017, 12:37
Location: Zagreb, Croatia

Deploying TD in a secure environment

Post by Igor Ivanovic » 08 Oct 2020, 08:46

I have a customer which has very high security setup and having problems with it.
In my app, for years now, I am starting an update automatically (it's an InstallShield QuickPatch) and got bitten this year when my certificate expired and the win security didn't allow the update anymore. The only resolution I found out was signing the original package with a new certificate and reinstall the application.

Now, I am bitten by the security for TD deployer also (which is also started automatically within the app).
The policy setting forbids the installation.

Not to mention that it's a bank group and they have very slow IT, with lots of authorization steps, so anything I need to get resolved by them takes a loooong time.
And usually I get an answer - you shouldn't do it.

How do you cope with policy settings, is there anything I could do from my side to avoid the problems I had?

Thanks!
Igor Ivanovic
Image

Acclaro
Germany
Posts: 155
Joined: 16 Mar 2017, 08:13
Location: Hannover, Deutschland

Re: Deploying TD in a secure environment

Post by Acclaro » 09 Oct 2020, 16:06

Hi Igor,

why don't you deploy the TD files in your own setup?
excecute the Deployer on one of your own machines
copy the files to your installshield setup

running the setup on the client you only have to copy the files to your program folder

that's the way we work

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3145
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Deploying TD in a secure environment

Post by Dave Rabelink » 10 Oct 2020, 09:43

I try to avoid using the TD deployer at all costs.

First of all, I have found it be better to deploy the TD runtime along with the application. So install the runtime in the same folder as the application.
For most installations, a xcopy is enough.

When COM registrations or specific registry settings need to be applied, using InstallShield setup project is the way to go.

The issue with highly secure systems can only be solved running an installer in elevated rights. So easy xcopy designs will mostly not work there and is often rejected by the system admins.
A setup needs to be designed to fit into the deployment architecture on that specific site.

So yes, having more and more secure systems makes deployment much more a hassle and easy changes can take much longer time and management than in the past.

Larger sites get also more professional and apply much more secure systems and build up official supported ways to get applications on workstations.
There is no one-solution-fits-all approach, but there are company specific rules which direct you which deployment design you are allowed to apply.

As an example:

On a very large site which is using TD applications for decades, we have designed a xcopy deployment system which updates the application on workstations automatically.
By deploying files on a server, each workstation will first update from there before running the application.
This has worked for many many years, because it was approved and offered quick updates. So a production issue could be solved by fixing, testing and deploying files on the server.
Within an hour, a blocked department which looses money by the hour when not able to use the application, can be up and running in no-time.

Other applications were using InstallShield projects which were pushed by a Windows package system. But designing, creating and deploying those packages could take at least days and mostly even weeks.

For a critical application, the easy update system was always the best option. So we got special rules.

But now, the architecture is more and more secure. So we had to fight to keep our rules. The architecture they want us to be on takes a minimal of weeks to get a fix to production.
This was not acceptable to us and the customers. So we got our special rules to keep supporting the customers. We had to be the exception to the rule which is indeed more secure and official, but does not meet the need to fix production issues within hours.

Maybe at some point we need to package the software and get into the official way of deployment. But then we need to drop the support for production fixes within x hours.
It is a choice between rules/security and making less money for the company when shit happens.

The counter argument is valid also. A less tight secure system could make shit happen, which will loose money for the company.
So it is up to the company to define their business and which risks they want to take. My advice is to give the pro's and cons for each choice.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

monchotgu
Honduras
Posts: 75
Joined: 24 Apr 2017, 02:55
Location: Honduras

Re: Deploying TD in a secure environment

Post by monchotgu » 12 Oct 2020, 17:22

Hi Dave, when you said "we have designed a xcopy deployment system which updates the application on workstations automatically."

Do you use xcopy in command line ? And run a Batch file. Or You created a PRogram in CTD to run the xcopy?

Thanks

Igor Ivanovic
Site Admin
Site Admin
Croatia
Posts: 1365
Joined: 05 Mar 2017, 12:37
Location: Zagreb, Croatia

Re: Deploying TD in a secure environment

Post by Igor Ivanovic » 13 Oct 2020, 05:38

Dave,

Great info, thanks.
Some time ago I used the same principle with xcopy and it was working great, but as the customer tightened their security I was forced to use InstallShield for installation and updates, as I had problems copying files into program files folder. It also worked ok for some time, but then they tightened the security even more and I am having more and more problems.
You must understand, it's bank group, and the department that is using my software is in their terms a small one.
It took me fifteen years for my app to enter their helpdesk system and aknowledge we even exist...
Oh, and they even have outsourced desktop sw installations to a third party...

Now let me get back on track.
I am interested if I could make it work again, but I have a question.
Do you install your app in a program files folder or is it installed in it's own folder to circumvent windows security with xcopy?
Igor Ivanovic
Image

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3145
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Deploying TD in a secure environment

Post by Dave Rabelink » 13 Oct 2020, 06:29

monchotgu wrote:
12 Oct 2020, 17:22
Do you use xcopy in command line ? And run a Batch file. Or You created a PRogram in CTD to run the xcopy?
Well, I still talk about xcopy method, but we are not using any batch/cmdline/vbs anymore. But the files are still just copied from A to B.

So the deployment system had to follow this rule: a setup (MSI) is authorized to users (AD group) and is pushed or installed by the user.
It always has admin rights.

Initially the setup installed only one file, a vbs script. Also a set of items (links) were added to the Windows start menu. Pointing to the vbs script.
When the user starts the application from start menu, the vbs script first checks if another vbs script was available on the server.
It downloads that vbs script and will call that script to execute. The contents of that second script can be changed so we have total control over what it executes.

The second script did some checks on the system and executed a sync which copied all TD runtime files to the local system in the same folder as the application.
Then it syncs a TD executable which is started. That application offers a nice GUI (progressbars and texts) and will sync the rest of the application files (exe's, apd's, dll's etc).

Afterwards it starts the "real" application from local folder.

The sync only copies changed files. So when no update is needed, the application immediately runs. When we only change one dynalib, only that dynalib is synced from server.

Unfortunately, the security rules were changed and any bat of vbs scripts were not allowed anymore.

So now we have mainly the same method. But instead of a initial vbs script, it installs a very small .NET application doing the same thing. Minor checks.
It now syncs an assembly from the server as a plugin for the initial .NET executable. So we are still in control of the contents of the plugin.

The plugin will check and sync all needed files using a nice GUI to inform the user of updates.
When all is done, the plugin will start the main TD application.

All in all, no registrations or admin rights are needed AFTER the application is installed by the MSI setup. Only one file is installed.
The plugin system and the rest of the TD application are fully in our control and can be changed at any time just by replacing files on the server.

We have to introduce signed executables yet. So that we can only deploy executables which are fully signed. But that is only an extra step in the build process.
Igor Ivanovic wrote:
13 Oct 2020, 05:38
Do you install your app in a program files folder or is it installed in it's own folder to circumvent windows security with xcopy?
We are only allowed to deploy and start applications from program files folder. Any executable on a different location are blocked by policy.
So we have one subfolder in program files and put all into that one folder. The TD runtime and all other custom stuff we need.

The exclusion we got here is that we (in fact the initial sync executable and plugin) are allowed to copy files to that particular folder.
Having signed executable it offers extra security, but still has the authorization to write to the folder using the user credentials.

This method is very effective as it allows us to quickly place changes on the server which are synced to the workstations when needed.

Also the deployment system is created in TD which shows all changes and files on the server and we can easily using that tool to move releases from Test to Acceptance to Production levels. The end user can start the application in any of the levels using the correct start menu items. The sync method will setup the local system to that level by syncing the needed files.

But this only works because the security department ha given us the approval for this system.

When we would not have this exception, we have to package the complete application as MSI and let it push to all users.
The design and testing and placing it in production would take at least weeks.

So if we need to change one line of code to fix an issue in production we would loose all those weeks.
Now it is a matter how fast we can rebuild, place on server which could take a couple of minutes to get it to the users.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Igor Ivanovic
Site Admin
Site Admin
Croatia
Posts: 1365
Joined: 05 Mar 2017, 12:37
Location: Zagreb, Croatia

Re: Deploying TD in a secure environment

Post by Igor Ivanovic » 13 Oct 2020, 07:11

Very nice system I must say.
Thank you Dave for sharing it with us.

It seems to me that I will have to fight and get some exceptions about deploying new versions in order to have my customers satisfied.
Igor Ivanovic
Image

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3145
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Deploying TD in a secure environment

Post by Dave Rabelink » 13 Oct 2020, 07:45

Where are the days we could just copy all our shit into the system32 folder :?
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

monchotgu
Honduras
Posts: 75
Joined: 24 Apr 2017, 02:55
Location: Honduras

Re: Deploying TD in a secure environment

Post by monchotgu » 13 Oct 2020, 19:07

Thanks Dave for taking the time to share!

Uwe van der Horst
Site Admin
Site Admin
Germany
Posts: 490
Joined: 05 Mar 2017, 14:21
Location: Wetter (Ruhr), Germany

Re: Deploying TD in a secure environment

Post by Uwe van der Horst » 14 Oct 2020, 08:56

Dave Rabelink wrote:
10 Oct 2020, 09:43
I try to avoid using the TD deployer at all costs.
Me too.
First of all, I have found it be better to deploy the TD runtime along with the application. So install the runtime in the same folder as the application.
For most installations, a xcopy is enough.
Same here.
When COM registrations or specific registry settings need to be applied, using InstallShield setup project is the way to go.
For COM registrations, we create a Digicert-signed register.exe-application that generates a batch file in the local Temp folder on the client PC, which is then executed via ShellExecuteExW with the "runas" parameter. If the user does not have Win admin rights, the Windows dialog opens asking to enter the user name and password of the Win Admin. This works, but it is painful when a customer has a secure system with many clients. I guess that there is no way to register COM objects without Windows admin rights?
Best regards,
Uwe van der Horst
Advo-web GmbH

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3145
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Deploying TD in a secure environment

Post by Dave Rabelink » 15 Oct 2020, 06:32

Uwe van der Horst wrote:
14 Oct 2020, 08:56
...I guess that there is no way to register COM objects without Windows admin rights?
There seems to be a way to create a custom .reg file from the original COM registration and change the keys from HKEY_CLASSES_ROOT to HKEY_CURRENT_USER.
This may be allowed to write to the user part of the registry.

Some explanation here:

https://stackoverflow.com/questions/371 ... hts-regasm

I did not try this myself.

Another option is to do registration-free COM:

https://docs.microsoft.com/en-us/previo ... dfrom=MSDN


This we implemented and works in TD. But it can be a pain to set this up, specially to get a correct .config and manifest file.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Return to “General Discussion”

Who is online

Users browsing this forum: [Ccbot] and 0 guests