Highlighted
Trusted Contributor.
Trusted Contributor.
414 views

Kanaka 3.1 Credentials Set Errors

I'm looking into an issue with Kanaka 3.1, where I can't get users to authenticate. First error in the log:
"Credentials Set is incomplete. Going into Setup Mode."

When a user logs in, this also additionally appears in the server log:
"Unable to obtain a proxy security context, Result = 8."

The Kanaka Client also shows an Error Result 8.

Upon viewing the Server Status from the Web Console for Kanaka, there are 0 users being indexed, even though the containers are set correctly, and the Proxy User line is blank.

However, the Setup Wizard successfully created the Proxy User & Admin Group in eDirectory and the rights are set correctly and the Admin Group is populated with a user.

So, I attempted to regenerate the proxy user's credentials using the init script's proxy-reset option, giving the following result:

NWXPLAT: m_pfnNWCCCloseConn() failed, rc = 0x00008801.
NWXPLAT: m_pfnNWCCCloseConn() failed, rc = 0x00008801.
Completed a Force Proxy Reset, Instance = "", Result = 230, bOK = 0.

It sounds like those errors showing might just be attempts to close connections, and may not be anything major, but I could not confirm based on what I've found so far.

It looks like there are a few result codes, for example 92 is also some sort of failure, when the wrong credentials are specified, I receive an additional NDS error before the two listed above.

That's what someone else was getting here with a similar script. I verified getting the same result 92 code if I specified incorrect credentials:
https://community.microfocus.com/t5/Storage-Manager-User-Discussions/Unable-to-Reset-NSMProxy/m-p/2638062

A result 230 may not be a successful result, either, as when I checked the salted stored password variable stored in the CredentialsSet.dat, none of those variables in the file, or the file itself, are changing between runs of the proxy-reset script. So, if it is actually changing the password, then you would expect the hash to change in the file each time. However, it may just be using the hash in the file to decode it and then reset/change the password in eDirectory (back) to be whatever that is, in which case it is working correctly.

Apart from those errors, I can log into port 3089 in the web browser just fine, and run the Setup Wizard, though there seems to be a bug where after completing it, Kanaka ends up in a state where it shuts down immediately and won't stay running. Toggling the NDS server parameter with the microfocus-kanakaengine-config script from hostname to IP or vice-versa appears to fix it so the server does start up successfully again. The error in the log is also similarly related to the credential set, which appears to be correct in the file.

I also tried applying Universal Password to the proxy user, just to see if perhaps it was having trouble with logging in using the password into either CIFS or AFP. I verified that I can log into both protocols and see volumes via a Mac, per the documentation. I also installed and made sure that the root certificate on the Mac side was set up correctly, as well as the server.pem on the server side.

I did not try changing the password for the proxy user manually to see if I received any different behavior from running the reset script. That seems like it would just break it in a different way, and may not offer any more information other than possibly a different error. I have also uninstalled/reinstalled the software a few times while troubleshooting.

Thanks in advance for any insight you might provide.


Labels (3)
0 Likes
24 Replies
Highlighted
Outstanding Contributor.
Outstanding Contributor.

Renew your server certificates and the connection will work correctly, also with 2018.2 and kanaka 3.1

 

0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.

Thanks for the suggestion! Yes, that is the server version that I am using. I tried a few more things, including repairing/recreating the CertificateDNS with the force option in iManager. I also checked and confirmed that KanakaProxy is logging in correctly by looking at the last login time, so it is not a password issue.

KanakaProxy has supervisor entry rights at the tree, which is something I really don't like about the development of this program. I think these kinds of add-on applications need to specify what rights they need, from a philosophical point of view, and not just provision themselves for supervisor.

I've tried setting the IP for the Kanaka server in the config utility to the loopback IP as well as the actual IP. I've also tried setting the NCP server to the IP, server short name, and FQDN. I also tried generating a CertificateIP and setting everything to the same IP in the config utility, to no avail.

At that point, I took a look at the CredentialsSet.dat, which showed three entries & salts (I assume passwords) for KanakaProxy, one with the IP, one with the short name, and one with the FQDN. I deleted all three and ran the proxy-reset command on the rc script, which didn't populate anything into the file, so maybe it needs at least one entry to tell which user to reset.

However, even with a single entry, the salt was not being changed after running the proxy-reset script, so not quite convinced it is meant to change the password. But this should be a moot point, as it appears that Kanaka server is logging in as the account, then it is not seeing anything (it's like it's having trouble traversing the tree.)

After running the Setup Wizard, it repopulated the CredentialsSet.dat with a new salt, but always stops here:

ML:  Failed to set the credentials set for the Security Context Pool subsystem, Result = 179.
ML:  Completed configuring the Security Context Pool subsystem, bOK = 1, nResult = 179.
ML:  Starting the Security Context Pool Service...
ML:  Completed starting the Security Context Pool Service, Result = 0, bOK = 1.
ML:  Waiting for the Security Context Pool to be filled...
CCSecurityContextPoolService - Worker thread has started.
CCSecurityContextPoolService - Subsystem shutdown detected.  The worker thread will terminate cleanly.
CCSecurityContextPoolService - Thread has terminated.
ML:  Finished waiting for the Security Context Pool to be filled, Result = 326, bOK = 0.
ML:  Failed to initialize 1 or more components and/or services.  Engine is switching to stop-pending state.

Then, the server shuts down and won't stay running, it just shuts down within minutes. If I change the NCP server address using the config utility, it will start back up. However, users can't log in and it can't find any users or storage resources.

This is what happens as soon as it's restarted after changing the NCP server name:

WD: Engine is running...
CC: Unable to obtain a proxy security context, Result = 8.

Earlier in the same log after doing that, it says this:

ML: Loading saved state information...
ML: Completed loading state information, bOK = 1.
ML: Credentials Set is incomplete. Going into Setup Mode.

I assume this is because of a mismatch between the NCP server name in the config utility that is set in the kanaka.conf file, and the CredentialsSet.dat, which has a server path entry. However, changing it back to where it matches just causes it to shut down after running for a few minutes again.

So, I tried creating a new, separate certificate just for Kanaka rather than using CertificateDNS/IP, and converting that, however, it did not change the behavior.


0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.

<duplicate>


0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

you must deleted all certificates object in edirectory and the recreate all new. Then Import the new certificate on mac osx. I can give Feedback for osx big sur public beta! Yes, it works without any problem!
Can you send the detailled steps you have do?
0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

I spent 2 days trying to get Kanaka 3.1 working. Finally gave up and restored back to 3.01. It continues working fine for 10.14 and older macs. Have now moved on and started using DSFW for mac auth. To be honest it works quite well and less headaches than Kanaka. Never knew when Kanaka would crash again. Logins have actually worked very well with DSFW and using as mobile accounts. Much easier to implement rights as well for the machines.

0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

without more Information, we are not able to help you.

i can confirm that kanaka 3.1 works with fine with oes2018.2 and all osx Versions catalina 10.15, also big sur public beta.

Kanaka 3.1 will not work on 10.14, when i remember me

Questions:

What is your os on MF side? oes11 - oes2015 - oes2018 and sp?

What is your osx System? 10.14.x, 10.15.x, 10.16.0

What do you have install on oes?
What do you have install on osx?
Do you have Import the certificate on osx machine?

If you certificate on oes are invalid, you must delete the certificate objects (four objects if i remember me correctly), recreate the certificates as documented from MF and Import the new certificate on osx.

Give us detailled informations for better Support/help

Thanks

cg

0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.

Client OS is macOS 10.15.6.
Server OS is OES 2018.2 with latest updates; nothing installed except Kanaka & the following OES Services:
- CIS
- AFP
- SMS
- CIFS
- NDS
- iManager
- iPrint
- iPrint Advanced
- NCP
- NetStorage
- Remote Manager
- NSS

Root cert is imported & trusted on Mac. All cert objects were deleted, created again with iManager, then converted to server.pem and imported to the Kanaka config folder. I am using Kanaka 3.1. I'll do some testing with DSfW as well, but this is rather disappointing that an off-the-shelf product like Kanaka doesn't seem to work with current updates on client & server.


0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

I will be straight up why I finally went this route. Use ZENworks in the environment as well. I prepped everything to be configured on the machines ahead of time and did all that with ZENworks. Including pushing policies. The only thing missing is they do not support deploy for macs and only iOS devices currently. So every mac has to be touched. But here is what do. I boot the mac and put a local administrator account on it. Then name the machine. Then install the ZENworks agent. Do a refresh and that installs all the apps that need and configures the policies for the machines. Even the AD setup to DSfW is created from ZENworks and added to the domain. Basically all the user has to do is login to the machine and set their prefs the way they want and add printers they need through print and they are good to go. The restore their documents from google and boom they are done. It has been solid as a rock. The accounts are just like kanaka that they are mobile accounts. So of course at times they may not be able to login if they are not on the school wifi but kanaka has the same issue. Actually all platforms for the mac have that issue. 

0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

Console Kanaka Version 3.1.0.0 Oct 22 2019 15:40:26

Do your console is configure correctly and runs on the oes Server?

When not, publish the Errors! Do you see your mappings?

https://192.168.x.x:3089/m/ServerStatus.html

Can you run the Login script?

Mac osx: what are your error message?

On the Kanaka Client 3.1.0?
On the Kanaka Utility?

I works with the same oes Tools and have allways zenworks, groupwise, gms, filr, vibe, iprint, Teamworks, Messenger as running products, edir, imanager, etc.... all in the newest Version and all patches...

waiting for clear and Details on Information/Errors!

cg

 

0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.

Yes, I can get to the web console for Kanaka, but only if I have renamed the CredentialsSet.dat. Otherwise, the server won't start up fully and shuts itself down. So, the issue seems to have something to do with what happens when it generates/accesses that file. The Proxy user is set up in eDirectory correctly with the correct rights. It shows that it has been logged into by Kanaka in the Login Restrictions.

On the Server Status page, it does not show the Proxy user listed, it is blank, but it does show the AdminGroup. I can't run the login script. I get a Result = 8 on the client & server. I did have the server at one point to where I was getting an SSL error on the client, but not currently.

I have enclosed an attachment of what is happening when I run the Wizard with debug log mode on.

Then, there is a second log showing what happens after the server starts back up and shuts itself down.

I also tried uninstalling Kanaka 3.1 and installing Kanaka 3.0.1 and setting that up instead, however, I had the same issue.


0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

why do you not open a sr by micro Focus?
Do you have a valid maintenance?
They will help with there remote tool?
only looking on your Client and Server side will solve your Problem!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.