Kanaka Troubleshooting tips:
When last I visited the topic of Kanaka, it was all NetWare all the time. I had lots of things to say, that you can read about in these articles:
But I wrote those way back in 2006, probably before I was even seriously involved in IDM stuff, and how the times have changed. Now Kanaka runs on Windows (not the free version with OES) or OES Linux. It now processes Login Scripts and much more.
Much of the advice I gave in the NetWare days is relevant in terms of Universal Password, Native File Access general concepts, however some of the specific details have changed.
For example, the web interface to configure Kanaka is no longer via NoRM (Novell Remote Manager) but rather its own web interface, which defaults to port 3088 (unsecure) and 3089 (Over SSL).
Configuring file access for AFP or CIFS is no longer NLM based, but rather Linux processes probably handled through yast.
Recently I ran into an issue with Kanaka, and since I had not really looked at it since the NetWare days, I needed to learn a bunch of things fast. As long as I was relearning this stuff, I figured I should write it down, since in searching for the answer to my issue, I came across my old stuff on Google, and it helped remind me of stuff I used to know. I guess Google has become my external memory store. Write it down, so Google can help me find it next time I need it.
First off, there are three main directories for stuff of interest.
/opt/novell/kanaka/engine/ (For the bin and lib subdirs with the actual code) /var/opt/novell/kanaka/engine/ (For the logs, and User index, storage list, etc) /etc/opt/novell/kanaka/engine/ (For the configuration).
That kind of makes sense. The configuration is in the /etc directory structure. The executable files are in the /opt directory structure, and the stuff that changes often (logs, user list, client list (No, not the Elliot Spitzer kind of client), storage resources is in the /var directory structure.
The main process is novell-kanakaengined, which can be called via the /etc/init.d/novell-kanakaengined script, which is also available as the rcnovell-kanakaengined script that should be in your path. This is fairly typical for Linux processes. There is an actual executable that takes parameters, that is called by a script that takes parameters, and then there is a shortcut to that script.
My issue was silly. I did something dumb (in hindsight, at the time it did not occur to me). I was helping setup a second Kanaka server to transition over from the production server. There is even some steps in the documentation that nicely explain how to migrate from one Kanaka server to the other. I followed the instructions, which were pretty good, except that they said at the end, to stop the first server, to copy the salt.dat file, then uninstall it.
I of course started up the second server while the first was running. So why does it matter? I wish the docs had explained WHY it matter! Well the salt.dat file is XML that looks like:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SaltState>
<Salt>ABCD71232C3ADEF44123417B95C7DD80</Salt>
<TimeStamp>1375387990</TimeStamp>
<IsLowSodium>0</IsLowSodium>
<Account>CN=KanakaProxy.O=acme</Account>
<RightsGroup/>
</SaltState>
As you can see, it has an <Account> node, which has a KanakaProxy.acme object referenced. Well each Kanaka server generates the password for that object. I assume the <Salt> node is somehow a secret used to generate a unique password for the object. I do not think it is the actual password, I think it is a key used to generate a password from.
So when I started up my second server, it reset the password on the shared object, and the first server (the production one, oops) stopped working. It reported an error, in the log file in the /var/opt/novell/kanaka/engine/log directory:
01 2013-08-01 14:29:29 -14400 3 0001 2548 2080 ML: Failed to authenticate as the Proxy Account, Result = 185
.
Hmm, the proxy account cannot log in. That cannot be good. Ok, so how to fix it.
I was lucky enough to get awesome support out of the forums, where one of the support folk was really on the ball and answered my initial request in about 25 minutes! (Faster than I would have waited on hold for support, I imagine!) We had a bit of back and forth before the final answer. Now his first answer was interesting, but he misunderstood my question. Regardless, his answer was very helpful, and in fact is worth recording, because it helps address another difference between NetWare and Linux.
On NetWare, NLMs (NetWare Loadable Modules) had the ability to act as root or admin, or whatever you want to call it. They could attain full permissions since they did not run as a user, rather as a process on the server itself. Linux is very different and does not have such a model per se. Therefore the CIFS.NLM and AFP.NLM could get files on behalf of any object that asked properly, since they could see everything.
In the Linux world, the process needs to run as something, and then it may still need a proxy user to get rights. He misunderstood my issue of Proxy users, in the more common sense of a proxy for AFP or CIFS, not in the KanakaProxy case. One nice thing added in either OES2 SP3 or OES 11, I forget which, is the move to share the proxy user for CIFS, AFS, LUM, NetStorage, whatever else, as a common-proxy user. This was a lot easier as it is easier to manage one than 4, 5 or more accounts.
Thus his advice was something like this.
Proxy user password is stored on the object itself and in the casa credentials as seen under CASAcli -l
You can reset the password on the eDir object as you do with any other user object. You then have to change the password stored for the user in the casa credentials.
See CASAcli -h for help. The bottom reports the following:
KEYVALUE=<cn=admin,o=novell> CASAcli -s -n <MyCredential> -k CN KEYVALUE=<password> CASAcli -s -n <MyCredential> -k Password
Therefore to set the password on a CASA stored credential, you can do something like:
KEYVALUE=mysecret CASAcli -s -n afp-casa -k Password
If you execute CASAcli -l you will see a user named afp-casa. Each service may have its own
casa store.
Thus he was able to explain how to reset the CIFS or AFP proxy passwords. Alas that was not my issue, and once I explained that, he quickly came up with the right answer. In hindsight, I should have thought to go look and find this myself.
This also relies on an understanding of how the Linux init scripts work.
As I noted above, there is a script rcnovell-kanakaengined that is really a short cut to /etc/init.d/novell-kanakaengined, which is a typical init script that takes parameters like, start, stop, status and so on.
It is the 'and so on' part that is key. Go look at that script or any init script and here is the key snippet from it!
Early on they define:
KANAKA_BIN=/opt/${_companyFolder}/${_productFolder}/${_componentFolder}/bin/${_componentBinary}
even earlier on they define the _companyFolder, _productFolder, etc since they sell a Condrey version and a Novell version, so this was a clever way to make their lives easier with variables.
But the key element is a case statement to handle possible values passed into this script. You can see the start, stop, restart, status elements that are pretty common in init scripts. But there is the magical talisman! The proxy-reset option!
# Service switches
case "$1" in
start)
echo -n "Starting Novell Kanaka for Mac Engine "
cert_check
## Start daemon with startproc(8). If this fails
## the return value is set appropriately by startproc.
/sbin/startproc -q $KANAKA_BIN $KANAKA_PARAMS
# Remember status and be verbose
rc_status -v
;;
stop)
echo -n "Shutting down Novell Kanaka for Mac Engine "
## Stop daemon with killproc(8) and if this fails
## killproc sets the return value according to LSB.
/sbin/killproc -TERM -t15 $KANAKA_BIN
# Remember status and be verbose
rc_status -v
;;
restart)
## Stop the service and regardless of whether it was
## running or not, start it again.
$0 stop
$0 start
# Remember status and be quiet
rc_status
;;
status)
echo -n "Checking for service Novell Kanaka for Mac Engine "
## Check status with checkproc(8), if process is running
## checkproc will return with exit status 0.
# Return value is slightly different for the status command:
# 0 - service up and running
# 1 - service dead, but /var/run/ pid file exists
# 2 - service dead, but /var/lock/ lock file exists
# 3 - service not running (unused)
# 4 - service status unknown :-(
# 5--199 reserved (5--99 LSB, 100--149 distro, 150--199 appl.)
# NOTE: checkproc returns LSB compliant status values.
/sbin/checkproc $KANAKA_BIN
# NOTE: rc_status knows that we called this init script with
# "status" option and adapts its messages accordingly.
rc_status -v
;;
proxy-reset)
# If the daemon is currently running, prompt for shutdown
# before going into the proxy-reset mode
/sbin/checkproc $KANAKA_BIN
_running=$?
# An exit code of "0" from checkproc means the specified service is running
if [[ ${_running} -eq 0 ]]; then
echo "The Engine service must be stopped before resetting the proxy account"
echo -n "Shutdown Engine [Y/N]: "
while :
do
read -n 1 _response
case "${_response}" in
[yY]) echo; $0 stop; break ;;
[nN]) exit 0 ;;
esac
done
fi
_default_server=$(hostname)
local _username=
local _password=
echo
echo "Enter a username and password. The username should be entered using"
echo "dotted FDN format and should have full rights to manage the configured"
echo "proxy account for Novell Kanaka for Mac."
echo
read -p "Username: " _username
read -p "Password: " -s _password
echo
echo "Enter the DNS name or IP address of an eDirectory server for this action."
echo "Hit [Enter] to select the default of the local hostname."
echo
read -p "eDirectory Server [${_default_server}]: " _temp_server
if [[ ${_temp_server} != "" ]]; then
_default_server=${_temp_server}
fi
$KANAKA_BIN --force-proxy-reset --default-server:${_default_server} --username:${_username} --password:${_password}
# Restart the service if it was already running.
echo -n "(Re)start service? [Y/N]: "
while :
do
read -n 1 _response
case "${_response}" in
[yY]) echo; $0 start ${_options}; break ;;
[nN]) break ;;
esac
done
echo
# Call rc_status quietly
rc_status
;;
*)
echo "Usage: $0 {start|stop|status|restart|proxy-reset}"
exit 1
;;
esac
There is more to the script, go take a look at your copy. I just excerpted the interesting part for this conversation.
If you read through the proxy-reset option, you will see it does a couple of things. Checks if it is running, stops the process if it is, (Warns you, and gives you a choice too, classy!), gets the username and password for an admin account, takes the current server hostname and lets you override it (Probably relevant in a clustering world) then it calls the main function, and finally restarts the process.
The main function here is:
$KANAKA_BIN --force-proxy-reset --default-server:${_default_server} --username:${_username} --password:${_password}Well we saw KANAKA_BIN is the path to the executable, set earlier and then it passes in the parameters it needs.
So we see that the main Kanaka binary, /opt/novell/kanaka/engine/bin/novell-kanakaengined has a parameter --force-proxy-reset.
What this does is forces Kanaka to use the admin credentials to go do a password change in eDir and change the password it stores in its configuration.
But the next question of interest is, if there is this parameter to the binary, what other ones does it take? So that is easy. Try the --help option. That returns:
acmeSrv:/opt/novell/kanaka/engine/bin # ./novell-kanakaengined --help
The following command line switches are supported:
--svc-install
Installs the program as a native NT service.
Program terminates immediately after performing this task.
Use the "--instance-name" switch if installing a specific
instance of the service.
--svc-uninstall
Uninstalls the program from the native NT service database.
Program terminates immediately after performing this task.
Use the "--instance-name" switch if uninstalling a specific
instance of the service.
--svc-start
Start the native NT service associated with the program.
Program terminates immediately after performing this task.
Use the "--instance-name" switch if starting a specific
instance of the service.
--svc-stop
Stop the native NT service associated with the program.
Program terminates immediately after performing this task.
Use the "--instance-name" switch if stopping a specific
instance of the service.
--log-level:<log-level#>
The logging level must be a valid log_levels_t value from
log_level_fatal [1] thru log_level_debug [8] {or
log_level_developer [9]}. This value will override the value
for logging level that is obtained from the configuration file.
Use only with the "--daemon" switch.
--instance-name:<instance-name>
The instance-name value must not have any spaces or punctuation
characters in it. Restrict the range of values to mixed case
alphanumerics [lower case on Linux].
Use with the "--daemon" switch or the "--svc-*" switches.
--create-dirs
Forces the creation of the data and config directories in the
default location if they do not already exist.
Use with the "--daemon" switch or the "--svc-install"
switch.
--daemon
Run the program's main loop and do normal application
processing. If this switch is missing, the program will not run
as normal. This switch cannot be specified in combination with
any of the "--svc-*" switches.
Use the "--instance-name" switch if running as a specific
instance of the application.
--extend-schema
Attempt to extend the schema. Program terminates
afterward.
If run on Linux in an eDir environment, the --username and
--password switches must be present with valid values to specify
an account to use to perform the password reset, and the
--default-server switch must be present with a valid value.
--force-proxy-reset
Attempt to reset the proxy account password. Program terminates
afterward.
If run on Linux in an eDir environment, the --username and
--password switches must be present with valid values to specify
an account to use to perform the password reset, and the
--default-server switch must be present with a valid value.
--username:<typeful-user-fdn>
The value must be a valid eDir "NDAP" object FDN in dotted
form. If the type information is omitted, default typing rules
will be used [e.g. "CN,OU,O"].
--password:[<password>]
The password that is associated with the object name that was
provided with the --username switch. If the object has no
password, then use the switch without a value trailing after the
switch.
--default-server:<server>
The value of <server> can be a fully qualified DNS host name or
an IP address that identifies the server to which a connection
is established when authenticating to eDirectory.
--not-accepting
Run the program with the engine in "Not Accepting Client
Requests" mode initially.
--help or -?
Display command line switch help information for this program.
02 2013-08-01 20:30:16 0 2 0001 5513 7fb4288ce700 ML: Saved the Salt state information, bResult = 0.
02 2013-08-01 20:30:16 0 2 0001 5513 7fb4288ce700 ML: Completed saving state information, bOK = 0.
Hmm, that is a fair number of switches. Looks like you can force it to extend the schema on demand, force the proxy reset as was discovered already, set the log level, install or uninstall it as a service (when running on Windows).
This is one of the nice things about Linux. Often a fair bit of information is sitting there in your file system that you may not be aware of, but if you think to look, you can find out some interesting things.
Now one of the issues I ran into along the way is that I did not know what should be in the various files. I thought it would be handy to post the contents of mine (Names have been changed to protect the innocent of course)
First off the main config file. This is the one that the /opt/novell/kanaka/engine/bin/novell-kanakaengine-config.sh file seems to mostly configure. Amusingly, if you read that script file, you will see it calls a Java program as the config utility. I suppose that makes it cross platform, which probably makes sense from a supportability perspective.
/etc/opt/novell/kanaka/engine/config/kanaka/conf
<?xml version="1.0" encoding="utf-8"?>
<Config>
<Version>1</Version>
<Engine>
<HostAddress>192.168.1.42</HostAddress>
<HTTPPort>3088</HTTPPort>
<HTTPSPort>3089</HTTPSPort>
<UserSessionTimeout>1800</UserSessionTimeout>
<HTTPXClientTimeout>60</HTTPXClientTimeout>
<DataPath>/var/opt/novell/kanaka/engine/data</DataPath>
<ProxyHomePath>\\SERVER_002\files\users\KanakProxy</ProxyHomePath>
<NeedsSupervisor>0</NeedsSupervisor>
<DefaultServerName>192.168.1.42</DefaultServerName>
<AdminsGroup>CN=KanakaAdmins.O=acme</AdminsGroup>
<IsAccepting>1</IsAccepting>
<NotAcceptingLoginsReason />
<IndexSearchObjects>
<Object>OU=admissions.O=acme</Object>
</IndexSearchObjects>
<IndexRebuildTimes>
<Time>0</Time>
</IndexRebuildTimes>
<IndexSubtree>0</IndexSubtree>
<SRScopedSearch>0</SRScopedSearch>
<SRServers />
<AccessRequestTableSize>1000</AccessRequestTableSize>
<WatchdogInterval>5000</WatchdogInterval>
<WatchdogInterval>5000</WatchdogInterval>
<WaitForDSReadyInterval>5000</WaitForDSReadyInterval>
<WaitForDSReadyRetryLimit>24</WaitForDSReadyRetryLimit>
<WebRoot>/var/opt/novell/kanaka/engine/data/www</WebRoot>
</Engine>
<Logger>
<Path>/var/opt/novell/kanaka/engine/log</Path>
<Level>5</Level>
<RolloverType>2</RolloverType>
<RetentionLimit>10485760</RetentionLimit>
<RetentionCount>10</RetentionCount>
<AdvancedLogging>
<Enabled>1</Enabled>
<Categories>
<CategoryConfig>
<Category>NWXPlat</Category>
<Level>8</Level>
</CategoryConfig>
<CategoryConfig>
<Category>DSTools</Category>
<Level>8</Level>
</CategoryConfig>
</Categories>
</AdvancedLogging>
</Logger>
</Config>
You can see the basic host info, ports, proxy home dir, Admin group. Which is a bit more than the script sets, but also some of the stuff the Config Wizard sets up. The Index Search Objects lists off the containers it is configured to do contextless logins through.
Also there is a Logger session that is where the changes you make in the web interface are recorded.
When you first set up a basic Kanaka instance via the config script you get something like this:
<?xml version="1.0" encoding="utf-8"?>
<Config>
<Version>1</Version>
<Engine>
<HostAddress>192.168.1.42</HostAddress>
<HTTPPort>0</HTTPPort>
<HTTPSPort>3089</HTTPSPort>
<DefaultServerName>server004</DefaultServerName>
<DataPath>/var/opt/novell/kanaka/engine/data</DataPath>
<WebRoot>/var/opt/novell/kanaka/engine/data/www</WebRoot>
</Engine>
<Logger>
<Path>/var/opt/novell/kanaka/engine/log</Path>
<Level>5</Level>
</Logger>
</Config>
Once you start mucking about you get the rest of the data fleshed out.
Then there are the .dat files, in the /var/opt/novell/kanaka/engine/data directory.
client.dat:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ClientManager>
<Clients>
<Client>
<MACAddress>000C93ACB4EC</MACAddress>
<Name>John Smith</Name>
<Active>1</Active>
</Client>
</Client>
</Clients>
</ClientManager>
This file is where the licensed and active workstations are tracked. The web interface will let you disable these, I suppose to minimize license count, if needed.
I trimmed this down to one example to save on space, but you will have one <Client> node set for each workstation.
policy.dat:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Policy>
<FullName>1</FullName>
<UID>1</UID>
<GID>1</GID>
<DefaultGID>20</DefaultGID>
<NoHomeDirectoryAttribute>2</NoHomeDirectoryAttribute>
<HomeDirectoryTest>2</HomeDirectoryTest>
<Shell>/bin/bash</Shell>
<LauchPluginConsoleAtLogin>0</LauchPluginConsoleAtLogin>
<MountUserHDOnDesktop>1</MountUserHDOnDesktop>
<MountGroupHDOnDesktop>1</MountGroupHDOnDesktop>
<DisplayUserHDInDock>1</DisplayUserHDInDock>
<DisplayGroupHDInDock>1</DisplayGroupHDInDock>
<IntegrateWithWGM>1</IntegrateWithWGM>
<EnableSyncAtLogin>0</EnableSyncAtLogin>
<EnableSyncAtLogout>0</EnableSyncAtLogout>
<SyncInterval>0</SyncInterval>
<Mobile>1</Mobile>
<CreateMobileAccountWithDefaultSync>0</CreateMobileAccountWithDefaultSync>
<WarnMobileAccountCreate>0</WarnMobileAccountCreate>
<EnableStorageLocationObjectProcessing>0</EnableStorageLocationObjectProcessing>
<EnableGroupProcessing>1</EnableGroupProcessing>
<EnableContainerProcessing>1</EnableContainerProcessing>
<EnableAuxProcessing>0</EnableAuxProcessing>
<EnableChangePassword>1</EnableChangePassword>
<EnablePasswordExpirationNotice>1</EnablePasswordExpirationNotice>
<EnableLoginScriptParser>1</EnableLoginScriptParser>
<EnableKanakaIDA>1</EnableKanakaIDA>
<DriveMappingDisplayName>Drives</DriveMappingDisplayName>
</Policy>
This is basically reflecting the settings you configured in the web interface. The names are pretty obvious, and this is helpful mostly is showing you what a working set of values might be.
storage-resources.dat:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<STORAGERESOURCES>
<VERSION>2</VERSION>
<LASTREBUILDBEGINTS>1375392205</LASTREBUILDBEGINTS>
<LASTREBUILDENDTS>1375392206</LASTREBUILDENDTS>
<LASTREBUILDSTATUS>0</LASTREBUILDSTATUS>
<DSContextType>2</DSContextType>
<SERVERITEMS>
<SERVERITEM>
<VERSION>1</VERSION>
<GUID>{432CC880-097D-11D8-B79F-00508BCFDC24}</GUID>
<FDN>CN=SERVER_001.O=acme</FDN>
<NETWORKNAME>SERVER_001</NETWORKNAME>
<DNSNAME/>
<OSTYPE>2</OSTYPE>
<OSMAJORVERSION>6</OSMAJORVERSION>
<OSMINORVERSION>50</OSMINORVERSION>
<OSREVISION>3</OSREVISION>
<OSBUILD>1055178</OSBUILD>
<OSVERSION>Server Version: Novell NetWare 5.70.03[DS]; Product Version: 6.50.3; OS Version: 5.70.3; DS Revision: 1055178</OSVERSION>
<OSNAME>OS Vendor: Novell; OS Revison: NetWare 5.70.03; OS Revision Date: May 23, 2005; OS Copyright: (C) Copyright 1983-2005 Novell Inc. All Rights Reserved.</OSNAME>
<LASTSUCCESSFULUPDATETS>1375392205</LASTSUCCESSFULUPDATETS>
<LASTATTEMPTEDUPDATETS>1375392205</LASTATTEMPTEDUPDATETS>
<LASTATTEMPTEDUPDATESTATUS>0</LASTATTEMPTEDUPDATESTATUS>
<ISVIRTUALNODE>0</ISVIRTUALNODE>
<ISCLUSTERMEMBERNODE>0</ISCLUSTERMEMBERNODE>
<IsDFSDomainHost>0</IsDFSDomainHost>
<IS64BIT>0</IS64BIT>
<VOLUMEITEMS>
<VOLUMEITEM>
<VERSION>1</VERSION>
<GUID>{365CA480-097E-11D8-843E-000BCD4FC45E}</GUID>
<LABEL>SYS</LABEL>
<FDN>CN=SERVER_001_SYS.O=acme</FDN>
<SERVERGUID>{432CC880-097D-11D8-B79F-00508BCFDC24}</SERVERGUID>
<FILESYSTEMTYPE>3</FILESYSTEMTYPE>
<FILESYSTEMSUBTYPE>3</FILESYSTEMSUBTYPE>
<MOUNTPOINT>SYS</MOUNTPOINT>
<ATTRIBUTESSUPPORTED>2147483840</ATTRIBUTESSUPPORTED>
<ATTRIBUTESENABLED>0</ATTRIBUTESENABLED>
<LASTSUCCESSFULUPDATETS>1375392205</LASTSUCCESSFULUPDATETS>
<LASTATTEMPTEDUPDATETS>1375392205</LASTATTEMPTEDUPDATETS>
<LASTATTEMPTEDUPDATESTATUS>0</LASTATTEMPTEDUPDATESTATUS>
</VOLUMEITEM>
</VOLUMEITEMS>
<VOLUMENAMEGUIDMAP>
<MAPITEM>
<NAME>CN=ADMIN_SERVER_001.O=acme</NAME>
<GUID>{365CA481-097E-11D8-843E-000BCD4FC45E}</GUID>
</MAPITEM>
</VOLUMENAMEGUIDMAP>
<STORAGEITEMS>
<STORAGEITEM>
<VERSION>1</VERSION>
<STORAGETYPE>3</STORAGETYPE>
<STORAGESUBTYPE>2</STORAGESUBTYPE>
<GUID>{365CA480-097E-11D8-843E-000BCD4FC45E}</GUID>
<NAME>SYS</NAME>
<DESCRIPTION/>
<FDN>CN=SERVER_001_SYS.O=acme</FDN>
<SERVERGUID>{432CC880-097D-11D8-B79F-00508BCFDC24}</SERVERGUID>
<VOLUMEGUID>{365CA480-097E-11D8-843E-000BCD4FC45E}</VOLUMEGUID>
<LOCALPATH>SYS</LOCALPATH>
<NETWORKPATH>SERVER_001/SYS:</NETWORKPATH>
<NetworkPathDNS/>
<DNSNameIsPreferred>0</DNSNameIsPreferred>
<LASTSUCCESSFULUPDATETS>1375392205</LASTSUCCESSFULUPDATETS>
<LASTATTEMPTEDUPDATETS>1375392205</LASTATTEMPTEDUPDATETS>
<LASTATTEMPTEDUPDATESTATUS>0</LASTATTEMPTEDUPDATESTATUS>
<ISRESERVED>0</ISRESERVED>
<ISHIDDEN>0</ISHIDDEN>
<ISDFS>0</ISDFS>
<ISDFSINTEGRATED>0</ISDFSINTEGRATED>
<IsDFSTarget>0</IsDFSTarget>
<ShareFlags>0</ShareFlags>
<DFSPropertyFlags>0</DFSPropertyFlags>
<DFSState>0</DFSState>
<DFSStorageState>0</DFSStorageState>
<HASEXTENDEDINFO>1</HASEXTENDEDINFO>
<DFSLinkTargetMap/>
<DFSLinkCommentMap/>
<DFSRootTargetMap/>
</STORAGEITEM>
</STORAGEITEMS>
<STORAGENAMEGUIDMAP>
<MAPITEM>
<NAME>SYS</NAME>
<GUID>{365CA480-097E-11D8-843E-000BCD4FC45E}</GUID>
</MAPITEM>
</STORAGENAMEGUIDMAP>
</SERVERITEM>
</SERVERITEMS>
</STORAGERESOURCES>
The storage-resources.dat file is where the information about the various servers, and the volumes they have, and how you wish them exposed/translated for the Mac (CIFS or AFP) is stored. This looks a lot more complex than what the NetWare version used to do.
I am not 100% sure what most of the settings mean and are used for, but I excerpted a single server with a single SYS volume for a complete example.
userindex.dat:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<IndexManager>
<LastRebuildBeginTimeStamp>1375401600</LastRebuildBeginTimeStamp>
<LastRebuildEndTimeStamp>1375401607</LastRebuildEndTimeStamp>
<LastRebuildStatus>0</LastRebuildStatus>
<Items>
<Item>CN=jsmith.O=student</Item>
</Items>
</IndexManager>
Finally we have the userindex.dat, where after a dredge (I think it also has been called a census in the past) the list of users found is stored. As before, for the sake of space I excerpted it down to a single users, but expect every user found in the various containers you specified in the IndexSearchObjects nodes in the kanaka.conf file will be stored. So I left only a single user in my example, but there are obviously going to normally be a lot more for you. You will just have many more <Item> nodes.
I hope by examining the files, the scripts, and config files Kanaka uses, it will make troubleshooting your issues easier. If nothing else, it may mean you have an example of what the various files content's should look like, when things are working properly.