Re: [Freeipa-devel] [PATCH 64] Implement password based session login
John Dennis wrote: On 02/27/2012 05:53 PM, Rob Crittenden wrote: John Dennis wrote: On 02/27/2012 01:50 PM, Rob Crittenden wrote: John Dennis wrote: Attached is a revised patch, it addresses the following concerns raised during review: * The version in ipa.conf has been bumped. * Rob reported duplicate session cookies being returned. As far as I can tell this was due to a Python bug where it reused the value of a default keyword parameter from a previous invocation rather than re-initializing it. Workaround is to change the default value from [] to the value to None and create an empty list if the arg is None. * Rob reported two test failures, one for ERRNO (e.g. **1234**) not being present in the docstring for an error I added and the other was for a change in the wsgi dispatch route() method that showed up in test_rpcserver.py The Requires on krb5-workstation is not required. The server requires the client which requires it. Yeah, I wasn't sure about that, now I know. OK, fixed I think you need a more unique way of generating the ccache name when doing the kinit (I'd use tempfile.mkstemp). Why? The session code is already set up to use a "temporary" ccache file for each request it processes (your suggestion). The file is created when the request comes, exists for the duration of the request, and is deleted when the request completes. Is there a compelling reason to treat initializing a ccache in a request from using a ccache in a request? Ok, I think this is fine. I thought you were storing the name of the file and since there is no way to predict which Apache subprocess would handle a given request there would have been a chance of collision. Since you always use the current pid as the name it is fine (as long as we never use the worker model). There is an incorrect comment in internal_error() Good catch, OK fixed. You want to return 401 Unauthorized and not 403 Forbidden on password failures. That wasn't an accident, I read the RFC for 401 and 403. The RFC for 401 states "The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource." But we're not doing Basic Auth here and we're not returning challenges as spec'ed out in the other RFC's, this is something a bit different so I concluded 401 was not appropriate. But I also see your point about 403 not being quite right either. I'm happy to change it to 401 though, your point is well taken, it's probably closer to being correct OK, fixed Hmm, yeah. I think we'll need to see what the browsers do when they get a 401 and no WWW-authenticate back. We shouldn't support the GET method as the password will appear in the logs: 192.168.0.1 - - [27/Feb/2012:13:46:31 -0500] "GET /ipa/session/login_password?user=admin&password=password HTTP/1.1" 200 - Good point, OK, fixed revised patch coming soon ... revised patch has arrived ... see attachement ACK, pushed to master and ipa-2-2 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
On 02/27/2012 05:53 PM, Rob Crittenden wrote: John Dennis wrote: On 02/27/2012 01:50 PM, Rob Crittenden wrote: John Dennis wrote: Attached is a revised patch, it addresses the following concerns raised during review: * The version in ipa.conf has been bumped. * Rob reported duplicate session cookies being returned. As far as I can tell this was due to a Python bug where it reused the value of a default keyword parameter from a previous invocation rather than re-initializing it. Workaround is to change the default value from [] to the value to None and create an empty list if the arg is None. * Rob reported two test failures, one for ERRNO (e.g. **1234**) not being present in the docstring for an error I added and the other was for a change in the wsgi dispatch route() method that showed up in test_rpcserver.py The Requires on krb5-workstation is not required. The server requires the client which requires it. Yeah, I wasn't sure about that, now I know. OK, fixed I think you need a more unique way of generating the ccache name when doing the kinit (I'd use tempfile.mkstemp). Why? The session code is already set up to use a "temporary" ccache file for each request it processes (your suggestion). The file is created when the request comes, exists for the duration of the request, and is deleted when the request completes. Is there a compelling reason to treat initializing a ccache in a request from using a ccache in a request? Ok, I think this is fine. I thought you were storing the name of the file and since there is no way to predict which Apache subprocess would handle a given request there would have been a chance of collision. Since you always use the current pid as the name it is fine (as long as we never use the worker model). There is an incorrect comment in internal_error() Good catch, OK fixed. You want to return 401 Unauthorized and not 403 Forbidden on password failures. That wasn't an accident, I read the RFC for 401 and 403. The RFC for 401 states "The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource." But we're not doing Basic Auth here and we're not returning challenges as spec'ed out in the other RFC's, this is something a bit different so I concluded 401 was not appropriate. But I also see your point about 403 not being quite right either. I'm happy to change it to 401 though, your point is well taken, it's probably closer to being correct OK, fixed Hmm, yeah. I think we'll need to see what the browsers do when they get a 401 and no WWW-authenticate back. We shouldn't support the GET method as the password will appear in the logs: 192.168.0.1 - - [27/Feb/2012:13:46:31 -0500] "GET /ipa/session/login_password?user=admin&password=password HTTP/1.1" 200 - Good point, OK, fixed revised patch coming soon ... revised patch has arrived ... see attachement -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ >From 8166749325a388d9237c668582fd6e80594517fe Mon Sep 17 00:00:00 2001 From: John Dennis Date: Sat, 25 Feb 2012 13:39:19 -0500 Subject: [PATCH 64-2] Implement password based session login Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit * Adjust URL's - rename /ipa/login -> /ipa/session/login_kerberos - add /ipa/session/login_password * Adjust Kerberos protection on URL's in ipa.conf * Bump VERSION in httpd ipa.conf to pick up session changes. * Adjust login URL in ipa.js * Add InvalidSessionPassword to errors.py * Rename krblogin class to login_kerberos for consistency with new login_password class * Implement login_password.kinit() method which invokes /usr/bin/kinit as a subprocess * Add login_password class for WSGI dispatch, accepts POST application/x-www-form-urlencoded user & password parameters. We form the Kerberos principal from the server's realm. * Add function krb5_unparse_ccache() * Refactor code to share common code * Clean up use of ccache names, be consistent * Replace read_krbccache_file(), store_krbccache_file(), delete_krbccache_file() with load_ccache_data(), bind_ipa_ccache(), release_ipa_ccache(). bind_ipa_ccache() now sets environment KRB5CCNAME variable. release_ipa_ccache() now clears environment KRB5CCNAME variable. * ccache names should now support any ccache storage scheme, not just FILE based ccaches * Add utilies to return HTTP status from wsgi handlers, use constants for HTTP status code for consistency. Use utilies for returning from wsgi handlers rather than duplicated code. * Add KerberosSession.finalize_kerberos_acquisition() method so different login handlers can share common code. * add Requires: krb5-workstation to server (server now calls kinit) * Fix test_rpcserver.py to use new dispatch inside route() method --- install/conf/ipa.conf | 10 +- install/ui/ipa.js |2 +- ipalib/errors.py
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
John Dennis wrote: On 02/27/2012 01:50 PM, Rob Crittenden wrote: John Dennis wrote: Attached is a revised patch, it addresses the following concerns raised during review: * The version in ipa.conf has been bumped. * Rob reported duplicate session cookies being returned. As far as I can tell this was due to a Python bug where it reused the value of a default keyword parameter from a previous invocation rather than re-initializing it. Workaround is to change the default value from [] to the value to None and create an empty list if the arg is None. * Rob reported two test failures, one for ERRNO (e.g. **1234**) not being present in the docstring for an error I added and the other was for a change in the wsgi dispatch route() method that showed up in test_rpcserver.py The Requires on krb5-workstation is not required. The server requires the client which requires it. Yeah, I wasn't sure about that, now I know. OK, fixed I think you need a more unique way of generating the ccache name when doing the kinit (I'd use tempfile.mkstemp). Why? The session code is already set up to use a "temporary" ccache file for each request it processes (your suggestion). The file is created when the request comes, exists for the duration of the request, and is deleted when the request completes. Is there a compelling reason to treat initializing a ccache in a request from using a ccache in a request? Ok, I think this is fine. I thought you were storing the name of the file and since there is no way to predict which Apache subprocess would handle a given request there would have been a chance of collision. Since you always use the current pid as the name it is fine (as long as we never use the worker model). There is an incorrect comment in internal_error() Good catch, OK fixed. You want to return 401 Unauthorized and not 403 Forbidden on password failures. That wasn't an accident, I read the RFC for 401 and 403. The RFC for 401 states "The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource." But we're not doing Basic Auth here and we're not returning challenges as spec'ed out in the other RFC's, this is something a bit different so I concluded 401 was not appropriate. But I also see your point about 403 not being quite right either. I'm happy to change it to 401 though, your point is well taken, it's probably closer to being correct OK, fixed Hmm, yeah. I think we'll need to see what the browsers do when they get a 401 and no WWW-authenticate back. We shouldn't support the GET method as the password will appear in the logs: 192.168.0.1 - - [27/Feb/2012:13:46:31 -0500] "GET /ipa/session/login_password?user=admin&password=password HTTP/1.1" 200 - Good point, OK, fixed revised patch coming soon ... ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
On 02/27/2012 01:50 PM, Rob Crittenden wrote: John Dennis wrote: Attached is a revised patch, it addresses the following concerns raised during review: * The version in ipa.conf has been bumped. * Rob reported duplicate session cookies being returned. As far as I can tell this was due to a Python bug where it reused the value of a default keyword parameter from a previous invocation rather than re-initializing it. Workaround is to change the default value from [] to the value to None and create an empty list if the arg is None. * Rob reported two test failures, one for ERRNO (e.g. **1234**) not being present in the docstring for an error I added and the other was for a change in the wsgi dispatch route() method that showed up in test_rpcserver.py The Requires on krb5-workstation is not required. The server requires the client which requires it. Yeah, I wasn't sure about that, now I know. OK, fixed I think you need a more unique way of generating the ccache name when doing the kinit (I'd use tempfile.mkstemp). Why? The session code is already set up to use a "temporary" ccache file for each request it processes (your suggestion). The file is created when the request comes, exists for the duration of the request, and is deleted when the request completes. Is there a compelling reason to treat initializing a ccache in a request from using a ccache in a request? There is an incorrect comment in internal_error() Good catch, OK fixed. You want to return 401 Unauthorized and not 403 Forbidden on password failures. That wasn't an accident, I read the RFC for 401 and 403. The RFC for 401 states "The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource." But we're not doing Basic Auth here and we're not returning challenges as spec'ed out in the other RFC's, this is something a bit different so I concluded 401 was not appropriate. But I also see your point about 403 not being quite right either. I'm happy to change it to 401 though, your point is well taken, it's probably closer to being correct OK, fixed We shouldn't support the GET method as the password will appear in the logs: 192.168.0.1 - - [27/Feb/2012:13:46:31 -0500] "GET /ipa/session/login_password?user=admin&password=password HTTP/1.1" 200 - Good point, OK, fixed revised patch coming soon ... -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
John Dennis wrote: Attached is a revised patch, it addresses the following concerns raised during review: * The version in ipa.conf has been bumped. * Rob reported duplicate session cookies being returned. As far as I can tell this was due to a Python bug where it reused the value of a default keyword parameter from a previous invocation rather than re-initializing it. Workaround is to change the default value from [] to the value to None and create an empty list if the arg is None. * Rob reported two test failures, one for ERRNO (e.g. **1234**) not being present in the docstring for an error I added and the other was for a change in the wsgi dispatch route() method that showed up in test_rpcserver.py The Requires on krb5-workstation is not required. The server requires the client which requires it. I think you need a more unique way of generating the ccache name when doing the kinit (I'd use tempfile.mkstemp). There is an incorrect comment in internal_error() You want to return 401 Unauthorized and not 403 Forbidden on password failures. We shouldn't support the GET method as the password will appear in the logs: 192.168.0.1 - - [27/Feb/2012:13:46:31 -0500] "GET /ipa/session/login_password?user=admin&password=password HTTP/1.1" 200 - rog ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
Attached is a revised patch, it addresses the following concerns raised during review: * The version in ipa.conf has been bumped. * Rob reported duplicate session cookies being returned. As far as I can tell this was due to a Python bug where it reused the value of a default keyword parameter from a previous invocation rather than re-initializing it. Workaround is to change the default value from [] to the value to None and create an empty list if the arg is None. * Rob reported two test failures, one for ERRNO (e.g. **1234**) not being present in the docstring for an error I added and the other was for a change in the wsgi dispatch route() method that showed up in test_rpcserver.py -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ >From 0a3758276e75d540cecce72703a744fa37e26f14 Mon Sep 17 00:00:00 2001 From: John Dennis Date: Sat, 25 Feb 2012 13:39:19 -0500 Subject: [PATCH 64-1] Implement password based session login Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit * Adjust URL's - rename /ipa/login -> /ipa/session/login_kerberos - add /ipa/session/login_password * Adjust Kerberos protection on URL's in ipa.conf * Bump VERSION in httpd ipa.conf to pick up session changes. * Adjust login URL in ipa.js * Add InvalidSessionPassword to errors.py * Rename krblogin class to login_kerberos for consistency with new login_password class * Implement login_password.kinit() method which invokes /usr/bin/kinit as a subprocess * Add login_password class for WSGI dispatch, accepts either GET or POST application/x-www-form-urlencoded user & password parameters. We form the Kerberos principal from the server's realm. * Add function krb5_unparse_ccache() * Refactor code to share common code * Clean up use of ccache names, be consistent * Replace read_krbccache_file(), store_krbccache_file(), delete_krbccache_file() with load_ccache_data(), bind_ipa_ccache(), release_ipa_ccache(). bind_ipa_ccache() now sets environment KRB5CCNAME variable. release_ipa_ccache() now clears environment KRB5CCNAME variable. * ccache names should now support any ccache storage scheme, not just FILE based ccaches * Add utilies to return HTTP status from wsgi handlers, use constants for HTTP status code for consistency. Use utilies for returning from wsgi handlers rather than duplicated code. * Add KerberosSession.finalize_kerberos_acquisition() method so different login handlers can share common code. * add Requires: krb5-workstation to server (server now calls kinit) * Fix test_rpcserver.py to use new dispatch inside route() method --- freeipa.spec.in|1 + install/conf/ipa.conf | 10 +- install/ui/ipa.js |2 +- ipalib/errors.py |7 + ipalib/krb_utils.py| 13 +- ipalib/session.py | 79 +++ ipaserver/plugins/xmlserver.py |5 +- ipaserver/rpcserver.py | 248 +--- tests/test_ipaserver/test_rpcserver.py |8 +- 9 files changed, 279 insertions(+), 94 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 47d0f28..0388453 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -95,6 +95,7 @@ Requires: nss Requires: nss-tools Requires: krb5-server >= 1.9.2-6 Requires: krb5-pkinit-openssl +Requires: krb5-workstation Requires: cyrus-sasl-gssapi%{?_isa} Requires: ntp Requires: httpd diff --git a/install/conf/ipa.conf b/install/conf/ipa.conf index cd806be..89c9849 100644 --- a/install/conf/ipa.conf +++ b/install/conf/ipa.conf @@ -1,5 +1,5 @@ # -# VERSION 3 - DO NOT REMOVE THIS LINE +# VERSION 4 - DO NOT REMOVE THIS LINE # # LoadModule auth_kerb_module modules/mod_auth_kerb.so @@ -60,7 +60,13 @@ KrbConstrainedDelegationLock ipa # Turn off Apache authentication for sessions - + + Satisfy Any + Order Deny,Allow + Allow from all + + + Satisfy Any Order Deny,Allow Allow from all diff --git a/install/ui/ipa.js b/install/ui/ipa.js index a599f6a..433d7fe 100644 --- a/install/ui/ipa.js +++ b/install/ui/ipa.js @@ -60,7 +60,7 @@ var IPA = function() { // if current path matches live server path, use live data if (that.url && window.location.pathname.substring(0, that.url.length) === that.url) { that.json_url = params.url || '/ipa/session/json'; -that.login_url = params.url || '/ipa/login'; +that.login_url = params.url || '/ipa/session/login_kerberos'; } else { // otherwise use fixtures that.json_path = params.url || "test/data"; diff --git a/ipalib/errors.py b/ipalib/errors.py index bdc4a5e..df4ab41 100644 --- a/ipalib/errors.py +++ b/ipalib/errors.py @@ -612,6 +612,13 @@ class SessionError(AuthenticationError): format= _('Session error') +class InvalidSessionPassword(SessionError): +""" +**1201** Raised when we
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
On Sun, 2012-02-26 at 11:22 -0500, John Dennis wrote: ... > There is one other minor issue not included in any previous patches nor > this one, the VERSION file should be updated to force the apache > configuration to be updated. Thanks for the patches John, a lot of work have been done. I would just like to clarify there. Its install/conf/ipa.conf that needs updating. In my previous mail, I was talking about these lines: install/conf/ipa.conf: # # VERSION 3 - DO NOT REMOVE THIS LINE # ... I wouldn't call it a minor issues as session features just would not work in upgraded machines without ipa.conf file updated. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
On 02/26/2012 04:40 PM, Rob Crittenden wrote: John Dennis wrote: On 02/26/2012 03:54 PM, John Dennis wrote: I assume you're running the script I attached. The reason why you keep getting new sessions is because the script does not send the previous cookie back, from the server's perspective these all appear to be new login requests. Sessions are not tracked by user, they are tracked by session id. I should have added that if this was being invoked from the browser UI like it is intended to be the cookie would be retransmitted by the browser and you wouldn't see this behavior. I think what you're seeing is an artifact of the clumsy way I cobbled together a test since we don't have a UI yet. But I will verify this in a little while. I would have expected to have gotten a brand new session with each request and yet it seems to be associating existing sessions as well. I'm fine with a new session each time but otherwise this could leak data. I reproduced the problem you were seeing, but in the middle of debugging it I got stuck because my vm is flaking out. All of sudden I'm getting errors about files missing, no space on device, etc. Yet df shows I've got plenty of space. I rebooted but it didn't help. Either something is very wrong all of a sudden on my vm or something is wrong on it's host. But I'll have to pick this up tomorrow. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
John Dennis wrote: On 02/26/2012 03:54 PM, John Dennis wrote: I assume you're running the script I attached. The reason why you keep getting new sessions is because the script does not send the previous cookie back, from the server's perspective these all appear to be new login requests. Sessions are not tracked by user, they are tracked by session id. I should have added that if this was being invoked from the browser UI like it is intended to be the cookie would be retransmitted by the browser and you wouldn't see this behavior. I think what you're seeing is an artifact of the clumsy way I cobbled together a test since we don't have a UI yet. But I will verify this in a little while. I would have expected to have gotten a brand new session with each request and yet it seems to be associating existing sessions as well. I'm fine with a new session each time but otherwise this could leak data. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
On 02/26/2012 03:54 PM, John Dennis wrote: I assume you're running the script I attached. The reason why you keep getting new sessions is because the script does not send the previous cookie back, from the server's perspective these all appear to be new login requests. Sessions are not tracked by user, they are tracked by session id. I should have added that if this was being invoked from the browser UI like it is intended to be the cookie would be retransmitted by the browser and you wouldn't see this behavior. I think what you're seeing is an artifact of the clumsy way I cobbled together a test since we don't have a UI yet. But I will verify this in a little while. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
On 02/26/2012 03:38 PM, Rob Crittenden wrote: John Dennis wrote: This patch adds support for password based session login (see detailed comments in patch) Only the server side is implemented, someone will have to add password based login to the UI, when they do they should update the unauthorized messges to include the new method, those message occur in two places. * in install/html/unauthorized.html * in the function error_handler() in install/ui/ipa.js:442 Sending the login requires sending the username (not the principal) and password as application/x-www-form-urlencoded parameters in a GET or POST request. Note, I only tested GET, but POST should work. Attached is a curl script I used to test (send_login_password). There is one other minor issue not included in any previous patches nor this one, the VERSION file should be updated to force the apache configuration to be updated. If one keeps running the script more and more cookies get set each time (it seems to add a new session every other request). I ended up with: < HTTP/1.1 200 Success < Date: Sun, 26 Feb 2012 20:36:38 GMT < Server: Apache/2.2.21 (Fedora) < Set-Cookie: ipa_session=905b903b164cc8449a1619f610012ad0; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=296d1c815326806be5dc609593950787; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=0a3ddb3e43f093f54acac0568bf2c8af; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=df4b39d4fe659ebfc401ee154c32fd1d; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=10ce26f372355b7ed2d11f34dbce8edf; httponly; Path=/ipa; secure < Content-Length: 0 < Connection: close < Content-Type: text/plain; charset=UTF-8 < * Closing connection #0 It also looks like some of the sessions only appear from time to time. For example, the next request I did did not contain 905b903b164cc8449a1619f610012ad0 but the one after that did again. I assume you're running the script I attached. The reason why you keep getting new sessions is because the script does not send the previous cookie back, from the server's perspective these all appear to be new login requests. Sessions are not tracked by user, they are tracked by session id. FWIW, there is a curl option to resend the cookies from the response it saved last time, I did not enable that in the script, but you could try it if you wish. I'm not sure about the every other request behavior, I'll look into that. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 64] Implement password based session login
John Dennis wrote: This patch adds support for password based session login (see detailed comments in patch) Only the server side is implemented, someone will have to add password based login to the UI, when they do they should update the unauthorized messges to include the new method, those message occur in two places. * in install/html/unauthorized.html * in the function error_handler() in install/ui/ipa.js:442 Sending the login requires sending the username (not the principal) and password as application/x-www-form-urlencoded parameters in a GET or POST request. Note, I only tested GET, but POST should work. Attached is a curl script I used to test (send_login_password). There is one other minor issue not included in any previous patches nor this one, the VERSION file should be updated to force the apache configuration to be updated. If one keeps running the script more and more cookies get set each time (it seems to add a new session every other request). I ended up with: < HTTP/1.1 200 Success < Date: Sun, 26 Feb 2012 20:36:38 GMT < Server: Apache/2.2.21 (Fedora) < Set-Cookie: ipa_session=905b903b164cc8449a1619f610012ad0; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=296d1c815326806be5dc609593950787; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=0a3ddb3e43f093f54acac0568bf2c8af; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=df4b39d4fe659ebfc401ee154c32fd1d; httponly; Path=/ipa; secure < Set-Cookie: ipa_session=10ce26f372355b7ed2d11f34dbce8edf; httponly; Path=/ipa; secure < Content-Length: 0 < Connection: close < Content-Type: text/plain; charset=UTF-8 < * Closing connection #0 It also looks like some of the sessions only appear from time to time. For example, the next request I did did not contain 905b903b164cc8449a1619f610012ad0 but the one after that did again. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel