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

[kevinparker124 at gmail.com]

On Tuesday, 19 February 2013 19:19:40 UTC+5:30, Stephen Hoffman  wrote:
> 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

Thanks a lot Steve for your kind help.