Several comments on this thread. First...
There is no way to get a user's current password. PERIOD. It is not possible. We in fact do not ever store the user's password in our system. We store a one-way hashed copy of the password. When validating a user, we hash the password they give us and compare to the hashed password we have stored. We cannot take the hashed password and regenerate the original password. This is the most secure method for handling passwords in the system. And, no one, not even an Administrator, can ever get the password that a user has defined. This is important because users generally use the same password for many things so if you could reverse engineer their password you could gain access to other things that that user has access to. This is not possible with the strategy we use. Now, on to the question about wanting to verify a user..... If you are coming in from a client or from workflow and you are the user and you want the user to verify their own password, the Application-Confirm-Password operation will work. NOTE that this is verifying the password of the CURRENT user session. There is no ability for one user to use this command to verify the password of another user. If you are coming in from an API program, simply issue a call like ARVerifyUser and supply the user name and password (and authentication information if that is required) and validate the user. If you want to run the program as a different user than the user whose password you are changing, just use different control records for the program and the call to the ARVerifyUser (remember to terminate both sessions). This will validate the password for the user as you are logging them into the system. Note that if using external authentication, your password is not in the AR System at all so you likely should be changing it through another mechanism supplied by the external source. If you are using external authentication directly, you can still validate a users password using the above techniques. Now, if using SSO, there is another layer going on. The AR System NEVER sees the user's password at all. That is intercepted at the SSO level. So, there is no way to validate the user's password through the AR System if using SSO (unless of course you write a custom interface to wherever SSO is validating things and you pass through that custom logic. I hope this is helpful in solving your situation. Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Kulkarni, Adhwari Sent: Thursday, January 02, 2014 1:06 AM To: [email protected] Subject: Re: Decrypt AR User password Hi James, If you want to validate a user and change its password using API, you can simply create an instance of ARServerUser (Changes as per C/Java code) and pass the username and password that the user has entered. By just trying to do a .login(), you should be able to check if it’s a valid user or not. Also, you can use the setPassword() method to change the password. Also, you should not pass the passwords from field ID 102 to the APIs. The password passed through field 102 is hashed and not encrypted. If you need to confirm the password, pass it through field ID 123. Regards, Adhwari The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of James Smith Sent: 01 January 2014 19:35 To: [email protected] Subject: Re: Decrypt AR User password Thanks LJ Longwing I tried executeSpecialCommand as well but its generating same exception. I saw a new method - ExecuteProcessForActiveLink but I need to pass the activelink name as an argument for this method. It seems there is no way to validate users password. Happy New Year. _______________________________________________________________________________ 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"
