netop remote control version 7.65

1

Modifications to NetOp Remote Control v. 7.65 Windows 2003 – XP – 2000 – NT – ME – 98 – 95 – CE Linux – Solaris – Mac OS X – ActiveX – Symbian OS

Current version 7.65 Latest build 2004-342 Shipping from 2004-12-22

Compared to version 7.65 build 2004317 all the error descriptions listed below have been fixed in this build.

Installation The Windows Host’s Setup wizard showed the wrong wizard page if the user selected “Custom “

and entered two non-matching passwords.

To configure the Windows firewall during silent install the following two parameters are available in the INSTALL section of SETUP.ISS: [INSTALL] WF_ENABLE_APP=1 WF_SUBNET_ONLY=0 If the values were not defined, the InstallShield installation program treated the values as set to zero, that is the firewall would not allow communication through it. The installation program would thus overwrite existing settings defined in the firewall. In addition a new log line is added to the install.log: Windows Firewall: Supported=1, Configure=1, EnableApp=1, SubnetOnly=0

The setup files for “Host modules” and “Minimal Host” that could be saved from the download files called <language>.EXE did not work.

Security Confirm Access was not shown on the Windows Guest if the Guest module was minimized to tray.

This could happen if the command line or a phonebook entry was used to start a connection while the Guest was minimized.

Windows Security Manager and Server could not use a BDC (Backup Domain Controller) to find group memberships in Windows NT Domains.

The NetOp Guest ID property "No callback" found in NetOp Definitions / Guest ID / Edit .../ General tab / Callback mode was not visible in the Windows Security Manager.

In the Security Manager “Active Connections”, “NetOp Log” and “Security Log” with automatic refreshing activated did not show more than 50 items after the first refresh.

Communication Name server support added to Windows CE Hosts.

Because of the caching of address resolving for Security Server and Name Server it imposes a problem to restart these modules. They get a different internal NetOp address when enhanced IP address is enabled. Enhanced IP address is enabled as default for all modules. With this build this is

2

changed for Security Server, Name Server and Gateway where the default now is disabled. Enhanced IP address is enabled as default for Guest and Host modules.

Misc. The Windows Host did not allow keyboard and mouse control if call back was used.

On the Windows Guest the Help Request life-belt did not disappear when requests were deleted.

Once a Windows Host had been run, it would be reloaded at every logoff until the next reboot. This happened even if that Host was NOT configured to "Run As Service".

Misc. changes for Linux and Solaris Guests and Hosts to improve stability.

Please notice the following builds numbers are released with this version: - Windows 32 bit modules 2004342 - Windows CE modules 2004342 - Linux Guest module 2004335 - Linux Host module 2004335 - Solaris Guest module 2004335 - Solaris Host module 2004335 - Mac OS X Host module 2004049 - ActiveX Guest module 2004202 - Symbian OS Guest module 2004052

3




Security Microsoft Hotfix KB840987 for Windows 2000 requires updated NetOp drivers.

On October 13, 2004 Microsoft released an urgent security update for Windows named KB840987. The Windows 2000 variant of that security update unfortunately has the side effect of requiring an update to the NetOp drivers in order for keyboard and mouse handling features in NetOp to remain fully functional. If the Microsoft update is installed without a corresponding update to NetOp, NetOp will be forced to use a less reliable fallback algorithm, which may result in some or all of the following symptoms: • When using NetOp to lock the keyboard, the user can bypass the lock by pressing "Ctrl+Alt+Delete" and then "Escape". • Some advanced keyboard sequences, typically used with accented letters, Asian or Middle Eastern languages might not be received correctly. • Some programs do not accept remote mouse clicks or keystrokes in any case. This build includes the updated drivers needed. Previously, a standalone fix for the same issue was released, so users may already have protected their computers.

A Windows Host running with “Public Host name” disabled and Host name set to “Enter name or leave name field blank” inserted a random Host IP address in the event log.

When the Windows Guest’s Guest ID was blank, the Windows Host displayed a random IP address in the Connection Notification and Disconnect Notification messages.

When the Windows Guest’s Guest ID was blank, the Windows Host inserted a random Guest IP address in the event log.

Graphics The screen transfer from a Windows Host was slowed down when disabling and enabling Active

Desktop.

Communications It was impossible to connect by IP address to a Windows Host running with “Public Host name”

disabled, if the Windows Guest used the setting “Check for duplicate names before connecting” or tried to establish the connection through an incoming NetOp Gateway.

Installation To facilitate mass deployment of NetOp in large networks, Danware has been offering licensed

users the option of performing their deployments using reduced size setup packages in which the NetOp components that would not actually be used in their deployment had been removed from the

4

actual setup package itself. Previously, these packages were only available for the English language version of NetOp Remote Control, however starting with this build; such subsets are available in most of the same languages as NetOp itself, and for both the NetOp Remote Control and NetOp School product families. To access the reduced size packages, download the "InstallShield based" product from our download site, run the self extracting file (typically called UK.EXE, DE.EXE, FR.EXE etc.), enable the "Advanced" check box on the first program page, select either the "save" or "diskettes" operation, choose a directory for the unpacked files and you should then be prompted to select which (if any) reduced size subset you prefer. This method of obtaining the subsets was introduced with the initial release of NetOp 7.65, but until today, only the traditional subsets of English NetOp Remote Control were actually included in the downloads, now they all are.

Misc. The Windows Security Manager did not display more than 50 workstation groups.

NetOp Remote Control copyright messages now say 1981-2004 not 1981, 2004.


5



Enhancements As part of our continuing effort to strengthen the security of NetOp, memory system objects (such

as processes and memory) used by NetOp on Windows Server 2003, XP, 2000 and NT 4.0 are routinely protected by strict Windows-based access permissions that prevent or limit misuse by viruses or unauthorized users. Beginning with this build, the granularity and strictness of those permission settings has been made even stricter, especially in multi-user environments such as Terminal Servers or Windows XP Fast User Switching.

To be at the cutting edge of future developments in intrusion methods the Windows Gateway authentication mechanism used for dynamic connections via TCP, ISDN and modem has been enforced with additional internal security routines.


Security This build fixes 3 small information disclosure issues found by Martin O'Neal of Corsaire ltd. The

Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2004-0950 to the issues summarized below: - If a Windows Host was configured with "Public Host Name" disabled, the Host itself, the Host name, the User name and the IP address of the Host could still be still be found by browsing with tools other than NetOp Guest. The implementation of the "Public Host Name" checkbox has been improved, so un-checking it makes NetOp no longer reply to such browsing attempts and not include the Host Name, User name or IP address in replies to certain other requests. - As a consequence of this security fix, the MAC/IP Address Check option now checks against the address of whatever Firewall or NetOp Gateway the connection passed through last before reaching the Host, previously it checked against the address of the Guest. This only makes a difference if the call is made through a NetOp Gateway or an address-translating firewall. - If an older Host is configured with MAC/IP Address Check, the New Guest cannot contact it unless you set the following option on the Guest in NETOP.INI: [TCPIP] Enh_ip_addr=0

The Windows Host module setting "Confirm Access, only when user is logged in" did not work. The Host always prompted for confirmation even though no users were logged on. The problem was not related to usage of the NetOp Security Server.

For a Windows Host set to use Windows Security Management on a computer with Windows Server 2003, it was not possible to add Windows users and groups to a NetOp Security Role.

6

When trying to connect to a Windows Host and exceeding the maximum number of password attempts, the Host correctly displays "Invalid logon-.... until OK", and disconnects the Guest. However the Host module still accepted new connections. The Host will now ignore further connections. In case the setting Program options / General / Allow multiple simultaneous Guest sessions is checked the Host will respond that it is currently remote controlled.

Installation A flaw in the Web Update files on update.netop.com caused attempts to apply updates directly

from SETUP.EXE to fail, but only if this was done from the InstallShield based variant of NetOp SETUP and only if an update was actually found on the web and accepted by the user. These download scenarios were NOT affected: - Updating from within an already installed NetOp. - Updating from within the single file setup programs that can be downloaded from the NetOp website. - Updating from within the setup.exe based on Windows Installer. - Checking for Web Updates when no newer update was available. - Checking for Web Updates, finding the Web Updates and reading the release notes - Declining to accept a Web Update. - Updating an installed program by simply installing a more recent NetOp build or version on top. - Installing NetOp without doing any updates. The Web Update files on update.netop.com have been corrected; the new files should work even with the previously released SETUP.EXE programs found on the NetOp Remote Control CDs.

Graphics Some ATI display drivers for Windows 2003, XP 2000 and NT 4.0 could prevent the Windows

Host module from detecting when the user was displaying a "DOS box" in full screen mode, leading to the screen not being transferred or recorded properly in that situation.

The Windows Guest module’s remote control window did not resize when video mode was changed on the Host for example by changing from a full screen DOS box to the Windows desktop or changing Windows resolution.

Misc. When the Windows Guest module used the setting Connection Properties / Host Window Fit / Do

Not Fit, a black frame occurred around the Host screen area, if the remote control window was sized to be larger than the Host screen area. Clicking in the black frame outside the Host screen area caused clicks to be transferred to the Host and executed on the Host computer outside, often at the edge of the screen.

If Microsoft Active Directory is supported on a computer NetOp Remote Control will as default use Active Directory system calls for e.g. authentication and adding users and groups to Security Roles. To force Windows NT 4.0 Domain system calls specify the following to the appropriate NETOP.INI section, e.g.: [HOST] NT4Domains=1 The default value is 0.

The Windows Guest module’s File Manager leaked memory.

7

Minor adjustments have been made in the WebUpdate scheduler.

A new NETOP.INI option has been introduced as a better alternative to older workarounds for only running Windows Host modules on the console session of a Windows Terminal Server or only on the primary (first) login session on Windows XP Fast User Switching. The new setting is [Host] NoTerminals=1 If this setting is placed in NetOp.INI and the NetOp Helper Service ("NetOp Host for NT Service") is then restarted, the following changes in NetOp operation and system load occur: 1. NetOp Host is not loaded at "Windows Startup" on the terminal sessions, only on the console. 2. NetOp Host as well as Gateway cannot be used on the terminal sessions even if started manually. 3. The NetOp Helper service is not loaded on each terminal session, thus saving some memory.

Sending a message to the Windows Host module failed if the Windows Guest’s Guest ID contained a slash ('/').


8



Enhancements Support for Windows XP Service Pack 2.

An updated version of NetOp is released to take care of changes introduced with Service Pack 2 (SP2) for Windows XP. To address the following fundamental issues, you are required to update previous builds to this build: - After applying SP2, the keyboard combination Ctrl+Alt+Del cannot be blocked any longer by the existing build 2004168 or previous. This influences the feature Lock keyboard and mouse. To keep the possibility for locking this keyboard combination you must update to this build. - The SP2 also prevents detection of the command console (CMD.EXE) going into full screen when using the existing build 2004168 or previous. To keep on working remotely in a full screen command console you must update to this build. - The new SP2 Windows Firewall will block communication with any application, if not added to the Exception List and enabled. As such NetOp must be added and enabled for incoming network connections to work. If you want to secure that NetOp automatically handles the necessary settings in the Windows Firewall, you must update to this build. - The Service Pack makes fundamental changes to the operating system affecting users of AMD64 processor based computers. In that case you must update your NetOp to this build. General recommendation: Since this build also contains a number of error corrections, it is in any case recommended to update to this build. Detailed notes about Windows XP Service Pack 2: AMD64 processor One of the changes is the NX ("No Execution") or DEP ("Data Execution Prevention") feature, which is available only on AMD64 and compatible CPUs (such as some Xeon CPUs). Without this build, any attempt to run NetOp on an AMD64 running 32 bit Windows XP with Service Pack 2 would fail with an error message from the operating system. Windows Firewall Installing Service Pack 2 after NetOp: - If you upgrade a Windows XP computer to Service Pack 2 and this NetOp build (or higher) is already installed, NetOp will automatically add the Host or Guest to the Windows Firewall and register it in the Windows Event Log. Installing NetOp after Service Pack 2: - As suggested by Microsoft, the NetOp Setup Program will ask the user to confirm an automatic change in the Windows Firewall settings to allow incoming network connections for the Host or Guest. The NetOp Setup Program will then store your answer as a new setting on the Exceptions List in Windows Firewall. The settings can be configured manually in the Firewall (disable/enable) afterwards, if desired.

9

If on such a computer, you install NetOp with a Silent Setup response file (setup.iss using Host Deployment), the equivalent answer is taken from the setup.iss file. The value in the INSTALL section is: WF_ENABLE_APP=1. If you reuse an older setup.iss file without the new setting, the answer is presumed to be ALLOW because NetOp is mostly useless with an answer of DENY. Windows Firewall setting deleted: If NetOp is deleted from the Exception List in the Windows Firewall, NetOp will automatically recreate the setting, assume an answer of ALLOW and log an explanatory message to the Windows Event log. To change such an automatic answer to DENY, simply open the Windows Firewall settings in control panel and uncheck the checkbox for NetOp instead of deleting the entry itself.

Cancel browse for Hosts While browsing for Hosts the Windows Guest user had until now patiently waited for the search to complete. A “Cancel” button has been added to the “Wait” dialog allowing the user to stop the search process. The search is stopped and whatever results obtained so far are shown or used in subsequent operations. This new option is for example available in browse from the Quick connect tab.

Reload the last running Host module. If more than one Windows Host program are installed on the same computer, and more than one of those are configured to load at boot (this is NOT a recommended configuration) and some circumstance forces NetOp to reload one of those modules, NetOp now tries to reload the module that was unloaded before it tries any of the other modules. Previous builds of the NetOp Helper Service always reloaded the most recently installed of those modules that were configured to load at Windows startup. Starting with this build, the NetOp Helper service first tries to reload the module that was unloaded, even if that module is not configured to load at Windows startup.

Default for Confirm Access changed. In order to prevent accepting Confirm Access unintentionally on the Windows Host, the Confirm Access dialog no longer has a default button. Focus is removed from the “Allow” button and pressing <Enter> will not allow connection directly. The user must navigate to the “Allow” or “Deny” button with the mouse or by using the <Tab> key.

Set session window size and position. The Windows Guest command line options can now set the initial position and size of remote control window. The option is defined as: NGSTW32.EXE /X:x[,y[,w[,h]]] where x is X position, y is Y position, w is the window width and h is the window height. The above command line is not complete, but must also contain other arguments like the Host address. The x position is mandatory. If y is not specified it will be defined as 0. If neither w nor h is defined the window will be default according to the Host Windows Fit option. If w is defined but not h, h will be set to 3/4*w.

Disconnect all sessions In the Windows Guest all running sessions can be disconnected by issuing the following command line: NGSTW32.EXE /D: The Guest will remain in memory without terminating. The command should not be used with any other command line switches.

10

Play sound on Guest events The Windows Guest now has the ability to play a sound file when the following events occur: Guest start: "GstStart.wav" Guest stop: "GstStop.wav" Connect: "Session.wav" Disconnect: "Discnct.wav" Communication error: "ComError.wav" The files in quotes must be present in the Guest media folder. If one or more files are not present, the sound is simply not played for that event. None of the files are installed today by the installation program and the Guest user has to copy the files there manually after install.


Installation Minor changes in the English Windows Installer installation.

Communications On Linux and UNIX Hosts repeated sessions on TCP and UDP could make them non-responsive

on TCP.

The Windows Guest crashed if connected to a valid non-RemPC NetBIOS name.

Security In light of the recent scientific results regarding security weaknesses in the MD5 checksum

formula, Danware have reviewed the use of the MD5, MD4, HAVAL, RIPEMD and SHA-0 algorithms in NetOp. HAVAL, RIPEMD and SHA-0 are not used by NetOp. MD4 is used only for interoperability with Microsoft products, and only in a way which does not depend on the (now vanished) security of the MD4 algorithm. The MD5 algorithm is similarly used in a few places that do not depend on the (now vanished) security of the MD5 algorithm. Additionally, some parts of NetOp rely on a security property of the MD5 algorithm which was not directly affected by the recent scientific results; this will be addressed at a later date. Finally there was a single place where NetOp relied on the MD5 algorithm being secure against "second-preimage" attacks. While the current scientific results do not directly invalidate that security property of the MD5 algorithm, it is likely that further scientific advancement will do so in the near future. Consequently, that particular use of the MD5 algorithm has been immediately replaced by the TIGER/192 algorithm invented by Eli Biham and Ross Anderson. TIGER/192 was designed with the specific goal of resisting the kind of attack now leveraged against MD5 and SHA-0. Once again, it must be emphasized that the recent scientific results do not pose an imminent threat to the security of NetOp, and that the changes made at this time are merely a precaution taken on the basis of likely future trends.

When Windows Security was used to authenticate connections to a Windows Host configured locally or via the Security Server / Manager, the extended local and universal group semantics of Windows Domains that used Windows 2000 or Windows 2003 domain controllers running Active

11

Directory in "native" mode was not utilized completely. Specifically, the kinds of groups that could be granted access to a Host have been enhanced as follows depending on the operating system and domain: - Windows 2000 or 2003 domain controller running native mode: local, global and universal groups from the server’s own domain; global and universal groups from other native mode domains; global groups from any domain. - Windows 2000 or 2003 domain controller running mixed mode: local and global groups from the server’s own domain; global and universal groups from other native mode domains; global groups from any domain. - Windows NT 4.0 domain controller (PDC or BDC): local and global groups from the server’s own domain; global groups from any domain. - Windows 2000/XP/2003 domain member in a native mode active directory domain: local groups from the computer’s local or group policy replicated configuration; local, global and universal groups from the computer’s domain; global and universal groups from other native mode domains; global groups from any domain. - Windows 2000/XP/2003 domain member in a mixed mode active directory domain: local groups from the computer’s local or group policy replicated configuration; global groups from the computer’s domain; global and universal groups from other native mode domains; global groups from any domain. - Windows 2000/XP/2003 domain member in an NT domain: local groups from the computer’s local or group policy replicated configuration; global groups from the computer’s domain; global groups from any domain. - Windows NT 4.0 domain member in any domain: local groups from the computer’s local configuration; global groups from the computer’s domain; global groups from any domain. - Windows NT/2000/XP/2003 standalone: local groups from the computer’s local configuration. - Windows 9x: global groups from any domain.

Starting the Windows Host program without having applied any Guest Access Security displayed a message that prompted you to Review your Security Settings. By checking the "Don’t Show This Warning Message Again" check box, the box temporarily went away but came back every time the Host was started.

In the Windows Security Server the synthetic Workstation Groups and Windows Users as Guests did not work with Microsoft Access database.

In the Windows Security Manager it was not possible to enter dummy Guest and Host IDs permanently into the database.

In the Windows Host a custom Host name can be used in all log events in Log Setup. The name was not updated properly when logging off and on the operating system.

The Windows Host crashed when common encryption format could not be negotiated.

When the Windows Host was using the Guest access method “Grant all Guests individual access privileges using Directory Services” against Microsoft Active Directory, members of the group Domain Users were denied access. In Active Directory all users are implicitly members of Domain Users. This relation is not stored in the Active Directory database and therefore not retrieved when querying the Active Directory database via LDAP. To solve this all users has been given a synthetic membership of the group Domain Users.

12

Microsoft Windows 2000 Hotfix KB841873 changed the permissions needed to load the Microsoft component NETAPI32.DLL. The permission adjustment code in NetOp has been updated to grant that extra permission. On some Windows 2000 Servers, the NetOp Host could not start without the extra permission, but on most other systems all programs have the required permission by default and this change is thus not necessary on other systems.

On Windows ME, 98 and 95 computers the Host did not show all Windows Groups while using the Guest Access method “Windows Security Management”. Due to a bug in Windows when reporting the number of Groups the Host fetched too few Groups. A built-in limitation sets the maximum number of Groups that can be returned to approximately 2600.

Graphics On Linux Hosts the graphics sometimes froze.

On Linux and Solaris Hosts some icons were not drawn correctly under openwin.

On Linux and UNIX Hosts no access to X display will now disconnect the Guest. Before a gray or black screen appeared in the Host window on the Guest computer and one had to disconnect manually.

The Linux and UNIX Guests displayed the Host window in wrong colors under certain circumstances. Please notice that the Guest has the 8-bit color design to use already existing colors only. When you try to map 256 new colors onto 256 existing colors, you are not always sure to get all colors exactly as they were on the host. This error correction gives a very acceptable set of colors and applies to the X11 Guests on Linux and UNIX, but only if the X display is configured to 256 colors.

Misc. In the Windows Host a bug in Microsoft Windows XP caused the IME bar to shrink whenever a

Host module (which includes Name Server, Gateway and Security Server) got focus, leaving out the possibility to use it for input of alternate signs in any Host dialog. After a while, the IME bar became unstable, in the end also preventing keyboard hotkeys related to this function from working. NetOp has been enhanced with additional code to work around this known bug in Microsoft Windows XP. The fix only affects IME based keyboard layouts (such as Japanese) and Speech input. Other operating systems or systems not using the IME bar for input are not affected. Under the condition that the computer is running Windows XP and the users profile specifies the usage of IME keyboard layout or alternative input system, please notice the following: - The Host modules will be reloaded whenever a user logs on or off. If the computer is being remotely controlled during logon or logoff, the reload will not happen until the Guest disconnects from the Host module. - The Host user can disrupt the operation of the Host program, so it is recommended to apply maintenance password or run the Host in stealth mode to prevent this from happening. Two new registry settings have been introduced to allow the system administrator to control this behavior, both are stored under the following registry key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetOp Host for NT Service\SecurityLevel]

AllowUserAlways Set this value to 1 to always use the workaround even on Windows NT/2000/2003 or XP without IME layout AllowUserNever Set this value to 1 to never use the workaround even on XP with an IME layout.

13

AllowUserAlways takes priority over AllowUserNever, both values should exist in the registry as soon as NetOp is installed and a user has logged on to the computer.

In the Windows Guest it was possible to start Inventory scan, Execute command, Run program and Send message from Connections tab while the File Manager or a Script was executing. This is now disabled everywhere else because the Host can only handle one Script session at a time. Launch of these commands are now disabled as they are in the rest of the user interface.

The Windows Host crashed if Restart was send from the Guest during Inventory retrieval.

When making e.g. an Inventory scan on a remote controlled Host the connection dialog would just show an error like: "Error = 0x1355". Descriptive error texts have been added in Inventory, Send Message, Execute Command and Run program dialogs.

The Windows Guest crashed when making a session recording with the Recordings tab disabled.

Transferring the Clipboard between the Windows Guest and Host sometimes caused a crash in either of the programs. Please notice that not all Clipboard formats are supported especially when using OLE.

By pressing the "restart" button 3-10 times very fast the Windows Host crashed.

The remote control ActiveX component crashed if the first thing adjusted was the Name Server settings.

The remote control ActiveX component did not display proper message texts if the user entered invalid numbers in properties dialog.

If the user presses Ctrl+Alt+Del in remote control ActiveX component, the delete key will no longer be sent to the Host. Instead, Alt-release and Ctrl-release events will be synthesized. The default keys for simulating Ctrl+Alt+Del on the Host are Ctrl+Alt+F7 as it used to be. If the default for simulating Ctrl+Alt+Del is changed to Ctrl+Alt+Del (53), then both Guest and Host will receive Ctrl+Alt+Del simultaneously. On the Host, in addition to this, also Alt-release and Ctrl-release events will be synthesized.

On Linux and UNIX the Host sometimes crashed after approximately 31 sessions.

Linux and UNIX Hosts will now write to this file /var/log/netophostsignal.log, if they catch a system signal. This is a useful feature for preserving a log after the Host has been restarted by the daemon. This can also be used to get a log file by typing kill -3 <pid> from a command prompt, where <pid> is the process id of the Host. The process list can be displayed by typing ps -ef | grep -i netop.


14



Enhancements The Windows Guest command line can now accept parameters for Host and Gateway login. The

parameters correspond to the Login tab in Connection Properties. Host command line login information: /LHN:Name /LHP:Password /LHD:Domain Gateway command line login information: /LGN:Name /LGP:Password /LGD:Domain An option containing blanks or white space characters must be included in quotes. Example: /C:TCP/IP "/H:My Host" "/LHN:PC 2" /LHP:password /LHD:MyDomain

The requested Help Service is now shown on the Windows Guest: - The Help Service Name is added as a separate column. - Is available as the command line option %S for "Run Local Program" in "Help Request Action". Older Hosts with predefined Help Service Problem Description will be truncated to 95 characters because the new Help Service Problem Description has been fixed to 95 characters. For old host the Help Service name will be blank.

The help request can now be deleted on Windows Guest from the Pop Up menu. The request will only be deleted locally on the Guest and has no effect on the Host.

If the Windows Guest is started from the command line with the /P: or /H: switch to control a specific Host an extra switch can be specified to set the title of the session windows (Remote Control, File Manager, Chat, Audio Chat): /T:Title for example: "/C:LAN (TCP)" "/H:My Host" "/T:My Title"

Audio chat now supports 16 bit audio samples.

A new NETOP.INI has been added to the Windows Guest to disable the Local File Transfer button and menu item in the main Guest window. The setting does however not affect the File Manager.

15

[GUEST] DisableLocalFileTransfer=1 Default value is 0 which means the Local File transfer icon is enabled.

The Windows Security Server and Manager now operate more flexibly regarding the scanning for domains and computers on pure Windows NT 4.0 domains. Active Directory domains are not affected. You can control the features in the NETOP.INI file by adding these entries: [NSS] NT4DOMAINS=1 NT4DOMAINLIST=DOM1,DOM2,DOM3 NT4DOMAINSCAN=0 COMPUTERSCAN=0 NT4DOMAINS Set this to 1 to disable all use of Active Directory functionality, even if present on your local workstation. This is useful to access Windows NT 4.0 domain controllers via pure Windows NT 4.0 functionality, even if the Active Directory functions are available on the Security Server computer. NT4DOMAINLIST=x,y,z, Instruct the Security Manager that these are the names of your domains. It will then assume that such domains exist. If NT4DOMAINSCAN was set to 0, only the domains from this list are visible. If it was set to non-0, the list is a combination. NT4DOMAINSCAN Set this to 0 to omit the scanning for Windows NT 4.0 domain controllers. This will result in no domains listed, unless you also use the next keyword COMPUTERSCAN If this is set to 0, then domains will not be scanned for computers. No list to select from is presented. Instead, a text field will be available for entry. It is the users’ responsibility that what you enter really represents a computer. This feature is valid for any type of domains, Windows NT 4.0 as well as Active Directory.


Installation The Windows Setup program now defaults to showing "Check for Updates" as unchecked to avoid

long timeouts if an Internet connection is unavailable.

In localized versions of the Windows programs where Danware only has supplied an InstallShield based setup program, the downloadable files on the http://www.netop.com (with file names such as AR.EXE) refused to install or unpack.

The moment you click “Next” in the Windows installation wizard the installation folder chosen is created on the hard disk. If you later click “Back” and then alter the installation directory, the already created directory is not deleted.

Graphics In version 7.6 the Windows modules changed the default font from "MS Sans Serif" to "Tahoma" –

the standard on newer operating systems (for all western languages). Unfortunately Tahoma didn't exist on Windows 95 and Windows NT 4.0, which lead to dialogs with erroneous fonts.

16

The Windows Guest’s Session recording didn’t show cached bitmaps.

Communications The Windows Guest and Host sometimes crashed on startup if the modules were configured to use

a NetOp Name Server.

When connecting using CAPI on a Windows module, the second remote-control session connection was not able to send mouse clicks or keystrokes.

It was not possible to specify the communication profile on the Windows Host command line: nhstw32.exe /C:TCP /R:HOSTNAME

Security Until now the first Windows Guest connecting to a Windows Host gained keyboard and mouse

control, if the permission (access privileges) allowed it. Subsequent Guests would never get keyboard and mouse control. This is now changed so that the Host will give keyboard and mouse control (plus lock keyboard and blank screen) to the first Guest with permission to keyboard or mouse control. If the first Guest doesn't have permissions to use keyboard or mouse the right will be given to the following Guest, etc.

The following changes have been made to the Windows Guest login dialog boxes: The login dialog for Default, NetOp, Security Server, Directory Services and RSA authentication have been updated to show “Login to {Host name}”. They will now be similar to the dialog box for Windows authentication. - The Default Login dialog title is changed from "Password" into "Login using NetOp authentication". - The NetOp Login dialog title is changed from "Login" into "Login using NetOp authentication". - The Windows Login dialog login name is changed from "Login name:" into "User name:". - The Windows authentication Login dialog title is changed from "Login using Windows NT authentication" into "Login using Windows authentication".

Security Servers using the Guest Access Method “Use Security Server” sometimes crashed.

The Windows Security Server sometimes crashed if the local system time returned a number of seconds, which was less that the number of seconds in “Clean up log entries older than” and the “Run Scheduler” was enabled.

The Security Manager did not do anything in case communication with the database server was lost. A message box is now displayed and after pressing the OK button the Security Manager unloads. The feature is needed if you have a clustered database failing over, and you run the Security Manager on the same computer as the Security Server. Until the Security Manager is exited, the Security Server will not be able to authenticate Hosts, because the failing over obviously does not take place until all applications have released their database handles. Please note that an inactive Security Manager thus will cause Security Server disoperation. It must be actively exited, which will happen as soon as you do any Security Manager operation that accesses the database.

Some Windows NT 4.0 system administrators lock down their registry using Security settings similar to those that are the default on Windows 2000. When this is done, special permissions need to be added for the NetOpActivity group or NetOp won't start. Beginning with this build update, NetOp now automatically sets those permissions on Windows NT 4.0 as well.

The Windows Security Manager crashed if an NT 4.0 workstation group had more than 50 members.

17

The Windows Security Manager could not show more than 50 role assignments when running with Microsoft SQL Server. Microsoft SQL server has a limitation of only being able to fetch from one database view using the same database connection. This has been overcome by disabling the "more" buttons when the database is Microsoft SQL, and for that vendor only always shows all records in the main role assignment table. This may cause the program to take some time at start up if there are many assignments, though.

The Windows Security Server Tools / Security Server setup dialog was not updated properly.

The Windows Security Manager did not in certain cases use Active Directory or Windows NT 4.0 functions correctly to select Windows items like users and groups. If ACTIVEDS.DLL is available on the computer and [NNS] NT4DOMAINS=1 is NOT present in the NETOP.INI or set to 0, then the Security Manager will use Microsoft Active Directory dialogs to select Windows items. If that is not the case, the Security Manager will use Windows NT 4.0 functions and dialogs.

In the Windows Security Manager the Host ID dialog automatically converts host names, which are IP addresses to xxx.xxx.xxx.xxx. If you enter a new host ID as 1.2.3.4, it is stored as 001.002.003.004. This is what the Host reports as identity to the Security Server. If you edit an existing host ID, its name will be changed accordingly.

The Windows Host can be configured to log off or restart after a Guest connection. If the Windows XP/2000/NT computer was Locked and a log off or restart was attempted the computer ended up in a limbo log-off state, pressing Ctrl-Alt-Del and logging off was the only way to handle that.

The Windows Security Server saved the log files EL<YYMMDD>.DWL (NetOp Log) and SL<YYMMDD>.DWL (Security Log) in the current Program Files folder for the latest installed NetOp module instead of in the All Users profile.

Inventory The Windows Guest did not retrieve Inventory from a Windows Host if the Guest’s Inventory tab

was disabled.

When dragging entries from the right of the Windows Guest’s inventory pane the items were deleted from the view. Dragging should only be possible when the right pane shows the overview of inventory scans (when the left pane selection is a folder), but not when displaying inventory information.

File Transfer By selecting and copying two files with the same name except for a difference in the letters’ case in

the same folder from a Solaris, Linux or Mac OS X Host to a Windows Guest in the same operation caused the File Manager to loop endlessly.

If more than three File transfer sessions were started, the Windows Guests crashed.

The <my documents> in the Windows Guest File Manager did not point at the correct folder on Windows XP.

If Closeafterlastsession=1 is set in NETOP.INI the Windows Guest crashed after running a script when the session was closed.

18

Version 6.5 scripts did not work on a 7.6x Windows Guest.

The Windows Guest script timeout did not work with batch files.

When trying to save a read-only script file on The Windows Guest, no error dialog was displayed.

Misc. The Windows Host used quite long time to exit if no communication profiles were started.

The Windows Host did not load at boot on certain Windows 2003/XP/2000/NT systems. This most frequently occurred on Windows 2000 Domain Controllers, but other 2000/NT systems were also affected if the administrator had applied the stricter file permissions normally used on Windows 2000 Domain Controllers. Windows 2003/XP systems were much less likely to be affected because NetOp uses the "Local Service" user name on those operating systems.

When a Windows Guest logged in to a Windows Host with Guest Access privileges set to NetOp Authentication, Windows Security Management or Directory Services the Host displays the login name in the Confirm Access dialog, in the title bar of the Host and the History tab. The Host did not display the login name with Guest Access privileges set to Security Server.

Send Message was not displayed on a Windows Host in Stealth mode and the “Minimized on startup” was unchecked.

The Windows Guest and Host were not able to use Caps Lock key press in a combination with another key as a hotkey.

The Windows Guest and Host sometimes crashed during an Audio Chat session if an encryption level other than NetOp 6.x/5.x compatible was selected.

The Windows Guest and Host audio chat could not use full duplex.

Entering Japanese characters in the Windows Guest’s Host name field or the Windows Host’s Host ID field by using double-byte characters terminated by the <Enter> key gave corrupted characters.

The password dialog box that popped up on a Windows Guest connected to a Host using Default Access Privileges did not look like the other Guest Access Method login dialog boxes.

When using different fonts as in Asian languages font or enlarged font in western languages a displayed bitmap in a dialog may appear too small. This can be solved in the following ways: 1. Having bitmaps for any font type and font size (=impossible) 2. Stretching the current bitmap (seldom looks good) 3. Painting the unfilled area with a background color similar to the bitmap. 4. Center the bitmap instead of showing it in the upper left corner. The following approaches have been used for the bitmap dialogs: Wizards: 3. Painting the unfilled area with a background color similar to the bitmap. Registration dialogs: ~1. Two sizes of bitmaps are used for 8- and 9-point fonts. About box: 4. Center the bitmap instead of showing it in the upper left corner.

The fonts used by the Initial Wizard used when interactively running NetOp Setup or the downloadable NetOp packages from http://www.netop.com have been changed for most combinations of Language and Operating System. This also solves a specific issue when running English or other Western versions of NetOp Setup on Japanese Windows 2000 or Windows XP. Those Windows versions incorrectly hide parts of Western wizards if those wizards specify the Western font explicitly.

19

By pressing F1 in a remote-control session on Windows 9.x and Windows NT 4.0 the Windows Guest Help popped up as in any NetOp dialog. For the Windows NT 4.0 platform it only appeared if local keyboard was enabled.

If a NetOp School Teacher and Windows Guest were running at the same time on a computer, the Guest failed to send messages to Hosts. The Guest reported success, but the Host received nothing.

Various Portuguese text corrections in the Windows modules.

Error in the Spanish and Portuguese tabs bitmaps.


20




Installation With the “Check for updates” checkbox selected at manual installation from the CDROM on

Windows NT4, Windows ME, Windows 98 and Windows 95, the SETUP program crashed.

On Windows ME, Windows 98 and Windows 95 the Web update options "Install later" and "Cancel" later followed by a reload of the NetOp module sometimes caused the operating system to stop responding.

Misc. Please notice the following builds numbers are released with this version:

- Windows 32 bit modules 2004058 - Windows CE modules 2004052 - Linux Guest module 2004049 - Linux Host module 2004049 - Solaris Guest module 2004049 - Solaris Host module 2004049 - Mac OS X Host module 2004049 - ActiveX Guest module 2004052 - Symbian OS Guest module 2004052

21



Enhancements The document NRC765-release-notes.pdf available at www.netop.com holds information about the

new features in version 7.65. The enhancements described below in this document are minor changes to existing features in version 7.60.

Palette handling for command mode added to the ActiveX Control NetOpX and Windows CE Guests.

The Windows Guest File Manager now displays more file information when the Guest user is prompted to delete or overwrite a file. A new Guest and Host are required to provide his feature.

The Name Space ID used in conjunction with the Name Server can now be changed on the Windows Guest without restarting it, but it requires that all TCP/IP connections using Name Servers are disconnected. An exception is the situation when a TCP/IP communication profile using Name Server is initialized at program startup typically used by Guest modules acting as Help Providers. In this case changing the Name Space ID will not have any effect until the module is reloaded. The restart message will not be shown any more.

New Desktop/My documents entry in Windows Guest File Manager drive dropdown.

The Windows Guest File Manager can now save and restore browse location for each Guest/Host session. If no saved information is available the default selected drive will be set to system drive.

New silent install options for the windows Gateway: GW_DEF_PASSWORD String Gateway Password for default access privileges Empty string means no password GW_DEF_CALL_BACK Number Gateway Call back type 0:No callback, 1:Fixed number, 2: Roving GW_DEF_CALL_BACK_NUMBER String Gateway Call back number for default access privileges

For silent install of Windows modules the log file or SETUP.ISS (-L and -K) can now be specified on the command line.

For the Windows modules the NetOp program folder with the icons can now be suppressed when using silent install. Specify the following in SETUP.ISS: [INSTALL] DONT_SHOW_PROGRAM_FOLDER=1 The default value is 0, meaning that program folder is shown.

TAPI/Windows modem support can be disabled completely with the following NETOP.INI setting: [HOST]

22

DisableTAPI=1 The default value is 0, meaning TAPI is enabled.

A new method has been introduced in the NetOp Security Server API for setting NetOp Passwords: AMconnection::NetOpUserResetPasswordNow(char* user, char* newpwd, int forceChange) This method will force a new password for a specific user. The history and error counts are reset. This is the method called from the NSM new/edit Guest ID dialog: Returns AM_ERR_NO_MATCH (0xCC011) if user does not exist. Returns DBE_GUEST_LOCKED (89) if the user is disabled. Returns AM_ERR_NONCONFORMING_PASSWORD (96) if password doesn’t conform to syntax. Other non-zero codes may be passed from ODBC. Returns AM_SUCCESS (0) on success. AMconnection::NetOpUserPasswordNullifyNow() has been removed. AMconnection::NetOpUserUpdatePasswordNow(char* user, char*oldpwd, char* newpwd) This method will change to a new password for a specific user if one knows the old password. The password history and the error counts are not reset. The "force password change" flag is lowered when a new password was successfully chosen. This is the method called by the NetOp Security Server when the Guest dynamically changes the password.

The NetOp Security Manager dialog box for entering and editing NetOp Guest IDs into the NetOp Security Server database has been changed. The "Reset" checkbox has been removed and passwords can no longer be "reset" to "there is no password". They will always have a string value, even if it is a blank string. The difference is that blank is now considered a legal password, which one can connect with. Before, the Guest would be told to prompt the user to enter a new password, if the string was blank. A confirm password edit field has been entered. Only if the two password fields contain identical strings, the Ok button is enabled. Please notice that a blank password is still listed in the NetOp Security Manager with the label "No password" and a gray key icon.


Security The Windows Security Manager did not display the NetOp log entries correctly.

In the Windows Security Server the Access Server Key could not be blank – a blank string was automatically replaced with a string containing one space. A blank string is now allowed – this is however not recommended due to security reasons.

The Red Hat 8.0 Linux Host could escalate file access rights to root level. A Guest user was hereby allowed to access the file system with root privileges during file transfer sessions with a less privileged account logged on.

The Windows Security Server did not allow a blank string as a NetOp password. A blank string is now allowed – this is however not recommended due to security reasons. - The password can be set to blank when creating a new Guest ID with the Security Manager - The password can be set to blank when editing a Guest ID with Security Manager - The password can be changed to blank when the Guest selects the Change password option

23

The above is valid also when using the NetOp password as an RSA "shadow" password.

In order to make the Windows Host capable of browsing a Directory Service correctly, the Directory Services settings must contain 'objectClass' spelled exactly in that case character by character.

The Windows Security Server crashed if the SQL statements were above 64 KB. This could happen if e.g. both Guest and Host were members of 65 groups each having names longer than 32 characters.

In the Windows Security Manager the labels "Lock NetOp Password after Errors" and "Lock NetOp Password If Not Used" switched places.

The Windows Security Manager did not display the text label "Host ID Group" correctly when scheduling a job.

Logging to a NetOp Log Server / Security Server failed if the server was temporarily down. Logging to a Log Server means that log events are sent with Remote Procedure Calls (RPC) to a specific Danware Transport Layer (DTL) address. If the Log Server was temporarily down these RPC failed, and required a restart of the Host or Guest program to continue logging. There was one exception for the Host, if the connection was just temporarily lost, because when a session was initiated, the Host would try to log to the old DTL address again, and if the Log Server was up, start logging again. But this failed if the Log Server was using TCP/IP and was restarted or communication reinitialized, because the Log Server would get a new DTL address. Because the Log Server’s DTL address might change, it is necessary to search for the Log Server after the connection has been lost. Therefore, after the connection is lost, the Host will wait for 5 minutes and the search for the Log Server again. This will continue until the Log Server is found or logging to the log server is disabled. The log retry at connection time is disabled. The time in seconds between retry searches can be modified by the following NETOP.INI setting: [HOST] LS_RETRY=300 The default value is 300 seconds (5 minutes). If set to zero the Log Server retry search is disabled.

The NetOp Security Server and Security Manager did not work with names containing single quotes. An example was Active Directory group names containing single quotes like “My 1’ group”.

Entering an invalid password when prompted by a Linux, Solaris, Mac OS X or Windows CE Host gave the message "This was your last attempt" already after first attempt. Now the login process allows three invalid password attempts before disconnecting the Guest.

Installing the Windows Gateway with Silent Install creates an unknown Gateway access password for "Grant all Guests default access privileges".

The Windows Security Server can search for nested groups in MS Active Directory. To limit the number of levels searched, the maximum number of levels “N” can be specified in NETOP.INI: [NSS] AD_NEST_LEVELS = N

In accordance with the LDAP v.3 RFC 2251, an LDAP bind in which a username is provided but a password is not [i.e. blank] is treated as an anonymous bind. This means that a bind is granted to users providing a username but no password. The bind granted is an anonymous bind but based on limitations in the LDAP specification; most LDAP implementations do not provide any indication that the bind is in fact anonymous. NetOp relies on the success or failure of a bind to determine whether a user’s username and password are authentic when LDAP authentication is being used [an LDAP trace

24

will show that blank password becomes anonymous bind]. The problem is fixed by not allowing blank passwords. This behavior can be overwritten by the following NETOP.INI setting on the Host: [LDAP] ALLOW_BLANK_PASSWORDS=0 0: Don't allow blank passwords (Default) 1: Allow blank passwords Please notice this is not an error, but a configuration issue.

A Windows Host configured with prompt for maintenance password at “Unload and Stop”, failed to prompt when the Host module was unloaded under following circumstance: When shutting down Windows, applications with unsaved data will prompt the user to save the data, but the user might cancel this dialog and Windows aborts the shut down. The Host was informed that Windows was going to shut down, but not that Windows aborted the shut down. This situation combined with maintenance password prompt being suppressed at Windows shut down, the user can subsequently unload the Host without a prompt.

All NetOp modules on a given network share the common “group parameters” for encryption. These "group parameters" are computed in a reproducible way from the configured "Name Server Scope ID" and the date/month/year, changing every Sundays. For about 1% of the possible "group parameter" values all connection attempts are refused. Because the selection is predictable, this will affect users for exactly 1 week, but which specific week depends on the "Name Server Scope ID" and the encryption level chosen. There is no security compromise, because connections are simply rejected when this happens.

The Security Server did not work with all Japanese characters in Guest IDs, Host IDs, Guest ID groups, Host ID groups, NetOp passwords, RSA user names, RSA group names, and simulated workstation group names.

Graphics Remote control of a non-Windows Host from the ActiveX Control NetOpX sometimes failed to

display the Host desktop.

The Linux and Solaris Hosts failed to access the display if the command line in the Xservers file was too long. As a consequence the Guest did not receive the Host desktop during remote control.

The Windows Security Manager could by change of views cause the columns’ width to be zero.

The Linux and Solaris Guests did not support 8 bit true color visuals.

On Red Hat 7.0 and SuSE 9.0 Hosts a “Log out” during remote control could cause display problems with the next remote control session.

File Transfer During delta file transfer of changed files larger than 96 MB the session caused a communication

timeout on the Windows Guest. Files larger than 768 MB omit the usage of delta file transfer because the transfer is faster without.

The Windows Guest’s File Manager crashed when a UNC path was specified in a Script.

Disabling delta file transfer in a script wasn’t saved in the Windows Guest.

25

For file sizes greater than 2 GB the Windows Guest File Manager displayed an incorrect value for the file size and also used it in file size calculations.

When processing certain files using delta file transfer the transfer speed decreased far below expected level.

When displaying a tool tip the NetOp File Manager could make the Windows Guest crash.

If the Windows Guest File Manager cancelled a file transfer, it would sometimes hang.

The Mac OS X Host had problems with file transfer sessions especially with transfer of multiple files.

Communications For the Windows Guest scripts using the “CONNECT” method with a dynamic protocol like TCP

or modem failed under certain conditions.

The Windows Host was unable to call back to the Guest on a dynamic protocol.

It was possible to load two Windows NetOp modules using the same UDP port number for both send and receive without a proper error message.

Installation Setup on Windows NT/2000/XP/2003 sometimes failed with an error that required reboot. If the

NetOp drivers from a previously installed copy of NetOp could not be unloaded, NetOp Setup failed with an error message telling the user to "try again" after a reboot.

Misc. The Windows Guest did not show all phonebook folders when using very large directories.

The Windows Guest did not send the keystrokes Print Screen and Alt Print Screen to the Windows Host.

When the Windows Guest was sending a message to a Windows Host and closing the send message window before sending the message, the dialog box was shown in English (asking whether the user wants to save the message) regardless of the language of module.

The Windows Host modules (Host, Security Server, Gateway or Name Server) erroneously allowed a serial number for a different Host module to be applied be selecting the “Apply license” under the “Help” menu. The following error message will now be given: Cannot apply a license for a different Host module. The installed Host module (Host, Security Server, Gateway or Name Server) does not match the Host module for the applied serial number. Please install the Host module again with the new serial number.

If the Windows Guest tried to send a message during a remote control session, the session window stopped responding if the Guest module was minimized to tray.

The Windows Host had problems with environment variables when logged on user changed. Some environment variables dependent on the user currently logged on. The Host lives across user logons and therefore the local NetOp environment variables must be reinitialized when a new user logs on.

26

The Windows Guest crashed when logging in using a directory server and communication failed while the Login dialog was shown.

The Windows Guest position was not saved on multi-monitor systems.

The NetOp Inventory feature failed on NTFS drives with very strict security settings. The Windows Host, Gateway, Security Server and Name Server now use a dedicated directory for their temporary files when running on Windows NT/2000/XP/2003. The directory is called “NetOpTMP” and is created below the system wide TEMP directory.

When using a Windows Guest to run a text Chat session with a DOS RemPC Host, only the Host text chat window received characters.

The Linux Guest running under Red Hat 7.3 crashed when the Host disconnected.

The Solaris and Linux Guests did not accept more than one new phonebook files with blank description. The Host name will now be used for description and thereby as filename, if the description string is blank.

During remote control of a Red Hat 7.1 Host the keyboard reacted very slowly.

Double click coordinates did not scale correctly in the ActiveX Control NetOpX.

The Linux and Solaris Guests did not handle Key Up for ALT and CTRL correctly. The symptoms were “hanging” ALT or CTRL keys causing strange characters to appear on the Host.

The ActiveX Control NetOpX did not always use remote keyboard layout by default.

The ActiveX Control NetOpX sometimes did not show the user name and password dialog box when required.

When inserting the NetOpX as a component into a Visual Basic program, one can develop a program and generate an application executable. NetOpX will work ok. If you activate the NetOpX and have a running remote control session WHILE developing INSIDE Visual Basic, that would also work, but if you then delete the NetOpX instance, for example by closing Visual Basic's illustration of the dialog, in which NetOpX resides, Visual Basic would crash after approximately 5-10 seconds.

In NetOp Remote Control version 7.6 the default font was changed from “MS Sans Serif” to “Tahoma” which is the standard on newer operating systems (for all western languages). Unfortunately “Tahoma” didn't exist on Windows 95 and Windows NT 4 leading to dialogs with erroneous font. NetOp will now use “MS Sans Serif” on Windows 95 and Windows NT 4.

English text appearing for "Password" and "Confirm password" in Japanese connection Wizard.

The error “Help entry not found” appeared when accessing online help from the Web Update schedule dialog.

Version 7.65 released for shipment with English, German, French, Spanish, Italian, Portuguese and Japanese programs and documentation.

Please notice the following builds numbers are released with this version: - Windows 32 bit modules 2004052 - Windows CE modules 2004052 - Linux Guest module 2004049 - Linux Host module 2004049 - Solaris Guest module 2004049 - Solaris Host module 2004049 - Mac OS X Host module 2004049

27

- ActiveX Guest module 2004052 - Symbian OS Guest module 2004052

Known issues When selecting the “Check for updates” checkbox at manual installation from the CDROM on

Windows NT4, Windows ME, Windows 98 and Windows 95, the SETUP program crashes – in the next build this issue will be solved. To proceed with the installation, restart the SETUP program and do not check the “Check for updates” checkbox. When the module is installed, the Web update feature from the Tools menu can be used to download and install new updates.

netop remote control version 7.65

Documents