Re: [Freeipa-users] Generic preauthentication failure while getting initial credentials using kinit -k -t

2015-09-27 Thread Alexander Bokovoy

On Sat, 26 Sep 2015, Brian J. Murrell wrote:

On Thu, 2015-09-24 at 08:23 +0300, Alexander Bokovoy wrote:

OK.  I have refreshed my memory of how Kerberos works.


The sequence above:

 - Sets a random Kerberos key for a principal named
aster...@example.com
   on IPA KDC and stores it to the local keytab file asterisk.keytab


Yes.  That keytab is intended to be the machine equivalent of the human
who enters their password at a kinit prompt.

Ok, I wanted to know what you were trying to achieve.




 - tries to use a key for
aster...@example.com to obtain ticket
granting
   ticket as
imap/linux.example@exampe.com


Why would it try to obtain a TGT as the imap/linux.example.com
principle?  It should be trying to obtain a TGT as the
aster...@example.com principle, exactly as a human named "asterisk"
would do using kinit.

Because *you* asked it to do so:
$ man kinit
...
SYNOPSIS
  kinit  [-V]  [-l  lifetime]  [-s start_time] [-r renewable_life] [-p | 
-P] [-f | -F] [-a] [-A] [-C] [-E] [-v] [-R] [-k [-t keytab_file]] [-c 
cache_name] [-n] [-Sservice_name] [-I input_ccache] [-T armor_ccache] 
[-X attribute[=value]] [principal]

DESCRIPTION
  kinit obtains and caches an initial ticket-granting ticket for principal.

So, when you run kinit as

 kinit -k -t /path/to/keytab imap/linux.example.com

You are asking "take the key for imap/linux.example.com from the
/path/to/keytab and obtain a ticket granting ticket from KDC using these
credentials".



The goal here is to have the daemon authenticate to the KDC as
aster...@example.com and then use that TGT to get service tickets to
the imap service so that it authenticates to the imap service as the
user "asterisk".
And that would be 


  kinit -k -t /path/to/keytab asterisk

That's enough. Not specifying the principal would mean using a default
(host/fqdn), not whatever is the principal in the keytab.


I suppose the other way, is to give the daemon the imap principle's key
and let it forge service tickets but that would require the daemon to
know that that is what is doing.  It does not know that.  It is just
acting like an imap client as any other imap client that uses kerberos
does.  To be perfectly clear, this daemon only wants to authenticate as
the single user "asterisk" to the imap server.  It does not need to
authenticate as many users.

Yes.

Once you've obtained a TGT in the current ccache, your application can
request the service ticket (imap/linux.example.com) automatically.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Generic preauthentication failure while getting initial credentials using kinit -k -t

2015-09-26 Thread Brian J. Murrell
On Thu, 2015-09-24 at 08:23 +0300, Alexander Bokovoy wrote:

OK.  I have refreshed my memory of how Kerberos works.

> The sequence above:
> 
>  - Sets a random Kerberos key for a principal named 
> aster...@example.com
>on IPA KDC and stores it to the local keytab file asterisk.keytab

Yes.  That keytab is intended to be the machine equivalent of the human
who enters their password at a kinit prompt.

>  - tries to use a key for 
> aster...@example.com to obtain ticket
> granting
>ticket as 
> imap/linux.example@exampe.com

Why would it try to obtain a TGT as the imap/linux.example.com
principle?  It should be trying to obtain a TGT as the 
aster...@example.com principle, exactly as a human named "asterisk"
would do using kinit.

The goal here is to have the daemon authenticate to the KDC as 
aster...@example.com and then use that TGT to get service tickets to
the imap service so that it authenticates to the imap service as the
user "asterisk".

I suppose the other way, is to give the daemon the imap principle's key
and let it forge service tickets but that would require the daemon to
know that that is what is doing.  It does not know that.  It is just
acting like an imap client as any other imap client that uses kerberos
does.  To be perfectly clear, this daemon only wants to authenticate as
the single user "asterisk" to the imap server.  It does not need to
authenticate as many users.

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Generic preauthentication failure while getting initial credentials using kinit -k -t

2015-09-24 Thread Brian J. Murrell
On Thu, 2015-09-24 at 08:23 +0300, Alexander Bokovoy wrote:
> You need to explain what are you trying to achieve first.

Sure.  It is entirely likely that I am misunderstanding what I should
be doing.

A system service needs to be able to authenticate to the service
imap/linux.example.com as a given user, so clearly that system service
cannot kinit and provide a password as a user would normally (I guess
this is what GSS-Proxy is for, FWIW).

> The sequence above:
> 
>  - Sets a random Kerberos key for a principal named 
> aster...@example.com

OK.

>on IPA KDC and stores it to the local keytab file asterisk.keytab

Right.

>  - tries to use a key for 
> aster...@example.com to obtain ticket
> granting
>ticket as 
> imap/linux.example@exampe.com

So maybe this is where I am going wrong.

> Unless imap/linux.example@example.com
>  has exactly same Kerberos key
> as aster...@example.com, the above should
> fail and it does.

So I want to put the imap/linux.example.com kerberos key into the
 asterisk.keytab file such as:

ipa-getkeytab -s server.example.com -p imap/linux.example.com -k 
/tmp/asterisk-krb5.keytab -e aes256-cts

I probably need to brush up on my kerberos here but is that what a user
effectively does?  When I, as a user do a "kinit brian" and then do a
klist (after having used my imap client) and I see:

24/09/15 09:00:28  25/09/15 06:19:42  imap/linux.example@example.com

Does that mean that I actually have the Kerberos key for that imap/linu
x.example@example.com
in my key cache -- the exact same key that I am going to put into the
asterisk.keytab above?

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Generic preauthentication failure while getting initial credentials using kinit -k -t

2015-09-23 Thread Alexander Bokovoy

On Wed, 23 Sep 2015, Brian J. Murrell wrote:

I've put a kerberos principle into a keytab:

# klist -k asterisk.keytab
Keytab name: FILE:asterisk.keytab
KVNO Principal
 --
  8 aster...@example.com

using:

# ipa-getkeytab -s server.example.com -p asterisk -k /tmp/asterisk-krb5.keytab 
-e aes256-cts

But when I try to use that keytab I get an error:

# kinit -k -t /etc/asterisk/asterisk.keytab imap/linux.example@example.com
kinit: Generic preauthentication failure while getting initial credentials

On the server I get the following error:

Sep 23 19:30:39 server.example.com krb5kdc[28970](info): AS_REQ (7
etypes {18 17 16 23 1 3 2}) xx: NEEDED_PREAUTH:
imap/linux.example@example.com for krbtgt/example@example.com,
Additional pre-authentication required

Any idea what is going on here?

You need to explain what are you trying to achieve first.

The sequence above:

- Sets a random Kerberos key for a principal named aster...@example.com
  on IPA KDC and stores it to the local keytab file asterisk.keytab
- tries to use a key for aster...@example.com to obtain ticket granting
  ticket as imap/linux.example@exampe.com

Unless imap/linux.example@example.com has exactly same Kerberos key
as aster...@example.com, the above should fail and it does.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project