Deepnet Server v3.x migration

The migration of deepnet server (v3.x) is very simple.

• stop Deepnet Authentication Server(das) service


It can be done by typing "net stop das" in Command Prompt


• stop MySQL(dasmysql) service(if applicable)


Do it with "net stop dasmysql"


• backup whole deepnet folder


By default, it is called "Deepnet Authentication Server" in the folder "C:\Program Files"


• copy the backup to the new server


For simplicity, you should copy the backup to "C:\Program Files" on the new machine, just keep the path same.


• start the services on existing server


If you still need the deepnet service running on the existing machine for a while, you can start them by the reverse order, which are

net start dasmysql

net start das


• save the following code to a batch file(migration.bat) on the new machine




"%cd%\mysql\bin\mysqld.exe" --install DASMYSQL --defaults-file="%cd%\mysql\das.ini"
net start dasmysql

"%cd%\Tomcat\bin\tomcat5.exe" //IS//DAS --Startup=auto --StartMode jvm --StopMode jvm --StartClass org.apache.catalina.startup.Bootstrap --StopClass org.apache.catalina.startup.Bootstrap --StartParams start --StopParams stop --Install "%cd%\Tomcat\bin\tomcat5.exe" --LogPath "%cd%\Tomcat\logs" --Classpath "%cd%\Tomcat\bin\bootstrap.jar";"%cd%\jython\jython.jar" --Jvm "%cd%\jre\bin\server\jvm.dll" --DisplayName "DAS" --Description "DAS SERVICE" --StartPath "%cd%\Tomcat" --StopPath "%cd%\Tomcat" --JvmOptions "-Dcatalina.home=%cd%\Tomcat;-Dcatalina.base=%cd%\Tomcat;-Djava.endorsed.dirs=%cd%\Tomcat\common\endorsed;-Djava.io.tmpdir=%cd%\Tomcat\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%cd%\Tomcat\conf\logging.properties;-Dpython.home=%cd%\jython"

net start das




• move the batch file to Deepnet folder


You must place the batch file in the deepnet folder, which is "C:\Program Files\Deepnet Authentication Server"


• run the batch file


On the new machine, open a Command Prompt, go to deepnet folder, run migration.bat


• open a web page http://localhost:8080


Still on the new machine, launch a browser, access http://localhost:8080, assume you are using the default port of deepnet management console. It will ask you to input new IP address of the new machine. Don't forget to click Submit button to finish.

Mind you, it is against Deepnet license agreement if you run the same license on two different machine simultaneously(unless it is a load-balance/failover infrastructure), so please fully shutdwon the deepnet server on the old machine once the migration is completed.

Two Factor Authentication on RDWeb

Some vendors provide a solution to protect MS Remote Desktop Service(RDWeb) with OTP, the implementation and deployment are very easy, just customize the RDWeb login page(C:\Windows\Web\RDWeb\Pages\en-US\login.aspx) and add a OTP authentication dll to BIN folder (C:\Windows\Web\RDWeb\Pages\Bin).



Really it is very neat, but is it safe? I was a bit wary of that.

In order to answer my own question, we have to understand how RDWeb works. Thank my friend Craig who provided me this link How TSWeb / TSAC / Remote Desktop Web Connection Client Works. In this article, the author Tristan Kingston says,

There's a common misconception that TSWeb allows you to connect to a Terminal Server over HTTP. The reality is that you just use HTTP to transfer the Remote Desktop Client ActiveX control to the client browser, which then runs and makes a regular RDP connection to the Terminal Server, just like the regular Remote Desktop client would, but presented in a browser window.

Short version: HTTP and RDP are used to connect to a TSWeb server. HTTP (TCP 80) is used to download the ActiveX control, which then connects directly using RDP (TCP 3389) to whatever server is specified by the page for the actual Terminal Server interface. Clients that can't use port 3389 through a firewall won't be able to connect, so clients that exclusively have Web protocol access are not able to use this method to connect. (They'll be able to download the client and the page, but not able to do the actual Terminal Server part)."

It was posted almost six years ago, however the conclusion is still correct.

Recently I had time to play with RDWeb. I published 2 applications.

When I tried to click one of them, Remote Desktop(mstsc.exe) was launched

From the result of Process Explorer, it was evident that mstsc took part in this job!

Still not convinced? try the option "Don't allow connections to this computer" on the RDWeb server

Unluckily, I got the result which was expected though. Without Remote Desktop, RemoteApp doesn't work at all!

Now imagine if I were an intruder, do you think I would bother to access RdWeb? No, I would access Remote Desktop directly!

Frankly, the protection through RDWeb is still feasible if there is an easy way to block Remote Desktop while allow RemoteApp only. Unfortunately, ServerFault has a verdict on this question - Allow only RemoteApp, not Remote Desktop,

There isn't an "officially sanctioned" way to do this because, fundamentally, TS RemoteApp functionality is just leveraging existing Remote Desktop code. You could do something silly like use Group Policy to set the user's shell to be "logoff.exe" such that if they attempted to access the machine's desktop they'd be immediately logged-off. Any application that uses a common "File / Open" dialog, though, can be used to get a command prompt or other programs open on the server's desktop.

You're better off making sure that you follow the principle of least privilege and give your TS RemoteApp users as few rights as they need to run the intended software. If they do end up on the server computer's desktop their restricted rights should prevent them from doing anything damaging to the server computer.

Is it a neccessary burden to the administrator for enhancing the secure access? Do you want to completely block the Remote Desktop? You'd better think it twice! Nervertheless, I think it is very possible to leave a back door open if you only customize the RDWeb login page to do a two factor authentication.

All of a sudden, I realized why Deepnet always recommended adding the second factor protection at credential provider level(LOGONUI.exe). Even if you are using RemoteApp only, the second factor login kicks in at some stage.

Reference

TS RemoteApp Step-by-Step Guide

How TSWeb / TSAC / Remote Desktop Web Connection Client Works

Allow only RemoteApp, not Remote Desktop

Deepnet Windows Logon Solution

There are a few cases that the user can't login with OTP after installing Deepnet Windows Logon Solution.

In Event Viewer on the domain controller, you see some error logs emitted from a source called "DasDCAgent", and the error detail reads:

Get ticket from client failed: Domain MYDOMAIN
Domain Controller: DC IP
Workstation: MYWS
User: me
Connect to client failed
ErrorCode: E-FAIL

This error message means the domain controller(actually Deepnet DC Agent) is unable to contact a service (Deepnet Client Agent)installed on client machine(workstation). There are two possibities.

Workstation Side

Deepnet Client Agent port 14283 is blocked by Windows Firewall(or other software firewall installed)


Deepnet Client Agent default port 14283 is taken by another process(rather than dasclientagent.exe)


The service "DAS Client Agent" doesn't start properly

Domain Controller Side

Somehow the DC can't resolve the workstation name to a correct IP address which is allocated on the workstation. Generally it is down to a DNS problem. You can confirm it by executing a ping command in Command Prompt.


ping MYWS


Check the result to see if it matches the one returned by doing "ipconfig" at your workstation side.

Ironically, the inverstigaton on all of the reported cases only goes to prove the problem was caused by incorrect IP resolve at DC side - DNS corruption!