[28064] in Kerberos
Re: Preauth mechanism provision in MIT kerberos
daemon@ATHENA.MIT.EDU (Gopal Paliwal)
Wed Jul 18 19:15:36 2007
Message-ID: <6a113f920707181615j48b7d6eex1aee65a822835f49@mail.gmail.com>
Date: Wed, 18 Jul 2007 16:15:00 -0700
From: "Gopal Paliwal" <gopalpaliwal@gmail.com>
To: "Marcus Watts" <mdw@spam.ifs.umich.edu>, kerberos@mit.edu
In-Reply-To: <E1IBFIJ-0003Lt-5D@spam.ifs.umich.edu>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hi,
The solution you guys provided help me.
Though I now observe following things on ethereal.
1)for the first time krb5_AS_REQ goes whenever user enters his username.
2) Authentication server responds back by giving error as "PRE_AUTH
REQUIRED"
3) Now new krb5_AS_REQ request gets formed with encrypted time-stamp.
4)Authentication server sends krb5_AS_RES this time with session key &
tickets.
I am curious why first two messages were generated. It makes sense though
that only authentication server knows that a particular user requires
pre_auth & the user will be unaware of this fact before it receives
"PRE_AUTH REQUIRED" error. Still, is there any way where I would be able to
avoid the flow of first two messages.
Thanks again,
Gopal
On 7/18/07, Marcus Watts <mdw@spam.ifs.umich.edu> wrote:
>
> John Washington <jawashin@uiuc.edu> sent:
> > Date: Wed, 18 Jul 2007 08:46:49 CDT
> > To: Mike Dopheide <dopheide@ncsa.uiuc.edu>
> > cc: kerberos@mit.edu
> > From: John Washington <jawashin@uiuc.edu>
> > Subject: Re: Preauth mechanism provision in MIT kerberos
> ...
> > Well, you do that and set it as a default for all new priciples.
> ...
>
> The only way to set it for existing principals is via 'modprinc'.
> For new principals, you can set "default_principal_flags"
> inside of kdc.conf [realms] your-realm {}, something like this:
> ...
> acl_file = /var/krb5kdc/kadm5.acl
> max_renewable_life = 7d 0h 0m 0s
> master_key_type = des-cbc-crc
> default_principal_flags = +preauth
> ...
>
> Note that default_principal_flags is not necessarily
> the default for principals you create for keytabs.
> Also note that you may not *want* preauth for keytab principals;
> it that's set, the keytab isn't useable by principals that
> for some reason did not authenticate using preauth.
>
> -Marcus Watts
> ________________________________________________
> 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
