OmniOS + napp-it, krb5.keytab not found

[Soeren Larsen]

Hi

I am running OmniOS (r151014 at f090f73) with napp-it 0.9f6 ontop.

When joining the server to our Active Directory domain log entries like the one below show up multiple times every 10 minutes:

idmap[X]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Key table file '/etc/krb5/krb5.keytab' not found)

I had the same issue a few months back when first getting started with OmniOS and napp-it. Leaving the domain stops the error/warning logging.

Anyone else experiencing this and willing to share some insights on why this happens and what to do about it?

 

[nle]

Could be this will help you solve your issue, a bit dated, but it seems to be a solution to the same problem.

(and welcome to the forums btw.)

 

[Soeren Larsen]

Thank you for the welcome.

I think I will elaborate a bit on what I have done and what I expected to happen.

This is a clean (test) installation of OmniOS and napp-it. I followed the simple (and to the point guide) by @gea here on initial OmniOS setup and installation of napp-it: napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : OmniOS

Right after installing napp-it, I rebooted the server and logged into the napp-it interface.
From here I used napp-it to join the AD domain and I then started seeing the log errors.

I would have expected napp-it to create the /etc/krb5/krb5.keytab file and add the missing host/<hostname>@realm entry. Seeing the log error multiple times repeated every 10 minutes is not comforting.

 

[gea]

Main problem is that the AD mechanism of Illumos is not updated for a long time.
Currently there is a lot of work at Illumos to add SMB 2.1 and to improve AD/ Kerberos support

These updates are on the way.
Currently I would just ignore the console warnings.

read the following mail from Illumos dev from last week

Thanks to help from authors (there were many!) and reviewers and
advocates, the SMB server can now do normal, Active Directory
(AD)-style authentication, using connection-less LDAP queries to find
the correct AD server, using Kerberos to authenticate the client, etc.
This also closes a four year old bug:
Bug #1087: Unable to connect to the CIFS server using \\servername.fqdn - illumos gate - illumos.org

This push represents quite a bit of work beyond what was in the
original OpenSolaris code. The changes add up to over ten thousand
lines of new code, or about fifteen thousand changed lines (according
to webrev).

One caution: After this, quite a lot of the on-line "advice" you'll
find about administering the SMB service is out of date and now wrong.
In particular, advice about OpenSolaris and adjusting lmauth_level no
longer applies to illumos. Similarly, one should now _disregard_
advice about changes on the Windows side to "dumb down" the security
levels it uses to connect to our SMB service, because we now can do
full Kerberos authentication etc.

Thanks to Nexenta Systems (www.nexenta.com) for supporting the effort
to upstream this major piece of work.

Gordon Ross

or
Feature #6399: SMB2 support - illumos gate - illumos.org
Feature #6352: Updated DC locator for SMB and idmap - illumos gate - illumos.org
Bug #6398: SMB should support path names longer than 1024 - illumos gate - illumos.org

 

[Soeren Larsen]

Thank you @gea - it seems the future is looking bright on this one.

In the meantime I found this fine blog post after a ton of searches and I will use it as a temporary fix for now.
Basicly the "solution" was to generate a keytab (for the OmniOS server) on the Windows domain controller and copy it over.