Distribution History

 

Version 18.2 (4/24/01)

 

This patch does two things. First, a new copy of ApAdmin.exe upgrades the diagnostic code so that

it uses the same code for testing the AP/Vista interface that the proxy uses to access it.  Second,

it fixes a flaw in the management of visit sites.  They have been stuffed into workstation

registry in the wrong format which causes other applications to reject them. This fix requires

a VistA code path to routine XUESVIS, a new copy of xuesap.exe and esso.exe.

 

This patch is an all or nothing upgrade. To do the upgrade you must install:

a) new copy of xuesap (the proxy)

b) new copy of APAdmin on proxy server

c) new copy of esso.exe on workstation

d) VistA code patch

All this assumes you are running v18.1.

 

Details:

 

1) Starting a visit from command line the NT Account field on the Esso window comes up blank.

Change effects xuesap.exe.

 

2) Redid the back-end to APAdmin so that the diagnostics use the same code as the proxy. Change

effects APAdmin.exe.  To use this version the rpc XUES ADMIN INTERFACE must be added

to the menu XUES AUTH PROXY.

 

3) Patch to GETVISS^XUESVIS

 

        . S PORT=$O(^XUESSO("VISIT SITES",SITE,AP,""))

<      . S RET(I)=SITE_U_PORT_U_AP

        . S I=I+1

------

        . S PORT=$O(^XUESSO("VISIT SITES",SITE,AP,""))

>      . S RET(I)=SITE_','_PORT_','_AP

        . S I=I+1

 

Replace the U with ',' in both places on the marked line.

 

4) New copy of Esso.exe.

 

5) New copy of EssoClient.exe - this is a new copy of the client workstation installation package.

It does the entire installation automatically - launch then two "ok" clicks and your done.  It

does not configure the registry with VistA and proxy addresses.

 

 

 


Version 18.1

 

As a minor release - no incompatibilities have been introduced between client,

Authentication Proxy, and VistA software (the protocols have remained

untouched).

 

1) EssoAdmin.exe - removed the requirement that EssoAdmin.exe be run

with local administrator priviledges.  File effected: EssoAdminU.pas.

 

2) xuesap.exe (the Authentication Proxy server) - if a vista

server is configured by name and the DNS lookup of that name

fails then the proxy can generate an error even if that vista server

is never used.  Files effected: APConfig.pas, InetAddr.pas.

 

3) XUES - if visit is requested that is not on the list in ^XUESSO then

a  GOVISIT+20 error will be reported. Routines effected: XUESVIS.

Patch adds $D test for visit site:

 

XUESVIS:

 

        I WHAT=1 D  Q  ; RETURN USERINFO AND REMOTEAP

        . S %=$$GET^XUESSO1(USERDUZ)

        . I +%=-1 D  Q

        . . S RET(0)=0_U_$P(%,U,2)

        . S RET(1)=%

        . I '$D(^XUESSO("VISIT SITES",VISSITE)) D  Q

        . . S RET(0)="0^Visit site "_VISSITE_" is not registered"

        . S RET(2)=$O(^XUESSO("VISIT SITES",VISSITE,"")) ; APSERVER

        . S RET(3)=$O(^XUESSO("VISIT SITES",VISSITE,RET(2),"")) ; PORT

        . S RET(0)=1

 

 

4) New application; EssoLnch.exe.  This is a basic launcher whose main purpose

is to establish a broker connection via Esso, launcha telnet like program

which gets in without access and verify codes (because of client agent

and the first connection). It then drops the first connection after

a timeout.

 

5) XUESAP - seems it is possible to get a broker connection without setting

IO("IP") or IO("CLNM") so change this block of code at ENVCHK+13

from:

 

        ; Accept tokens only from APs registered in ^XUESSO("AP",IPADDR)

        ; This can be in numeric or name format

        I $D(^XUESSO("AP",IO("IP")))=0,$D(^XUESSO("AP",IO("CLNM")))=0 D  Q 1

        . S LOG=1

        . S MSG="Token received for user "_NTUSER_"  from Authentication Proxy running on "_IO("IP")_" ("_IO("CLNM")_") - this Authentication Proxy is not registered with this VistA server"

        . S CODE=-1

        ;

        ; null token?

        I TOKEN="" S CODE=-5,LOG=1,MSG="NULL TOKEN" Q 1

 

to:

 

        ; Accept tokens only from APs registered in ^XUESSO("AP",IPADDR)

        ; This can be in numeric or name format

        I $D(IO("IP")),$D(^XUESSO("AP",IO("IP"))) G ENVCHK1

        I $D(IO("CLNM")),$D(^XUESSO("AP",IO("CLNM"))) G ENVCHK1

        S LOG=1

        S MSG="Token received for user "_$G(NTUSER)_"  from Authentication Proxy running on "_$G(IO("IP"))_" ("_$G(IO("CLNM"))_") - this Authentication Proxy is not registered with this VistA server"

        S CODE=-1

        Q 1

        ;

ENVCHK1 ; null token?

        I TOKEN="" S CODE=-5,LOG=1,MSG="NULL TOKEN" Q 1

 

6) Created patch so that Client Agent is not used for Auth Proxy account.  This account is identifiable

because it holds the key "XUES AP".  The patch is in two parts, XUS1 and XUESAP.  The XUS1 part of the

patch must only be installed if the XUESAP part is. I am proposing that this patch to XUS1 be approved

and made permanent.

 

COOKIE+4 (as show below )is a new line to be inserted.

 

XUS1:

 

COOKIE(J1,J2) ;Call VAdeamon for a cookie

        N ZZ,%

        I $G(XQXFLG("ZEBRA"))=-1 K XQXFLG("ZEBRA") Q "" ;Disabled

        Q:$G(IO("IP"))="" "" ;Not using Telnet

        I $D(^XUESSO) Q:$$ISAPROXY^XUESAP($G(DUZ)) "" ;No cookie for Authentication Proxy

        S %=$$CMD^XWBCAGNT(.ZZ,"XWB CREATE HANDLE",J1_"^"_J2) Q:'% ""

        ;D MSG^XUESLOG("    "_$G(ZZ(1)))

        Q $G(ZZ(1))

 

This part of the patch adds a new entry point that the above part calls.

 

XUESAP:

 

ISAPROXY(IEN) ; does DUZ represent the Authentication Proxy?

        I +IEN=0 Q 0

        I $D(^XUSEC("XUES AP",IEN)) Q 1

        Q 0

        ;

 

7) Fixed bug in diagnostic part of esso.exe (reached via esso.exe /diag). It failed in Seattle by trying to

read from an invalid memory address.  The real problem was that it expected to find either c:\tmp

or c:\temp available as temp directories.  Neither existed and the error handling code failed instead of

posting a message.

 

 

 

 


Version 18

 

REQUIRED INSTALLATION

 

VistA routines, Client workstation, Authentication Proxy

 

CHANGES

 

1) The AProxy panel of APAdmin has been renamed Proxy Registration.

 

2) Added a check box to the Proxy Registration panel of APAdmin.exe.  The check box is labeled

"Log Authentication Proxy Accesses" and if not checked the VistA routines will prevent

the silent sign-on done by the Authentication Proxy from showing up in the Event Log.

 

3) VistA Log Panel of APAdmin.exe now retrieves log entries 25 per RPC. A stop loading button is

visible while it is loading.  The M support code no longer does sorting. Instead it uses a

reverse $Order.

 

4) VistA Log now captures a visit in a single log entry which shows the NT user, M user, and home

system in a single log entry.

 

5) Changed point of view of APAdmin.  It only performs tasks from the point of view of the Authentication

Proxy.  So, for VistA, it only is capable of signing-on using silent sign-on.  Testing from the point of view

of a client (using the Authentication Proxy) will be moved to another tool.

 

6) Because of change #5, you must be a member of the local Administrators group (or Domain Admins) to

run ApAdmin.

 

7) Esso.exe enhanced to show more status of connection - specifically the connection attempt to the AP

followed by the connection attempt to VistA.

 

8) Added new diagnostic panel for ApAdmin.  This panel diagnoses connections to VistA and guides the

administrator through initial configuration. 

 

9) Added new /diag option to esso.exe.  To run diagnostics, start esso from the command line as

"esso /diag".  Select the VistA server of interest and press "Connect".  The list of servers will

be replaced with a list collecting diagnostic output as the software probes the environment.  Success or

failure is reported.

 

10) A lot of error messages have been cleaned up.  There are still a few more to go that can occur when

visiting.

 

11) Added Config button to esso.exe.  Esso /config still works from the command line.

 

12) Created new diagnostic tool EssoAdmin.exe.  This contains all the elements of the old ApAdmin that

require the user to be signed on to VistA.  It manages visiting, the NT map etc.

 

13) Some new terminology has been introduced to (hopefully) simplify configuration.  Until now, the word

"visitor" refered to a user who was electronically leaving your site or arriving.  Now "visitor" refers

to a user who is visiting from another site.  The new term "traveler" refers to a local user who is

"traveling" (formerly visiting) another site.  Tabs in EssoAdmin now refer to "visitor" and "traveler".

 

14) Several new tabs have been added to EssoAdmin:

Client Agent - displays installed/not-installed status of client agent.  Can use this tab to "hide" client

               agent so that system runs without it.  This hide just renames the exe.  I have noticed that Broker

               client software runs slower if you hide the client agent so I appears that it is either looking for

               it or waiting for an exec to fail.

Traveler Status - to get the status of a traveler, type in a name prefix (partial name) in the combo box

               labeled "User". Push the combo box button and all users with that prefix will be displayed.  Select

               a user and his travel status will be displayed.  The travel status is the list of exportable

               menus (configured for this site) in the left column and in the right column is listed whether

               this user has access to each menu item. 

Visitor Status - Lists each visitor to this site giving name, NT account, Home system, and whether he has

               a local account.  Remember that if he has a local account then the export/import of menus does not

               count - he gets his locally configured menus. Once the list of visitors is listed, select one and push

               the "Visit Menu Detail" button.  The listbox will redisplay showing each menu the visitor brought with

               him from his home system and check marks indicating which ones were accepted at this site on his last

               visit.

 

15) Several tabs in EssoAdmin/ApAdmin that load large lists have been rebuilt so that they load incrementally.

AP Log, VistA Event Log, NT Map are examples.

 

 

 

 


Version 16 (11/27/00)

  1. These changes were made following testing in Seattle and White City.
  2. Only a small number of menus and keys could be transferred from home system to visit system as part of a visit user's credentials. This has been expanded so that this software no longer limits the number of menus or keys.
  3. Utilities LaunchTest.exe and APInstall.exe have been integrated into APAdmin.exe.
  4. Vista network address AND port number are now used to select Vista system.
  5. New Connect-to-Vista mechanism added to APAdmin.exe
  6. This version is also available from the San Francisco FTP site:
  1. Online documentation is out of date - download V16/esso.chm for most up to date copy.

unreleased

  1. If user workstation and proxy server are the same machine (they should never be) then new mapping happens without access;verify code challenge. This is because proxy does not drop connection to vista early enough and user connection piggy-backs and gets in without challenge based on clagent status. FIX: drop connection earlier, specifically in MProxyInterface:LGetTokenForServer. Affects xuesap.exe. (executable for proxy server).
  2. Log information about a visit is not saved in event log, instead it is stored in status of last visit which is indexed by the local duz. FIX: Duplicate information about user's home system and whether user has a local account (real local account and not a special visit account) in the event log. Affects M routines XUESVIS and XUESLOG.
  3. M command line event log viewer loops and shows log multiple times. Affects routine XUESLOG.

2/2/00

  1. Documentation updated to have Authentication proxy installed in a VISN domain to support visiting.
  2. Clean up of M code which includes simplifying the OPTION/RPC structure.
  3. Added "Launch Authentication Proxy" menu to the ESSO.exe to help with installation/testing.
  4. Lots of other tiny fixes.

 

Xxxx

  1. Fixed problem with Esso.exe. If registry entry representing hospital server did not include authentication proxy location then Esso.exe would crash.
  2. Added code to clean out old visit map entries. Called at the start of every visit.

 

11/15/99

  1. M Code has been split up into 8 routines (was 3). The code now meets the 10k character limit for a routine and passes the ^XINDEX code verifier.
  2. Esso.exe and EventLog.exe now accept command line arguments that specify the VistA server to attach to. This works for attaching to a home system or for visiting. See client user guide.html for details.
  3. The core functionality needed for a client application is packaged as a Delphi component. This makes it possible to integrate authentication proxy into an application as an alternative to using the separate Esso.exe utility. This new component, TEntSingSign, can be used instead of TRPCBroker for new applications or with an existing instance of TRPCBroker for ease of integration into existing applications. I hope to have this component documented and distributed for general use in the next release (still working on documentation and packaging).
  4. Installation guides have been expanded greatly after the experience with the Seattle installation. They now include a great deal of testing of the local environment to ensure that the local environment is ready for this software.

 

?????

  1. Integrated visit code. This effects all three distribution files.
  2. Fixed "endless loop on cancel" problem with EventLog.exe
  3. Option XUES EDIT AP - set type to Broker (was menu).
  4. New functionality - you can now visit to a permanent account. I judge it a permanent account if it has access/verify codes in piece 3 of ^VA(200,DUZ,0). You do not get visit privileges - you keep local privileges instead (usually more).
  5. Installation instructions moved to install directory (proxy instruction file installpserver.html moved from Apdoc directory into Server directory with executables).

13 Oct 99 -

  1. Oops - fixes for NT SP 4 bugs (dcomcnfg creates incomplete registry entry for DCOM service).
  2. NT bug - DCOM services exe file must fit into 8.3 name format. Had to rebuild entire system. New name of proxy is xuesap.exe. New name of proxy object is xuesap1 object.

6 Oct 99 - New release to Silver Spring and Seattle. Contains only phase 1. Updated to operate on NT 4.0 service pack 5. All M routines and globals moved out of Z namespace and into XUES namespace.

 3 Sept 99 - Initial release to Silver Spring and Seattle. Contains phase 1 and 2 but only intended for serious phase 1 consideration.

 

Updated: 11/15/ 99