Re: View Form Issue with Date Field and Epoch Time
Thanks. I'll give that a shot because I don't really care about the actual time on these dates anyway. Thanks, Shawn Pierson Remedy Developer | Energy Transfer 1300 Main St. Houston, TX 77002 | 713.989.7226 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, January 03, 2014 11:04 PM To: arslist@ARSLIST.ORG Subject: Re: View Form Issue with Date Field and Epoch Time ** Shawn, What you will need to do is convert it to a Date instead of a Date/Time field if you want to handle before 1970. You will loose fidelity of time of day, but will be able to handle any date you will encounter On Jan 3, 2014 9:45 PM, Pierson, Shawn shawn.pier...@energytransfer.commailto:shawn.pier...@energytransfer.com wrote: ** Good afternoon, I think I've found a limitation in View Forms that is causing some issues. Basically, for the integration I built with HR data, I'm seeing errors when converting dates for people hired prior to 1970. There aren't any active folks like this, but it seems to be causing issues with my Escalation that double checks that these people, who may have left the company decades ago, no longer have a People record (despite the fact that none would have ever been created.) I've been planning on resolving this by filtering the data to only include records where the termination date is null or where the termination date happened in the past month. However, I am curious, how do we make Remedy handle dates prior to 1/1/1970 if the need arises in the future? Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed herehttp://www.energytransfer.com/mail_disclaimer.aspx. If you cannot access hyperlink, please e-mail sender. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Decrypt AR User password
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:arslist@ARSLIST.ORG] On Behalf Of Jean-Louis Halleux Sent: Monday, January 06, 2014 1:54 AM To: arslist@ARSLIST.ORG 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 supp...@arsmarts.com On 02 Jan 2014, at 18:35, Mueller, Doug doug_muel...@bmc.com 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:arslist@ARSLIST.ORG] On Behalf Of Kulkarni, Adhwari Sent: Thursday, January 02, 2014 1:06 AM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of James Smith Sent: 01 January 2014 19:35 To: arslist@ARSLIST.ORG 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
Re: Decrypt AR User password
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 supp...@arsmarts.comwrote: 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 supp...@arsmarts.com On 06 Jan 2014, at 15:52, Grooms, Frederick W frederick.w.gro...@xo.com 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: arslist@ARSLIST.ORG] On Behalf Of Jean-Louis Halleux Sent: Monday, January 06, 2014 1:54 AM To: arslist@ARSLIST.ORG 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 supp...@arsmarts.com On 02 Jan 2014, at 18:35, Mueller, Doug doug_muel...@bmc.com 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: arslist@ARSLIST.ORG] On Behalf Of Kulkarni, Adhwari Sent: Thursday, January 02, 2014 1:06 AM To: arslist@ARSLIST.ORG 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
Re: Decrypt AR User password
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 supp...@arsmarts.com On 06 Jan 2014, at 15:52, Grooms, Frederick W frederick.w.gro...@xo.com 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:arslist@ARSLIST.ORG] On Behalf Of Jean-Louis Halleux Sent: Monday, January 06, 2014 1:54 AM To: arslist@ARSLIST.ORG 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 supp...@arsmarts.com On 02 Jan 2014, at 18:35, Mueller, Doug doug_muel...@bmc.com 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:arslist@ARSLIST.ORG] On Behalf Of Kulkarni, Adhwari Sent: Thursday, January 02, 2014 1:06 AM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of James Smith
Re: Ignore WSDL Mappings
What I have done in the past for this type of situation is to grab the WSDL and save it as a file. I then Edit the file to remove the elements I don't want. In Remedy I then use that file to create the Filter. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tommy Morris Sent: Friday, January 03, 2014 11:09 AM To: arslist@ARSLIST.ORG Subject: Ignore WSDL Mappings ** AR, CMDB, ITSM 7.6.04sp4 MSSQL 2012 I am using a Filter to set fields in an external web service. When the WSDL loads it pulls all of the input mappings but I do not want to push some of the data. Is there a way to ignore a mapping field? If I leave the Form/Field next to the XML Data Type blank is pushes a NULL value which the external system does not like. Tommy Morris Sr. Remedy Developer | RadioShack Office# 817-415-2510 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: AIE Flat File to CMDB question
Hugo, What operating system is your AR Server? If it is Unix/Linux you will need to 'convert' the .csv using the win2Unix utility on the AR Server. Thanks! .: Mike T :. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hugo Ruesga Sent: Thursday, January 02, 2014 4:45 PM To: arslist@ARSLIST.ORG Subject: AIE Flat File to CMDB question ** Hhi Listers; I'm working with AIE but found something odd. I'm creating a Data mapping from a Flat file to push data into our CMDB, however and besides that I already have the .tbl file in place, when I'm creating the data mapping I'm not able to find none of the fields associated. I thought this is being done automatically when placing the tbl file path on the data mapping. Am I doing something wrong? Thanks in advance Hugo Ruesga Software Development Advisor US 972.577.7000 x 332.3868 MX +52 (33) 3332.3868 P Please consider the environment before printing this email The information contained in and transferred with this electronic message is intended only for the recipient(s) designated above, it is protected by law and it may contain information which is privileged and confidential. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. _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
Re: Caught exception :Object doesn't support property or method 'getProxyGlobalFields -
We are still facing this issue with no solution. And since this is external users with no control on what browser version they are using any help/ideas would be greatly appreciated. Support has been unable to guide us in anyway so far. Thank you, Pascale Sterrett Kenavo ar wech all jesus.ort...@lyondellbasell.com Sent by: arslist@ARSLIST.ORG 12/05/2013 12:48 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Caught exception :Object doesn't support property or method 'getProxyGlobalFields - I am not sure how it fixes it, but there seems to be some corruption that happens to the user's search preference, especially if it was migrated from the older version. The error usually pops in the consoles because the first thing that the console workflow does is to pull data for the logged in user from the AR System Search Preference table. Upon returning data to the form, the corrupt data ends up causing the mid-tier to throw the error. It is something in one of the rows that is returned. I would suggest trying it with one of your problem users in Production. I never got a straight answer on how to prevent it from happening. -Original Message- From: Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG] On Behalf Of pascale.sterr...@daimler.com Sent: Thursday, December 05, 2013 2:28 PM To: arslist@ARSLIST.ORG Subject: Re: Caught exception :Object doesn't support property or method 'getProxyGlobalFields - This is very odd. I did exactly what you suggested in our QA environment. And so far the error seems to be gone. I will not do the happy happy joy joy dance yet. But I don't understand the link between that form and the error. But the Web is not my strongest point knowledge. Thank you, Pascale Sterrett Kenavo ar wech all jesus.ort...@lyondellbasell.com Sent by: arslist@ARSLIST.ORG 12/05/2013 11:59 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Caught exception :Object doesn't support property or method 'getProxyGlobalFields - This happened to me when upgrading to 7.6.04 SP2. Our particular error, Caught exception :Object doesn't support property or method, was being caused by the AR System Search Preferences form. Apparently any user search preferences that were created previous to the upgrade were causing the issue. BMC recommended deleting entries in the AR System Search Preferences form. It only happened to a few users and when they would encounter these issues, I would go to that form and delete any entries for a particular user. That error usually pops up whenever the user would go to one of the consoles. Try that out. -Original Message- From: Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG] On Behalf Of pascale.sterr...@daimler.com Sent: Thursday, December 05, 2013 10:11 AM To: arslist@ARSLIST.ORG Subject: Caught exception :Object doesn't support property or method 'getProxyGlobalFields - Hi all, We need some help with a production issue from all the web guru out there. This issue only happens since we upgraded our environment to AR Server and Mid Tier to 7.6.04 SP5. This is only on a custom Web application. Only users on IE 9 or IE10 experience this error. The same users were fine on Mid Tier 7.5 patch 007. Users on IE8 are OK. We have the web servers running in IE8 compatibility mode in QA as a test to see if it would solved the issue, but that did not solved the issue. It doesn't seemed to be a compatibility issue anyway. We told the user to clear their cache and run in compatibility mode but that doesn't work at all just in case but off course it doesn't change anything. As anyone have any idea what this could be? and why only since the upgrade? Thank you, Pascale Sterrett Kenavo ar wech all If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years Information contained in this email is subject to the disclaimer found by clicking on the following link: http://www.lyondellbasell.com/Footer/Disclaimer/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years Information contained in this email is subject to the
Last object executed
I seem to remember a plug-in or Run Process which would allow you to view the name of the the last object executed (Active Link, Filter, Escalation, etc.) We have an intermittent occurrence that could be caught through a trap (Filter, etc.) with such a plug-in (or we leave a log on forever :) ) This could be a manual mis-entry of data and it is definitely low priority. Does anyone recall such a plug-in or Run Process? I remember it way back in the good old days, so all of you old people from pre-3.0, please tax your minds. Thanks Gordon ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Decrypt AR User password
Jean-Louis, To confirm the response from Fredrick - we export the hashed value and then import the hashed value. So, there is no decrypting of the value and there is never a time when we store the clear text password. Now, on minor clarification on LJ's comments. Sure, in general, an arx file is generated by the AR System, but it can be generated by anyone - it is a defined format. And, you could import users using a .csv or other format - or create them manually. If you are exporting from AR System, the password will always be the hashed value as that is all we have stored. But, if you create an import file from ANOTHER source or you create users manually in a file (with passwords which is terribly unsecure of course), you could have cleartext passwords in a file. NOTE that the Remedy environment would NEVER do this. But, you could do it outside our system How do we know it is the hashed value vs. a password??? Because of the length. All hashed values are the same length and are the max password length. Anything not that length is assumed to be the password itself. We would hash that password and that is what we would store. Of course we have the password for that transaction because you just sent it to us, but we store only a hashed value and NEVER the clear text. So, we do know the difference between a hashed and clear text value and will handle it appropriately. But to re-emphasize. We never store the clear text password anywhere - you will even see that we do not report that information in the logs so you cannot use logging to trap passwords. In addition, we even know the password field and do an encryption on the wire so that it is not cleartext on the wire between the client and the server either (this is independent of whether you have turned off full package encryption which is on by default). We can accept a clear text password to define a user or modify a user (all controlled by permissions of course) and we do know the difference between the value we receive about whether it is hashed or clear text. I hope this helps, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Monday, January 06, 2014 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Decrypt AR User password ** 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 supp...@arsmarts.commailto:supp...@arsmarts.com 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 supp...@arsmarts.commailto:supp...@arsmarts.com On 06 Jan 2014, at 15:52, Grooms, Frederick W frederick.w.gro...@xo.commailto:frederick.w.gro...@xo.com 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:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Jean-Louis Halleux Sent: Monday, January 06, 2014 1:54 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG 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 supp...@arsmarts.commailto:supp...@arsmarts.com On 02 Jan 2014, at 18:35, Mueller, Doug doug_muel...@bmc.commailto:doug_muel...@bmc.com 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
Re: Decrypt AR User password
Excellent explanation Doug. -vineet bhargava Sent from BlackBerry® on Airtel -Original Message- From: Mueller, Doug doug_muel...@bmc.com Sender: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Date: Mon, 6 Jan 2014 12:14:50 To: arslist@ARSLIST.ORG Reply-To: arslist@ARSLIST.ORG Subject: Re: Decrypt AR User password Jean-Louis, To confirm the response from Fredrick - we export the hashed value and then import the hashed value. So, there is no decrypting of the value and there is never a time when we store the clear text password. Now, on minor clarification on LJ's comments. Sure, in general, an arx file is generated by the AR System, but it can be generated by anyone - it is a defined format. And, you could import users using a .csv or other format - or create them manually. If you are exporting from AR System, the password will always be the hashed value as that is all we have stored. But, if you create an import file from ANOTHER source or you create users manually in a file (with passwords which is terribly unsecure of course), you could have cleartext passwords in a file. NOTE that the Remedy environment would NEVER do this. But, you could do it outside our system How do we know it is the hashed value vs. a password??? Because of the length. All hashed values are the same length and are the max password length. Anything not that length is assumed to be the password itself. We would hash that password and that is what we would store. Of course we have the password for that transaction because you just sent it to us, but we store only a hashed value and NEVER the clear text. So, we do know the difference between a hashed and clear text value and will handle it appropriately. But to re-emphasize. We never store the clear text password anywhere - you will even see that we do not report that information in the logs so you cannot use logging to trap passwords. In addition, we even know the password field and do an encryption on the wire so that it is not cleartext on the wire between the client and the server either (this is independent of whether you have turned off full package encryption which is on by default). We can accept a clear text password to define a user or modify a user (all controlled by permissions of course) and we do know the difference between the value we receive about whether it is hashed or clear text. I hope this helps, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Monday, January 06, 2014 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Decrypt AR User password ** 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 supp...@arsmarts.commailto:supp...@arsmarts.com 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 supp...@arsmarts.commailto:supp...@arsmarts.com On 06 Jan 2014, at 15:52, Grooms, Frederick W frederick.w.gro...@xo.commailto:frederick.w.gro...@xo.com 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:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Jean-Louis Halleux Sent: Monday, January 06, 2014 1:54 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG 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 supp...@arsmarts.commailto:supp...@arsmarts.com On 02 Jan 2014, at 18:35, Mueller, Doug doug_muel...@bmc.commailto:doug_muel...@bmc.com 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
Re: Decrypt AR User 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. Hashes don’t change because you copy it. -John On Mon, Jan 6, 2014 at 1:54 AM, Jean-Louis Halleux supp...@arsmarts.comwrote: 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 supp...@arsmarts.com On 02 Jan 2014, at 18:35, Mueller, Doug doug_muel...@bmc.com 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: arslist@ARSLIST.ORG] On Behalf Of Kulkarni, Adhwari Sent: Thursday, January 02, 2014 1:06 AM To: arslist@ARSLIST.ORG 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: arslist@ARSLIST.ORG] On Behalf Of James Smith Sent: 01 January 2014 19:35 To: arslist@ARSLIST.ORG 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
Re: SSL cert Import Error: keytool error: java.lang.Exception: Input not an X.509 certificate
SSL cert with .cert or .pfx format but gives an error. On Fri, Jan 3, 2014 at 8:04 AM, John Baker jba...@javasystemsolutions.comwrote: What are you trying to import? It sounds like you need to use openssl or some other tool to convert the certificate into something keytool can read - keytool is a nightmare. :) ___ 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
Join Form fields positioning
Hi, I create a Join Form from two forms which contain a lot of fields. I take all fields from the first form and only one from the second. The result Join form is a mess of fields. One through other, one above the other. I would like to have the positioning and the whole join form view appearance as the first form (view) of the Join. My questions: - When I create the Join form and choose the first Regular form there is also a choice of the View of the regular form but this view is totaly not taken into account. Why is there then this choice possibility ? - How can I make the join so the view of the join looks exactly as the View of the first regular ? I use 7.6.04 btw. thank you all in advance for any tips. best regards Marek ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Join Form fields positioning
The view question is for Field Labels if I'm not mistakenand I'm not familiar with ANY mechanism available to ensure that they sync on form creation, or at any point later in time, simply because they are different forms with different views, so they can be different from eachother. On Mon, Jan 6, 2014 at 11:40 AM, Marek Ceizel freean...@freeangel.euwrote: Hi, I create a Join Form from two forms which contain a lot of fields. I take all fields from the first form and only one from the second. The result Join form is a mess of fields. One through other, one above the other. I would like to have the positioning and the whole join form view appearance as the first form (view) of the Join. My questions: - When I create the Join form and choose the first Regular form there is also a choice of the View of the regular form but this view is totaly not taken into account. Why is there then this choice possibility ? - How can I make the join so the view of the join looks exactly as the View of the first regular ? I use 7.6.04 btw. thank you all in advance for any tips. best regards Marek ___ 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
Re: Join Form fields positioning
Hi, I mean the fields positioning not fields labels. Marek ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: BSM Dashboards 7.7
Tauf, Thanks for the reply. The more and more I keep digging into Dashboards 7.7.01, the more and more I shake my head I've found that it not only utilizes an instance of mySQL, but utilizes an instance of Apache Derby DB as well. The Dashboard users are stored in the schema BSMDASHBOARDSAPP under the table BSD_USERS within Derby. Utilizing command line JDBC calls, the following call is stating that userid or password is invalid 'jdbc:derby://localhost:1528/bsmdashboards'; Once I can get in through this jdbc connection it will be easy to script out my integration - it's just finding the userid and password that I will need to connect :-) Rob On Sat, Jan 4, 2014 at 6:28 AM, Tauf Chowdhury taufc...@gmail.com wrote: ** Rob, I don't know the answer to your question but from experience and the direction I've seen BMC going, they will most likely retire the Dashboards product. They will be looking to take advantage of BOXI 4 and it's SDK for both Analytics and dashboards capabilities. So armed with that knowledge, you can weigh the pros and cons of pursuing the integration and development time you're going to be putting in to the current product. Sent from my iPhone On Jan 3, 2014, at 1:08 AM, Rob Dudley duds1...@gmail.com wrote: ** Listers, Ok, so I've figured out the root MySQL password and the cs050101 password... however, I'm still having an issue as to where it stores the Dashboards usernames/passwords since they don't store anywhere in the database... Has anyone built an integration using Remedy API to create a Dashboards account through Remedy? Basically what I was thinking was: When a user profile is saved/modified within Remedy (with some kind of dashboards flag albeit checkbox or group membership), to fire a command to dashboards to create an account with the same login id. Was hoping to write a SQL script to do it, however that seems to be out of the question now... Thoughts? Comments? Bueller? On Thu, Jan 2, 2014 at 4:40 PM, Rob Dudley duds1...@gmail.com wrote: Greetings listers, I've searched and searched and searched, yet I cannot seem to find the default root user password for the MySQL db which is installed with the dashboards product. The problem is that I've changed the root password so that I can see/access the Db (I did this hoping that I could find out which table holds the actual dashboards users so that I could write an api to auto create the accounts). Apparently changing it was bad because some genius thought it would be good to have the jdbc connection, connect to the Db using the root user instead of granting a specific user to the databases it needs...smh I would be ever so grateful if someone could please either post or email me directly the default root password so that I can change it back without having to do a reinstall. Thank you in advance, Rob _ARSlist: Where the Answers Are and have been for 20 years_ _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
AR System 7.5 SSO Plug-ins
Hello, I thought I would reach out here for some insight and see if any of you have experience with Single Sign-On functionality with Remedy 7.5 There are some Plug-ins floating around out there, but the ones I have found I have not had any luck with. According to BMC these plug-ins while functional are not technically supported, but there is a very high demand for this functionality in my organization so I was going to do some testing with them, but I have yet to find any plug-ins that have been successful. Have any of you found a reliable place to get these or done the same with your 7.5 environments? Any tips, tricks, advice or information would be extremely helpful. Thank you! Tim ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
