IBM Mainframe Forum

We have a requirement to set an ID to have the PROTECTED attribute. Very straightforward, but how would we back out that change if we needed to? Removing the PROTECTED attribute is simply a matter of setting a password, but as we don't know what the current password is, we can't do that, we could only set a different one which wouldn't be much use.

We have zSecure Admin and CKGRACF has an a PWSET PREVIOUS option, but I cannot get that to work in this instance. I assume setting the ID to PROTECTED wipes the password history.

Any ideas?

Thanks.

Removing the PROTECTED attribute is simply a matter of setting a password, but as we don't know what the current password is, we can't do that, we could only set a different one which wouldn't be much use.

This makes ABSOLUTELY no sense. Since the password history is removed when PROTECTED is set, what does it matter what the current password is? Answer: it doesn't -- if you have to remove the PROTECTED attribute by giving the user id a password, you just give it whatever password you want it to have. The current password would not be what the new password is, but again -- so what? You don't explain WHY it "wouldn't be much use" to use a different password, and I cannot see any circumstances under which it would matter.

Apologies if I wasn't clear, but I thought that my mentioning a backout of the change meant that it was self explanatory.

The ID is currently not PROTECTED, i.e.; it has a password, but we do not know what the password is.
We wish to make it PROTECTED.
In the case of any unexpected problems meaning we need to backout, how would we do that, i.e.; set it back to the previous (unknown) password?

how would we do that, i.e.; set it back to the previous (unknown) password?

You don't -- if you don't know the password, you cannot undo the change to PROTECTED by resetting the password to what it was. RACF does not store the password so there is no way to know what it was (other than asking whoever set it). There are some occasions (and this would be one of them) when back out cannot occur or is very expensive to implement.

I suppose you could make a backup of the RACF data base before making the change so you could back out the change by restoring the RACF data base, but why would you need to back out the change? Your whole line of questioning here is EXTREMELY bizarre since the whole point of using PROTECTED is for a user id that is NEVER used to sign onto the system -- and if that is true, when and how did the user id get a password in the first place? If it is still using the default password assigned when the user id was created, then you could set it to whatever you want with no issues; if the password is not the default password then why was the user id used for a log on (or why are you wanting to set a user id used to sign onto the system to PROTECTED)?

I’m sorry that you find that my question makes ABSOLUTELY no sense and my whole line of questioning EXTREMELY bizarre. I can only presume that you work in an environment where you can slap anything in to production without a tested and proven backout plan. Unfortunately I do not have that luxury. Either that or you work somewhere where everything is set up so perfectly in the first place that nothing ever needs changing, or everything has been documented to the n’th degree so there is never any room for uncertainty or ambiguity.

I am fully aware of what the PROTECTED attribute does. If I knew why the ID had a password in the first place then perhaps I wouldn’t be in this situation, but the reason for that, if there ever was one, is lost in the midst of time. Since you seem so keen on knowing all the ins and outs of the situation, the ID is a DB2 package owner and an authorisation call is made to RACF when the package is executed. As far as I can ascertain, that is it’s only use, there is no other evidence of any activity. We wish to protect it, as otherwise, were it to be revoked either accidentally or maliciously, those packages would fail to execute. But in order to get the change approved, we need a backout – and that means getting the password back to whatever it is now, not merely unprotecting it.

You’re suggestion about restoring the RACF database is really not viable. If we were making the change at a time when there was no activity and we could test it immediately then it might be, but the nature of the issue is such that if there were to be a problem, it would likely surface some time later. There must be a way, albeit not necessarily documented or supported, to get the encrypted password out of the database. In case anyone else comes across this issue, this is what we have found –

From reading the zSecure manual, it suggests that the R (Recreate) command in option RA.U can be used to generate all commands to recreate a user, including the current password. This example from the manual –
ckgracf field USER USR0001 set password(’E40B16EBE88BD808’X)

Initially we couldn’t get this to work, it was generating a password statement without a corresponding value, which means it will assign a random (and unknown) password. We then determined that accessing the RACF database directly rather than via the CKNSERVE task (in SE.1, blank out the ‘zSecure Node name’ field) will correctly generate the set password statement with the encrypted password value, assuming of course that you have read access to the RACF database. This can then be used to set the password back to it’s previous value when backing out the PROTECT.

Can I suggest in future, if you don’t know the answer to the question, as you clearly don’t in this case, that you just refrain from posting anything rather than critiquing the approach?

Interesting, I have always been under the impression that you could not retrieve the passwords stored in the RACF database, indeed the manual still says "RACF provides a one-way encoding. That is, data encrypted by RACF can only be decoded if the data is already known.".
But I can see that ZSecure reading the encrypted value and later writing it back would solve that issue. And it should not be a security exposure as noone could deduct the real password. I've never come across the format "password(’E40B16EBE88BD808’X)", must be a ZSecure thingie. I'm not a ZSecure export, though I know a guy who is.
And now a stupid question - when your DB2 package is called, is the password not passed along in the request?

Good point about the DB2 packages! I can’t be 100% sure of course, which is one of the reasons we need a backout, but I suspect that password is not used. For one, although I’m not a DB2 expert, as I understand it anyone with the correct level of authorisation can bind a package to have a particular owner. The password is not specified as part of that process and so presumably it’s not used later. I also know for a fact that we have other packages executing successfully where the owner is PROTECTED, so again, that suggests that a password is not used.

I believe that the “password(’E40B16EBE88BD808’X)” statement is merely the encrypted value of the password taken directly from the RACF database rather than anything specific to zSecure. Indeed, under the FIELD command, the manual says “The FIELD command requires an exact specification of the field in a format that matches the RACF internal representation of the field value.”