ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ STIGs Requirement Document

Post new topicReply to topic
MQ STIGs Requirement Document View previous topic :: View next topic
Author Message
dhanaraj
PostPosted: Tue May 15, 2007 2:11 pm Post subject: MQ STIGs Requirement Document Reply with quote

Voyager

Joined: 10 Aug 2004
Posts: 92

Does any one having MQ STIGs Requirement Document?


Thanks
Dhanaraj
Back to top
View user's profile Send private message Yahoo Messenger
popebb
PostPosted: Wed May 16, 2007 10:45 am Post subject: Reply with quote

Apprentice

Joined: 23 Aug 2006
Posts: 34

MQSeries & Required NT Rights
Page 1
Prepared By Michael Olson
Officially, IBM states that the core MQSeries product requires the following NT rights
(with explanation from IBM)
LOGON AS A BATCH JOB
This security setting allows a user to be logged on by means of a batch-queue
facility. For example, when we submit a job by means of the task scheduler, the task
scheduler logs that user on as a batch user rather than as an interactive user. This
enables WebSphere MQ Services COM server to run under user account.
SHUTDOWN THE SYSTEM
We would require this to terminate our processes that do not respond to a shut down
or log off command and also allows the WebSphere MQ Service to restart the server
if configured to do so when recovery of a service fails.
ACT AS PART OF THE OPERATING SYSTEM
We use LogonUser call, by which we receive a handle to a token that represents the
logged-on user. We then use this token handle to impersonate the specified user, or
in most cases, to create a process running in the context of the specified user. The
process calling LogonUser requires the SE_TCB_NAME privilege. If the calling process
does not have this privilege, LogonUser fails !!
BYPASS TRAVERSE CHECKING
The process that calls LogonUser must also have the SE_CHANGE_NOTIFY_NAME
privilege enabled. Otherwise, LogonUser fails and GetLastError returns
ERROR_ACCESS_DENIED.
REPLACE A PROCESS LEVEL TOKEN
On windows, processes run with a specific security token. By default, threads use
that token. To do this with win32 calls LogonUser and ImpersonateLoggedOnUser are
used. LogonUser gives you a handle which ImpersonateLoggedOnUser can then use
to "become" the user. To do this the thread calling, LogonUser, needs
SE_TCB_NAME, SE_CHANGE_NOTIFY_NAME,and SE_ASSIGNPRIMARYTOKEN_NAME
privileges.
INCREASE QUOTAS
When we need to impersonate, we use CreateProcessAsUser, for which Increase
quotas, SE_INCREASE_QUOTA_NAME is required...
LOGON AS A SERVICE
Log on as a service security setting determines which service accounts can register a
process as a service. The WebSphere MQ Services snap-in and the components
associated with it use the Microsoft Windows security model. It is this security model
that allows WebSphere MQ services to run as a service....
MQSeries & Required NT Rights
Page 2
Prepared By Michael Olson
The NT Right SHUTDOWN THE SYSTEM under the condition that we don’t set the option
within MQSeries to reboot the server upon MQ Service(s) failure(s) IBM states the
following:
sounds fine, but remember they would never be able to configure it to reboot to
recover a service
Based on this reply the consensus is that the SHUTDOWN THE SYSTEM is not needed in our
environment.
A discussion involving IBM Level 3 support from England regarding NT Rights at issue:
ACT AS PART OF THE OPERATING SYSTEM, REPLACE A PROCESS LEVEL TOKEN,
INCREASE QUOTAS and a question regarding the use of a local/system account rather then
having to use an explicit account was raised. Given the questions/concerns raised IBM
responded as follows:
These rights are needed by the id under which the MQ service processes are running
when MQ needs to either impersonate another user or start a process as another
user. Typically this is when the MMC is being used, both locally and remotely or when
remote clients or other queue managers need to connect (using channels) to get and
put messages remotely. Naturally, these are those points where it is important that
the id issuing the requests is always fully authenticated and, where possible the
credentials of that id are used when performing tasks. We agree that it is not
immediately apparent why the right to, say, "Increase quotas" is relevant, however
these are the rights needed when MQ makes calls such as "CreateprocessAsUser". I
think these were discussed earlier in the PMR. It is not possible to run as the "local
system". Although the top levelservice runs under this id it is not intended for DCOM
services and cannot be set. The services provided by MQ could be considered as
similar to Web or database servers which would typically require similar rights for
their administration ids.
To summarize at this point: First, the local/system account it is a moot point because you
still need an explicit account for DCOM. As to the right REPLACE A PROCESS LEVEL
TOKEN, it is essential because MQ needs it to start processes, connect to remote Queue
Managers via channels etc. The right INCREASE QUOTAS is required to make call such as
“CreateprocessAsUser” without it product functionality is effected.
MQSeries & Required NT Rights
Page 3
Prepared By Michael Olson
Of greatest concern is the NT Right ACT AS PART OF THE OPERATING SYSTEM. To
understand why we refer to Microsoft’s description of this right:
This policy allows a process to authenticate as any user, and therefore gain access to
the same resources as any user. Only low-level authentication services should
require this privilege. The potential access is not limited to what is associated with
the user by default, because the calling process may request that arbitrary additional
accesses be put in the access token. Of even more concern is that the calling process
can build an anonymous token that can provide any and all accesses. Additionally,
the anonymous token does not provide a primary identity for tracking events in the
audit log. Processes that require this privilege should use the LocalSystem account,
which already includes this privilege, rather than using a separate user account with
this privilege specially assigned. By default, only the LocalSystem account has the
privilege to act as part of the operating system.
In questioning IBM further about the requirement for having this NT right IBM states:
The Windows call we use that explicitly requires this right, LogonUser, is only issued
by an infrequently used part of MQ (the ADSI interface described in the manual
"Using the Component Object Model interface") and I am assuming that this is not
used. The other area of doubt is the Windows call: CreateProcessAsUser. My reading
of this (in the MSDn library) suggests SE_TCB_NAME is not needed unless LogonUser
is used to obtain the primary security token for the user, here, MQ uses the
alternative approach (DuplicateTokenEx).
This response strongly suggests that unless an application was specifically using the
ADSI or Active Directory Services Interface and specifically using LogonUser to obtain
the primary security token for the user the right is not needed. However, when pressed for
validation in the form of a statement regarding the design of the MQSeries product as it
pertains to the ACT AS PART OF THE OPERATING SYSTEM IBM stated the following:
I can't say that MQ was designed to be able to run without the SE_TCB_NAME right -
if it was we would have documented and tested it. MQ was designed with the
assumption that the MUSR_MQADMIN id did have the right, if it (mostly) works
without it, it is just good luck. Again, I recommend to go with the special OU or the
specified rights explicitly granted to the domain\MUSR_MQADMIN id (or equivalent
id), and to put in a requirement or formal request for a design change so that
running without the right can be properly supported.
As to support of MQSeries:
MQ was not designed/tested to be run without the rights specified. Probably we
would be able to provide support only on issues not related to security or failures due
to 'required' privileges not being present. More seriously, we would not be able to
guarantee that changes in CSDs or future releases would continue (assuming that it
does so at present) to allow operation if expected rights were not assigned.
MQSeries & Required NT Rights
Page 4
Prepared By Michael Olson
Lastly IBM states:
I would strongly recommend running with the normal, required, rights assigned, but
raising and perusing a requirement/design change to allow and support the behavior
desired.
Based on the last two responses specifically, to run without the NT right ACT AS PART
OF THE OPERATING SYSTEM is a support issue because IBM neither tested or designed
MQSeries to run without this right. IBM summed it up best by stating:
MQ was designed with the assumption that the MUSR_MQADMIN id did have the
right, if it (mostly) works without it, it is just good luck
In summary, based on all the discussions (PMR # 24606 B122) with IBM, we need all
the NT rights mentioned with the exception of SHUTDOWN THE SYSTEM. The NT rights
required by MQSeries for version 5.3 are: LOGON AS A BATCH JOB, SHUTDOWN THE
SYSTEM, ACT AS PART OF THE OPERATING SYSTEM, BYPASS TRAVERSE CHECKING,
REPLACE A PROCESS LEVEL TOKEN, INCREASE QUOTAS, LOGON AS A SERVICE.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ STIGs Requirement Document
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.