Hi Doug,
I guess a direct sql against the user_cache will work as long as you do not
run an arrelod -U command, or copy the records from the User-form to another
server using ARX-files or the API...
The above steps would reactivate the user, right?
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Everyone,
>
> As an adjunct to this conversation, there has come up again a topic that is
> asked about periodically -
>
> What does the Disable mean on the User form for a user.
>
> Well, out of the box, it doesn't mean anything. We always are considering
> what it should mean, but a bit
> part of the discussion is what does it mean in conjunction with AREA and
> external authentication. If a user
> is disabled, should they fail in an AREA authentication? Or do they succeed.
> If they succeed, do we still add
> on permissions from the user record (cross-reference-blank-password) or do we
> authenticate them but
> not authorize them (confusing). Or, do we just let them succeed and attach
> permissions or whatever that
> is cross-referenced but if you chain AREA and ARS, we would be OK with AREA
> but not if that didn't pass
> and we moved to (chained to) ARS for authentication.
>
> Anyway, for those who want to make the disable operation be meaningful, there
> is a simple workflow
> technique you can use. To offer a complete solution, we are talking about 3
> or 4 filters.
>
> This would be for handling ARS validation - essentially using the 3rd option
> above for AREA, if the user
> validates with AREA, it is OK and any information on the AR System user record
> that is cross referenced is
> used - but we would not pass any authentication that is chained to ARS.
>
>
> OK, the filters:
>
> Disable an existing user
>
> Filter that fires on Modify with a run if of TR.Status = "Disabled".
> Action is to perform a Direct SQL command to update the password in the
> user_cache table to INVALID
>
> Update user_cache SET (password = 'INVALID') WHERE entryId = '$1$'
>
> entry ID is the key we link by although you could also user username =
> '$101$' as well to set for matching
> user name. Either would work.
>
> Yes, the word INVALID. This is the same value we put in the password field of
> the user_cache record when
> a user is blocked for too many bad password attempts. This user can NEVER
> login unless his password is
> reset by someone else as they cannot login to change it.
>
> (depending on your DB as some DBs want parenthesis around the set clause and
> others do not if there is
> only one item in the clause)
>
>
> Prevent work on a disabled user
>
> Filter that if Status = "Disabled" and Password != $NULL$ will return an
> error that you cannot change the
> password of a disabled user.
>
> Or you could block all change to a disabled user or do whatever you want here
> to prevent a password change
> for a disabled user which would then reset the password and reactivate them.
>
>
> Reactivate a disabled user
>
> Filter that if TR.Status = "Enabled" and DB.Status = "Disabled" will run check
> that there is a password
> specified (must change password on enable) and that if you are using the user
> password feature you set the
> option to require the user to change password on first login for this user so
> that they have to change after
> login as their password is known by someone else.
>
>
> Create a disabled user
>
> Now if you want to create a disabled user, there is a bit more effort. The
> problem is that the user_cache
> entry doesn't exist for you to modify as the User record is being created.
>
> You could just disallow Status = Disabled on Create/Merge. Argument is why
> are you creating disabled users?
>
> Of if you want to, you need to do something to disable the user right after
> create (phase 3 run process that
> comes back and updates the user_cache entry after it is there or something
> similar).
>
>
> Whether we add this or not is under discussion, but it is clearly something
> you can do on your own system
> if desired. I just wanted to get a solution out there for folks who wanted to
> do something in this area.
>
> I hope this is useful,
>
> Doug Mueller
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
