hi,
i'm writing an AD client for mac i'm able to get a kerberos ticket and can also bind to AD using ldap_gssapi_bind and everything works fine I can do searches modify/create attributes etc.
when I unbind and try to bind to a different server, it hangs in a "select" call inside openldap lib. even though I've successfully got a TGS ticket before binding.
I'm using heimdal for kerberos implementation. I also have cyrusSASL in the project.
in one of my test environments it tries to go back to old "server" to get ticket. so I'm assuming there is some sort of caching involved here.
before rebinding I always delete the credential cache file and krb5.conf and re create them for new server.
I'm not using an conf file with openldap.
What could be going on is there some kind of caching somewhere in library?
there are no errors when unbinding and I can also see a call getting to server when I unbind.
Thanks..
On 06/02/12 16:42 -0700, Sajid K wrote:
hi,
i'm writing an AD client for mac i'm able to get a kerberos ticket and can also bind to AD using ldap_gssapi_bind and everything works fine I can do searches modify/create attributes etc.
when I unbind and try to bind to a different server, it hangs in a "select" call inside openldap lib. even though I've successfully got a TGS ticket before binding.
Can you attach gdb to your process and get a backtrace at the point you are hanging on the select?
I'm using heimdal for kerberos implementation. I also have cyrusSASL in the project.
in one of my test environments it tries to go back to old "server" to get ticket. so I'm assuming there is some sort of caching involved here.
When you say that it tries to go back to the old server to get a ticket, do you mean that it requests the same service ticket from your kdc? Or that it does not request a new service ticket and uses the existing ticket when connecting to the new server?
before rebinding I always delete the credential cache file and krb5.conf and re create them for new server.
I'm not using an conf file with openldap.
What could be going on is there some kind of caching somewhere in library?
there are no errors when unbinding and I can also see a call getting to server when I unbind.
Do you have an example of your code to look at? Are you using the same "LDAP *ld" between the two calls? If so, does it make a difference if you use a separate *ld reference that is newly ldap_init'd?
ok I've figured it out. gssapi seems to be caching the security context and for whatever reason there is no function to delete it. but atleast I've the source and can always put one in myself.
On Mon, Jun 4, 2012 at 7:44 AM, Dan White dwhite@olp.net wrote:
On 06/02/12 16:42 -0700, Sajid K wrote:
hi,
i'm writing an AD client for mac i'm able to get a kerberos ticket and can also bind to AD using ldap_gssapi_bind and everything works fine I can do searches modify/create attributes etc.
when I unbind and try to bind to a different server, it hangs in a "select" call inside openldap lib. even though I've successfully got a TGS ticket before binding.
Can you attach gdb to your process and get a backtrace at the point you are hanging on the select?
I'm using heimdal for kerberos implementation. I also have cyrusSASL in
the project.
in one of my test environments it tries to go back to old "server" to get ticket. so I'm assuming there is some sort of caching involved here.
When you say that it tries to go back to the old server to get a ticket, do you mean that it requests the same service ticket from your kdc? Or that it does not request a new service ticket and uses the existing ticket when connecting to the new server?
before rebinding I always delete the credential cache file and krb5.conf
and re create them for new server.
I'm not using an conf file with openldap.
What could be going on is there some kind of caching somewhere in library?
there are no errors when unbinding and I can also see a call getting to server when I unbind.
Do you have an example of your code to look at? Are you using the same "LDAP *ld" between the two calls? If so, does it make a difference if you use a separate *ld reference that is newly ldap_init'd?
-- Dan White
openldap-technical@openldap.org