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.

[Thanassis Papadimitriou]

I have placed getuai.zip file into the following dir:

$ show def
SYS$COMMON:[SYSMGR.TEST.GETUAI]

Then I issued the following:

$unzip getuai.zip
$@link
$GETUAF == "$SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.EXE"
$GETUAI == "$SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.EXE"

I am trying to extract the following info:

$ set verify
$ getuai * /access=NO /disuser=NO
%CLI-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
\ACCESS\
%CLI-F-IVQUAL, unrecognized qualifier - check validity, spelling, and placement

1. Currently when I type help, I cannot find getuai syntax. How may open getuai help file to read it.

2. Should I check for any vms service that might be a prerequisite for getuai to work?

[Joseph Huber_1]

Maybe we have different versions of GETUAI, but mine has no /ACCESS qualifier, only /ACCOUNT.

And by the way, it makes not much sense to retrieve different items into the same symbol (=NO in Your example).

[Steven Schweda]

If we had a list of the files in your kit, we
might be able to guess if there's something
to use with a SET COMMAND command, or with a
HELP /LIBRARY command. Or, if we knew
exactly whence you got your kit, we could
look for ourselves.

[Joseph Huber_1]

And to the question how to get getuai help:
the distribution contains getuai.hlp file. Place that into your sites help library,
or into a help library of itself (LIBR/CREATE GETUAI.HLB/HELP getuai.hlp), and use
HELP/LIBRAY=dev:[dir]getuai .

[Joseph Huber_1]

The ACCESS fields You can get with the UAF utility from the freeware80 CD
http://mvb.saic.com/freeware/freewarev80/uaf/

[Thanassis Papadimitriou]

Dear All,

I downloaded getuai from the following link:
http://vms.process.com/scripts/fileserv/fileserv.com?GETUAI

It sounds rather difficult to setup getuai to the platforms I intend to use it.

I tried to create the help library to the directory I have unzip the files, because I don't want to mix these files with the OS ones.

$ dir

Directory SYS$COMMON:[SYSMGR.TEST.GETUAI]

AAAREADME.TXT;1 DESCRIP.MMS;1 DESCRIP2.H;1 GETUAI.ALPHA_OBJ;1
GETUAI.C;1 GETUAI.CLD;1 GETUAI.EXE;1 GETUAI.HLB;1
GETUAI.HLP;2 GETUAI.HLP;1 GETUAI.I64_OBJ;1 GETUAI.VAX_OBJ;1
GETUAI.ZIP;1 GETUAI_TABLES.ALPHA_OBJ;1 GETUAI_TABLES.I64_OBJ;1
GETUAI_TABLES.VAX_OBJ;1 LINK.COM;1 PRIVBITS.H;1
TO_BUILD.COM;1 UAIDEF.H;1 VAXC$MEM_OPT.H;1 VAXCRTL.OPT;1
VAXTYPES.H;1

Total of 23 files.

I issued the following commands to create the help library:

LIBR/CREATE GETUAI.HLB/HELP getuai.hlp
$ HELP/LIBRAY=$SYS$COMMON:[SYSMGR.TEST.GETUAI]getuai
%HELP-E-OPENIN, error opening $SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.HLB; as input
-RMS-F-DEV, error in device name or inappropriate device type for operation

Currently, I am not an experienced sys admin.

[Joseph Huber_1]

As the error message explains: is $SYS$COMMON a valid device name in Your system?
I would rather think SYS$COMMON as in most systems.

[Martin Vorlaender]

Thanassis,

>>>
HELP/LIBRAY=$SYS$COMMON:[SYSMGR.TEST.GETUAI]getuai
<<<

Try

HELP/LIBRARY=SYS$COMMON:[SYSMGR.TEST.GETUAI]getuai

That is, "LIBRARY" spelled correctly, and SYS$COMMON without the leading "$" (that one is reserved for telling DCL that we're defining a foreign command).

GETUAI works like this: every qualifier takes as a value the symbol name that the information should be placed into, e.g.

$ getuai system /LAST_LOGIN=xx
$ show symbol xx
XX = "19-JAN-2009 13:54:50.64"

I'm under the impression that you assume you can use the qualifiers as a filter - that is not the case.

HTH,
Martin

[Thanassis Papadimitriou]

I have defined the following:

GETUAF == "SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.EXE"
GETUAI == "SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.EXE"

when I tried to extract info for system account, it produces the following:

getuai system /LAST_LOGIN=xx
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\SYS$COMMON\

[Martin Vorlaender]

When definig a command, you need the leading "$", like

GETUAF == "$SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.EXE"
GETUAI == "$SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.EXE"

HTH,
Martin

[Joseph Huber_1]

My goodness, You really should read AT LEAST the DCL basics manual before starting to play system manager!

The foreign command verb definition is:
GETUAI:=$SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.EXE

The help file specification is:
SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.HLB

The leading $ is NOT part of the file specification.
So: HELP/LIBR=SYS$COMMON:[SYSMGR.TEST.GETUAI]GETUAI.HLB

[Thanassis Papadimitriou]

Thank you all very much for your help.

I wish I had time to read in detail all the docs related to system management.

My role is not dedicated only to OpenVMS system management! So, any input is appreciated!

A last question about getuai. In case that I would like to extract all usernamea that have a password lifetime set to 60 days. Is it possible to retrieve these usernames with a single getuai command or do I have to write down a short program to loop throughout all uaf lines. Someone told me that getuai is not used to filter uaf records!!

[Joseph Huber_1]

As far I see, GETUAF has no selection criteria, and no wildcard functionality.

The other mentioned freeware program, UAF, does have /SELECT= and wildcard functionality,
on the other hand does not return the result in a DCL symbol, but just displays on terminal or file. Get the UAF program, it has examples in the help showing how to use /select=...

[Joseph Huber_1]

The UAF query for a PWDLIFE of 60 days would look like:
uaf/select=pwdlife=(59-0,60-00:00)/display=(username,pwdlifetime)

[Thanassis Papadimitriou]

I have downloaded uaf.gz file into the following directory:

SYS$COMMON:[SYSMGR.TEST.UAF]

I unzipped uaf.gz file and all files where extracted in the afore-mentioned directory. I have found compile.com file. Should I execute it, prior initiating a query against uaf records?