| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Domain IDs: Changing the User Password |
« View previous topic :: View next topic » |
| Author |
Message
|
| SAFraser |
 Posted: Mon Jul 11, 2005 7:16 am Post subject: Domain IDs: Changing the User Password |
 |
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
I'd like to go a bit further on a recent & useful topic from the General Discussion Forum: http://www.mqseries.net/phpBB2/viewtopic.php?t=23108 regarding domain IDs and MQ.
We have about 100 Windows-based production queue managers that run under a domain ID (a "service account"). The security folks are about to institute a policy to change the passwords of service accounts every 30 days. <sigh> Oh, yes, we told them the havoc they will wreak. <sigh again> They're gonna do it anyway.
There is a command line utility that will set MQ processes to run under a particular ID. The command is:
| Code: |
| amqmsrvn –regserver –user domain\username –password <psw> |
Here is my current thinking.
1. Spend a zillion hours coordinating with app teams.
2. Change the domain ID password.
3. Using a batch file, connect remotely to each MQ server (net use).
4. Execute the amqmsrvn command.
5. Net stop MQSeries.
6. Net start MQSeries.
7. Respond to trouble tickets when badly coded apps don't reconnect to MQ on their own.
Of course, this assumes that all projects will let us do this at the same time on the same day, which is probably a bad assumption. An alternative might be to have two service IDs and change both the username and the password so that we could cycle through all the queue managers in an orderly fashion.
Has anyone faced this type of thing? How did you handle it? Your thoughts will be much appreciated.
Shirley |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Jul 11, 2005 7:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I would let things break once, and watch them change their mind about expiring passwords for service users.
Well.
Okay, likely, in your case, I wouldn't do this.
It actually seems like a good excuse to schedule a maintenance window for all your queue managers.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Mon Jul 11, 2005 7:32 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
Well I would vote for a service account with no password expiry, but I would also make sure that it can't logon interactively.
If this is not secure enough for your company, you could look into Kerberos certificates. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 11, 2005 7:47 am Post subject: Re: Domain IDs: Changing the User Password |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| SAFraser wrote: |
We have about 100 Windows-based production queue managers that run under a domain ID (a "service account"). The security folks are about to institute a policy to change the passwords of service accounts every 30 days. <sigh> Oh, yes, we told them the havoc they will wreak. <sigh again> They're gonna do it anyway.
|
<sigh> indeed. I'd prefer the pineapple from Little Nicky over dealing with this.
What do they say about sebastianirt's idea of a non log on ID with a non expiring password?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| SAFraser |
| Posted: Mon Jul 11, 2005 8:18 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
I will certainly float the idea of a non-logon ID and see what happens. I suspect they won't like it just because.... well, just because. The security guys are on a roll at present and seem to have the power to implement what they want.
Keep your comments coming, and any technical comments you have also.
Thanks,
Shirley |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 11, 2005 8:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you have to go with rolling passwords, then I would make sure that you have more than one service user for MQ.
At a minimum, have one per "environment" - dev, test, prod, etc.
Even better would be to have more than one per environment, to minimize impact at a particular time. Maybe have six per environment, that are have their expiration dates staggered by 5 days, so that you're only ever dealing with one changeover a week, and for a small set of qmgrs.
And, make sure that they work this change through the normal progression of environments, as well - get it working in dev, migrate to test, get sign off, migrate to prod...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Mon Jul 11, 2005 9:09 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| Excellent suggestion, Jeff, thanks so much. |
|
| Back to top |
|
|
| hguapluas |
| Posted: Tue Jul 12, 2005 3:06 pm Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
I'd say, pass on the responsibility of changing passwords and synchronizing all of the MQ services to them on the first go-around and let them deal with it. Redirect all support call to them - call forwarding miracles - and watch how fast they change their minds!
Of course, like Jeff said, that's me but you may not be able to do that.
Almost had that same argument in place I consult for and convinced them of downstream impact of what would happen when all of our MQ services fail, what would be placed in jeapardy, how they'd be responsible for failing to maintain 9's status and other impacts in critical services, costs, and liabilities that would be incurred from even a minor outage. They changed their minds quickly, especially once liability and 9's issues were brought to light.
Good luck to ya. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
