Question
· Mar 16, 2017

How can we give users access to Change Password in %SYS?

Hello; we have users on the system with cache logins.  They have access to a specific namespace, and no access to %SYS of course.  I'd like to give each user the ability to change his own password from within our application, using Security.User.PasswordExternal.  This only exists in the %SYS namespace, and the average user can't get to it.  

 

Should I give the users access to this column in this table (column Password, table Security.Users)?  What about access to the namespace?  Is this possible? Has anyone done this before?

 

Thanks,

Laura

Discussion (10)1
Log in or sign up to continue

We've been using the $SYSTEM.Security.ChangePassword since 3/2017, apparently, and only recently have I noticed that it's logging a <PROTECT> error, and yet still changes the user's password (only recently have users been required to change passwords):

<PROTECT>EMSUpdatePassword+2^%SYS.SECURITY *c:\intersystems\ensembledev\mgr\"  at  8:27 am.   $I=|TNT|192.168.32.100:62074|11696   ($X=0  $Y=26)
     $J=11696  $ZA=0   $ZB=$c(13)   $ZS=262144 ($S=268247904)
     source   code not available

I'm using this line of code: 

set bChanged = $system.Security.ChangePassword($username,newPass,oldPass,.ok)

bChanged is not in the error trap; ok =1; the user's password is generally changed, as far as I can tell, because we don't get users asking why they cannot log in.  I can recreate this from the terminal using a username without much acess (no %SYS access).

I'm sure there's a security thing going on here.  Why would this error get logged?  It makes me nervous, as we're adding more users who will need to change their passwords often.

Any ideas?

I can't compile or step through the code - it's hidden.

Thanks,

Laura

I can do that.  For future queries, I'm getting these 4 errors in the Audit Database for each error:

Description: Attempt to access a protected resource
Reoutine: EMSUpdatePassword+2^%SYS.SECURITY |"^^c:\intersystems\ensembledev\mgr\"|
Namespace: {namespace}
Event Data: <PROTECT>EMSUpdatePassword+2^%SYS.SECURITY *c:\intersystems\ensembledev\mgr\

Description: Attempt to access a protected database
Routine: Store+5^%ETN |"^^c:\intersystems\ensembledev\mgr\cachelib\"|
Namespace: {namespace}
Event Data: <PROTECT>Store+5^%ETN

Description: Attempt to access a protected database
Routine: Value^%STACK |"^^c:\intersystems\ensembledev\mgr\cachelib\"|
Namespace: {namespace}
Event Data: <PROTECT>Value^%STACK

Description: Attempt to access a protected resource
Routine: ^%SYS.SECURITY |"^^c:\intersystems\ensembledev\mgr\"|
Namespace: {namespace}
Event Data: <PROTECT>^%SYS.SECURITY *$TEXT(EMSUpdatePassword+2^%SYS.SECURITY)

I'll ask IS.

Thanks,

Laura

Laura, this probably deserves to be posted as a new question so more people will see it. But your situation isn't clear to me. If a user can't log in (why?), how are they going to be able to run something that will log out all their sessions?

I also recommend the use of the "comment" link that appears under questions, answers, or other comments. I think this helps put a response into the relevant context.

John, thanks for the response. I might ask this explicitly in the DC later, but I'll have to look at my notes before I do, as I'm sure I'll get some flak.  Just for informational purposes: we were instructed to restrict our users to a  single tab in our web application.  I know this is not how a web application is supposed to work (according to many users on google groups writing about this sort of thing), but the directive came from above.  I wrote simple logic to check if a user has a session already, and if so, he can't open a second tab. Sometimes, due to a bug, or timeouts on queries, the logic thinks the user has a second session when he does not.   At that point the user can't even log into the application. It's at this point that he'll have to call IT, who will have to call a developer, who can then kill his sessions manually from the management portal.  I was trying to give the users a way to "reset" or "clear" their own sessions (logging in first to a separate page perhaps) so that they can use the application again.  When I first began to look at this, I realized that most of this has to be done in the %SYS namespace; hence the problem, and its relavance to this question about changing their own password.

 

However, it hasn't been an issue (yet), so it's on my back burner. When it becomes an issue I'm sure I'll be back asing about it.

 

As always, thanks for the help.

Laura