One of my clients has a class of user IDs that are enabled for emergency production problems, then turned off afterward. Normally they're suspended, but if a user jumps through the right hoops the ID is enabled FOR(1) (or maybe 2) and automatically expires thereafter.
I just created one of those ACIDs, and realized I don't know how to handle that part of it. I tried ADD SUSPEND and it gave it ASUSPEND; that means the help desk won't be able to release it if necessary. FOR(0) and UNTIL(today) don't work, presumably because the expiration date must be in the future. I've tried various other possibilities but TSS slaps me down. I suppose I can set the expiration date for tomorrow—it's not like it's a huge security risk—but surely there's a way to do it? Anyone know?
There isn't a control option or anything to automatically suspend a newly created user. As you pointed out in your update, the security administrator can put the SUSPEND keyword on the TSS CREATE command and the newly created user will be ASUSPENDed. The administrator can also do a TSS CRE(acid1) USING(acid2) and if 'acid2' is suspended (ASUSPEND, PSUSPEND, VSUSPEND, etc), then 'acid1' will have the same suspension (ASUSPEND, PSUSPEND, VSUSPEND, etc).
Use a batch job to add create the ACID and add the line to add the suspend to the ACID; this works for our site and our end users can call our Service Desk to have the remove the suspensions. Also, look at the permissions of your Help Desk staff and see if they have MISC1 SUSPEND and MISC8 REMASUP. Hope this helps.
Michael, many installations I've worked at don't allow the usual Help-Desk process to remove ASUSPEND. I think the rationale is that the usual process is a little on the lax side: "Oh, you claim you're Bob Bridges? Prove it—what's your SSN?" Of course, when the help-desk guy happens to know me personally, perhaps because I call them three times a week, then it's safe enough; but otherwise there is (I surmise) the fear that a recently fired employee could call and get his ID reënabled by a careless help-desk technician. At any rate, that's why I mentioned it in my original post: At the installation in question they can't remove ASUSPEND, so I was looking for another way.
Understand this. Every installation has their own verification and authentication process they follow. Would think if an individual is terminated for cause access would be terminated immediately. Can that organizations' Service Desk remove expirations from an ACID? Another way is to find a user who is suspended with either PSUSPEND or VSUSPEND and use the TSS CREATE(ACID) USING(ACID) PASS(XXXXX) NAME('******'); then use the TSS commands to add/remove or permit/revoke the permissions the new user should be assigned. We have tried this and it will work; just a little more work. Just a thought. The Service Desk staff should be able to remove those suspensions?
Sorry did not read Bob Boerum's note above.