Thanks Rob.

Hm, thinking about this, this problem occured only when I use the python code for ipa api.

When I begin my script, I perform the following :
api.bootstrap_with_global_options(context='cli')
api.finalize()
api.Backend.xmlclient.connect()
When I end my script, I just do a kdestroy command in python.
Do I need to perform a disconnect() also ?

Best regards.

Lune





Le mer. 19 déc. 2018 à 15:11, Rob Crittenden <rcritten@redhat.com> a écrit :
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 <lune.voo1234@gmail.com
> <mailto:lune.voo1234@gmail.com>> 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 <rharwood@redhat.com
>     <mailto:rharwood@redhat.com>> a écrit :
>
>         lune voo via FreeIPA-users <freeipa-users@lists.fedorahosted.org
>         <mailto:freeipa-users@lists.fedorahosted.org>>
>         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 -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
> 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/freeipa-users@lists.fedorahosted.org
>