The fourth case of "create" is a "create or merge" to put whatever protection you wanted about bringing in a user from another environment. You could even check on the merge whether the user exists and do the "modify" control or the "create" control.
So, that is covered however you want. Yes, an arreload would reload the passwords and cause a reset of the password. Note that it would also reset the password for the case of a user who was invalidated because of too many bad passwords. arreload is a brute force reset of the user list. Of course if there were a productized disable, arreload would protect this (and it is probable that we should have arreload not clear INVALID to not reset accounts where they are disabled by bad passwords either -- but that is a discussion to have and a decision to make. We never run arrload so you are in complete control of whether or not it is run and if you run it, you can always disable users again by setting their status to Disabled (notice the logic will run to remark INVALID if they are an disabled user already and you reset the status to Disabled so you could have an Escalation that never runs and do a one time run that finds all Disabled users and sets them to Disabled that you do a one time run after any run of arreload.... The key to this message is that if this is something that is of interest, there is a way you can do it yourself and the idea of keying of the feature of too many bad passwords and the INVALID user is an interesting way to do it. Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Friday, January 31, 2014 1:19 PM To: arslist@ARSLIST.ORG Subject: Re: Target Attack and BMC Software ITSM? (Disable user sub-discussion) 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
