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 Index » IBM MQ Installation/Configuration Support » Unable to configure for testing with .NET Core

Post new topic  Reply to topic
 Unable to configure for testing with .NET Core « View previous topic :: View next topic » 
Author Message
derrickatdecdev
PostPosted: Tue Feb 09, 2021 1:01 pm    Post subject: Unable to configure for testing with .NET Core Reply with quote

Newbie

Joined: 11 Mar 2020
Posts: 9

Hello again!

I'm trying to test a client connection using amqmdnetstd.dll for .NET Core.
(Previously, you helped me successfully test a similar thing using the .NET Framework dll, in post number 433569.)

Well, I'm having some trouble connecting the client. Since this is for testing only and because I have no ability to change my local network or AD settings, I thought that disabling all auth would be the straightest path forward.

Instead, I'm getting 2035 errors. For unknown reasons, these errors are not logged in AMQERR01.LOG (which does exist and does log some things), but Windows Event Viewer is revealing what's happening.

Note that the same installation+qm+queue+channel is currently working and communicating with the .NET Framework client dll, so I don't think there's anything broken in the installation.

Each time I try, 3 warnings and then 1 error appear, in this order:
"Unable to obtain account details for channel MCA user ID."
" The trust relationship between this workstation and the primary domain failed."
"Authorization failed because the SID for entity 'derrick$' cannot be obtained. "
"Queue Manager User ID initialization failed for 'DERRICK$'. "

I'll paste the entire entry for the first warning and the final error:

2/9/2021 15:48:45 - Process(9824.10) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(DERRICK) Installation(Installation2)
VRMF(9.2.1.0) QMgr(qm2)
Time(2021-02-09T20:48:45.170Z)
CommentInsert1(DERRICK$)
CommentInsert2(channel2)
CommentInsert3(qm2)

Unable to obtain account details for channel MCA user ID.

IBM MQ was unable to obtain the account details for MCA user ID 'DERRICK$'. This user ID was the MCA user ID for channel 'channel2' on queue manager 'qm2' and may have been defined in the channel definition, or supplied either by a channel exit or by a client.

Ensure that the user ID is correct and that it is defined on the Windows local system, the local domain or on a trusted domain. For a domain user ID, ensure that all necessary domain controllers are available.




2/9/2021 15:48:45 - Process(9824.10) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(DERRICK) Installation(Installation2)
VRMF(9.2.1.0) QMgr(qm2)
Time(2021-02-09T20:48:45.171Z)
ArithInsert1(2) ArithInsert2(2035)
CommentInsert1(DERRICK$)

Queue Manager User ID initialization failed for 'DERRICK$'.

The call to initialize the User ID 'DERRICK$' failed with CompCode 2 and Reason 2035. If an MQCSP block was used, the User ID in the MQCSP block was ''. If a userID flow was used, the User ID in the UID header was '' and any CHLAUTH rules applied prior to user adoption were evaluated case-sensitively against this value.

Correct the error and try again.




If I try to specify an arbitrary username and password, the warnings+error are very similar except that this sentence changes: "If an MQCSP block was used, the User ID in the MQCSP block was 'arbitraryFakeUsername'. "
I'm pretty lost - what is the .NET Core dll doing differently? Thanks in advance![/b]
Back to top
View user's profile Send private message
hughson
PostPosted: Tue Feb 09, 2021 8:47 pm    Post subject: Re: Unable to configure for testing with .NET Core Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

derrickatdecdev wrote:
For unknown reasons, these errors are not logged in AMQERR01.LOG (which does exist and does log some things), but Windows Event Viewer is revealing what's happening.


Make sure that you are viewing the correct AMQERR01.LOG. Are you looking at the queue manager one? That is the one in MQ_DATA_PATH\qmgrs\qm2\errors\AMQERR01.LOG ?

derrickatdecdev wrote:
Each time I try, 3 warnings and then 1 error appear, in this order:
"Unable to obtain account details for channel MCA user ID."
" The trust relationship between this workstation and the primary domain failed."
"Authorization failed because the SID for entity 'derrick$' cannot be obtained. "
"Queue Manager User ID initialization failed for 'DERRICK$'. "


Does the user ID 'DERRICK$' exist on the machine where the queue manager is running? Or are you using domain security? The second error message suggests you might be. What is it telling you and have you fixed that issue that you have not shown us in your question?

From the error messages you have shown us, the user ID 'DERRICK$' is either specifically coded in the SVRCONN MCAUSER field or is flowed from the client. Can you show us your SVRCONN definition please?

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
derrickatdecdev
PostPosted: Wed Feb 10, 2021 7:06 am    Post subject: Reply with quote

Newbie

Joined: 11 Mar 2020
Posts: 9

Quote:
Does the user ID 'DERRICK$' exist on the machine where the queue manager is running? Or are you using domain security? The second error message suggests you might be. What is it telling you and have you fixed that issue that you have not shown us in your question?


'DERRICK' is the machine name, so I assumed the dollar sign was being added by that convention.

Quote:
From the error messages you have shown us, the user ID 'DERRICK$' is either specifically coded in the SVRCONN MCAUSER field or is flowed from the client. Can you show us your SVRCONN definition please?


I'm not sure if there's a correct way to get that info, but it has a blank MCA user ID field, type "Server-connection", and I haven't changed the rest from default (TCP, 300 heartbeat, ~4M max message bytes, auto keep alive...).
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Feb 10, 2021 7:39 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

derrickatdecdev wrote:
Quote:
Does the user ID 'DERRICK$' exist on the machine where the queue manager is running? Or are you using domain security? The second error message suggests you might be. What is it telling you and have you fixed that issue that you have not shown us in your question?


'DERRICK' is the machine name, so I assumed the dollar sign was being added by that convention.


Perhaps you should check on that assumption. If your client machine logon user id is the machine name with a $ added, we wouldn't know that. That is nothing to do with MQ either. It does not arbitrarily invent user ids. The user id it is using came from somewhere. If it is not the client machine ID, and you don't have an MCAUSER coded on the SVRCONN, and you are not supplying a user in an MQCSP, then all I can think of is a security exit? Do you have any of those?

The second error message you told us about, but didn't show any details about was "The trust relationship between this workstation and the primary domain failed." I feel you are ignoring this error when it actually might be rather important. I asked about it once already but I'll try again a little more explicitly. Can you show us the whole error message for this one please? Have you fixed whatever problem it was reporting?

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
derrickatdecdev
PostPosted: Wed Feb 10, 2021 11:55 pm    Post subject: Reply with quote

Newbie

Joined: 11 Mar 2020
Posts: 9

Quote:
The user id it is using came from somewhere. If it is not the client machine ID, and you don't have an MCAUSER coded on the SVRCONN, and you are not supplying a user in an MQCSP, then all I can think of is a security exit? Do you have any of those?


I guess my confusion is that I thought the purpose of disabling auth is to make it stop caring about users altogether. I'm pretty sure I haven't set up any security exits.

Quote:
The second error message you told us about, but didn't show any details about was "The trust relationship between this workstation and the primary domain failed." I feel you are ignoring this error when it actually might be rather important. I asked about it once already but I'll try again a little more explicitly. Can you show us the whole error message for this one please? Have you fixed whatever problem it was reporting?


Sure! I left it out because it seemed very generic, but I could be wrong. Error is below. If this is related to the ultimate problem, I wonder why... it seems strange because this is all on the same machine, so I didn't think it would even try to do any trust checks.

2/9/2021 15:56:15 - Process(14564.20) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(DERRICK) Installation(Installation2)
VRMF(9.2.1.0) QMgr(qm2)
Time(2021-02-09T20:56:15.965Z)
CommentInsert1(The trust relationship between this workstation and the primary domain failed.
)

IBM MQ encountered the following network error: The trust relationship between this workstation and the primary domain failed.


MQ failed to successfully complete a network operation due to the specified error. If the error is encountered on systems that are part of a Windows 2000 domain it can indicate incorrect DNS or WINS configuration.

Ensure that your network is functioning correctly. On the Windows platform check DNS and/or WINS settings to ensure that domain controllers, used for authentication or authorisation functions, are accessible.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Feb 11, 2021 1:11 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Are you sure you are not trying to authenticate a domain user/ID on a machine that is not running with a domain service user?

The way your MQ is set up on your machine, it can only recognize users that have been explicitly defined on the machine (Derrick). Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
derrickatdecdev
PostPosted: Thu Feb 11, 2021 10:37 am    Post subject: Reply with quote

Newbie

Joined: 11 Mar 2020
Posts: 9

Quote:
Are you sure you are not trying to authenticate a domain user/ID on a machine that is not running with a domain service user?


I apologize, but I don't think I know enough about AD/windows admin to parse this sentence. Are you asking whether this user could exist elsewhere? I don't understand why that could possibly matter if I'm telling it to ignore auth and allow any user.

Quote:
The way your MQ is set up on your machine, it can only recognize users that have been explicitly defined on the machine (Derrick).


Hmm...I've got the same confusion here. I thought I was asking it to ignore all of this. But even more importantly, why does it currently work with the .NET Framework client (amqmdnet.dll)? It seems believable that .NET Framework and .NET Core would use a different service user, but I get a little lost after that, for the reasons listed above. Thanks btw.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Feb 11, 2021 7:15 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

derrickatdecdev wrote:
I guess my confusion is that I thought the purpose of disabling auth is to make it stop caring about users altogether.

You have mentioned disabling auth a few times now. Could you clarify how you did so?

Also, I suspect disabling authorization checks does not remove the requirement to obtain the user id. Just because the queue manager is not making authority checks for the user id, does not imply it doesn't need to determine what the user id is for other reasons.

Given that you are running a client connection, the simplest way to avoid security failures would be to code an mqm group user ID in the SVRCONN MCAUSER field and turn off CHLAUTH and CONNAUTH. Three things. Of which only the first actually has anything to do with authorization.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Fri Feb 12, 2021 6:14 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

hughson wrote:
... the simplest way to avoid security failures would be to code an mqm group user ID in the SVRCONN MCAUSER field and turn off CHLAUTH and CONNAUTH.

Not a recommended practice.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Feb 12, 2021 7:10 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
hughson wrote:
... the simplest way to avoid security failures would be to code an mqm group user ID in the SVRCONN MCAUSER field and turn off CHLAUTH and CONNAUTH.

Not a recommended practice.


Neither is trying to turn off all authority checking, but the OP seems content with that for this use case.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
derrickatdecdev
PostPosted: Mon Feb 15, 2021 7:50 am    Post subject: Reply with quote

Newbie

Joined: 11 Mar 2020
Posts: 9

Quote:
You have mentioned disabling auth a few times now. Could you clarify how you did so?


I followed the instructions given in post 433569 ( http://www.mqseries.net/phpBB2/viewtopic.php?p=433569#433569 ).

Quote:
Given that you are running a client connection, the simplest way to avoid security failures would be to code an mqm group user ID in the SVRCONN MCAUSER field and turn off CHLAUTH and CONNAUTH. Three things. Of which only the first actually has anything to do with authorization.


Hmm...why don't I need to do that with the .NET Framework dll? Also, anything involving mqm means I'd need to be able to change Active Directory settings, right? I don't think I can.
Back to top
View user's profile Send private message
hughson
PostPosted: Mon Feb 15, 2021 1:20 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

derrickatdecdev wrote:
anything involving mqm means I'd need to be able to change Active Directory settings, right? I don't think I can.

If your queue manager is able to run, there must be one pre-existing mqm group user ID that you can use. If you issue this command:-
Code:
DISPLAY CONN(*) TYPE(CONN) WHERE(APPLTYPE EQ SYSTEM) USERID

What user id do you see in use? Coding that in the MCAUSER of the SVRCONN would allow it to pass any authorization check.

Again, as has been said, turning off security is not recommended, but just so long as you know you have no security, running in this way is better than trying to disable whole components of the queue manager.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
derrickatdecdev
PostPosted: Mon Feb 15, 2021 1:46 pm    Post subject: Reply with quote

Newbie

Joined: 11 Mar 2020
Posts: 9

Quote:
What user id do you see in use? Coding that in the MCAUSER of the SVRCONN would allow it to pass any authorization check.

Again, as has been said, turning off security is not recommended, but just so long as you know you have no security, running in this way is better than trying to disable whole components of the queue manager.


Setting it to MUSR_MQADMIN worked. The tests of basic functionality now pass with both .NET Framework and .NET Core. Thank you again for all the help! :D
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Feb 16, 2021 8:00 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

fjb_saper wrote:

The way your MQ is set up on your machine, it can only recognize users that have been explicitly defined on the machine (Derrick). Enjoy

derrickatdecdev wrote:
Setting it to MUSR_MQADMIN worked

For a full authorization model you need to run the MQService with a Domain ID.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Unable to configure for testing with .NET Core
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.