On Thu, Mar 5, 2015 at 4:34 PM, Dan Mossor <danofs...@gmail.com> wrote:
> > > On Thu, Mar 5, 2015 at 4:16 PM, Dmitri Pal <d...@redhat.com> wrote: > >> On 03/05/2015 04:15 PM, Dan Mossor wrote: >> >> Good day, folks. >> >> This time it is something different, yet the same. I have re-deployed >> my IPA installation due to some underlying issues with the host of the >> virtual machine. Even with the new installation, I cannot authenticate >> through the web UI. >> >> So far, there is exactly one client in the domain (my workstation), and >> exactly one user - admin. I am not comfortable with the command line tools, >> and I have others below my position that require a GUI for management >> purposes, so I have to make this work to proceed any further. >> >> Following up with the information Martin asked for in my previous >> thread, let me walk you through the process: >> >> I attempted to log in to https://vader.rez.lcl/, and received the error >> "Your session has expired. Please re-login." At this point, I clicked the >> link to configure Firefox. On the command line, I obtained a kerberos >> ticket for admin (note - I am root on this workstation for the time being): >> >> [root@dmfedora ~]# kinit admin >> Password for ad...@rez.lcl: >> [root@dmfedora ~]# klist >> Ticket cache: KEYRING:persistent:0:0 >> Default principal: ad...@rez.lcl >> >> Valid starting Expires Service principal >> 03/05/2015 14:46:22 03/06/2015 14:46:15 krbtgt/rez....@rez.lcl >> >> I then finished the Firefox configuration, and attempted to log in >> again. I still received the error. The Firefox console shows: >> >> POST https://vader.rez.lcl/ipa/session/login_password [HTTP/1.1 200 >> Success 756ms] >> POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized >> 3ms] >> GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 401 >> Unauthorized 2ms] >> GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 200 >> Success 26ms] >> POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized >> 4ms] >> >> /var/log/krb5kdc.log during the process: >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: HTTP/vader.rez....@rez.lcl >> for krbtgt/rez....@rez.lcl, Additional pre-authentication required >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 >> tkt=18 ses=18}, HTTP/vader.rez....@rez.lcl for krbtgt/rez....@rez.lcl >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: ad...@rez.lcl for >> krbtgt/rez....@rez.lcl, Additional pre-authentication required >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 >> tkt=18 ses=18}, ad...@rez.lcl for krbtgt/rez....@rez.lcl >> >> /var/log/httpd/access_log shows the same thing as the Firefox console: >> 10.1.1.15 - - [05/Mar/2015:21:06:30 +0000] "POST >> /ipa/session/login_password HTTP/1.1" 200 25 >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json >> HTTP/1.1" 401 - >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "GET >> /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 401 1469 >> 10.1.1.15 - ad...@rez.lcl [05/Mar/2015:21:06:31 +0000] "GET >> /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 200 20 >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json >> HTTP/1.1" 401 - >> >> Nothing is entered into any error logs, the audit log, or the system >> journal. I am at my wits end here, and lost. What other information do you >> need to help me solve this problem? >> >> Thank you, >> Dan Mossor >> >> -- >> >> Dan Mossor, RHCSA >> Systems Engineer at Large >> Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG >> Fedora Infrastructure Apprentice >> FAS: dmossor IRC: danofsatx >> San Antonio, Texas, USA >> >> >> >> Can you authenticate using UI from the server host? >> It seems that the Kerberos authentication goes through but then it is >> lost. >> So here are some wild ideas: >> - Is the browser properly configured? May be there is something with the >> browser that is not working? Have you cleaned the old IPA CA cert? It might >> not be related but I have seen issues in the past with it. >> - Are you sure that server has all the components? For example session on >> the server side is stored in memcached. If it is not running or something >> is not right with it the ticket sharing might be broken. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> First off, apologies if the thread is broken - I am stuck using the Gmail > interface temporarily. > > The server host - both the actual host and the IPA server - do not have > GUIs on them, so I cannot launch a web browser from them. The old IPA CA > cert was never on this workstation - this workstation was built Tuesday, > and the IPA server deployed yesterday. The previous one I was having issues > with had already been wiped - so this is starting off from scratch with > both the server and the client. I did check the ipa_memcached service as > suggested by Martin in my previous thread. > > [root@vader ipa]# systemctl status httpd.service dirsrv@REZ-LCL.service > ipa_memcached.service > ● httpd.service - The Apache HTTP Server > Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) > Active: active (running) since Fri 2015-03-06 18:19:16 GMT; 19h left > Main PID: 1103 (httpd) > Status: "Total requests: 150; Idle/Busy workers 100/0;Requests/sec: > 3.49e-08; Bytes served/sec: 0 B/sec" > CGroup: /system.slice/httpd.service > ├─1103 /usr/sbin/httpd -DFOREGROUND > ├─1104 /usr/libexec/nss_pcache 98307 off /etc/httpd/alias > ├─1105 /usr/sbin/httpd -DFOREGROUND > ├─1107 /usr/sbin/httpd -DFOREGROUND > ├─1108 /usr/sbin/httpd -DFOREGROUND > ├─1111 /usr/sbin/httpd -DFOREGROUND > ├─1113 /usr/sbin/httpd -DFOREGROUND > ├─1339 /usr/sbin/httpd -DFOREGROUND > ├─1471 /usr/sbin/httpd -DFOREGROUND > ├─1473 /usr/sbin/httpd -DFOREGROUND > ├─1474 /usr/sbin/httpd -DFOREGROUND > ├─1475 /usr/sbin/httpd -DFOREGROUND > ├─1926 /usr/sbin/httpd -DFOREGROUND > └─1927 /usr/sbin/httpd -DFOREGROUND > > Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 2 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 2 > Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 2 > > ● dirsrv@REZ-LCL.service - 389 Directory Server REZ-LCL. > Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled) > Active: active (running) since Fri 2015-03-06 18:18:53 GMT; 19h left > Process: 1006 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i > /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid > (code=exited, status=0/SUCCESS) > Main PID: 1020 (ns-slapd) > CGroup: /system.slice/system-dirsrv.slice/dirsrv@REZ-LCL.service > └─1020 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-REZ-LCL -i > /var/run/dirsrv/slapd-REZ-LCL.pid -w /var/run/dirsrv/slapd-REZ-LCL.startpid > > Mar 05 21:43:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 21:58:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > > ● ipa_memcached.service - IPA memcached daemon, increases IPA server > performance > Loaded: loaded (/usr/lib/systemd/system/ipa_memcached.service; disabled) > Active: active (running) since Fri 2015-03-06 18:19:15 GMT; 19h left > Process: 1094 ExecStart=/usr/bin/memcached -d -s $SOCKET_PATH -u $USER > -m $CACHESIZE -c $MAXCONN -P /var/run/ipa_memcached/ipa_memcached.pid > $OPTIONS (code=exited, status=0/SUCCESS) > Main PID: 1095 (memcached) > CGroup: /system.slice/ipa_memcached.service > └─1095 /usr/bin/memcached -d -s > /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P > /var/run/ipa_memcached/ipa_memcached.pid > [root@vader ipa]# > > Thanks, > Dan > > -- > Dan Mossor, RHCSA > Systems Engineer at Large > Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG > Fedora Infrastructure Apprentice > FAS: dmossor IRC: danofsatx > San Antonio, Texas, USA > > > As an additional test, I created a new user on my workstation and switched to it. the first thing I did was kinit as admin, then started Firefox, went through the browser configuration provided by the IPA server, and attempted to log in. I received the same error[1]. [1]http://i.imgur.com/mhX86Ng.png
-- 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