| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| BIP1360E: Configuration Manager is not at the required softw |
« View previous topic :: View next topic » |
| Author |
Message
|
| mgadiraju |
 Posted: Thu Jun 17, 2004 8:28 pm Post subject: BIP1360E: Configuration Manager is not at the required softw |
 |
|
Newbie
Joined: 09 Mar 2004
Posts: 2
Location: Melbourne, Australia
|
I have installed the following software...
MQ Series 5.3, CSD05
WMQI V2.1 CSD05 + efixes.
DB2 8.1 FP5.
I have created the config manager to run under a domain service account. This acount is a member of all the mqm* groups and also administrator group. When I start the control center to access the config manager I get the following error.
BIP1360E: Configuration Manager is not at the required software level.
A request was sent to the Configuration Manager to process the current operation, but the reply received back indicates that the Configuration Manager is not at a sufficient level to recognize requests from your level of Control Center.
The most likely cause is that the Control Center has been upgraded to the latest product level, but a similar upgrade has not been made to the Configuration Manager. This is an incompatible combination of software. Either upgrade the Configuration Manager to the same level as the Control Center, or connect the Control Center to a different Configuration Manager.
I get this error only when the config manager is created using domain account. If I delete the config manager and recreate using local account I don't get this problem. Any suggestions on why I get this error.
This is the command I use to create the config manager with domain account.
mqsicreateconfigmgr -i oceaniatst4\auwmqsvc -a Password1 -q AU30NE1.MQ -n WMQICMDB -u auwmqsvc -p Password1 -m WMQIMRDB -e auwmqsvc -r Password1 -l 2
Thanks
Mali |
|
| Back to top |
|
 |
| kirani |
| Posted: Thu Jun 17, 2004 10:19 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
What CSD level do you have on your Control Center box? Is this the first time you are installing s/w or is this an existing Broker domain?
Did you try using -d option when creating the config mgr? Try removing the e-Fix and see if it works.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| fschofer |
| Posted: Fri Jun 18, 2004 7:19 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Hi,
the error
BIP1360E: Configuration Manager is not at the required software level.
is simply wrong
To use a Config Manager under domain account you have to use
another batch file to start your command center.
You can find it in the wmqi Tools directory, its called mqsilccdom
and don't forget to add the paramter 1
=> mqsilccdom 1
(I did a complete reinstall until i found this out)
Greetings
Frank |
|
| Back to top |
|
|
| kirani |
| Posted: Fri Jun 18, 2004 11:23 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Well .. If you specify -d option when creating config mgr, you can still use mqsilcc command to run your control center.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| fschofer |
| Posted: Fri Jun 18, 2004 11:54 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
By using the -d option you cannot use some new post CSD 3 features
=>
Readme.txt, WMQI CSD6
| Quote: |
Using Fully Qualified User Names for Control Center Users
---------------------------------------------------------
In previous versions of WMQI, restrictions were placed on the
Windows NT groups that support WMQI Control Center roles. The
WMQI Configuration Manager, which is responsible for
determining which roles a Control Center user can adopt, may
be configured to draw its users and groups from either a
Windows NT Account, Primary or Trusted domain. The view of
domains are 'flat', it does not provide support for NT group
nesting or recognizing users from other domains that are
members of its groups.
A new feature introduced in CSD03 for WMQI 2.1 optionally
allows the exploitation of the fuller Windows NT domain
model as follows:
(A) Allows fully qualified user names to be flowed from the
Control Center to the Configuration Manager.
(B) Supports Windows NT group membership resolution and group
nesting.
(C) Provides backward compatibility, allowing
customers to continue to operate in the current manner.
The Restrictions and Limitations that have been Overcome:
-------------------------------------------------------------
Core Limititation
------------------
Loss of Unique Identity
Prior to CSD03 for WMQI 2.1 the Configuration Manager is
unable to distinguish between different Control Center users,
for example, devt\user1 and test\user1, where 'devt' and
'test' are Windows NT domains. The system assumes that user1
belongs to whichever domain, 'test' for example, was specified
to the Configuration Manager when the latter was created.
Provided there is a user1 in 'test' Control Center connections
from devt\user1 would be accepted and they would assume the
role defined for test\user1 through membership of the various
test\Domain mqbrdevt, etc groups. Under the new feature, the
system is able to distinguish between Control Center users
devt\user1 and test\user1 and is able to resolve their roles
through their direct or indirect membership of the mqbrdevt,
etc groups in the local account domain of the machine on which
the Configuration Manager is installed.
Security Limitation
-------------------
Fabrication of Privileged Identity
One of the implications of the loss of unique identity
information is that an intruder may masquerade as a
privileged user in an environment where the Control Center
security exit has not been deployed.
If the intruder knows:
(A) The IP address on which an unprotected Configuration
Manager is running.
(B) The name of the queue manager against which the
Configuration Manager is running.
(C) The port on which that Configuration Manager is
listening.
(D) The name of a privileged user in the Windows domain
configured for the Configuration Manager.
then they may define a corresponding userid on their local
machine domain, start a Control Center under that userid and
connect to the Configuration Manager and assume the authority
of the privileged Configuration Manager user. Under the new
feature, the system is able to distinguish between Control
Center users HELL\privileged and PRODUCTION\privileged.
Exploitation of the Control Center security exit would still
be required to fully secure the connection.
Configuration Limitation
------------------------
Multiple Configuration Managers Operating in the same Domain
A further limitation of the pre-CSD03 architecture arises
where a customer wishes to configure multiple Configuration
Managers in the same corporate Windows Domain, for example
where they wish to set up a Configuration Manager for a
Development and Production Broker domain. In such an
environment, where the customer has configured their
configuration managers to work against the 'Corporate' Windows
domain, for example, Control Center roles are determined
through membership of the Corporate\Domain mqbrdevt, etc
groups. Thus users assume identical roles on each
Configuration Manager.
Under the new feature the customer would configure each
Configuration Manager to operate against its local Windows
account domain (by not setting the '-d' parameter). Group
memberships would then be determined in the usual Windows
domain manner. So, if a user Corporate\user1 were a member,
either directly or indirectly, of the local devt\mqbrdevt
group, then they would be able to assume the role of a message
flow developer while working against the development
Configuration Manager. That membership could be achieved
indirectly, so that Corporate\user1 could be a member of a
global group Corporate\Devt_mqbrdevt which was in turn a
member of the local devt\mqbrdevt group.
Configure WMQI 2.1 CSD03 to support Fully Qualified Usernames
-------------------------------------------------------------
Unless you reconfigure your Configuration Managers and
Control Centers, WMQI will continue to operate the existing
scheme. If you want to exploit the new feature then it will
be necessary to:
(A) Decide on the appropriate group memberships for your
environment.
Under the new feature you should configure each
Configuration Manager to operate against its local Windows
account domain (by not setting the '-d' parameter or
ensuring that it is set to null). Group memberships
should then be determined in the usual Windows domain
manner. So, Control Center roles will be established,
either directly or indirectly, through membership of the
local mqbrdevt, mqbrops, etc groups.
You may wish to set up global groups in a primary or
trusted domain that would be added to the appropriate
local group. A role could then be defined indirectly, so
that, for example, a user Corporate\user1 could be a
member of a global group Corporate\Devt_mqbrdevt which was
in turn a member of the local devt\mqbrdevt group.
(B) Reconfigure the Configuration Manager and Control Center.
Please refer to the WMQI 2.1 CSD03 Release Guide, Chapter 3
for more information.
To ensure that both Control Center and Configuration Manager
support fully qualified usernames, it is necessary to:
Configure the Configuration Manager to operate against its
local Windows account domain by setting the
SecurityDomainName parameter (-d) to null. Either create
the Configuration Manager omitting this parameter, or
reset its value by specifying -d on the
mqsichangeconfigmgr command.
Configure the Configuration Manager by specifying the
appropriate level of domain awareness on the
mqsicreateconfigmgr or mqsichangeconfigmgr command (the
parameter): For example, Level 2 indicates that the
Configuration Manager requires fully qualified username
information from the Control Center client.
Start the Control Center using either the mqsilccdom
command or the mqsilccsedm command, specifying the
appropriate parameter to ensure that fully qualified
usernames are flowed to the Configuration Manager. |
|
|
| 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
|
|
|
|
