Re: Kerberos Authentication question(s)
On Wed, Jun 24, 2015 at 2:07 PM, Albert C. Baker III wrote:
> I am using the Java class org.apache.hadoop.security.
> authentication.server.AuthenticationFilter from Apache
> Hadoop 2.5.0 as a filter in front of a Tomcat 6 Servlet we
> wish to add Kerberos authentication to.
>
> I am attempting to write some test cases against this filter
> so that we have a better understanding of how it
> works and what it does.
>
> In order for the filter to authenticate a user, it is reading the
> 'Authorization' header of the HTTP request,
> expecting the value to contain 'Negotiate '
>
> My understanding of how Kerberos works leads me to believe that I
> should be able to write code while creating my
> HTTP request that looks something like this:
>
> // normally the server principal keytab is not available from the
> client side,
> // but for the purpose of making test cases I see no problem with
> sharing the keytab
> // between the client side and the server side
> javax.security.auth.kerberos.Keytab kt = KeyTab.getInstance("keytab");
> KerberosKey keys[] = kt.getKeys("HTTP/voltage-pp-
> .albert@alberts.int");
Hi Albert,
This *should* be possible but unfortunately it's not. Last I checked
(which was probably several years ago), you actually cannot initiate
Kerberos authentication from just a raw Kerberos key using the builtin
Java API in a platform independent way. Specifically, on Windows you
MUST use the Kerberos LoginModule to "login" first. Otherwise, you
will get an error when you try to use the security context. The above
code would work fine on non-Windows platforms like Linux but on
Windows, the builtin Java Kerberos library uses the Windows credential
cache and SSPI (the security API for Windows) so that the Java program
will use the system credential cache (instead of a ccache file),
identity of the user and existing system Kerberos configuration. In
theory it should still be possible to initiate auth using only a
Kerberos key like in your code but again, last I checked, it
unfortunately does not work and I have no explanation as to why other
than to recall that the builtin Java Kerberos library has been a point
of criticism and outright failure since forever (although it has
gotten better over the years). Note that the reason the Windows SSPI
is used by Java is largely because there is otherwise no way to insert
credentials into the Windows credential cache. It actually used to be
possible but at some point early on MS decided this was probably not a
good idea and so now Java and MIT or Heimdal or whoever cannot insert
creds into the Windows credential cache. They have to just use the
Windows Kerberos SSPI.
> SomeTokenType token = new SomeTokenType();
>
>
> // my understanding of Kerberos is that the only cyphertext key
> // needed on this token
> // is one of the server principal's keys from the Keytab file
> // (which does contain ~5
> // keys of different sizes and types, I've checked)
> EncryptedTokenType etoken =
> byte[] array = etoken.getBytes();
First, note that the "token" in the Authorization / WWW-Authenticate
headers in HTTP are not quite the same as the "token" as defined in
the Kerberos protocol documentation. Technically, the HTTP "token" is
the Base64 encoded product of the InitializeSecurityContext function
of the Microsoft Windows SSPI of which there are several but could be
Kerberos or NTLM but in practice almost always SPNEGO which is a
little binary wrapper used to NEGOtiate Keberos or NTLMSSP where
NTLMSSP is a little binary wrapper around NTLM. Lost yet? Anyway, with
respect to Windows HTTP clients (including Firefox and Chrome running
on Windows which just tap into the Windows SSPI), the HTTP "token" is
almost certainly an SPNEGO token. However, if you're just trying to
initiate authentication (meaning you're the client), you can
*probably* skip SPNEGO and feed the server a raw Kerberos token. At
least Windows servers like IIS should detect this and handle it
correctly. And Apache's mod_auth_kerb would almost certainly handle it
correctly as well.
Regarding the keytab, yes, it contains the target principal keys
although technically you only need the one with the principal name
that matches the target you're trying to authenticate with
(HTTP/www.example.com).
> httprequest.addHeader("Authorization","Negotiate " + new
> Base64(0).encode(array));
>
> So, questions here:
> 1) What is the Java Class that embodies the Kerberos Auth Token sent
> in "Authorization Negotiate"?
Again I am not familiar with your "token" code but fortunately, even
though the Authorization: Negotiate ... token is an Internet
Explorer-ism, it's SPNEGO payload is largely compatible with the
Kerberos token and more generally the GSSAPI token where GSSAPI is the
RFC definition of this type of authentication which is meaningful
because JGSS is the Java implementation of this and this is a run-on
sentence. Meaning GSSAPI's GSS_Init_sec_context() is largely
compa
Re: help with persistent ccache
Thanks again Brandon.
Yes I know that the PAM module is linked against libraries pre 1.12 that
don't support the persistent option. These are different from the system
libraries that sshd is linked against.
I'm going to work on seeing if updating those libraries fixes this, or if I
can use a different PAM module that is using more up to date libraries.
I'll try to update this when that happens, but it may be a while off. For
now I think we will be reverting to the FILE based cache.
On Wed, Jun 24, 2015 at 3:35 PM, Brandon Allbery
wrote:
> Hard to say, but I would expect the keyring interaction to be in the
> Kerberos libraries so a problem at that level might indicate that the
> PAM module is linked against a different version of the Kerberos
> libraries. This would seem unlikely if it is using shared libraries
> (which you can check with ldd).
>
> It is more likely that the correct context for the keyring is not yet
> established when the PAM session stack is run, so it is either creating
> the keyring but in the wrong place (keychain) or getting an error while
> trying to create it. This would be controlled by when sshd runs the PAM
> session stack relative to other parts of session establishment, and
> might depend on details of how the Linux keychain is associated with a
> user process. It could also be related to recent sshd features such as
> sandboxing, where the keyring might e.g. be created inside the sandbox
> instead of in the user session.
>
> (It also would not be the first time that sshd turned out to do things
> slightly incorrectly; in the (somewhat distant) past this has led to
> file ccaches owned by root, for example.)
>
>
> On Wed, 2015-06-24 at 15:27 -0500, Ben H wrote:
> > Thanks for the quick reply Brandon.
> >
> >
> > I don't have this issue if I remove the "default_ccache_name =
> > KEYRING:persistent:%{uid}" and thus default back to the file based
> > cache. In that case, the cache is created properly on login in /tmp,
> > That would indicate to me that PAM is properly creating a cache.
> >
> >
> > Would this indicate that it isn't the PAM stack not creating the cache
> > or would it more likely be the PAM module not utilizing the keyring
> > properly? Or perhaps the PAM module doesn't understand how to work
> > with the keyring?
> >
> >
> > thanks.
> >
> >
> >
> > On Wed, Jun 24, 2015 at 3:21 PM, Brandon Allbery
> > wrote:
> > On Wed, 2015-06-24 at 15:10 -0500, Ben H wrote:
> > > Why is not cached initialized on interactive login and an
> > additional
> > > manual
> > > kinit is required?
> >
> > This may have nothing to do with keyring ccache, but only with
> > a
> > misconfigured PAM stack that is not creating a ccache with the
> > ticket
> > from login.
> >
> > Alternately it could mean that login is running the session
> > PAM stack in
> > the wrong context, so the wrong keyring is created. I would
> > check the
> > first part before trying to diagnose the second, though.
> >
> > --
> > brandon s allbery kf8nh sine nomine
> > associates
> > allber...@gmail.com
> > ballb...@sinenomine.net
> > unix openafs kerberos infrastructure xmonad
> > http://sinenomine.net
> >
> >
> > Kerberos mailing list Kerberos@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
>
> --
> brandon s allbery kf8nh sine nomine associates
> allber...@gmail.com ballb...@sinenomine.net
> unix openafs kerberos infrastructure xmonadhttp://sinenomine.net
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
RE: pkinit makes application crash
Hi Ben, thanks for the quick response. > > On Wed, 24 Jun 2015, Osipov, Michael wrote: > > > Hi folks, > > > > we are trying to perform some LDAP requests with Perl against Active > Directory > > with Kerberos auth by MIT Kerberos. > > A core file is dumped and following written to stderr: > > $ ./ldap.pl > > Assertion failed: __thread_init == NULL, file > ../../../../../core/libs/libc/shared_em_32_perf/../core/threads/pthread_st > ubs1.c, line 1045 > > Abbruchkommando (Speicherabzug geschrieben) > > > > I first have assumed that the Perl module is broken but I guess it > isn't?! > > Loading the core file into GDB gives me: > > > == > = > > (gdb) where > > #0 0x6000c020f6d0:0 in _lwp_kill+0x30 () > >from /usr/lib/hpux32/libpthread.so.1 > > #1 0x6000c0174be0:0 in pthread_kill+0x9f0 () > >from /usr/lib/hpux32/libpthread.so.1 > > #2 0x6000c0403460:0 in raise+0xe0 () from /usr/lib/hpux32/libc.so.1 > > #3 0x6000c05277b0:0 in abort+0x170 () from > /usr/lib/hpux32/libc.so.1 > > #4 0x6000c03ce5f0:0 in _assert+0x260 () from > /usr/lib/hpux32/libc.so.1 > > #5 0x6000c0590980:0 in pthread_once+0x80 () from > /usr/lib/hpux32/libc.so.1 > > #6 0x6000c4bab160:0 in pkinit_init_plg_crypto () > > at pkinit_crypto_openssl.c:410 > > This pthread_once() stuff is in the library initializor for pkinit's use > of openssl, thought it's not immediately clear what assertion is being > made in the innards of libc. The fact that the file named in the > assertion failure message is named pthread_stubs1.c makes me wonder if > there is an issue with an executable which was not compiled as threaded > (i.e., is compiled to use the stub implementation) then loaded an object > which uses the pthread interfaces, but that is basically pure speculation. > I don't have enough experience with HP-UX to have any sense of how > plausible that might be. Based on your explanation, I have made some digging: The Perl installation provided by HP says (perl -V) it is multithreaded. After that I have recompiled and lined the GSSAPI Perl module against 1.13.1. According to HP's compiler options -mt has to be passed. I have added that to the Makefile. Calling gss_init_sec_context from Perl gives me the same crash. So I guess, some C binding from Perl isn't multithreading aware. [1] Unfortunately, I cannot go further than that because my experience stops here. > [...] > > As a workaround, I would recompile MIT Kerberos on all servers without > pkinit > > for now. > > That workaround seems advisable for now. At least I have one now. Maybe someone else will share some wisdom on that. Thank you a lot, Michael [1] http://search.cpan.org/~perigrin/HTTP-Thin-UserAgent-0.011/local/lib/perl5/darwin-2level/Net/SSLeay.pod#Combining_Net::SSLeay_with_other_modules_linked_with_openssl Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: help with persistent ccache
Hard to say, but I would expect the keyring interaction to be in the
Kerberos libraries so a problem at that level might indicate that the
PAM module is linked against a different version of the Kerberos
libraries. This would seem unlikely if it is using shared libraries
(which you can check with ldd).
It is more likely that the correct context for the keyring is not yet
established when the PAM session stack is run, so it is either creating
the keyring but in the wrong place (keychain) or getting an error while
trying to create it. This would be controlled by when sshd runs the PAM
session stack relative to other parts of session establishment, and
might depend on details of how the Linux keychain is associated with a
user process. It could also be related to recent sshd features such as
sandboxing, where the keyring might e.g. be created inside the sandbox
instead of in the user session.
(It also would not be the first time that sshd turned out to do things
slightly incorrectly; in the (somewhat distant) past this has led to
file ccaches owned by root, for example.)
On Wed, 2015-06-24 at 15:27 -0500, Ben H wrote:
> Thanks for the quick reply Brandon.
>
>
> I don't have this issue if I remove the "default_ccache_name =
> KEYRING:persistent:%{uid}" and thus default back to the file based
> cache. In that case, the cache is created properly on login in /tmp,
> That would indicate to me that PAM is properly creating a cache.
>
>
> Would this indicate that it isn't the PAM stack not creating the cache
> or would it more likely be the PAM module not utilizing the keyring
> properly? Or perhaps the PAM module doesn't understand how to work
> with the keyring?
>
>
> thanks.
>
>
>
> On Wed, Jun 24, 2015 at 3:21 PM, Brandon Allbery
> wrote:
> On Wed, 2015-06-24 at 15:10 -0500, Ben H wrote:
> > Why is not cached initialized on interactive login and an
> additional
> > manual
> > kinit is required?
>
> This may have nothing to do with keyring ccache, but only with
> a
> misconfigured PAM stack that is not creating a ccache with the
> ticket
> from login.
>
> Alternately it could mean that login is running the session
> PAM stack in
> the wrong context, so the wrong keyring is created. I would
> check the
> first part before trying to diagnose the second, though.
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix openafs kerberos infrastructure xmonad
> http://sinenomine.net
>
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix openafs kerberos infrastructure xmonadhttp://sinenomine.net
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: help with persistent ccache
Thanks for the quick reply Brandon.
I don't have this issue if I remove the "default_ccache_name = KEYRING:
persistent:%{uid}" and thus default back to the file based cache. In that
case, the cache is created properly on login in /tmp,
That would indicate to me that PAM is properly creating a cache.
Would this indicate that it isn't the PAM stack not creating the cache or
would it more likely be the PAM module not utilizing the keyring properly?
Or perhaps the PAM module doesn't understand how to work with the keyring?
thanks.
On Wed, Jun 24, 2015 at 3:21 PM, Brandon Allbery
wrote:
> On Wed, 2015-06-24 at 15:10 -0500, Ben H wrote:
> > Why is not cached initialized on interactive login and an additional
> > manual
> > kinit is required?
>
> This may have nothing to do with keyring ccache, but only with a
> misconfigured PAM stack that is not creating a ccache with the ticket
> from login.
>
> Alternately it could mean that login is running the session PAM stack in
> the wrong context, so the wrong keyring is created. I would check the
> first part before trying to diagnose the second, though.
>
> --
> brandon s allbery kf8nh sine nomine associates
> allber...@gmail.com ballb...@sinenomine.net
> unix openafs kerberos infrastructure xmonadhttp://sinenomine.net
>
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: help with persistent ccache
On Wed, 2015-06-24 at 15:10 -0500, Ben H wrote: > Why is not cached initialized on interactive login and an additional > manual > kinit is required? This may have nothing to do with keyring ccache, but only with a misconfigured PAM stack that is not creating a ccache with the ticket from login. Alternately it could mean that login is running the session PAM stack in the wrong context, so the wrong keyring is created. I would check the first part before trying to diagnose the second, though. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix openafs kerberos infrastructure xmonadhttp://sinenomine.net Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
help with persistent ccache
I'm trying to understand how the newer KEYRING:persistent cache is working
in relation to interactive and GSSAPI SSO.
Using Centos 6.4 and 7.1.
My 7.x box is using the default configuration of:
default_ccache_name = KEYRING:persistent:%{uid}
Please take a look at the below session. What we see is that when
performing an interactive login (no tickets) from centos64 to centos71, a
persistent cache is seemingly not created (or at least not found).
However, if I initialize a ticket via kinit for my user and then SSH using
GSSAPI it appears to have initialized the persistent cache.
Obviously this is problematic because it means the first interactive login
to a 7.x box fails to create a cache and thus can't get a ticket for future
SSO operations.
It appears that if I manually kinit following the first login the
persistent cache is created.
Why is not cached initialized on interactive login and an additional manual
kinit is required?
thanks!
[root@centos64-01 ~]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
[root@centos64-01 ~]# ssh sppu...@centos71-01.spptech.com
Password:
Last login: Wed Jun 24 14:59:06 2015 from centos64-01.spptech.com
[sppuser@centos71-01 ~]$ klist
klist: Credentials cache keyring 'persistent:402243354:402243354' not found
[sppuser@centos71-01 ~]$ exit
logout
Connection to centos71-01.spptech.com closed.
[root@centos64-01 ~]# kinit sppuser
Password for sppu...@spptech.com:
[root@centos64-01 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: sppu...@spptech.com
Valid starting ExpiresService principal
06/24/15 14:59:34 06/25/15 00:59:37 krbtgt/spptech@spptech.com
renew until 07/01/15 14:59:34
[root@centos64-01 ~]# ssh sppu...@centos71-01.spptech.com
Last login: Wed Jun 24 14:59:21 2015 from centos64-01.spptech.com
[sppuser@centos71-01 ~]$ klist
Ticket cache: KEYRING:persistent:402243354:402243354
Default principal: sppu...@spptech.com
Valid starting Expires Service principal
06/24/2015 14:59:49 06/25/2015 00:59:37 krbtgt/spptech@spptech.com
renew until 07/01/2015 14:59:34
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: pkinit makes application crash
On Wed, 24 Jun 2015, Osipov, Michael wrote: > Hi folks, > > we are trying to perform some LDAP requests with Perl against Active Directory > with Kerberos auth by MIT Kerberos. > A core file is dumped and following written to stderr: > $ ./ldap.pl > Assertion failed: __thread_init == NULL, file > ../../../../../core/libs/libc/shared_em_32_perf/../core/threads/pthread_stubs1.c, > line 1045 > Abbruchkommando (Speicherabzug geschrieben) > > I first have assumed that the Perl module is broken but I guess it isn't?! > Loading the core file into GDB gives me: > === > (gdb) where > #0 0x6000c020f6d0:0 in _lwp_kill+0x30 () >from /usr/lib/hpux32/libpthread.so.1 > #1 0x6000c0174be0:0 in pthread_kill+0x9f0 () >from /usr/lib/hpux32/libpthread.so.1 > #2 0x6000c0403460:0 in raise+0xe0 () from /usr/lib/hpux32/libc.so.1 > #3 0x6000c05277b0:0 in abort+0x170 () from /usr/lib/hpux32/libc.so.1 > #4 0x6000c03ce5f0:0 in _assert+0x260 () from /usr/lib/hpux32/libc.so.1 > #5 0x6000c0590980:0 in pthread_once+0x80 () from > /usr/lib/hpux32/libc.so.1 > #6 0x6000c4bab160:0 in pkinit_init_plg_crypto () > at pkinit_crypto_openssl.c:410 This pthread_once() stuff is in the library initializor for pkinit's use of openssl, thought it's not immediately clear what assertion is being made in the innards of libc. The fact that the file named in the assertion failure message is named pthread_stubs1.c makes me wonder if there is an issue with an executable which was not compiled as threaded (i.e., is compiled to use the stub implementation) then loaded an object which uses the pthread interfaces, but that is basically pure speculation. I don't have enough experience with HP-UX to have any sense of how plausible that might be. > What we would like to do: > Use Net::LDAP with uses Authen::SASL which in turn calls Authen::SASL::XS with > a Perl to C binding against Cyrus SASL. The very same happens when > Authen::SASL::Perl > with GSSAPI module is used: failure. This must be some generic incompat. > All calls are performed with an empty ticket cache (non-default location as > once > advised by Greg Hudson) and a client keytab. > Using an interactive ticket cache makes the entire stuff work, so client > ticket > makes it crash. We do not use PKINIT at all. > Interesting to say that the very same LDAP request works with ldapsearch(1) > and a minimal C app with libldap. > > Any ideas? Can this be some interference with Perl and preinit of OpenSSL? Not necessarily perl itself, but this is quite plausible. The motivation for switching to library initializers for the openssl calls is discussed in http://krbdev.mit.edu/rt/Ticket/Display.html?id=6413 , but in general, openssl is not amenable to having multiple library consumers in a given application. I was not directly involved in this work, so it is possible that someone else (Greg?) may have more insights to offer. > As a workaround, I would recompile MIT Kerberos on all servers without pkinit > for now. That workaround seems advisable for now. -Ben Kaduk Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Kerberos Authentication question(s)
> From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf > Of Albert C. Baker III > Sent: Wednesday, June 24, 2015 8:08 PM > To: kerberos@mit.edu > Subject: Kerberos Authentication question(s) > [...] > Any leads on how to figure this out would be greatly appreciated! Hi Albert, this is probably the wrong mailing list to ask because this is about Kerberos in general and MIT Kerberos, not linked to JGSS. From your Code, you are using private APIs from Oracle. If you trying to have SPNEGO authentication on your Tomcat 6 instance, I can provide you a ready-to-go library for that. In general, tokens are opaque and should be treated as such. I have mostly given up writing portable JUnit test code with JGSS. All you can do is, write a mock GSSManager which creates mocked objects. Feel free to contact me directly. Michael Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
pkinit makes application crash
Hi folks, we are trying to perform some LDAP requests with Perl against Active Directory with Kerberos auth by MIT Kerberos. A core file is dumped and following written to stderr: $ ./ldap.pl Assertion failed: __thread_init == NULL, file ../../../../../core/libs/libc/shared_em_32_perf/../core/threads/pthread_stubs1.c, line 1045 Abbruchkommando (Speicherabzug geschrieben) I first have assumed that the Perl module is broken but I guess it isn't?! Loading the core file into GDB gives me: === (gdb) where #0 0x6000c020f6d0:0 in _lwp_kill+0x30 () from /usr/lib/hpux32/libpthread.so.1 #1 0x6000c0174be0:0 in pthread_kill+0x9f0 () from /usr/lib/hpux32/libpthread.so.1 #2 0x6000c0403460:0 in raise+0xe0 () from /usr/lib/hpux32/libc.so.1 #3 0x6000c05277b0:0 in abort+0x170 () from /usr/lib/hpux32/libc.so.1 #4 0x6000c03ce5f0:0 in _assert+0x260 () from /usr/lib/hpux32/libc.so.1 #5 0x6000c0590980:0 in pthread_once+0x80 () from /usr/lib/hpux32/libc.so.1 #6 0x6000c4bab160:0 in pkinit_init_plg_crypto () at pkinit_crypto_openssl.c:410 #7 0x6000c4ba0b20:0 in pkinit_client_plugin_init () at pkinit_clnt.c:1490 #8 0x6000c4d19110:0 in k5_init_preauth_context () at preauth2.c:154 #9 0x6000c4d19540:0 in k5_preauth_request_context_init () at preauth2.c:218 #10 0x6000c4cee100:0 in restart_init_creds_loop () at get_in_tkt.c:742 #11 0x6000c4cef8f0:0 in krb5_init_creds_init () at get_in_tkt.c:981 #12 0x6000c4cf48a0:0 in get_init_creds_keytab () at gic_keytab.c:229 #13 0x6000c4cf4c10:0 in krb5_get_init_creds_keytab () at gic_keytab.c:283 #14 0x6000c3a62750:0 in get_initial_cred () at acquire_cred.c:608 #15 0x6000c3a62980:0 in maybe_get_initial_cred () at acquire_cred.c:634 #16 0x6000c3a64320:0 in kg_cred_resolve () at acquire_cred.c:975 #17 0x6000c3a803d0:0 in krb5_gss_init_sec_context_ext () at init_sec_context.c:972 ---Type to continue, or q to quit--- #18 0x6000c3a80f50:0 in krb5_gss_init_sec_context () at init_sec_context.c:1085 #19 0x6000c3a3b9d0:0 in gss_init_sec_context () at g_init_sec_context.c:210 #20 0x6000c3414020:0 in gssapi_client_mech_step () at gssapi.c:1604 #21 0x6000c38d7780:0 in sasl_client_step () at client.c:958 #22 0x6000c38d7370:0 in sasl_client_start () at client.c:904 #23 0x6000c3321a20:0 in XS_Authen__SASL__XS_client_start () at XS.xs:1382 #24 0x6000c4e0:0 in Perl_pp_entersub () at pp_hot.c:2877 #25 0x6000c4870c00:0 in Perl_runops_standard () at run.c:38 #26 0x6000c4773870:0 in S_run_body () at perl.c:2366 #27 0x6000c4772d60:0 in perl_run () at perl.c:2283 #28 0x4003720:0 in main () at perlmain.c:99 === As you can see, the fault happens when PKINIT is attempted with OpenSSL. After that I have recompiled MIT Kerberos (1.13.1 and 1.13.2) without PKINIT support and it worked instantly. This is our environment: HP-UX 11.31, MIT Kerberos 1.13.1, Perl 5.8.8, Cyrus SASL 2.1.16, OpenSSL 1.0.1m What we would like to do: Use Net::LDAP with uses Authen::SASL which in turn calls Authen::SASL::XS with a Perl to C binding against Cyrus SASL. The very same happens when Authen::SASL::Perl with GSSAPI module is used: failure. This must be some generic incompat. All calls are performed with an empty ticket cache (non-default location as once advised by Greg Hudson) and a client keytab. Using an interactive ticket cache makes the entire stuff work, so client ticket makes it crash. We do not use PKINIT at all. Interesting to say that the very same LDAP request works with ldapsearch(1) and a minimal C app with libldap. Any ideas? Can this be some interference with Perl and preinit of OpenSSL? As a workaround, I would recompile MIT Kerberos on all servers without pkinit for now. I'd be more than happy to assist here. Michael Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Kerberos Authentication question(s)
I am using the Java class org.apache.hadoop.security.
authentication.server.AuthenticationFilter from Apache
Hadoop 2.5.0 as a filter in front of a Tomcat 6 Servlet we
wish to add Kerberos authentication to.
I am attempting to write some test cases against this filter
so that we have a better understanding of how it
works and what it does.
In order for the filter to authenticate a user, it is reading the
'Authorization' header of the HTTP request,
expecting the value to contain 'Negotiate '
My understanding of how Kerberos works leads me to believe that I
should be able to write code while creating my
HTTP request that looks something like this:
// normally the server principal keytab is not available from the
client side,
// but for the purpose of making test cases I see no problem with
sharing the keytab
// between the client side and the server side
javax.security.auth.kerberos.Keytab kt = KeyTab.getInstance("keytab");
KerberosKey keys[] = kt.getKeys("HTTP/voltage-pp-
.albert@alberts.int");
SomeTokenType token = new SomeTokenType();
// my understanding of Kerberos is that the only cyphertext key
// needed on this token
// is one of the server principal's keys from the Keytab file
// (which does contain ~5
// keys of different sizes and types, I've checked)
EncryptedTokenType etoken =
byte[] array = etoken.getBytes();
httprequest.addHeader("Authorization","Negotiate " + new
Base64(0).encode(array));
So, questions here:
1) What is the Java Class that embodies the Kerberos Auth Token sent
in "Authorization Negotiate"?
2) What fields of that auth token have to be set to what values?
3) What is the encryption algorithm used to encrypt the auth token
against the keytab key?
4) What is the best keytab key to use?
5) What is the mechanism for byte-serializing the auth token, once
encrypted?
I have done significant research on the internet, and have found no
answer to this, and exploring the source code available leads into
some very complex interactions between interfaces and implementations
thereof...
Any leads on how to figure this out would be greatly appreciated!
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
