| Author |
Message
|
| r4v3n |
 Posted: Wed Jul 07, 2010 7:24 am Post subject: 9999 and 8074 error with different server names |
 |
|
Newbie
Joined: 07 Jul 2010
Posts: 6
|
Windows 2008 SP2 x64 7.0.1.2 transactional client and Windows 2008 SP2 x64 MQSeries 7.0.1.2 server.
When I configure MQSeries 7.0.1.2 transactional client to communicate with transactions over MSDTC with default Network service account configuration I cannot get it to work. If I change the client MSDTC to use a user account it works fine though, but I don't want this as I have other services using MSDTC on this server.
What I see is this:
9999
Error on receive from host niklasebts0904 (192.168.0.104)
An error occured receiving data from niklasebts0904 (192.168.0.104) over TCP/IP. This may be due to a communications failure.
The return code from the TCP/IP recv() call was 10054 (X'2746'). Record these values and tell the systems administrator.
8074:
Authorization failed as the SID 'S-1-5-20' does not match the entity 'niklasebts09'.
The Object Authority Manager received inconsistent data - the supplied SID does not match that of the supplied entity information.
Ensure that the application is supplying valid entity and SID information.
To me this seems like a bug where MQSeries truncates the server name to 12 characters. Could that be the case?
Trying another workaround without success as well:
I have seen that you can also configure security exits in IBM Technote article 1223479:
• Add a Network Service account to the local mqm group, so that the application is able to connect and run under this account. This works, but does pose a security exposure, in that anyone could run a task under that userid and have full authorization to the queue manager. A workaround for this problem is to install a security exit on the svrconn channel, which looks for the Network Service account and replaces it with another user id. Grant +connect authority to this userid using the setmqaut command.
• Run REFRESH SECURITY against your queue manager before attempting to connect after making the change
I have added Network Service account to the local mqm group and to folder security for Qmgr, but it still doesn't work. Anyone knows the exact steps to "install a security exit on the svrconn channel, which looks for the Network Service account and replaces it with another user id. Grant +connect authority to this userid using the setmqaut command. " (I am not too experienced with MQSeries configuration)
Thanks
Niklas |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jul 07, 2010 7:36 am Post subject: Re: 9999 and 8074 error with different server names |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| r4v3n wrote: |
To me this seems like a bug where MQSeries truncates the server name to 12 characters. Could that be the case?
|
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 07, 2010 7:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| It's not a BUG, it's a KNOWN LIMITATION. |
|
| Back to top |
|
|
| r4v3n |
| Posted: Wed Jul 07, 2010 8:06 am Post subject: |
|
|
Newbie
Joined: 07 Jul 2010
Posts: 6
|
Known limitations usually log what you need to do if it is known  I don't see that in my 8074 and 9999 errors so as long as it is not logged properly I would call it a known bug. Anyway, so I need to rename my server or user another server with max 12 characters in the name?
Cheers
Niklas |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 07, 2010 8:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Just use a network service account with 12 characters/bytes max... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zonko |
| Posted: Wed Jul 07, 2010 8:46 am Post subject: |
|
|
Voyager
Joined: 04 Nov 2009
Posts: 78
|
| Quote: |
If the WebSphere MQ server is on Windows and the client is on a platform that uses the environment variable for specifying the user ID, the user ID can be in the format user@domain. The WebSphere MQ server then retrieves user account information from the specified NT domain. In this case, the maximum length for the user ID is 64 characters.
If the WebSphere MQ server is on Windows and the client is on a platform that uses the environment variable for specifying the user ID, but no domain is specified, the WebSphere MQ server attempts to retrieve user account information from its primary domain or trusted domains. In this case, the maximum length for the user ID is 20 characters.
On all other platforms and configurations, the maximum length for user IDs is 12 characters.
|
Just because you do not know about it does not make it any less of a known limitation. |
|
| Back to top |
|
|
| r4v3n |
| Posted: Wed Jul 07, 2010 3:35 pm Post subject: |
|
|
Newbie
Joined: 07 Jul 2010
Posts: 6
|
Let's keep it technical and leave classication aside as that is of no interest.
Thanks alot for documenation. When I searched for it I found this:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzaf.doc/cs11900_.htm
-----
If the WebSphere® MQ client is on Windows® and the WebSphere MQ server is also on Windows and has access to the domain on which the client user ID is defined, WebSphere MQ supports user IDs of up to 20 characters.
A WebSphere MQ for Windows server does not support the connection of a Windows client if the client is running under a user ID that contains the @ character, for example, abc@d. The return code to the MQCONN call at the client is MQRC_NOT_AUTHORIZED.
On all other platforms and configurations, the maximum length for user IDs is 12 characters.
-----
Both my client 7.0.1.2 and my server 7.0.1.2 are running Windows 2008 SP2 x64 and both are in the same domain and I have configured domain mqm group. So shouldn't first section apply and 20 characters limit then?
Could it be because this exceeds 20 characters: NT AUTHORITY\Network Service . Or is it 12 characters because it doesn't recognise the NT AUTHORITY as a domain?
Cheers
Niklas |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 07, 2010 8:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
I don't think it likes spaces either. And you may be right that the qualified name i.e. "NT AUTHORITY\Network Service" needs to be less than 20 chars.
What is it with your site and the awfully long names... with spaces...?
I would have used some kind of short like nta\netsvce... (total even under 12 chars)...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| r4v3n |
| Posted: Wed Jul 07, 2010 10:27 pm Post subject: |
|
|
Newbie
Joined: 07 Jul 2010
Posts: 6
|
NT AUTHORITY\Network Service is the default Windows computer system account between computers that MSDTC (Windows transaction coordinator) uses, which impersonates the currently logged on user. You cannot change that (without getting problems). The actual impersonated user in the end is actually NIKLASEDOM\btshost (10+1+7=18 characters with domain and \)
Without transactions it works fine to put an get messages. It is just when enabling transactions the problem arises.
Cheers
Niklas |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 08, 2010 1:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| r4v3n wrote: |
NT AUTHORITY\Network Service is the default Windows computer system account between computers that MSDTC (Windows transaction coordinator) uses, which impersonates the currently logged on user. You cannot change that (without getting problems). The actual impersonated user in the end is actually NIKLASEDOM\btshost (10+1+7=18 characters with domain and \)
Without transactions it works fine to put an get messages. It is just when enabling transactions the problem arises.
Cheers
Niklas |
You probably need to set up your MSDTC with an account with equivalent rights molded on NT AUTHORITY\Network Service so that you can use a shorter account name for the distributed transaction service.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
