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.
When I check the logs in cli.log, I find this kind of lines : 2018-10-31T12:06:39Z 1933 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:39Z 1933 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:06:39Z 1947 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:39Z 1947 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:06:40Z 1961 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:40Z 1961 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:06:40Z 1975 MainThread ipa.ipalib.rpc.xmlclient INFO trying https://<IPA-MASTER>/ipa/xml 2018-10-31T12:06:40Z 1975 MainThread ipa.ipalib.rpc.xmlclient INFO Forwarding 'user_show' to server u'https://<IPA-MASTER>/ipa/xml' 2018-10-31T12:07:27Z 2159 MainThread ipa INFO The ipactl command was successful 2018-10-31T12:07:27Z 2160 MainThread ipa INFO The ipactl command was successful
I cannot see anything special in the krb5kdc.log neither for this time. The only line corresponding to the IP of the client are the followings : Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: NEEDED_PREAUTH: <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM>, Additional pre-authentication required Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: NEEDED_PREAUTH: <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM>, Additional pre-authentication required Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): closing down fd 10 Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137188](info): closing down fd 10 Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: ISSUE: authtime 1540983984, etypes {rep=18 tkt=18 ses=18}, <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM> Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): AS_REQ (4 etypes {18 17 16 23}) <IP CLIENT>: ISSUE: authtime 1540983984, etypes {rep=18 tkt=18 ses=18}, <MYUSER>@<MYREALM> for krbtgt/<MYREALM>@<MYREALM> Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): closing down fd 10 Oct 31 12:06:24 <IPA-MASTER> krb5kdc[137181](info): closing down fd 10
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
So when it works, it sets a session cookie ? Some information about FreeIPA and cookies : https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
May you help me please ?
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.
Lune
lune voo via FreeIPA-users 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
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 a écrit :
lune voo via FreeIPA-users 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
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%5Cr%5Cn*Cookie: ipa_session=bbf68dc97c054ade093fff2695eedbd2;*\r\nUser-Agent: xmlrpclib.py/1.0.1 (by 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 ?
Best regards
Lune
Le sam. 3 nov. 2018 à 12:21, lune voo 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 a écrit :
lune voo via FreeIPA-users 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
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%5Cr%5Cn 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.fedorahoste...
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%5Cr%5Cn 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.fedorahoste...
lune voo via FreeIPA-users wrote:
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 ?
Depending on the release you are using it is best practice to use rpcclient instead of xmlclient (should operate the same either way).
It is a good idea to call disconnect in general, cleaner that way. It won't affect the session at all but it'll free up server resources.
rob
Best regards.
Lune
Le mer. 19 déc. 2018 à 15:11, Rob Crittenden <rcritten@redhat.com mailto: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> > <https://IPAHOSTNAME/ipa/xml%5Cr%5Cn>*Cookie: > ipa_session=bbf68dc97c054ade093fff2695eedbd2;*\r\nUser-Agent: > xmlrpclib.py/1.0.1 <http://xmlrpclib.py/1.0.1> <http://xmlrpclib.py/1.0.1> (by www.pythonware.com <http://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> > <mailto: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> > <mailto: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> > <mailto: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 <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto: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 >
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.fedorahoste...
freeipa-users@lists.fedorahosted.org