Dmitri Pal wrote:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/19/2012 03:37 PM, Nathan Lager wrote:

 >
 > On 09/19/2012 02:54 PM, Rob Crittenden wrote:
 > > Nathan Lager wrote:
 > >>
 > >>
 > >> On 09/19/2012 11:34 AM, Rob Crittenden wrote:
 > >>> Nathan Lager wrote:
 > >>>>
 > >>>> On 09/19/2012 10:37 AM, Rob Crittenden wrote:
 > >>>>> Lager, Nathan T. wrote:
 > >>>>>>
 > >>>>>> ----- Original Message -----
 > >>>>>>> From: "Rob Crittenden" <rcrit...@redhat.com> To:
 > >>>>>>> "Nathan Lager" <lag...@lafayette.edu> Cc:
 > >>>>>>> freeipa-users@redhat.com Sent: Tuesday, September 18,
 > >>>>>>> 2012 5:17:00 PM Subject: Re: [Freeipa-users] sudden ipa
 > >>>>>>> errors.
 > >>>>>>>
 > >>>>>>> Ok, what are the permissions on the keytab,
 > >>>>>>> /etc/httpd/conf/ipa.keytab? They should be
 > >>>>>>> apache:apache mode 0600.
 > >>>>>>
 > >>>>>> [lagern@caroline0 PROD ~]$ ls -lZ
 > >>>>>> /etc/httpd/conf/ipa.keytab -rw-------. apache apache
 > >>>>>> unconfined_u:object_r:httpd_config_t:s0
 > >>>>>> /etc/httpd/conf/ipa.keytab
 > >>>>>>
 > >>>>>>>
 > >>>>>>> Are you in SELinux enforcing mode? Can you try in
 > >>>>>>> permissive to see if that works?
 > >>>>>> I was enforcing at the start of all of this, but ive
 > >>>>>> since switched to permissive for troubleshooting. It
 > >>>>>> hasnt made a difference.
 > >>>>>
 > >>>>> Are you getting an HTTP service principal in the client?
 > >>>>>
 > >>>>> $ kdestroy $ kinit admin $ ipa user-show admin <fail> $
 > >>>>> klist -fea
 > >>>>>
 > >>>>> Lets try to skip s4u2proxy. Does this work:
 > >>>>>
 > >>>>> $ ipa --delegate user-show admin
 > >>>>>
 > >>>>> Unfortunately the major and minor error codes are as
 > >>>>> generic as can be so they aren't any help at all.
 > >>>>>
 > >>>>> rob
 > >>>>
 > >>>> Here's the output. The --delegate still failed.
 > >>>>
 > >>>> [root@caroline0 PROD ~]# klist -fea Ticket cache:
 > >>>> FILE:/tmp/krb5cc_0 Default principal:
 > >>>> lag...@systems.lafayette.edu
 > >>>>
 > >>>> Valid starting Expires Service principal
 > >>>> 09/19/12 11:23:03 09/20/12 11:22:52
 > >>>> krbtgt/systems.lafayette....@systems.lafayette.edu Flags:
 > >>>> FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
 > >>>> aes256-cts-hmac-sha1-96 Addresses: (none) 09/19/12 11:23:11
 > >>>> 09/20/12 11:22:52
 > >>>> HTTP/caroline0.lafayette....@systems.lafayette.edu Flags:
 > >>>> FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
 > >>>> aes256-cts-hmac-sha1-96 Addresses: (none) [root@caroline0
 > >>>> PROD ~]# ipa --delegate user-show admin ipa: ERROR: cannot
 > >>>> connect to u'http://caroline0.lafayette.edu/ipa/xml':
 > >>>> Internal Server Error [root@caroline0 PROD ~]#
 > >>>
 > >>> Is it the same major/minor error in gss_acquire_cred()?
 > >>>
 > >>> Does GSSAPI over LDAP work?
 > >>>
 > >>> $ ldapsearch -Y GSSAPI -h ipa.example.com -b
 > >>> cn=users,cn=accounts,dc=example,dc=com admin
 > >>>
 > >> This appears to work.
 > >>
 > >> [root@caroline0 PROD ~]# ldapsearch -Y GSSAPI -h
 > >> caroline0.lafayette.edu -b
 > >> cn=users,cn=accounts,dc=systems,dc=lafayette,dc=edu admin
 > >> SASL/GSSAPI authentication started SASL username:
 > >> lag...@systems.lafayette.edu SASL SSF: 56 SASL data security
 > >> layer installed. # extended LDIF # # LDAPv3 # base
 > >> <cn=users,cn=accounts,dc=systems,dc=lafayette,dc=edu> with scope
 > >> subtree # filter: (objectclass=*) # requesting: admin #
 > >>
 > >> # users, accounts, systems.lafayette.edu dn:
 > >> cn=users,cn=accounts,dc=systems,dc=lafayette,dc=edu
 > >>
 > >> # admin, users, accounts, systems.lafayette.edu dn:
 > >> uid=admin,cn=users,cn=accounts,dc=systems,dc=lafayette,dc=edu
 > >>
 > >> <-- a bunch of other users here -->
 > >>
 > >> # search result search: 4 result: 0 Success
 > >>
 > >> # numResponses: 10 # numEntries: 9
 > >>
 >
 > > Ok, so it's JUST Apache then.
 >
 > > Is the hostname on caroline0 set as a FQDN (/bin/hostname)?
 >
 > > If not, I'd try setting it to caroline0.lafayette.edu
 >
 > > If so, might be worth trying to refresh your Apache keytab. I made
 > > some educated guesses on your hostnames/realm, please
 > > double-check:
 >
 > > # ipa-getkeytab -s caroline0.lafayette.edu -p
 > > HTTP/caroline0.lafayette.edu@ SYSTEMS.LAFAYETTE.EDU -k
 > > /etc/httpd/conf/ipa.keytab
 >
 > > Should not be required to restart httpd but it shouldn't hurt. Run
 > > kdestroy/kinit before trying ipa user-show again.
 >
 > > rob
 >
 > well, seems like we're at least narrowing things down. But its still
 > no good.
 >
 > The hostname is the fqdn. /bin/hostname returns it as such.
 >
 >
 > [root@caroline0 PROD ~]# ipa-getkeytab -s caroline0.lafayette.edu -p
 > HTTP/caroline0.lafayette....@systems.lafayette.edu -k
 > /etc/httpd/conf/ipa.keytab
 > Keytab successfully retrieved and stored in: /etc/httpd/conf/ipa.keytab
 > [root@caroline0 PROD ~]# service httpd restart
 > Stopping httpd: [ OK ]
 > Starting httpd: [Wed Sep 19 15:34:24 2012] [warn] worker
 > ajp://localhost:9447/ already used by another worker
 > [Wed Sep 19 15:34:24 2012] [warn] worker ajp://localhost:9447/ already
 > used by another worker
 > [ OK ]
 > [root@caroline0 PROD ~]# kdestroy
 > [root@caroline0 PROD ~]# kinit lagern
 > Password for lag...@systems.lafayette.edu:
 > [root@caroline0 PROD ~]# ipa pwpolicy-show
 > ipa: ERROR: cannot connect to
 > u'http://caroline0.lafayette.edu/ipa/xml': Internal Server Error
 >
 >

Rob, keytab and kerberos part seems to be fine, ldap works too.
Can it be one of the certs? May be some cert expired?

No, the error is coming from GSSAPI, it is unfortunately completely useless. I think we've pretty well narrowed down the problem to httpd/mod_auth_kerb but I don't know yet if this is a configuration issue or a bug.

Nathan, can you show me your /etc/httpd/conf.d/ipa.conf?

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to