Hi,

I am getting the below errors in nirvana.log after setting up LDAP authentication in universal messaging.

We have created JNDI alias for these UM realms.

,SECURITY: Mandatory credentials not supplied - webm@ISHOST on nsp://ISIPaddress:47771

Please let me know what could be the issue.

Kavitha,
if you configured LDAP authentication, then credentials will need to be provided by all clients, including JNDI clients. You can provide valid credentials in the JNDI alias configuration in IS.

Thanks Jonathan,

I have given valid credentials for JNDI and restarted the IS and realm as well. But i still see the same issue.
Then i deleted the JNDI’s and recreated but still no luck.

How precisely have you provided the credentials in the JNDI alias?
You should enter the username in the Security Principal field and the password in the Security Credentials field.
Did you do that?
(Note: You do not need to restart IS after this - just clicking the Test button for the JNDI alias is enough).
Have you validated using a different client (e.g. a webMethods Messaging alias in IS) that the credentials are working correctly?

Hi Jonathan,

Yes i have given the credentials as you have described. I did check the UM connection alias and it is configured for SSL port and not for default port 9000.

I donot see any issue with messaging alias.

There are 3 JNDI aliases and all are configured with correct credentials and tested with Test button right next to them and test is successful.

I get the below error mails every second and nirvana.log is getting piled up.

SECURITY: Mandatory credentials not supplied - webm@ptseelm-lx4680.ikeadt.com on nsp://10.230.9.133:49517

here webm is the user to login to UM linux box.

The users.txt user is Administrator and our UM is configured for both LDAP and users.txt.
I am able to login to EM with both LDAP user and users.txt user.
Messaging alias is up with SSL port.
JNDI aliases are set with default port 9000 with Administrator user (users.txt user)

It might not be from JNDI. but what could be the other connection trying to login to UM from IS host?

It indeed doesn’t look like JNDI is the issue. You have now clarified that you are seeing this login failure in the UM logs.
Are you using Command Central? If so, can you temporarily stop the Platform Manager (SPM) and see whether the errors stop?
If you stop the IS, do the errors stop?
Also, the error message showed webm@hostname. Is that hostname the same machine as UM itself is running on?

Hi Jonatha,

Yes command central is configured. Will try the step you have mentioned. But please see my next comments.
When i stop Integration server, the error messages disappears from nirvana.log in data folder.
webm@hostname means webm user at IS host.

I think it might be the NERV or ERF configuration. What version of IS are you using?

we are using IS 9.10 version.

First stop IS.
Then go to \profiles\IS-default\configuration\event\routing\servicegroups and change “service-usage” to "SourceOnly "
Then restart IS.
Hopefully now it will not attempt to reconnect.

Could you please explain me what exactly is happening at Server? what is the issue and how will it help?

There is a separate messaging layer, called Event Routing Framework, that by default is configured to connect to UM at localhost:9000. You can reconfigure it using Command Central under Event Routing. The instructions I gave are a simple way to stop it connecting to UM, as you probably don’t need ERF.

Thanks Jonathan, but this did not solve the issue

I am still facing the same issue again

Do you also have a JMS aliias defined in IS? If you disable that, does the error message stop in UM?
If so, have you provided credentials in the JMS alias definition? (You need to).
Also check any wM Messaging aliases for the same thing.

Yes Jonathan, we have configured JMS aliases, and they are all set with the correct user credentials.

Even when i have disabled JMS aliases, i get the same error.
The user credentials set for LDAP is Administrator, but the error is showing as webm@IShost.

Not sure if it is JMS or JNDI issue. The number at the end of the error message keeps changing.
SECURITY: Mandatory credentials not supplied - webm@ISHost on nsp://ISIPAddress:57966

Hello Jonathan,

There are some channnels created for monitoring events at TN dashboards. Will that be an issue?

Regards,
Kavitha

If you are using TN dashboards, then they do use the ERF layer that I mentioned earlier. I have checked with R&D and unfortunately it is not possible to configure credentials on an ERF connection.
To work around this, you can specify exemptions for clients unable to specify credentials. Add an extra line to the Server_Common.conf, similar to where you specified auth.mandatory=Y
-DNirvana.auth.exempt=/path/to/file
In that file, specify trusted clients in the same format, e.g. webm@ISHost
One per line.

Hope this helps.

Thanks Jonathan.

This helped.

Regards,
Kavitha

Hi Jonathan,

I am getting the similar error when trying to connect using managed file transfer client (goanywhere) to UM

Can you please suggest what changes I need to make to resolve this issue.

Thanks.
Vishal

Vishal,
I assume your MFT client is connecting using JMS. Is that correct?
If so, then you should be able to provide credentials as part of the JMS connection settings in your MFT client. Providing credentials is part of the JMS standard.
If not using JMS, then please provide more details on the protocol your MFT client is using to connect to UM.

MFT client is using JMS interface for connection and I am setting the credentials. UM log is showing the user@ under which MFT client is running, it should ideally show the user which is part of credentials entered.

What version of UM are you using?

Version 9.9

Hi Jonathan,

This is regarding clients connections with UM, we have several applications which are connecting with central UM HUB. We would like to authenticate the users connecting from those application in UM. We have set up the Active Directory based authentication and JMS clients are able to connect by passing the security credential and security prinicpal. However, DOTNET clients are unable to connect because we don’t have an option to pass credentials in DOTNET library. I can see the following error in the logs :
SECURITY: Mandatory credentials not supplied

I am not sure the next steps to resolve this.
Can you help me here please.

Thanks.
Vishal.

Hi Vishal,

the DotNet client does not (yet) support client authentication based on username/password. We are currently planning to include this in the October 2017 release of Universal Messaging.

Thanks for the quick reply.

Do we need to setup the exception for DOTNET clients because for the moment we have AD based authentication setup for the JMS clients, how can we bypass that ?

Do we have any other ways to authenticate DOTNET client ?

Vishal,
you could authenticate DotNet clients using client certificates, but that will not work well in combination with basic authentication with your Java clients, so likely not an option.
What you could do is set up a file of authentication-exempt clients, e.g. based on the IP addresses of your DotNet clients. Create a file with the auth-exempt clients, e.g.
*@192.168.0.1
*@192.168.0.2
Then point to that file by adding this line to server_common.conf:
-DNirvana.auth.exempt=/path/to/file

This will allow your DotNet clients to connect, while still enforcing username/password for your Java clients.

Is there any way if they can co-exist ? I mean java client can use basic authentication and DotNet clients can use client certificates ?

May be not possible if using same REALM or if we can use different interface within same REALM?

Otherwise we need to use different REALM for DotNet clients to use client certificates.

Jonathan
Does this mean any user from the host 192.168.0.1 can connect with out credentials when the application is .net.
We also having same problem with .Net app. For me its only working when i provide username@hostname not *@hostname.

*@192.168.0.1
*@192.168.0.2
Then point to that file by adding this line to server_common.conf:
-DNirvana.auth.exempt=/path/to/file

Hi Krishna,

This thread is pretty old. In the meantime plain SASL authentication (with a username and a password) was made available in .Net (depending on the version you are using you may have to install the latest fixes - check the respective fix readme for further information).

To your question, you cannot use wildcards when adding users that are exception to authentication - only explicit user@host is allowed there.

Thanks,
Stefan