getuai.exe for OpenVMS 7.3-1 and OpenVMS 7.3-2

[Thanassis Papadimitriou]

Currently, GETUAI.EXE is not installed in our OpenVMS 7.3-1 and OpenVMS7.3-2 platforms.

I need this utility to generate some reports based on conditions which cannot be extracted by the uaf utility.

Instead of writing down codes to use mcr authorize and produce outputs with time consuming codes, is it possible to download GETUAI.EXE from somewhere and then ftp it to our platforms?

[Jim_McKinney · Accepted solution]

http://vms.process.com/scripts/fileserv/fileserv.com?GETUAI

[Thanassis Papadimitriou]

I cannot reach this url. It produces an error.

[Thanassis Papadimitriou]

I managed to download it from an alternate link. I unzipped the file on my PC and then ftp the files in a directory of the platform.

The problem that came up is that to_build.com does not start to produce GETUAI.EXE

Any hints on that?
Should I ftp the files at a specific directory in OpenVMS 7.3-2?

[Hoff]

GETUAI.EXE is an add-on tool.

Here's the Google search used:

http://www.google.com/search?hl=en&q=%22GETUAI.EXE%22

And when rummaging, always check the Google caches and the Internet Archive:

http://www.archive.org/

The Google search shown above will find the following archive (at Ruslan's server) on the first page of hits for the search:

http://starlet.deltatel.ru/~laishev/tools/

And I've confirmed a zip is located there.

Depending on what you are doing, an application calling the sys$getuai system service may be appropriate. While common on Unix, parsing command output isn't generally something that HP seems to recommend on OpenVMS.

If you have specific requirements here, there might be alternatives. You've asked a specific question (where can I get tool X) without providing details of why you're looking for the tool (and what data you're after here), which means that alternative approaches or suggestions might not be available.

Do also review the local production configuration too, as this request could imply an area of improvement is available here. If I have open-source tools as a component of my production, I also work toward a local cache of the source code of the particular version I'm using. This in addition to a cache of the installed LP kits that is a central part of running the local production environment; like having data archives, having an archive of tools and kits is a part of a basic recovery and replication strategy.

[Jim_McKinney]

Was the integrity of the files preserved throughout your UNZIP and transfer from the PC? UNZIPing on the VMS system is preferred method.

Since there are .OBJs for each architecture included in the kit I would expect that all that would be required would be linking to create the EXE. Did you try executing that LINK.COM that is included? (I have not examined the kit beyond scanning the file names.)

$ @LINK

[Hoff]

> The problem that came up is that to_build.com does not start to produce GETUAI.EXE

Ok; so you're looking for help debugging a build procedure in your environment. What's the current build procedure do? Errors? Messages? Output?

Gather some data and post it. (It is certain my local server configuration is different than yours, so it doesn't seem the best use of effort to test this build in my local configuration; I'm running V8.3, for instance.)

As a first pass to gathering the data, issue the DCL command SET VERIFY and then invoke the build.

That SET VERIFY may or may not provide output of the commands, but it's a start. (It's possible that the author of the build procedure disabled verification within the build, meaning you'll have to take a look at what's there to see how the build works in the most general of terms.)

[Thanassis Papadimitriou]

Thank you for your reply.

What I try to achieve is the following:

1. find all accounts that have /access=YES, /flag=nodisuser and /pwdlifetime="60-".

2. Once found change the pwdlifetime to 60 days.

Is there any other way to do it without using GETUAI.EXE?

[Hoff]

>Is there any other way to do it without using GETUAI.EXE?

Auditors, eh? Passwords aren't secure, but some auditors still think they can make them work. Ah, well.

As for your question, sure, there are various ways to implement a SYSUAF policy. Most are a little ugly, but there are ways.

The brute-force DCL approach works fine, and would take a half hour or so to code that DCL.

The SCANUAF tool might work here.

There's the Python library: http://www.vmspython.org/LastAccountLoginExample
http://www.vmspython.org/PythonExamples

UAF:
http://mvb.saic.com/freeware/freewarev80/uaf/

RMS calls and sys$getuai and sys$setuai would work, too; your own program. Here's a template for some of that code:

http://unix.derkeiler.com/Newsgroups/comp.os.vms/2005-01/0288.html

The GETUAI tool is (also) on the OpenVMS Freeware V8 distro, BTW.

It would be feasible to make this sort of thing a password policy module, too, and take care of this sort of thing on-line. Assuming the auditors are willing to be pinned down on their specific requirements. Here's a shell of a password policy module (this one is a password character set filter, but shows how to use the API):

http://64.223.189.234/node/643

Another option is to move all this stuff out into LDAP and deal with the policies out there, but that would require OpenVMS Alpha upgrades here to get connected to the LDAP external authentication. (If you have an existing LDAP or Active Directory installation, the LDAP approach tends to become rather more interesting.)

I could probably find a few other tools and approaches here, too...

[Robert Atkinson]

You shouldn't need to run TO_BUILD.COM, as the Alpha OBJ file is already in the kit.

Run LINK.COM which should give you GETUAI.EXE, then create these commands, replacing the drive/directory as appropriate :-

GETUAF == "$SYS$SYSDEVICE:[LOCAL.UTILITIES.GETUAI]GETUAI.EXE"
GETUAI == "$SYS$SYSDEVICE:[LOCAL.UTILITIES.GETUAI]GETUAI.EXE"

Rob.