if it's an arx file, that means that it was exported from Remedy. Remedy never stores un-encrypted passwords in the password file, so the value that was export must already be a hash...so the imported value from an arx file IS a hash.
On Mon, Jan 6, 2014 at 8:56 AM, Jean-Louis Halleux <[email protected]>wrote: > Then another question: how does ARS know that the value you submit in an > arx file containing users and passwords is the hash, and not the value in > clear text ? > > Thanks > Jean-Louis Halleux > [email protected] > > > > On 06 Jan 2014, at 15:52, "Grooms, Frederick W" <[email protected]> > wrote: > > > Export/Import works because both systems are ARS servers. You are not > decrypting/encrypting the password, just copying the encrypted value from > one server to another. It is just like having to restore a backup. > > If you look at the export you will see it is the hashed value. > > > > Fred > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of Jean-Louis Halleux > > Sent: Monday, January 06, 2014 1:54 AM > > To: [email protected] > > Subject: Re: Decrypt AR User password > > > > Hello Doug, > > > > I have then a question if you cannot decrypt a password: how can you > export data from the user form (including the password field), and then > import it to another server (with the password field) ? I tried it a long > time ago, and it used to work: users had access to the new server. > > > > Best regards, > > > > Jean-Louis Halleux > > [email protected] > > > > > > > > On 02 Jan 2014, at 18:35, "Mueller, Doug" <[email protected]> wrote: > > > >> 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"
