I have two domains, a production and development. My development domain has suddenly started giving the error DirectoryServicesCOMException: A referral was returned from the server.
This has only started happening today. I validated it was working yesterday. No changes have been identified with domain controllers or my application.
When my development server performs an LDAP search of a production user profile. I'm using some fairly standard LDAP query code:
private IUserDetails queryUserBySID(string sid)
{
DirectoryEntry de = new DirectoryEntry(domainLdap); // "DC=production,DC=local"
var ds = new DirectorySearcher(de);
ds.Filter = $"(&(objectCategory=User)(objectClass=person)(objectSid={sid}))";
var result = ds.FindOne(); // <-- referral error
//...
}
However, this works (Even when using IIS AppPool credentials):
PS C:\> Get-ADUser -Server productiondc -Identity testuser
I validated both domains trust each other. What could have changed on either of my domains to cause this?
Edit 1
The issue resolved itself for 1-2 days and then appeared again.
Checking the ExtendedErrorMessage gives
0000202B: RefErr: DSID-03100835, data 0, 1 access points
ref 1: 'production.local'
A quick google shows to run dcdiag
Edit 2
I believe this to be a pertinent error with dcdiag:
An error event occurred. EventID: 0xC0000010
Time Generated: 02/22/2022 22:22:22
Event String:
While processing a TGS request for the target server <user>/SERVER, the account DevMachine$#DEVELOPMENT.LOCAL did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 18 17. The accounts available etypes were 18 17 23 -133 -128 24 -135. Changing or resetting the password of PRODUCTION.LOCAL will generate a proper key.
A referral means "I don't have the information you want, but I know where you can get it." So it's a mismatch between the server you're connecting to and where the data is. I can't tell you what changed, but I can tell you how to get more information about it.
After the exception is thrown, call de.Options.GetCurrentServerName() to see which server the search was performed on.
Then check the ExtendedErrorMessage property of the exception and see if it tells you which server it is referring you to.
To get around the exception and automatically follow the referral, you can use the ReferralChasing property of the DirectorySearcher:
ds.ReferralChasing = ReferralChasingOption.All;
Related
I have written code which retrieves data from ClientID and modifies it to Int32. There's no error while debugging. I've deployed the site to network. It is working as intended when accessed through same LAN where server is located. However is throwing an error when others (outside this Network) are trying to login to site.
The error is:
Server Error in '/' Application
Exception Details: System.FormatException : Input string was not in a correct format.
PS: The site is accessible. They are able to register, change password and redirect to different pages from home page. However, when profile loads they are seeing the error.
I've tried to debug again, check with db (mySQL) connectivity, refreshed the IIS server manager completely, Checked with the permissions, tried to change the "Int to Var" in cs code, remove "value=" and ".text()" from the error line and deployed the site again multiple times with modifications each time debugging.
function getdays(date){
var days = ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'];
var d = new Date(date);
var dayName = days[d.getDay()];
var selecteddays = value = $('#<%=lblweekoff.ClientID%>').text();
var selectedSplittedDays = selecteddays.split(',');
}
C#
string MyConString = ConfigurationManager.ConnectionStrings["connStr"].ConnectionString;
var dayColumns = new[] { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" };
var selectedDayColumn = dayColumns[(int)nextDate.DayOfWeek];
var sp = (dr["p"].ToString());
Int sp1 = Convert.ToInt32(sp);
MySqlConnection connection = new MySqlConnection(MyConString);
The code should be able to accept the number and load the page with the calculation with respect to number given and split the days which are divided by "," stored in database.
It should allow the user to login in and show the page without any error.
As it is running as intended with in same LAN, I don't think there is a serious problem with the code. However, all the suggestions would be highly appreciated.
UPDATE :
To explain further, there are 2 sets of predefined users, lets say set A has 100 users and set B has 100 users. When I place myself as a user in set A, I'm able to login to the site. When I'm in set B, I'm unable to login and its casting same error.
I've removed entire set B and added inserted updated details. Still it's posing same error for all the users in set B. Set A however doesn't have any problem logging in and accessing the features.
I think the error is with $('#<%=lblweekoff.ClientID%>'). Further with all the ClientID functions. I've tried to comment the error line and tried to execute where I've received error with another .ClientID function. So, would the issue be with the code interacting with db?
If that's the case, they are able to register or change password which links to the same db.
I got it!
The input was in int form.
Int sp1 = Convert.ToInt32(sp);
However, the inputs data were float(decimal numbers).
Corrected it to:
float sp1= math.round(Convert.ToInt32(sp));
It actually worked. Thank you all for suggestions and help.
I need to use CCDT file for MQ.NET client to connect to MQ Server, both are running locally, but got error below.
IBM.WMQ.MQException: MQRC_Q_MGR_NAME_ERROR CompCode: 2, Reason: 2058
Please find below the server setup, and MQ.NET client.
Server Setup
I setup and created CCDT file following the links below:
Setting up the server using IBM MQ Explorer
Server-connection Channel: LOCAL.DEF.SVRCONN
MCA User ID: I tried either omitting it or providing it. And either member of mqm or not of it.
Setting up the client using IBM MQ Explorer
Clinet channe: LOCAL.DEF.SVRCONN
Queue Manager name: LocalQM
Connection name: 192.168.1.9 (1415)
192.168.1.9 is localhost address
1415 is queue manager, LocalQM, TCP port.
IBM MQ.NET
The code is below from here
MQQueueManager qm = null;
System.Environment.SetEnvironmentVariable("MQCHLLIB", "C:\\ProgramData\\IBM\\MQ\\qmgrs\\LocalQM\\#ipcc");
System.Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL.TAB");
try
{
Hashtable props = new Hashtable();
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
qm = new MQQueueManager("LocalQM",props);
MQQueue queue1 = qm.AccessQueue("LocalQueue", MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING);
MQMessage msg = new MQMessage();
msg.WriteUTF("Hello this message is from .net client");
queue1.Put(msg);
queue1.Close();
qm.Disconnect();
}
catch (Exception ex)
{
Console.Write(ex);
}
IBM MQ V8 on Windows 10
MQ.NET Client V8 on Windows 10
Creating a client channel definition table
Using a client channel definition table with .NET
UPDATE
If I change to below without using CCDT, it works.
var properties = new Hashtable
{
{MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED },
{ MQC.HOST_NAME_PROPERTY, "192.168.1.9" }, //"localhost" },
{ MQC.PORT_PROPERTY, "1415"},
{ MQC.CHANNEL_PROPERTY, "LOCAL.DEF.SVRCONN" },
{MQC.USER_ID_PROPERTY, "xxx" }, //usrename
{MQC.PASSWORD_PROPERTY, "xxx" } //password
};
_queueManager = new MQQueueManager(_queueManagerName, properties);
UPDATE 2
I changed queue manager to LocalQM
C:\Users\'#.lp\source>SET MQCHLLIB=C:\ProgramData\IBM\MQ\qmgrs\LocalQM\#ipcc
C:\Users\'#.lp\source>SET MQCHLTAB=AMQCLCHL.TAB
C:\Users\'#.lp\source>echo DIS CHL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN) ALL | runmqsc -n
5724-H72 (C) Copyright IBM Corp. 1994, 2015.
Starting local MQSC for 'AMQCLCHL.TAB '.
1 : DIS CHL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN) ALL
AMQ8414: Display Channel details.
CHANNEL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN)
AFFINITY(PREFERRED) ALTDATE(2018-04-16)
ALTTIME(22.16.03) CERTLABL( )
CLNTWGHT(0) COMPHDR(NONE)
COMPMSG(NONE) CONNAME(192.168.1.9 (1415))
DEFRECON(NO) DESCR( )
HBINT(300) KAINT(AUTO)
LOCLADDR( ) MAXMSGL(4194304)
MODENAME( ) PASSWORD( )
QMNAME(LocalQM) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCIPH( ) SSLPEER( )
TPNAME( ) TRPTYPE(TCP)
USERID( )
No commands have a syntax error.
C:\Users\'#.lp\source>
UPDATE 3: MQRC_NOT_AUTHORIZED is Not resolved
I changed
192.168.1.9 (1415) -> 192.168.1.9(1415)
Put AMQCLCHL.TAB also to C:\ProgramData\IBM\MQ (I don't know why which might not be correct, because error on log file:
AMQ9518: File 'C:\ProgramData\IBM\MQ\AMQCLCHL.TAB' not found.
)
3 I tried
MCA User Id ->
1 mqlclient who is memeber of mqm
2 mqlclient who is not memeber of mqm
3 empty
But still got error. Below is exception and error for 3.1
IBM.WMQ.MQException: MQRC_NOT_AUTHORIZED
----- cmqxrsrv.c : 2356 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5540: Application 'bin\Debug\Producer.exe' did not supply a user ID
and password
EXPLANATION:
The queue manager is configured to require a user ID and password, but none was
supplied.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the queue manager configuration to OPTIONAL to allow applications to connect
which have not supplied a user ID and password.
----- amqzfuca.c : 4311 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5541: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'mqclient' and its password were checked because the user ID is
privileged and the queue manager connection authority (CONNAUTH) configuration
refers to an authentication information (AUTHINFO) object named
'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM).
This message accompanies a previous error to clarify the reason for the user ID
and password check.
ACTION:
Refer to the previous error for more information.
Ensure that a password is specified by the client application and that the
password is correct for the user ID. The authentication configuration of the
queue manager connection determines the user ID repository. For example, the
local operating system user database or an LDAP server.
To avoid the authentication check, you can either use an unprivileged user ID
or amend the authentication configuration of the queue manager. You can amend
the CHCKCLNT attribute in the CHLAUTH record, but you should generally not
allow unauthenticated remote access.
-------------------------------------------------------------------------------
17/04/2018 23:50:45 - Process(14900.9) User(SYSTEM) Program(amqrmppa.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ9557: Queue Manager User ID initialization failed for 'mqclient'.
EXPLANATION:
The call to initialize the User ID 'mqclient' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 2356 -------------------------------------------------------
OP added the following information to the question in UPDATE 2:
SET MQCHLLIB=C:\ProgramData\IBM\MQ\qmgrs\QM1\#ipcc
SET MQCHLTAB=AMQCLCHL.TAB
echo DIS CHL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN) ALL | runmqsc -n
I see two possible issues with the CCDT:
You have a space in the CONNAME between the IP and the open parenthesis. This may be causing MQ to disregard the port 1415 and use the default port 1414, it also may ignore the space and it may not be a problem, I have never tested with a space.
COMPMSG(NONE) CONNAME(192.168.1.9 (1415))
The QMNAME of the CLNTCONN channel should match what you are specifying in the call to new MQQueueManager, so this should say QM1 not LocalQM, this is likely the direct reason for your 2058 error, but #1 may cause an issue as well once you fix #2.
QMNAME(LocalQM) RCVDATA( )
There are also other uses for QMNAME where you can specify a group name or a blank. See my answer to "Connecting to IBM MQ using CCDT file in JMS
" for more details on this. The answer is related to JMS but the information presented for the setQueueManager would be the same as the first parameter to your call to new MQQueueManager.
Generally speaking, reason code of 2058 (MQRC_Q_MGR_NAME_ERROR) means that you have an invalid queue manager name or that the server does not have that particular queue manager. Check the spelling of the queue manager name that you inputted. Also, queue manager names are case sensitive (e.g. MQA1 is not the same as mqa1).
Also, every queue manager will have its own port #. i.e. 1414, 1415, 1416, etc. So, if there is more than 1 queue manager running on that server then make sure you are using the correct port.
System.Environment.SetEnvironmentVariable("MQCHLLIB", "C:\\ProgramData\\IBM\\MQ\\qmgrs\\QM1\\#ipcc");
System.Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL.TAB");
Try setting the environment variables before starting your program rather than from inside your program. I have found weird issues in Windows and/or .NET with setting environment variables inside a program - sometimes it works, sometimes it doesn't.
Finally, are you running your application on the same server as where the queue manager is running? If so, then connect in 'bindings mode' rather than 'client mode'. Bindings mode will be way faster as there is no network involved.
I have C# Windows Form application to test the LDAP SSL authentication.
Here is the code. First, I made a function.
using System.DirectoryServices;
private bool VerifyDomainUserUsignLDAP(string UserName, string Password, string Domain,string mode, out string message)
{
bool retVal = false;
message = null;
DirectoryEntry de;
try
{ if (mode =="Plain")
//plain mode
de = new DirectoryEntry(Domain, UserName, Password);
else
//SSL mode
de = new DirectoryEntry(Domain, UserName, Password,
AuthenticationTypes.Secure | AuthenticationTypes.SecureSocketsLayer);
DirectorySearcher ds = new DirectorySearcher(de);
SearchResult sr= ds.FindOne();
lblResult.Text = "Authentication Passed! " + sr.ToString();
retVal = true;
}
catch (Exception ex)
{
retVal = false;
lblResult.Text = ex.Message;
}
return retVal;
}
My problem is the invoke.
Share with some background first.
We have multiple domain control servers (Windows). dcserver001.mydomain.com is one of them. (of course, we have dcserver002.mydomain.com, dcserver003.mydomain.com, etc). each server provides LDAPS service.
And we created a VIP name ldap.mydomain.com in F5 (Load balance), we put all above dc servers into the Load balance. All DC servers are Windows servers.
Days before, if I use following line to invoke above function for LDAP authenticate on the VIP name - ldap.mydomain.com.
For e.g.
VerifyDomainUserUsignLDAP("mydomain\\myuserid", "mypassword",
#"LDAP://ldap.mydomain.com", "SSL" ,out Message);
It always worked fine and the user was authenticated.
However, some days before, our LDAP service team made a registry change (LdapEnforceChannelBinding) on each ldap servers to
enhance the security based on MS suggestion.
In short, they changed following key value from 0 to 2
Path: HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/NTDS/Parameters
Key: LdapEnforceChannelBinding
Here is detail page about the setting on MS web site.
Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure
https://support.microsoft.com/en-hk/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry
After that, I noticed my above function stop working.
i.e. if I use same line to invoke above function for LDAP authenticate.
For e.g.
VerifyDomainUserUsignLDAP("mydomain\\myuserid", "mypassword",
#"LDAP://ldap.mydomain.com", "SSL" ,out Message);
It always returned exception "Logon failure: unknown user name or password."
(I promise password and user name were correct.)
Then, I did further investigation.
I tried to use following line to invoke above function for LDAP authenticate on any individual dc server, e.g.
dcserver001.mydomain.com.
VerifyDomainUserUsignLDAP("mydomain\\myuserid", "mypassword",
#"LDAP://dcserver001.mydomain.com", "SSL" ,out Message);
It worked fine as well.
I actually tested all individual dc servers one by one, thwy were all working.
So, it looks like the ldap request with same invoke parameters works well on the individual dc server, but it doesn't work on the VIP name.
Then, I asked the ldap server team to rollback to LdapEnforceChannelBinding change to value 0. Then, I re-tested ldap against both individual server and VIP name, both worked.
I checked with our metwork team and got got some more information as follwoing.
They said this won't work with LDAPS VIPs because the SSL channel from client is terminated on F5, and reestablished to DC.
the reason why it works directly to the dc is because its one continuous packet.
The update addresses this vulnerability by incorporating support for Extended Protection for Authentication security feature, which allows the LDAP server to detect and block such forwarded authentication requests once enabled.
What I need help is - is there anyone here encountered the similar ldap ssl logon issue against F5 VIP and with the LdapEnforceChannelBinding registry value = 1 or 2?
If LdapEnforceChannelBinding registry value = 1 or 2 on the LDAP servers, what changes need to be done to resolve above LDAPS logon issue?
Thanks a lot!
Jun
Caching behavior of the last Dynamics SDK is driving me crazy.
First, if you want to use CrmServiceClient to access different environments you have to use the parameter RequireNewInstance=True; in the connection string. If not, every instance of CrmServiceClient will use the same connection, even if you create and dispose instances to different environments.
Now, even if you use the RequireNewInstance=True; in the connection string I found that cache still occurs in some scenarios.
var client1 = new CrmServiceClient("RequireNewInstance=True;
Url=https://myCompany.crm.dynamics.com;
Username=myUser#myCompany.onmicrosoft.com; Password=myPassowrd;
AuthType=Office365");
//Now, client 2 points to a url that doesn’t exists:
var client2 = new CrmServiceClient("RequireNewInstance=True;
Url=https://xxx.crm.dynamics.com; Username=myUser#myCompany.onmicrosoft.com;
Password=myPassowrd; AuthType=Office365");
The client2 keeps using the first connection string, so you cannot determine if the new connection string is correct.
Any ideas how to test Dynamics Crm connections strings correctly in my asp.net application?
Late reply, but the behavior you're seeing is because when you're specifying an erroneous URL the discovery service is used to ascertain which instance to connect to.
To prevent this specify SkipDiscovery=True in your connection string:
var connectionString2 = #"AuthType=Office365;Url=https://FAKE.crm.dynamics.com;Username=USERNAME;Password=PASSWORD;RequireNewInstance=True;SkipDiscovery=True;";
Edit: SkipDiscovery is true by default starting with 9.0.7, kudos to #mwardm
I think I found the problem. It seems to only happens on Dynamics 365 online trials, that was the reason we were getting inconsistent results depending on the environment.
Apparently, the url doesn't need to be completely valid to establish a connection to a CRM online trial environment, as long as the credentials are valid and the url structure is kept.
Let's consider the following example:
var client1 = new CrmServiceClient("RequireNewInstance=True;
Url=https://fake.crm.dynamics.com;
Username=myUser#myCompany.onmicrosoft.com; Password=myPassowrd;
AuthType=Office365");
In this case I can substitute the "fake" part of the url with whatever I want, but still execute requests correctly using the CrmServiceClient service.
If I try to do this with another environment (e.g. 2015, on premise, not-trial crm online, etc.), the IsReady property of the CrmServiceClient would return false and I would get an error in the LastCrmError property.
Very weird behavior, and difficult to pinpoint.
Now that I think I understand the inconsistent behavior I know that finally it will not affect our clients, so I will mark this response as the answer even if I still do not know why we have different behavior between a trial and a normal environment..
I agree choosing to reuse the existing connection if you don't include RequireNewInstance=true seems counter-intuitive, but I can't reproduce what you're seeing. If I try the following from LinqPad crmSvcClient2 will print out errors and then throw a null ref on the Execute call (8.2.0.2 version of the SDK). With this version of the SDK you'll want to always check LastCrmError after connecting to see if the connection failed.
var connectionString = #"AuthType=Office365;Url=https://REAL.crm.dynamics.com;Username=USERNAME;Password=PASSWORD;RequireNewInstance=True;";
var connectionString2 = #"AuthType=Office365;Url=https://FAKE.crm.dynamics.com;Username=USERNAME;Password=PASSWORD;RequireNewInstance=True;";
using (var crmSvcClient = new CrmServiceClient(connectionString))
{
"crmSvcClient".Dump();
crmSvcClient.LastCrmError.Dump();
((WhoAmIResponse)crmSvcClient.Execute(new WhoAmIRequest())).OrganizationId.Dump();
crmSvcClient.ConnectedOrgFriendlyName.Dump();
}
using (var crmSvcClient2 = new CrmServiceClient(connectionString2))
{
"crmSvcClient2".Dump();
crmSvcClient2.LastCrmError.Dump();
((WhoAmIResponse)crmSvcClient2.Execute(new WhoAmIRequest())).OrganizationId.Dump();
crmSvcClient2.ConnectedOrgFriendlyName.Dump();
}
I am trying to connect to a test instance of a Websphere MQ 7.5 server (on a Windows domain) from a C# application using the full MQ Client install, but I've had no luck. I keep getting the error code 2035 MQRC_NOT_AUTHORIZED from the MQ server. Initially I tried the code below:
string QueueManagerName = "myNewQManager";
MQEnvironment.Hostname = "tst-mqsvr";
MQEnvironment.Channel = "test.channel";
MQEnvironment.Port = 1414;
MQEnvironment.UserId = "domainUser";
MQEnvironment.Password = "********";
//set transport properties.
MQEnvironment.properties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_CLIENT;
try
{
queueManager = new MQQueueManager(QueueManagerName);
}
catch(MQException mqexp)
{
//I get the error code 2035
log.Error(mqexp)
}
changing to this doesn't work either:
string QueueManagerName = "myNewQManager";
var queueProperties = new Hashtable();
queueProperties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_CLIENT;
queueProperties[MQC.HOST_NAME_PROPERTY] = "tst-mqsvr";
queueProperties[MQC.PORT_PROPERTY] = "1414";
queueProperties[MQC.CHANNEL_PROPERTY] = "test.channel";
queueProperties[MQC.USER_ID_PROPERTY] = "domainUser";
queueProperties[MQC.PASSWORD_PROPERTY] = "*********";
try
{
queueManager = new MQQueueManager(QueueManagerName, queueProperties);
}
catch(MQException mqexp)
{
//I still get the error code 2035
log.Error(mqexp)
}
This error goes away and I can connect/put/get messages from my queue if
I manually set the MCAUSER on my channel, or
I run the application as the domain user who set up the MQ server (using RunAs)
However, I will not be able to use either of these two workarounds for the production set up. I am assuming I'm getting the error code 2035 because the MQ client is sending the wrong user-id. I need to be able to override (or at least determine) the flowed userid during server connection. How do I go about this?
Edit: I got the errors below in my AMQERR01.log file
-------------------------------------------------------------------------------
7/6/2016 13:06:14 - Process(1380.10) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ8075: Authorization failed because the SID for entity 'sinistrian' cannot be
obtained.
EXPLANATION:
The Object Authority Manager was unable to obtain a SID for the specified
entity. This could be because the local machine is not in the domain to locate
the entity, or because the entity does not exist.
ACTION:
Ensure that the entity is valid, and that all necessary domain controllers are
available. This might mean creating the entity on the local machine.
----- amqzfubn.c : 2273 -------------------------------------------------------
7/6/2016 13:06:14 - Process(1380.10) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ8073: Authorization failed because SID: ((None)) could not be resolved.
EXPLANATION:
The Object Authority Manager was unable to resolve the specified SID into
entity and domain information.
ACTION:
Ensure that the application provides a SID that is recognized on this system,
that all necessary domain controllers are available, and that the security
policy is set as you required.
----- amqzfubn.c : 4397 -------------------------------------------------------
7/6/2016 13:06:14 - Process(3008.3) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ9557: Queue Manager User ID initialization failed.
EXPLANATION:
The call to initialize the User ID failed with CompCode 2 and Reason 2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 1975 -------------------------------------------------------
7/6/2016 13:06:14 - Process(3008.3) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ9999: Channel 'TEST.CHANNEL' to host 'WKS-L450 (192.168.10.23)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 3008(2192) for channel
'TEST.CHANNEL' ended abnormally. The host name is 'WKS-L450 (192.168.10.23)';
in some cases the host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
Until version 7.5, MQ client always flows the logged-in UserId and not the UserId specified by the application, to queue manager for authorization. You will need a security exit for this scenario.
This changed in MQ v8 where UserId specified by the application is flowed to the queue manager for authorization check. More details here: https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q113260_.htm
You could use the MQS_REPORT_NOAUTH or MQSAUTHERRORS setting to get more info the authority failure.