Does the offending value of memberUid correspond to something specially related to the modify operation? E.g. to the identity that is performing the modification, or is any other operation 'round when the hang occurs?
The memberUids in this example are completely fictitious, so they don't have any connection to the uids of real users. The thing I find particularly intriguing is that I can change whether or not the update is successful by simply adding or removing a single digit on the last memberUid. If the last memberUid is 7 characters long (i.e. t247800), the modification goes through fine. However, if the last memberUid is 8 or more characters long (i.e. t2478000), then the operation hangs indefinitely.
Is your GSSAPI somehow related to LDAP?
We use GSSAPI for write authorization. I sent a copy of our slapd.conf file a few messages back, that should show the appropriate configuration details.
Are credentials actually stored in the same slapd you're modifying?
I'm not sure I understand the question. Yes, account information is stored in the slapd database I'm modifying, but not the specific entry I'm modifying. The actual authorization happens through GSSAPI, so authorization for write access is actually happening via kerberos. Does this answer your question?
Mark