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.
Related
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;
I try to generate a new device and publish some random data to it via MQTT.
I follow this official example:
https://cumulocity.com/guides/device-sdk/mqtt-examples/#hello-mqtt-cs
All operations are executed without any error. Even establishing connection. But when I try to publish a message to the device I get the following error
"Connecting with MQTT server failed (ConnectionRefusedNotAuthorized)"
Here is my info to connect to the server
const string serverUrl = "mytenant.eu-latest.cumulocity.com";
const string clientId = "d:testdevice4";
const string device_name = "testdevice4";
const string user = "<mytenant>.eu-latest/<myusername>";
const string password = "XXXXXXXX";
And here are the operations that are executed without throwing any exception or ConnectionFailed event:
Establish Connection
await client.EstablishConnectionAsync();
Create Device
string topic = "s/us";
string payload = $"100,{device_name}, c8y_MQTTDevice";
var message = new MqttMessageRequestBuilder()
.WithTopicName(topic)
.WithQoS(QoS.EXACTLY_ONCE)
.WithMessageContent(payload)
.Build();
The other operations on Cumulocity Example
// set device's hardware information
var deviceMessage = new MqttMessageRequestBuilder()
.WithTopicName("s/us")
.WithQoS(QoS.EXACTLY_ONCE)
.WithMessageContent($"110, {device_name}, MQTT test model, Rev0.1")
.Build();
await client.PublishAsync(deviceMessage);
// add restart operation
await client.SubscribeAsync(new MqttMessageRequest() { TopicName = "s/ds" });
await client.SubscribeAsync(new MqttMessageRequest() { TopicName = "s/e" });
await client.PublishAsync(new MqttMessageRequestBuilder()
.WithTopicName("s/us")
.WithQoS(QoS.EXACTLY_ONCE)
.WithMessageContent("114,c8y_Restart")
.Build());
But when I try to publish a message to the device as follows, ConnectionFailed event is invoked with the error:
"Connecting with MQTT server failed (ConnectionRefusedNotAuthorized)"
Random rnd = new Random();
while (!cToken.IsCancellationRequested)
{
int temp = rnd.Next(10, 20);
Console.WriteLine("Sending temperature measurement (" + temp + "º) ...");
var xx = client.ConnectionDetails;
await client.PublishAsync(new MqttMessageRequestBuilder()
.WithTopicName("s/us")
.WithQoS(QoS.EXACTLY_ONCE)
.WithMessageContent("211," + temp)
.Build());
Thread.Sleep(1000);
}
You get a ConnectionRefusedNotAuthorized error because your credentials are not correct. To be precise, the user:
const string user = "<mytenant>.eu-latest/<myusername>";
The user is formed as tenantID/username
Your tenant domain (<mytenant>.eu-latest) is not the tenant ID. Tenant IDs – in most of the cases – are a number preceded by the letter t, e.g. t123123.
so your string should look like:
const string user = "t123123/mytenant";
More details can be found in the public documentation:
Tenant ID and Tenant domain
GET the current tenant details
There could be more reasons than just authorization issues, as per
https://cumulocity.com/guides/device-sdk/mqtt/
which states for return code 5 - "Connection refused, not authorized"
Mostly a device side related problem, used when the device doesn’t
have permissions or is doing something forbidden. For example, if the
client sends malformed messages or tries to execute an operation
without authenticating first, such as publishing a message. Thrown on
any issue with certificate authentication (for example, wrong common
name, failed auto registration). Also thrown on general issues with
receiving device data or some other authorization problem related to
the device state on the platform. For example, device managed object
problems, or the sudden removal of permissions. In this situation it
may be required to take action on the platform to investigate and
apply a fix. When clientId is too long the user can receive this error
when using 3.1 version of MQTT. This can happen if clientId has 24
characters or more. Lastly, it can also be thrown on unexpected
exceptions like performance issues, especially during connection.
Therefore it is a good approach to repeat the connection a few times
to overcome temporary performance issues.
I had the same issue where all my coded attempts (C#, Node.js) were failing with this same error.
In my case I am using a trial Cumulocity environment where the tenant id differs from all the Cumulocity documentation (which says the tenant id starts with a 't' followed by a number of digits. In my trial environment, the Tenant ID is shown in the Cumulocity Cockpit under the user details (top right), and this is in the format "ENVxxxxxx".
To try to troubleshoot the issue I began testing with an online MQTT client http://www.emqx.io/online-mqtt-client and through this process I mistakenly typed the username with lower case "env" and this resolved my issue. Hope that helps others.
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
Ok, first of all here is the error message from WMI-Activity / Operational in EventLog (Windows 8):
Id = ; ClientMachine = machinename; User = machinename\Dev; ClientProcessId = 1440; Component = WMIService; Operation = connect to namespace : root\CIMV2\Security\MicrosoftVolumeEncryption; ResultCode = 0x80041003; PossibleCause = the user was not granted appropriate permission on the namespace.
the thing is User name "Dev" is not the username that I fed to the ConnectionOptions of ManagementScope() when I attempted connection to remote computer.
The machinename(I hide) was correct.
Trying to make a remote connection is a service and most suspicious scenario is service running as local machine somehow overwrites the username..
I need a confirmation with somebody who might know and able to explain what I am doing wrong here..
I see Username and Password are correct until fed into properties of ConnectionOptions and made Scope.Connect() call.