OK, also understood. Next item why I don't get any logging or it's not working as espected.
I'm actually out of options to be honest. 2015-03-31 11:54 GMT+02:00 Sumit Bose <[email protected]>: > 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: >> [email protected] for krbtgt/[email protected], >> 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}, [email protected] for >> krbtgt/[email protected] >> 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}, [email protected] for >> HTTP/[email protected] >> >> >> 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 . <[email protected]>: >> > 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 <[email protected]>: >> >> 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/[email protected] >> >>> 03/31/2015 11:00:09 04/01/2015 11:00:07 >> >>> HTTP/[email protected] >> >>> >> >>> 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 . <[email protected]>: >> >>> > 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 <[email protected]>: >> >>> >> 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" <[email protected]>: >> >>> >>> >> >>> >>> > 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
