[Samba] Using samba4 with kerberos outside of an AD realm

[Kyle Brantley]

Hello --

I'm trying to run a samba4 server (note: Fedora packaged version,
samba-4.0.0-174.fc18.x86_64) under a kerberos realm that isn't AD.

This is a summation of the config that I'm using (works under samba 3.6):

security = ADS
passdb backend = tdbsam
restrict anonymous = yes
server signing = auto
client signing = auto
smb encrypt = auto
realm = MYREALM.COM
kerberos method = system keytab

However, whenever I try to access the samba server, the client fails to
connect. I can see that a ticket has been issued for
cifs/host...@MYREALM.COM, but in /var/log/messages I get this:

Jan 21 11:27:00 elastic smbd[1573]: [2013/01/21 11:27:00.675545, 0]
../auth/kerberos/gssapi_pac.c:116(gssapi_obtain_pac_blob)
Jan 21 11:27:00 elastic smbd[1573]: obtaining PAC via GSSAPI
gss_get_name_attribute failed: The operation or option is not available
or unsupported: No such file or directory
Jan 21 11:27:07 elastic smbd[1574]: [2013/01/21 11:27:07.559656, 0]
../auth/kerberos/gssapi_pac.c:116(gssapi_obtain_pac_blob)
Jan 21 11:27:07 elastic smbd[1574]: obtaining PAC via GSSAPI
gss_get_name_attribute failed: The operation or option is not available
or unsupported: No such file or directory
Jan 21 11:27:07 elastic smbd[1576]: [2013/01/21 11:27:07.643158, 0]
../auth/kerberos/gssapi_pac.c:116(gssapi_obtain_pac_blob)
Jan 21 11:27:07 elastic smbd[1576]: obtaining PAC via GSSAPI
gss_get_name_attribute failed: The operation or option is not available
or unsupported: No such file or directory

Well, no kidding there is no PAC available, it's an MIT kerberos realm! :)

Does anyone know what I need to be doing to get this working again?

--Kyle
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Andrew Bartlett]

It is probably a bug in the reworked krb5 code. The code paths to
support this are still there, but clearly something doesn't trigger
correctly.

The first thing to do would be to turn up the log level, to see what the
real failure is (the mentioned message shouldn't actually be fatal).

Then, once we rule out it being something else, it probably just needs a
new test environment to be created in our 'make test' that tells our AD
server to not send the PAC. This will allow this code path to be
covered, and prevent regressions.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

[Kyle Brantley]

As far as I can tell, prior to accepting a connection:

dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.AVERAGEURL.COM
(Success)
ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL)
[ ... ]
Could not look up dc's for domain AVERAGEURL.COM
ads_connect: leaving with: No logon servers

Those records (*._msdcs.) don't exist all right...

And while the socket is connected:

Starting GENSEC mechanism spnego
Starting GENSEC submechanism gse_krb5
name_to_fqdn: lookup for ELASTIC failed. /* Reverse DNS and forward DNS
IS resolving properly here... one thing to note: this is an IPv6 only
host */
Security token: (NULL)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0

obtaining PAC via GSSAPI gss_get_name_attribute failed: The operation or
option is not available or unsupported: No such file or directory

Unable to find PAC in ticket from ky...@AVERAGEURL.COM, failing to allow
access

Checking the process with strace isn't really useful either, unfortunately:

open("/etc/krb5.keytab", O_RDONLY) = 33
[ ... ]
open("/dev/urandom", O_RDONLY) = 33
open("/dev/urandom", O_RDONLY) = 33
open("/dev/urandom", O_RDONLY) = 33
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 33
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
[ ... ]
open("/usr/share/locale/en_US/LC_MESSAGES/mit-krb5.mo", O_RDONLY) = 33
[ ... ]
open("/var/tmp/cifs_0", O_RDWR) = 33
open("/usr/lib64/krb5/plugins/authdata/sssd_pac_plugin.so",
O_RDONLY|O_CLOEXEC) = 35
open("/dev/urandom", O_RDONLY) = 34
open("/dev/urandom", O_RDONLY) = 34
open("/dev/urandom", O_RDONLY) = 34

obtaining PAC via GSSAPI gss_get_name_attribute failed: The operation or
option is not available or unsupported: No such file or directory

open("/etc/krb5.conf", O_RDONLY) = 33
open("/dev/urandom", O_RDONLY) = 33
open("/etc/krb5.conf", O_RDONLY) = 33
open("/dev/urandom", O_RDONLY) = 33
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=958, si_uid=0} ---
+++ killed by SIGTERM +++


Full logs:
http://averageurl.com/samba/samba-log.gz
http://averageurl.com/samba/samba-strace-log.gz

I've already changed the keys out, so I'm not too worried about what key
data is actually in those logs.

--Kyle

[Andrew Bartlett]

> Full logs:
> http://averageurl.com/samba/samba-log.gz
> http://averageurl.com/samba/samba-strace-log.gz
>
> I've already changed the keys out, so I'm not too worried about what key
> data is actually in those logs.

The logs were very helpful. The attached patch should fix it, or at
least move the failure to somewhere else :-). Please file the bug, so
we can get this into 4.0.2

[Kyle Brantley]

Thanks. I've filed the bug
(https://bugzilla.samba.org/show_bug.cgi?id=9581) and am currently
rebuilding samba with the patch applied. I'll let you know how it goes...

[Kyle Brantley]

That worked great. I've been able to enumerate the shares and connect to
them now. I validated with wireshark that the kerberos authentication
was occurring, and it looks like everything functions now thanks to your
previously attached patch.

Thanks much!

[Andrew Bartlett]

Metze, Can you get this into master? I'll try and follow-up with a
testcase (setting the UF_NO_AUTH_DATA_REQUIRED on an account and doing a
kerberos login) soon, but this much needs to get to 4.0.2