Thanks.
This information will be provided to openjdk dev as they were asking about
MIT krb5 behavior -> https://bugs.openjdk.java.net/browse/JDK-8272162
On Wed, Aug 25, 2021 at 1:00 PM Isaac Boukris wrote:
> Hi Vipul,
>
> On Wed, Aug 25, 2021 at 6:12 AM Vipul Mehta
> wrote:
>
aPruflFCEp!xs7LC6xF-p5noCT18UnibXxKXcrNUf6GDk_BArh2V7T3TRWFgGLo5IL9RlB1cVwEOw$>
Is this implemented in the MIT Kerberos client ?
On Thu, Jul 29, 2021 at 2:20 PM Vipul Mehta
wrote:
> Thank you.
> This was a useful discussion for me.
>
> On Wed, Jul 28, 2021 at 4:36 PM Isaac Boukris wrote:
>
>> On Wed, Ju
Thank you.
This was a useful discussion for me.
On Wed, Jul 28, 2021 at 4:36 PM Isaac Boukris wrote:
> On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta
> wrote:
> >
> > Now we know that behavior is unified and S4U2Self ticket should be
> forwardable to avoid vulnerabilit
update, now I cannot change the forwardable flag from false to true in
S42U2Self ticket in case 1).
On Tue, Jul 27, 2021 at 9:58 PM Isaac Boukris wrote:
> On Tue, Jul 27, 2021 at 6:54 PM Vipul Mehta
> wrote:
> >
> > Need a clarification:
> > MIT KDC will set the forwa
this check:
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java
-> line 105
On Wed, Jul 28, 2021 at 2:08 PM Isaac Boukris wrote:
> On Wed, Jul 28, 2021 at 11:10 AM Vipul Mehta
&
l 27, 2021 at 12:44 AM Greg Hudson wrote:
> On 7/23/21 4:38 PM, Vipul Mehta wrote:
> > I did some testing with Windows KDC and it will set forwardable flag in
> > S4U2Self service ticket in either of the following cases:
> >
> > 1) TrustedToAuthForDelegation is set to tr
Hi,
To perform constrained delegation from Service A to Service B, forwardable
flag must be set in the S4U2Self service ticket returned by KDC to Service
A.
I did some testing with Windows KDC and it will set forwardable flag in
S4U2Self service ticket in either of the following cases:
1)
/dd1b47f9-580c-4c4e-8f34-4485b9728331
This is proved here:
https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#serendipity
On Sat, Jul 24, 2021 at 2:08 AM Vipul Mehta
wrote:
> Hi,
>
> To perform constrained delegation from Service A to Service B,
> forwardable flag must be set in
in version 1.19.
On Thu, May 13, 2021 at 9:15 PM Robbie Harwood wrote:
> Vipul Mehta writes:
>
> > I am trying to compiler MIT Kerberos version 1.19.1 in RedHat linux with
> > following gcc:
> > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
> >
> > What is the vers
Hi,
I am trying to compiler MIT Kerberos version 1.19.1 in RedHat linux with
following gcc:
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Getting following error:
gic_keytab.c:185: error: ‘etype_list’ may be used uninitialized in this
function
At top level:
cc1: warning: unrecognized command line
2, 2021 at 11:13 PM Simo Sorce wrote:
> Note that this is true only for RC4-HMAC keys, because the RC4-HMAC key
> is unsalted. AES keys are salted so two machines will have different
> AES keys even if the "password" is the same.
>
> HTH,
> Simo.
>
> On Mon, 2021-03
Benjamin Kaduk wrote:
> On Fri, Mar 19, 2021 at 11:47:49PM +0530, Vipul Mehta wrote:
> > Hi,
> >
> > Suppose there are two servers A and B running under different kerberos
> > service principals.
> > If both the service principals have same password and kvno then
Hi,
Suppose there are two servers A and B running under different kerberos
service principals.
If both the service principals have same password and kvno then kerberos
long term encryption key will be same for both. Seems to be the case for
windows KDC.
In such case, a client having service
Hi,
Following are my setup details :
=> AIX version 6
=> MIT Kerberos version 1.12.4
=> Windows Server 2008 KDC.
Our kerberos authentication API dynamically loads MIT Kerberos and calls
its APIs via function pointer. It works fine in Linux.64 and Windows.
We have done two file changes for
, Vipul Mehta vipulmehta.1...@gmail.comwrote:
Your understanding is correct but credential delegation requirements are
API dependent instead of platform.
For Unix :
Putty uses MIT Kerberos - GSS API. When you enable delegation in putty it
requests GSS_C_DELEG_FLAG instead
Yes, it does logs a warning on using socklen_t :
argument of type socklen_t * is incompatible with parameter of type int
*.
On Mon, Apr 28, 2014 at 7:44 AM, Simo Sorce s...@redhat.com wrote:
On Sun, 2014-04-27 at 11:47 -0400, Greg Hudson wrote:
On 04/26/2014 02:59 PM, Vipul Mehta wrote
As everything is working fine with the change, can someone please
commit this change to the repository for get_so_error() in
sendto_kdc.c
#if defined(__hpux)
int sockerrlen;
#else
socklen_t sockerrlen;
#endof
On Tue, Apr 8, 2014 at 7:55 PM, Vipul Mehta vipulmehta.1...@gmail.comwrote
Your understanding is correct but credential delegation requirements are
API dependent instead of platform.
For Unix :
Putty uses MIT Kerberos - GSS API. When you enable delegation in putty it
requests GSS_C_DELEG_FLAG instead of GSS_C_DELEG_POLICY_FLAG which doesn't
check ok_as_delegate_flag,
;
#endof
It works perfectly fine. I tried using hpux macro but didn't work, so i
introduced my own HPUX-IA64 macro and defined it via CFLAGS.
On Mon, Apr 7, 2014 at 8:37 PM, Greg Hudson ghud...@mit.edu wrote:
On 04/07/2014 04:44 AM, Vipul Mehta wrote:
I've narrowed down the problem
and MIT Kerberos version 1.11.1
On Tue, Apr 1, 2014 at 4:59 PM, Vipul Mehta vipulmehta.1...@gmail.comwrote:
Hi,
I am using mit kerberos library build in HP-UX IA64 platform but not able
to get credentials from keytab. Username - password case works fine.
Same method in my API to get
Hi,
I am using mit kerberos library build in HP-UX IA64 platform but not able
to get credentials from keytab. Username - password case works fine.
Same method in my API to get credentials from keytab works fine in library
build for other platforms( win32, linux, aix ).
On debugging i found
@Christopher : I know about that option. I don't want to disable delegation
but i want to know the correct behaviour of MIT Kerberos with KDC Option i
specified.
@Greg, now it's clear to me.
Checked the code also. So, if initiator has requested GSS_C_DELEG_FLAG,
then delegation will always be
Hi,
Scenario : User A forwards his credentials to User B. User B uses the
forwarded credentials to interact with User C on behalf of user A.
[Delegation]
In windows KDC there is delegation option associated with user properties.
I've set it to Do not trust this user for delegation for User B
One more question, what is the exact use of context delegation flag if it
doesn't need to be same on initiator and acceptor side.
On Fri, May 17, 2013 at 9:54 PM, Vipul Mehta vipulmehta.1...@gmail.comwrote:
On Fri, May 17, 2013 at 8:31 PM, Greg Hudson ghud...@mit.edu wrote:
The GSSAPI
Hi,
It seems there is a bug in MIT kerberos gss source code where the
delegation state is set in context flags on acceptor side.
I am using a keytab on server side to acquire credentials with in memory
credential cache : *cred-usage == GSS_C_BOTH*
Client has *delegation flag set to false* but
, Vipul Mehta wrote:
So, for case B, the above if() condition will be true and it will set the
context delegation flag to true on acceptor side though delegation flag
is
false on initiator side.
This is how our constrained delegation (S4U2Proxy) support works. I
don't see anything in RFC
26 matches
Mail list logo
