-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lifetime of credentials #33
Comments
I think it is a bug, we do not handle lifetime, that I can see at a glance. |
But I need to reprouce to figure out what is the issue. In either case I am surprised the mechglue interposer is not making a call to gssproxy to get the lifetime? |
Sure, gssproxy log for that steps:
The overall process is:
diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py
index 095e74b2a..c46da7c15 100644
--- a/ipaserver/plugins/ldap2.py
+++ b/ipaserver/plugins/ldap2.py
@@ -199,6 +199,18 @@ class ldap2(CrudBackend, LDAPCache):
else:
os.environ['KRB5CCNAME'] = ccache
+ import time
+ import gssapi
+ time.sleep(25)
+ from pdb_clone import pdb
+ pdb.set_trace_remote()
+
+ store = {'ccache': ccache}
+ creds = gssapi.Credentials(
+ usage="initiate", name=None, store=store
+ )
+ creds.lifetime
+
principal = krb_utils.get_principal(ccache_name=ccache)
client.gssapi_bind(server_controls=serverctrls,
I modified (in FreeIPA PR) Next (in the same method) auth_tokens = ldap.sasl.sasl({}, 'GSS-SPNEGO')
conn = ldap.initialize(
"ldapi://%2Frun%2Fslapd-IPA-TEST.socket",
)
conn.sasl_interactive_bind_s('', auth_tokens, None, None) It seems that gssproxy on every
after expiration and
|
I do not see why krb_utils.get_princpial would raise any exception, the information is available, then fact a ccache is expired does not invalidate it's contents. Have you checked what's in creds.lifetime? As for the behavior on initiate: |
Ok, so setting name=None if you mean to test "admin" credentials is definitely not ok given's gssproxy configuration for HTTP, so the log you gave me is not useful, as I see that what happens is that a new credential based on client_keytab is returned. |
Based on the current behaviour of python-gssapi for non-gssproxy env I expect
So, I can't know the principal name from expired creds using python-gssapi.
Yes, this is the actual behaviour I see. |
The problem is that you are calling this: |
that example is for non-gssproxy environment. |
I see that. I'm just trying to demonstrate you the issue. Regarding
result for valid (not expired) creds is some constant value (not changed from call to call for credentials instance):
log: Instantiation of Credentials on expired creds:
|
Ok, so the second one is kind of expected, given gss-proxy cannot get you creds for admin and the original creds are expired. @frozencemetery do you know if we have a test setup somewhere that I can use to try this out ? |
Hi, not really sure what you're asking for. Long-lived machines isn't a thing we can do on our infrastructure. If you need a KDC set up, you could use gssapi-console, but it's only a handful of commands to set one up (or fewer, if you use IPA). |
It seems gssproxy doesn't expose lifetime of credentials or doesn't do it properly.
In IPA env(WSGI, GSS_USE_PROXY=yes) I inquire the lifetime of creds as:
which always show the initial lifetime of credentials (in my example it was always 20) even the credentials are expired.
While the decrypted ccache
shows the correct remaining lifetime of creds and raises with
ExpiredCredentialsError
on expiration.Is such proxied lifetime's behaviour expected, bug or not implemented yet?
The text was updated successfully, but these errors were encountered: