Doug,

   With the below, would we not also have to create a filter (or escalation 
maybe) that fires on a system restart to set the user_cache password to 
INVALID?  Otherwise, I assume that a system restart will put the users pwd back 
in cache.

   Would be nice if BMC had some way to simply identify that the user is no 
longer a valid user of the system and cannot log in?  Seems like once a support 
person, always a support person.  Is it possible to change the 'support person' 
flag to 'No' and remove the user record?

thank you
  

----- Original Message -----
From: "Doug Mueller" <doug_muel...@bmc.com>
To: arslist@ARSLIST.ORG
Sent: Friday, January 31, 2014 3:59:04 PM
Subject: Re: Target Attack and BMC Software ITSM?  (Disable user sub-discussion)

** 


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 3 rd 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 _ARSlist: "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"

Reply via email to