On Tue, Mar 31, 2015 at 11:38:30AM +0200, Matt . wrote:
> Here some extra logging from the kerberos log:
> 
> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6
> etypes {18 17 16 23 25 26}) 10.10.0.121: NEEDED_PREAUTH:
> kinituser@DOMAIN.LOCAL for krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL,
> Additional pre-authentication required
> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6
> etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491,
> etypes {rep=18 tkt=18 ses=18}, kinituser@DOMAIN.LOCAL for
> krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): TGS_REQ (6
> etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491,
> etypes {rep=18 tkt=18 ses=18}, kinituser@DOMAIN.LOCAL for
> HTTP/ldap-01.domain.local@DOMAIN.LOCAL
> 
> 
> I don't get the preauth needed, does it have anything todo with the
> 301 redirect which I follow with CURL ?

no, this is part of the AS_REQ (request to get a TGT) and will always
happen. Since the Kerberos client cannot know what kind of pre-auth
schemes are supported or required in the server side it first send a
request without pre-auth data. The server sends back a list of supported
schemes with a special NEEDED_PREAUTH error code if pre-auth is
required. And with IPA pre-auth is required otherwise e.g. replay
attacks would be easy.

HTH

bye,
Sumit

> 
> 2015-03-31 11:15 GMT+02:00 Matt . <yamakasi....@gmail.com>:
> > Yes I would assume too, but it's just kicking out possibilities what
> > could make it not working.
> >
> > I cannot figure out why it only logs the 401 after the known 301's in
> > the access_log and nothing further, apache really blocks, so kerberos
> > should be in the way for sure, but how.
> >
> >
> >
> > 2015-03-31 11:09 GMT+02:00 Sumit Bose <sb...@redhat.com>:
> >> On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote:
> >>> On my client I still see:
> >>>
> >>> 03/31/2015 11:00:08  04/01/2015 11:00:07  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
> >>> 03/31/2015 11:00:09  04/01/2015 11:00:07  
> >>> HTTP/ldap-01.domain.local@DOMAIN.LOCAL
> >>>
> >>> Should ldap-01 not be ldap as I go through my loadbalancer ?
> >>
> >> I guess not, because your loadbalancer just redirects the traffic and
> >> the authentication is done with ldap-01.
> >>
> >> bye,
> >> Sumit
> >>
> >>>
> >>> Do I need to merge keytabs or so ?
> >>>
> >>> 2015-03-31 7:54 GMT+02:00 Matt . <yamakasi....@gmail.com>:
> >>> > Hi,
> >>> >
> >>> > I tried to trace some stuff but this doesn't give me much more info.
> >>> >
> >>> > What I see at the moment in the /var/log/httpd/acces_log is exactly
> >>> > what happens but without the info I need to get a better view:
> >>> >
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 
> >>> > 301 258
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1"
> >>> > 301 259 "https://ldap.domain.local/ipa/json"; "-"
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 
> >>> > 401 1469
> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 
> >>> > 401 1469
> >>> >
> >>> > 2015-03-30 15:03 GMT+02:00 Sumit Bose <sb...@redhat.com>:
> >>> >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote:
> >>> >>> Hi,
> >>> >>>
> >>> >>> I just tot home and typing from my cell so i'm suite short in words
> >>> >>>
> >>> >>> Create keytab for ldap-01.domain
> >>> >>> Kinit with that to ldap.domain
> >>> >>> Curl against ldap.domain
> >>> >>> Get a 301 which I manage from curl (goes well)
> >>> >>> Get kerberos ticket error
> >>> >>>
> >>> >>> now I don't kinit anymore so re-use my existing ticket and curl 
> >>> >>> against
> >>> >>> ldap-01.domain and I'm accepted and can execute stuff.
> >>> >>>
> >>> >>> My ssl is OK, ticket also it seems.
> >>> >>
> >>> >> Maybe the output of
> >>> >>
> >>> >> KRB5_TRACE=/dev/sdtout curl -v ....
> >>> >>
> >>> >> might help to see what is going on?
> >>> >>
> >>> >> bye,
> >>> >> Sumit
> >>> >>
> >>> >>>
> >>> >>> Thanks M.
> >>> >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" <d...@redhat.com>:
> >>> >>>
> >>> >>> > On 03/29/2015 04:47 AM, Matt . wrote:
> >>> >>> >
> >>> >>> >> Hi Guys,
> >>> >>> >>
> >>> >>> >> Now my Certification issues are solved for using a loadbalancer in
> >>> >>> >> front of my ipa servers I get the following:
> >>> >>> >>
> >>> >>> >> Unable to verify your Kerberos credentials
> >>> >>> >>
> >>> >>> >> and in my logs:
> >>> >>> >>
> >>> >>> >> Additional pre-authentication required.
> >>> >>> >>
> >>> >>> >> This happens when I connect throught my loadbalancers, I see my 
> >>> >>> >> server
> >>> >>> >> coming ni with the right IP.
> >>> >>> >>
> >>> >>> >> When I access my ipa server directly, not using the loadbalancer IP
> >>> >>> >> between it, my kerberos Ticket is valid.
> >>> >>> >>
> >>> >>> >> I get the feeling that when I use my loadbalancers and because of 
> >>> >>> >> that
> >>> >>> >> I get a 301 redirect it needs a preauth. I see some issues on
> >>> >>> >> mailinglists but it doesn't fit my situation.
> >>> >>> >>
> >>> >>> >> Why wants it the preauth when I already have a valid ticket and my
> >>> >>> >> redirect is followed by CURL and posted the right way ?
> >>> >>> >>
> >>> >>> >
> >>> >>> > Can you describe the sequence?
> >>> >>> > What do you do?
> >>> >>> >
> >>> >>> > From the client you try IPA CLI and this is where you see the 
> >>> >>> > problem even
> >>> >>> > with the valid ticket or is the flow different?
> >>> >>> >
> >>> >>> >  I hope someone has an idea.
> >>> >>> >>
> >>> >>> >> Thanks,
> >>> >>> >>
> >>> >>> >> Matt
> >>> >>> >>
> >>> >>> >>
> >>> >>> >
> >>> >>> > --
> >>> >>> > Thank you,
> >>> >>> > Dmitri Pal
> >>> >>> >
> >>> >>> > Sr. Engineering Manager IdM portfolio
> >>> >>> > Red Hat, Inc.
> >>> >>> >
> >>> >>> > --
> >>> >>> > 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
> >>> >>> >
> >>> >>
> >>> >>> --
> >>> >>> 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
> >>> >>

-- 
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

Reply via email to