Author |
Message
|
maheshnair78 |
Posted: Fri Nov 21, 2003 10:50 am Post subject: [SOLVED]Serious issue ADMIN PASSWORD GOT CHANGED |
|
|
Newbie
Joined: 21 Nov 2003 Posts: 4
|
,
We had a serious issue in our production environment .
All of a sudden the admin password got changed
We could not trace it for 2 days and due to which workflow could not be stopped ...fmcautil -u admin -p password ???
Nor we could not start extra execution servers , On account of which performance in production was degrading .
But to our luck , We could trace it from one of our engineers had mistakingly changed the password from his client thinking it was pointing to a test server and he forgot about it .So due to which we could get the old password restored .
Now my worry is , in case we were unlucky , is their any way to reset it nor get it back ..
Becauuse since without admin password none of workflow activities is possible like monitoting etc .
During my analysis i could find that workflow stores the user details in table PERSON IN THE RUNTIME DATABASE .
Is their any way to get the password in case we loose or forget it .
************************************************************ |
|
Back to top |
|
 |
devin |
Posted: Fri Nov 21, 2003 11:20 am Post subject: |
|
|
Voyager
Joined: 27 Oct 2003 Posts: 82
|
|
Back to top |
|
 |
maheshnair78 |
Posted: Fri Nov 21, 2003 11:44 am Post subject: |
|
|
Newbie
Joined: 21 Nov 2003 Posts: 4
|
Ya ,
I have seen the link .
The issue is we have no other users with admin rights.
ADMIN is the only administartor . |
|
Back to top |
|
 |
vennela |
Posted: Fri Nov 21, 2003 11:48 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
You will have to delete the configuration and recreate the configuration. There is no other way. |
|
Back to top |
|
 |
jmac |
Posted: Fri Nov 21, 2003 12:07 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
It is always a good idea to define yourself another "System Administrator" user and import it into your runtime db. To do this simply go to the Authorizations tab and select All the functions, give the user access to the workitems of ALL Users, and Administration Access to ALL categories. _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
Andy |
Posted: Tue Nov 25, 2003 4:48 am Post subject: |
|
|
 Centurion
Joined: 14 May 2003 Posts: 122
|
maheshnair78 wrote: |
The issue is we have no other users with admin rights. |
You can update ADMIN password and import FDL if any of the user have 'Staff Definition' authorization.
It is not necessary to have System Administrator role to import FDL into run time. Isn't it? _________________
Andy |
|
Back to top |
|
 |
sshaker |
Posted: Thu May 27, 2004 9:40 am Post subject: |
|
|
 Disciple
Joined: 20 Sep 2002 Posts: 185
|
Hi
U can change the password using APIs. Create a small program that changes the password for admin. Good practice is to change the password from default and restrict the usage. It will help to have different passwords to each environment.
Regarding having more than one system administrator, my understanding is we can have only one system administrator as the role system administrator allows one user to be assigned, unlike other roles we define.
Quote: |
The exception to the rule is that
the predefined ROLE System Administrator can only have one
related person. |
_________________ shaker |
|
Back to top |
|
 |
Ratan |
Posted: Thu May 27, 2004 11:59 am Post subject: |
|
|
 Grand Master
Joined: 18 Jul 2002 Posts: 1245
|
Shaker, how would he login to change the pasword??
Probably I am missing something. _________________ -Ratan |
|
Back to top |
|
 |
jmac |
Posted: Thu May 27, 2004 12:05 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
I have recently solved this issue with an authorization exit.
You simply have a way using your auth exit that would always let you in. Then you can use the API to change the Password.
The issues are:
1. You need to have the auth exit with this special "feature".
2. You need to secure the special feature so that not anyone can get in and use it.
I have tested this on 3.4 and 3.5 and it works fine. _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
Ratan |
Posted: Thu May 27, 2004 12:30 pm Post subject: |
|
|
 Grand Master
Joined: 18 Jul 2002 Posts: 1245
|
John, What is the special feature you are talking about? I always thought I can just define an authentication exit and log a user in without the password(code my authentication exit in such a way that it does nothin but return the userID to WF ). Once I am in I can Change the password (In case I lost the password).
Do I need any special feature for this? _________________ -Ratan |
|
Back to top |
|
 |
jmac |
Posted: Thu May 27, 2004 3:13 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
Ratan:
I sent the last note on a quick break so I did not explain fully. What I mean by "special feature" is that I need to have some type of a hook in my authentication exit that will let me in without actually doing any password evalutation.
Assume I am using LDAP, most times when my exit gets control I call LDAP and determine whether or not I let the user into MQWF. In order to use this password reset facility, I want to have some "hook" in the exit that lets me in without authenticating against LDAP. In my sample what I did was use "RESETPW" as my Credentials. Now anytime my authentication exit is triggered I check to see if the credentials are RESETPW and if so, I let the user in without authenticating against LDAP. This would get me a valiad ExecutionService object without logging in with the current MQWF RT password. Using the ExecutionService::setPassword().
I am out until next tuesday, if you need a better explanation I will get back with you then.
Regards _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
Ratan |
Posted: Fri May 28, 2004 7:14 am Post subject: |
|
|
 Grand Master
Joined: 18 Jul 2002 Posts: 1245
|
Ok. That is what I thought.
-Thnx _________________ -Ratan |
|
Back to top |
|
 |
bharath |
Posted: Tue Jun 01, 2004 2:40 pm Post subject: Resetting admin password to default value |
|
|
Newbie
Joined: 27 May 2003 Posts: 4
|
Just wanted to share alternative solution for information purpose though it looks a bit crude way..
The idea is to UPDATE password column of fmc.person table from WF runtime db with default password. For any newly created runtime system, admin user's password = password. (This is the only reverse hashed value that we can know for WF system on any machine). I think, the underlying password hashing technique in MQ WF uses system & network specific information (like IP address, domain names).
1. Create new runtime system, get hashed password value from fmc.person table of workflow runtime db
(select password from fmc.person where name='ADMIN'
ex - x'5DC201936915DECABB651611D9D5E437'
)
2. Update your runtime system [that is locked up] db with hashed password retrieved from newly created runtime system.
(update fmc.person set PASSWORD=x'5DC201936915DECABB651611D9D5E437' where NAME='ADMIN')
This should reset ADMIN password back to default value 'password'.
Eventhough, IBM strongly suggests users NOT to touch runtime db, I think, any action would be no worse than getting rid of runtime (IBM suggests that as last option). _________________ ------------------------------------------------------------
Bharath
IBM Certified Solution Designer - MQ Workflow 3.4 |
|
Back to top |
|
 |
jmac |
Posted: Tue Jun 01, 2004 3:18 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
Bharath:
I do not think what you are suggesting will work. The issue is that the MQWF password is encrypted using the SYSTEM and SYSTEM GROUP names.
IF you want to do this ( I would strongly recommend you not except in a dire emergency) follow these steps.
1. Export ADMIN from a Buildtime Database that matches the System and SystemGroup of the target Runtime system.
2. Using the value specified in the PASSWORD tag of the FDL update the Password column of the Person table in the affected RTDB.
Remember, this is NOT recommended, and you can avoid the problem by simply importing an Emergency_user into your RTDB that has all authorities and a known password when your RTDB is created. Or if you have an authentication exit you can follow the procedure outlined above.
Here is the FDL I use for my Emergency user. Note that with NO password specified the default password will be password. Also note that there is NO System or SystemGroup specified, this will default to the System/SystemGroup specified for the RTDB you import into. If you wish to change the password for this user, simply use the admin utility to make the change
Code: |
PERSON 'EMERGENCY'
DESCRIPTION ""
AUTHORIZED_FOR STAFF
AUTHORIZED_FOR AUTHORIZATION
AUTHORIZED_FOR OPERATION
AUTHORIZED_FOR TOPOLOGY
AUTHORIZED_FOR PROCESS_MODELING
AUTHORIZED_FOR PROCESS_CATEGORY ALL AS_ADMINISTRATOR
AUTHORIZED_FOR WORKITEMS_OF ALL
IS_NOT_ABSENT
DO NOT RESET_ABSENT
END 'EMERGENCY' |
_________________ John McDonald
RETIRED |
|
Back to top |
|
 |
manoj |
Posted: Tue Jun 01, 2004 5:46 pm Post subject: |
|
|
 Master
Joined: 30 Jan 2002 Posts: 237 Location: Virgina
|
John,
Are you sure that the SQL update with the hashed password will work. I have tried this once and failed. If it's working for you then i might have messed up something.. _________________ -manoj |
|
Back to top |
|
 |
|