[Info-vax] OpenVMS issue for person's STATUS

[Stephen Hoffman]

On 2013-02-19 11:41:34 +0000, kevinparker124 at gmail.com said:

> I got stuck at very crucial stage of point, and the problem is stated below:

>From "Hello, World" to tussling with a text editor to OpenVMS system 
security?  That's fast-track development.

Given some details of your posting and given the nature of the 
question, is this related to the "Need help in REVOKE" thread from a 
week or so ago, from adityagtm4?

> suppose when XYZ company's person has a value "T" in his "Status" field 
> which means Termination. So I just want to remove all the identifiers 
> and flag as a Disuser.

OpenVMS has no "STATUS" field, so I'm going to assume this is something 
stored elsewhere.  Is this related to the question that was in the 
Attunity forums?

In general, just flag the user as /FLAGS=DISUSER, and leave the 
username fallow.

To DISUSER the username, use the sys$setuai system service and maybe 
sys$getuai to manage the username settings, rather than attempting to 
spawn commands.   (There are cases where you have to spawn commands to 
stay within support, though; there's no documented means to add )

Removing the identifiers loses the context that usename had, which 
makes both re-adding the user more involved — you just have to store 
that configuration somewhere else — and it also makes subsequent audits 
more involved as there's no central store for what access the user 
(formerly, now DISUSER'd) had.  And it's more work.  For no value.

Otherwise, you're going to be looking at the revocation and related 
system services, as a start; at sys$revokid and maybe sys$grantid 
calls, as well as various others detailed in the Programming Concepts 
manual and the Guide to Security manual.

The other and more general consideration here is whether migrating the 
OpenVMS systems to LDAP and external authentication might be 
appropriate than messing around with this stuff — if this was related 
to what was posted over at Attunity and is involving multiple 
platforms, then it's possible to manage (part of) OpenVMS user 
authentication via Active Directory or Open Directory, which means a 
central data store, which can mean somewhat less work with DISUSER; 
what's necessary can be batch-oriented, and not centrally triggered 
from whatever the core user data store might be.  But that's subject to 
learning some more background on what's going on here, and thus 
probably fodder for another discussion...

> In short, I just need figure out how we can pass the user status 
> attribute to the adapter so that it can decide whether or not it needs 
> to remove the IDENTIFIERS

"Adapter" is not a term used on OpenVMS, and using terminology from 
other platforms means — unless you get lucky — somebody here has to 
figure out what that term is on whatever the platform, if we even know 
the context.  If you're working with OpenVMS, please read the Guide to 
System Security.  That'll get you the grounding in the terms and 
concepts used on OpenVMS, and that'll give all of us a basis for 
discussing the details of your questions.

>  I am confused that how should I move ahead.

The OpenVMS manuals are reasonable, Guide to System Security, and the 
Programming Concepts manuals.  I have some $setuai calls in NEWUSER, 
which I've mentioned previously, and there are other examples around 
the 'net and around the OpenVMS manuals.  There are large reservoirs of 
OpenVMS source code at decuslib.com and at digiater.nl servers, for 
instance, and these can be searched with Google or Bing and the site: 
keyword.

> Any suggestion would be appreciated.

If this project has a schedule, get somebody that knows how to do this 
stuff.  It's easy to make mistakes here, and I've seen more than a few 
folks — including myself — make mistakes with password prompts, 
security, and related baggage.   This is a fairly arcane area, and 
you're going to be doing a whole lot of reading of the documentation, 
as these system services are typical for OpenVMS system services, but 
are probably unlike what you've encountered before.


-- 
Pure Personal Opinion | HoffmanLabs LLC