On 09/30/14 02:46 PM, Wendy Lin wrote:
> Does Kerberos5 have a ticket to ascii converter so someone can see
> what a ticket looks like in plain text?
Wireshark has a dissector for krb5 messages including the tickets and
given appropriate keytab it can even decode encrypted parts.
Tomas
On 09/30/14 20:56, Wendy Lin wrote:
> On 30 September 2014 18:32, ronnie sahlberg wrote:
>> On Tue, Sep 30, 2014 at 9:17 AM, Wendy Lin wrote:
>>> On 30 September 2014 17:55, ronnie sahlberg
>>> wrote:
On Tue, Sep 30, 2014 at 8:25 AM, Wendy Lin wrote:
> On 30 September 2014 15:25, Rick
On 10/31/14 18:38, Rufe Glick wrote:
> Hello,
>
> I have Kerberos infrastructure set up and GSSAPI enabled in
> ssh_config/sshd_config of the SSH client/server (GSSAPIAuthentication yes).
> When I connect to the SSH server using verbose mode I see that SSH client
> uses 'gssapi-with-mic' mode to
Hi,
in MIT krb there used to be a check making sure, that the principal name
of a keytab entry used to decode enc-part of a ticket equals sname from
that ticket. But this check went away with the following commit:
http://anonsvn.mit.edu/viewvc/krb5/trunk/src/lib/krb5/krb/rd_req_dec.c?r1=21179&r2=2
On 04/12/13 18:00, steve wrote:
> We are using the cifs multiuser option with sec=krb5. This requires the
> user to have a ticket cache under /tmp
> I know we can get that by using kinit, But I hear rumours that pam can
> do it upon successful authentication.
>
> Can anyone point me in the right
Hi all,
I am confuzzled about usefulness of the QOP concept in GSS-API.
RFC 2743 states, that using non-default QOP is a mechanism specific,
non-portable construct.
RFC 4121 says, that applications using different QOP than default are
not guaranteed portability and interoperability. It also say
On 11/12/13 04:29 PM, Benjamin Kaduk wrote:
> On Tue, 12 Nov 2013, Tomas Kuthan wrote:
>
>> Hi all,
>>
>> I am confuzzled about usefulness of the QOP concept in GSS-API.
>>
>> RFC 2743 states, that using non-default QOP is a mechanism specific,
>> non-
Hi Wendy,
(I can only comment on Solaris)
I suppose, you are referring to automatic renewal of tickets by
ktkt_warnd. ktkt_warn service is enabled by default, but there are
upgrade scenarios, were you can end up with ktkt_warn disabled. Run
'svcs ktkt_warn' to confirm.
If ktkt_warn is up and
On 03/18/14 03:00 PM, Wendy Lin wrote:
> On 18 March 2014 13:54, Tomas Kuthan wrote:
>> Hi Wendy,
>>
>> (I can only comment on Solaris)
>>
>> I suppose, you are referring to automatic renewal of tickets by
>> ktkt_warnd. ktkt_warn service is enabled by defa
On 04/15/14 21:16, Nico Williams wrote:
> That said, it's best practice to key all devices. Still, nothing in
> NFSv4 requires such keys to be named in host-based ways.
Makes sense ... but still, basing on host is a nifty way of constructing
unique principal name. Is there a meaningful alternativ
10 matches
Mail list logo
