JUMP and Ldap logon

[ptrskg]

Hi,

We are using the freeware tool JUMP a lot, both in our system operation and development.

Now we have started to use Ldap as an external authentication method and when trying to do a JUMP after logon it fails. If we do a "/local" logon with the corresponding user it works as normal. It seems that there is a problem to "impersonate" the new user and with the "pseudo" terminal device allocated.

Have anybody experience of this?
Any suggestions what to do?
Perhaps a newer version?

OpenVMS is 8.4 on HP Integrity BL860c i2
JUMP is V5.0 2005-02-19

Thanks
Peter

[Hoff]

I'd be surprised if JUMP had any clue how to do the external authentication calls; it's almost certainly using the older calls, and failing.

The dates on that JUMP code are also before ACME was particularly widely available, too.

And JUMP isn't widely used.

Which implies a couple of choices. Wade into the source code and have a look for the error, or convince somebody else to wade into the code for you.

Or switch to some other means of managing the VMS servers, and get JUMP out of the mix.

I've tangled with external authentication and have gotten VMS to authenticate against Mac OS X Server boxes and their Open DIrectory LDAP directory structures, and that was a couple of days of hair-pulling not-fun.

Here, I'd expect to have to recode one or two of what are probably sys$getuai calls over to $acmw calls; to switch from the older mechanisms to the ACME-related calls.

Here's an example of the newer calls:

http://snow.hoffmanlabs.net/node/1514

And FWIW, it's been my experience that sites using JUMP tend to have issues with the protections and ownerships settings, and resolving those issues can often clear up the need for tools such as JUMP. (This from direct experience using earlier generations of this stuff to work around the messes in the environment, and spending time maintaining the tools as traded off with the time needed to fix the protections and ownerships settings.)

[Craig A Berry]

Hoff wrote:

>I'd be surprised if JUMP had any clue how to
>do the external authentication calls

I'd be surprised if JUMP had any reason to do authentication at all since its job is impersonation, not authentication. I believe it's basic modus operandi is to call SYS$CREPRC with the UIC and other account info of the target user (from a privileged image, obviously).

A more likely problem would have something to do with passing LOGINOUT.EXE to SYS$CREPRC with only ExtAuth defined in the UAF record. Try adding VMSAuth to the flags of the source account and see if that makes any difference. Or it could be something with pseudo-terminals, as you suspect.

The author of JUMP is responsive and has contact info in the source and readme files of the package. He was recently taking feature requests on comp.os.vms.

[John Gillings]

Peter,

I've never heard of "JUMP", but it sounds like a utility for switching user names on the fly?

There have been many attempts to create such utilities in the past. For better or worse, OpenVMS makes it hideously complicated to get it right. Some people have managed to make it kind-of-mostly work for some brief period of versions, but there is always an update, eventually, that breaks something. In most cases failures are benign, but since these programs are digging deep into privileged data structures, occasionally they will take down a whole system.

The only reliable way to "become" another user is to login as that user.

If you want to bypass passwords and execute a command in the context of another user, define TCPIP proxies and use RSH, or configure the appropriate keys and use SSH. This is a safe, supported, controlled, and non-privileged way to allow specific users to act on behalf of other specific users.

I strongly recommend you examine the reasons your users think they need to use this utility and find a supported means to achieve their goals.

[Jeremy Begg]

Hi Peter,

I have used JUMP for many years but haven't tried it in an environment that uses external authentication.

Can you please confirm the following:

1. If you log on to the system using external authentication, then enter the JUMP command, the JUMP fails.
2. If you log on without using external authentication, then enter the JUMP command, the JUMP succeeds.

If so, can you please show us the details, i.e. what error message does JUMP produce?

I notice you're running VMS 8.4, whereas the object libraries supplied with your version of JUMP were built against a somewhat older version of VMS (8.2 would be my guess). So rebuilding from sources might fix it. I can help here if necessary.

Regards,
Jeremy Begg

[ptrskg]

Hi Jeremy,

Yes, I can confirm you assumptions.
And yes, I have re-build (and re-compiled) the application.

Some notes what I've found out:

Logical setup:
"JUMP_000004DB" = "NOCHAIN "
"JUMP_ACCESS_LIST" = "SYS$SYSDEVICE:[JUMP]JUMP_ACCESS_INUSE.DAT"
"JUMP_AUDIT_TRAIL" = "SYS_LOG:JUMP_AUDIT.DAT"
"JUMP_DOUBLE_CHECK" = "TRUE"
"JUMP_SECURE_DIR" = "SYS_LOG:"
"JUMP_USER_DIR" = "SYS_LOG:"

The command we use is $ JUMP /EXACT/NOT=(BEFORE,AFTER,NOINCLUDE,NOMAIL,OPCOM)
and the image is installed according to instructions.

I don't receive any errors, not in the session nor in the logfile, perhaps except for an additional trace printout "ALPHA8.4". It notify's me; "%JUMP-S-TRANSFER, Control transferred to user 140MGR" on the terminal, and I get an entry in JUMP_AUDIT_TRAIL and a file in JUMP_USER_DIR:. See below.

What happens is that I get a new process but for the same user and default directory as origin and the terminal doesn't display any output. And the login.com is not executed, it looks like it doesn't perform a complete login.

It works ok if I JUMP to myself.

If I use the /OVERRIDE_UAF it behaves like normal, it changes the uic but not the default directory

Printouts from a JUMP session that fails:
Terminal:
---
SDEV04_MGR_V075949> jump 140mgr

ALPHA8.4
%JUMP-S-TRANSFER, Control transferred to user 140MGR

SDEV04_MGR_V075949> sho def
SDEV04_MGR_V075949> sho proc
SDEV04_MGR_V075949> lo

%JUMP-S-RETURN, Control returned to user MGR_V075949
SDEV04_MGR_V075949>
---
AUDIT_TRAIL:
03-FEB-2011 11:37:59 MGR_V075949 to [140,1] = [140MGR] *SECURE* _FTA0: Host: segotwd1224
5.vcn.ds.volvo.net Port: 2103 TNA39: TNA39:
---
JUMP_USER_DIR:
SDEV04_MGR_V075949> typ sys_log:JUMP_MGR_V075949-140MGR.20110203_113759;1
------------------------------------------------------------------------------
JUMP V5.0 2005-02-19 (19-Feb-2005) Pseudo-terminal session log.
SYS$SYSDEVICE:[SYS_LOG]JUMP_MGR_V075949-140MGR.20110203_113759;1
User: MGR_V075949
Login time: 03-FEB-2011 10:59:55.03
From PID: 00001216
Process: _TNA39:
To PID: 0000024F
Phys Dev: TNA39:
Terminal: TNA39:
Port: Host: segotwd12245.vcn.ds.volvo.net Port: 2103
JUMP time: 03-FEB-2011 11:37:59.08
Target user: 140MGR
Mode: Secure
Attributes: NOCHAIN
Command: JUMP /EXACT/NOT=(BEFORE,AFTER,NOINCLUDE,NOMAIL,OPCOM) 140MGR
-----------------------------------------------------------------------------

SDEV04_MGR_V075949> sho def
SDEV04_MGR_V075949> sho proc
SDEV04_MGR_V075949> lo

SDEV04_MGR_V075949>
SDEV04_MGR_V075949>
SDEV04_MGR_V075949>
SDEV04_MGR_V075949>
---

I hope you from this info can get some ideas of the problem.

Thanks
Peter