Hi,
I just installed 3.0.2rc1 for testing, and I came across a problem with
cross-realm authentication. I joined samba to our active directory
domain, and I can see that it has host and cifs principals in windows
kerberos. Our organization's primary kerberos realm (CEDE.PSU.EDU) is an
MIT kerb5 realm, and we have a one-way non-transitive trust such that
windows (server 2003) kerberos (WIN.CEDE.PSU.EDU) is slaved to our MIT
realm. We have a cross-realm test account called 'krbtest' that has a
kerberos principal mapping defined in AD. The test sun server's name is
'alcor'. If I do the following, everything works as expected:
kinit krbtest@WIN.CEDE.PSU.EDU
smbclient //alcor/krbtest -k
Furthermore, if I do the following, everything is still ok:
kinit krbtest@CEDE.PSU.EDU
smbclient //alcor/krbtest -k
However, my own account is not a kerberos mapped principal in AD for
security reasons. If I do the following, the results are troubling:
kinit tkeiser@CEDE.PSU.EDU
smbclient //alcor/tkeiser -k
Obviously, this should fail since cross-realm trust into AD requires an
explicit principal mapping (we don't turn on the map all principals
option). However, instead of dealing with this gracefully, smbd
segfaults! Interestingly, if I do a klist afterwards, I've managed to
acquire a cross-realm tgt and a service ticket for alcor$@WIN.CEDE.PSU.EDU
even though my prinipal isn't mapped. Here's a snippet of debug level
10
output from smbd:
[2004/01/28 02:23:56, 3] smbd/process.c:(685)
switch message SMBsesssetupX (pid 27145)
[2004/01/28 02:23:56, 3] smbd/sec_ctx.c:(288)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2004/01/28 02:23:56, 5] auth/auth_util.c:(486)
NT user token: (NULL)
[2004/01/28 02:23:56, 5] auth/auth_util.c:(505)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
[2004/01/28 02:23:56, 5] smbd/uid.c:(218)
change_to_root_user: now uid=(0,0) gid=(0,0)
[2004/01/28 02:23:56, 3] smbd/sesssetup.c:(638)
wct=12 flg2=0xc801
[2004/01/28 02:23:56, 3] smbd/sesssetup.c:(518)
Doing spnego session setup
[2004/01/28 02:23:56, 3] smbd/sesssetup.c:(549)
NativeOS=[Unix] NativeLanMan=[Samba] PrimaryDomain=[]
[2004/01/28 02:23:56, 3] smbd/sesssetup.c:(427)
Got OID 1 2 840 48018 1 2 2
[2004/01/28 02:23:56, 3] smbd/sesssetup.c:(427)
Got OID 1 3 6 1 4 1 311 2 2 10
[2004/01/28 02:23:56, 3] smbd/sesssetup.c:(430)
Got secblob of size 492
[2004/01/28 02:23:56, 10] passdb/secrets.c:(698)
secrets_named_mutex: got mutex for replay cache mutex
[2004/01/28 02:23:56, 10] libads/kerberos_verify.c:(323)
ads_verify_ticket: enc type [18] failed to decrypt with error Bad
encryption type
[2004/01/28 02:23:56, 10] libads/kerberos_verify.c:(323)
ads_verify_ticket: enc type [16] failed to decrypt with error Bad
encryption type
[2004/01/28 02:23:56, 10] libads/kerberos_verify.c:(316)
ads_verify_ticket: enc type [23] decrypted message !
[2004/01/28 02:23:56, 10] passdb/secrets.c:(710)
secrets_named_mutex: released mutex for replay cache mutex
[2004/01/28 02:23:56, 10] libsmb/clikrb5.c:(386)
Got KRB5 session key of length 16
[2004/01/28 02:23:56, 0] lib/fault.c:(36)
==============================================================[2004/01/28
02:23:56, 0] lib/fault.c:(37)
INTERNAL ERROR: Signal 11 in pid 27145 (3.0.2rc1)
Please read the appendix Bugs of the Samba HOWTO collection
[2004/01/28 02:23:56, 0] lib/fault.c:(39)
==============================================================[2004/01/28
02:23:56, 0] lib/util.c:(1400)
PANIC: internal error
In case it matters, the build environment is Solaris 9 9/03 and Sun ONE
Studio 8. My optimization flags were "-x03 -xarch=v8plusa
-xchip=ultra2".
I linked against openldap 2.1.22, mit-krb5 1.3.1, and cups 1.1.20 all from
blastwave.com's pkg-get archive. The configure flags were:
--with-pam --with-acl-support --with-ads --with-ldap --with-krb5=/opt/csw
I attached to smbd with dbx in follow child on fork mode, and here's what
I got:
Attached to process 27186
t@1 (l@1) stopped in _libc_poll at 0xfed1ca1c
0xfed1ca1c: _libc_poll+0x0004: ta %icc,%g0 + 8
(dbx) cont
detaching from process 27186
Attached to process 27621
t@1 (l@1) stopped in __fork at 0xfeeb5ec8
0xfeeb5ec8: __fork+0x0008: bgeu __fork+0x30
(dbx) cont
t@1 (l@1) signal SEGV (no mapping at the fault address) in
get_auth_data_from_tkt at 0xcc92c
0x000cc92c: get_auth_data_from_tkt+0x0018: ld [%i4], %i2
(dbx) gdb on
(dbx) bt
current thread: t@1
=>[1] get_auth_data_from_tkt(0xffbfe518, 0x468350, 0x10, 0xffbfd5c4, 0x0,
0x469848), at 0xcc92c
[2] ads_verify_ticket(0x0, 0x3d2b10, 0xffbfe4ec, 0x390400, 0xffbfe50c,
0xffbfe4e0), at 0x21ccd4
[3] reply_spnego_kerberos(0x0, 0x4276b0, 0x447b00, 0xffbfe530, 0x0,
0xffbfe5d4), at 0x9705c
[4] reply_spnego_negotiate(0x0, 0x4276b0, 0x447b00, 0x278, 0x20000,
0xffbfe5e8), at 0x97b94
[5] reply_sesssetup_and_X_spnego(0x0, 0x4276b0, 0x447b00, 0x278,
0x20000, 0xc), at 0x98068
[6] reply_sesssetup_and_X(0x0, 0x4276b0, 0x447b00, 0x278, 0x20000,
0x3b1c00), at 0x98334
[7] switch_message(0x447b00, 0x0, 0x447b00, 0x278, 0x20000, 0x3b0800),
at 0xba510
[8] construct_reply(0x4276b0, 0x447b00, 0x278, 0x20000, 0x3b2800, 0x0),
at 0xba61c
[9] process_smb(0x4276b0, 0x447b00, 0x1, 0x278, 0x3bd8d4, 0x3b1f30), at
0xba9b8
[10] smbd_process(0x0, 0xea60, 0x93a80, 0x0, 0x0, 0x3b0800), at 0xbb674
[11] main(0x3b3800, 0x3b3800, 0x3b1f30, 0x0, 0x395400, 0x3b3800), at
0x2285c4
(dbx)
If anybody wants more information about my setup in order to reproduce the
problem, let me know. My apologies if this is a duplicate problem report;
I looked in bugzilla and on the list archives and didn't see anything.
Other than this troubling little potential security issue, everything is
working wonderfully. Congratulations on an excellent job with samba 3!
Regards,
____________________________________________________
Tom Keiser
Senior UNIX and Network Systems Administrator
The Center for Engineering Design & Entrepreneurship
213Q Hammond Building
tkeiser@cede.psu.edu
