Re: Help with SASL/GSSAPI to remote Kerberos server
Russ Allbery wrote:
Quanah Gibson-Mount<quanah(a)zimbra.com> writes:
> The other major difference between MIT and Heimdal is the behavior when
> a ticket expires. With MIT, any existing connections will stop
> working. With Heimdal, existing connections will continue to work, just
> new connections will fail until the ticket is renewed. I strongly
> prefer the Heimdal behavior if using something like SASL/GSSAPI for
> doing replication with persistent connections.
True. The problem is that the Heimdal behavior is arguably wrong from a
security standpoint. Once the ticket has expired, all products of that
ticket should be treated as expired; otherwise, someone who's Kerberos
principal has been revoked can continue to access services past the
expiration of their ticket, which violates the Kerberos security model.
Perhaps, but it adheres to the Unix security model - that is, once you have
access to a resource, you can use it until you're done with it. Likewise,
slapd will not terminate connections for clients that are currently bound but
whose credentials have subsequently been disabled, by whatever means. And, the
per-connection group ACL caching means that whatever group privileges you had
at the start of your session remain yours, even if someone removes you from
various groups while your connection is active.
The right thing to do would be to rekey the persistant connection
with a
new ticket, but I don't know if the underlying protocols support that.
It's possible to establish a new SASL security context on an existing LDAP
session, just by starting a new SASL Bind.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/