lune voo via FreeIPA-users wrote: > Hello everyone. > > I had this problem again but forgot to perform a klist -ef. :( > > I was wondering if my problem was coming from the session I had > established with Freeipa. > So I was wondering if I could reinitialize the session, maybe by > removing the cookie ? > > When we use the ipa command, I can see that we establish a session and > we set a cookie : > > # ipa -vv user-show myUser --raw > > The result : > ipa: INFO: trying https://IPAHOSTNAME/ipa/session/xml > ipa: INFO: Forwarding 'user_show' to server > u'https://IPAHOSTNAME/ipa/session/xml' > send: u'POST /ipa/session/xml HTTP/1.0\r\nHost: > IPAHOSTNAME\r\nAccept-Language: en-us\r\nReferer: > https://IPAHOSTNAME/ipa/xml\r\n > <https://IPAHOSTNAME/ipa/xml%5Cr%5Cn>*Cookie: > ipa_session=bbf68dc97c054ade093fff2695eedbd2;*\r\nUser-Agent: > xmlrpclib.py/1.0.1 <http://xmlrpclib.py/1.0.1> (by www.pythonware.com > <http://www.pythonware.com>)\r\nContent-Type: > text/xml\r\nContent-Length: 655\r\n\r\n' > send: "<?xml version='1.0' > encoding='UTF-8'?>\n<methodCall>\n<methodName>user_show</methodName>\n<params>\n<param>\n<value><array><data>\n<value><string>myUser</string></value>\n</data></array></value>\n</param>\n<param>\n<value><struct>\n<member>\n<name>raw</name>\n<value><boolean>1</boolean></value>\n</member>\n<member>\n<name>all</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>version</name>\n<value><string>2.49</string></value>\n</member>\n<member>\n<name>no_members</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>rights</name>\n<value><boolean>0</boolean></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n" > reply: 'HTTP/1.1 200 Success\r\n' > header: Date: Wed, 12 Dec 2018 08:19:39 GMT > header: Server: Apache/2.2.15 (Red Hat) > header: *Set-Cookie: ipa_session=bbf68dc97c054ade093fff2695eedbd2;* > Domain=IPAHOSTNAME; Path=/ipa; Expires=Wed, 12 Dec 2018 08:39:39 GMT; > Secure; HttpOnly > header: Connection: close > header: Content-Type: text/xml; charset=utf-8 > body: "<HIDDEN>' > uid: myUser > givenname: MyFirstName > sn: MyLastName > homedirectory: /home/myUser > loginshell: /bin/sh > mail: myMail > uidnumber: myUID > gidnumber: myGID > nsaccountlock: False > has_password: True > has_keytab: True > > The thing is, I don't know where this cookie is, to remove it. > Any idea where the cookie is guys ? Or any idea how could I destroy my > session ?
It is stored in the ccache. Use kdestroy -A to remove it. rob > > Best regards > > Lune > > Le sam. 3 nov. 2018 à 12:21, lune voo <[email protected] > <mailto:[email protected]>> a écrit : > > Hello ! > > Yes the clocks are insynced. I am going to try klist -ef next time > this problem occure. > > Lune. > > > Le jeu. 1 nov. 2018 à 18:49, Robbie Harwood <[email protected] > <mailto:[email protected]>> a écrit : > > lune voo via FreeIPA-users <[email protected] > <mailto:[email protected]>> > writes: > > > Hello ! > > > > I contact you because I have a random problem with my 3.0.0.47 > FreeIPA > > server. > > > > Sometimes, suddenly, I cannot use anymore the REST API and I > got the > > following errors when I try things like ipa user-show <myuser> : > > Insufficient access: SASL(-1): generic failure: GSSAPI Error: > Unspecified > > GSS failure. Minor code may provide more information (Ticket > expired)] > > traceback : <traceback object at 0x3b917a0> > > > > The kinit works fine, klist also. > > My ticket is valid until the day after so no problem from there. > > The datetime is the same between the IPA server and the IPA > client. > > > > When I check the httpd logs on the IPA server, as long as this > error lasts, > > I don't see any logs at all. > > For example, today, the problem occured at 12:06:39 and in the > HTTPD error > > logs : > > [Wed Oct 31 12:05:23 2018] [error] ipa: INFO: aPrincipal@MYREALM: > > user_show(u'anotherPincipal', rights=False, all=True, raw=False, > > version=u'2.49', no_members=False): SUCCESS > > [Wed Oct 31 12:07:23 2018] [error] ipa: INFO: aPrincipal@MYREALM: > > user_find(u'PrincipalPattern_', sizelimit=1000, whoami=False, > all=False, > > raw=False, version=u'2.49', no_members=False, > pkey_only=False): SUCCESS > > > > There is nothing in the dirsrv error logs at this time and > around this time. > > Nothing neither in the PKI CA logs. > > > > We are multiple users connecting to the same server with SSH > and using root. > > But each one of us use a different KRB5CCNAME to take a > kerberos ticket. > > (we take different ticket, me for example I take an admin > ticket, a > > colleague takes another principal ticket). > > > > I tried using the ipa user-show with the -d flag : ipa -d > user-show > > <myuser> and I compared the result between one which failed > and one which > > was successfull. > > The difference came at this step : > > > > When it failed : > > > > ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL > Server > > ipa: DEBUG: cert valid True for "CN=<IPA-MASTER>,O=<MYREALM>" > > ipa: DEBUG: handshake complete, peer = <IP>:443 > > ipa: DEBUG: Protocol: TLS1.2 > > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA > > ipa: DEBUG: Caught fault 2100 from server > > https://<IPA-MASTER>/ipa/session/xml: Insufficient access: > SASL(-1): > > generic failure: GSSAPI Error: Unspecified GSS failure. Minor > code may > > provide more information (Ticket expired) > > ipa: DEBUG: Destroyed connection context.xmlclient > > ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI > > Error: Unspecified GSS failure. Minor code may provide more > information > > (Ticket expired) > > > > > > When it succeeds : > > ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL > Server > > ipa: DEBUG: cert valid True for "CN=<IPA-MASTER>,O=<MYREALM>" > > ipa: DEBUG: handshake complete, peer = <IP>:<PORT> > > ipa: DEBUG: Protocol: TLS1.2 > > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA > > ipa: DEBUG: received Set-Cookie > > 'ipa_session=385454761d74afed915a24124ba5ef25; > Domain=<IPA-MASTER>; > > Path=/ipa; Expires=Wed, 31 Oct 2018 15:57:45 GMT; Secure; > HttpOnly' > > ipa: DEBUG: storing cookie > 'ipa_session=385454761d74afed915a24124ba5ef25; > > Domain=<IPA-MASTER>; Path=/ipa; Expires=Wed, 31 Oct 2018 > 15:57:45 GMT; > > Secure; HttpOnly' for principal <myPrincipal>@<MYREALM> > > ipa: DEBUG: args=keyctl search @s user > > ipa_session_cookie:<myPrincipal>@<MYREALM> > > ipa: DEBUG: stdout=485338998 > > > > ipa: DEBUG: stderr= > > ipa: DEBUG: args=keyctl search @s user > > ipa_session_cookie:<myPrincipal>@<MYREALM> > > ipa: DEBUG: stdout=485338998 > > > > ipa: DEBUG: stderr= > > ipa: DEBUG: args=keyctl pupdate 485338998 > > ipa: DEBUG: stdout= > > ipa: DEBUG: stderr= > > ipa: DEBUG: Destroyed connection context.xmlclient > > > > As a note, I found a workaround for that. I need to destroy my > ticket > > with kdestroy and then to disconnect from the server. Then when I > > connect back to the server, I take a kerberos ticket and I can > use the > > rest api. This problem is really strange, thank you in > advance for > > your help guys. > > Are the clocks in sync? Can you show `klist -ef` before and after a > failure? > > Thanks, > --Robbie > > > > _______________________________________________ > FreeIPA-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
