You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in this PR #249CanCacheTickets property was introduced in order to fix issue #248
publicboolCanCacheTicket=>this.CacheTicket??true&&string.IsNullOrWhiteSpace(this.S4uTarget)&&// is this line needed ?this.S4uTicket==null&&this.S4uTargetCertificate==null;
But when we pass string s4u to GetServiceTicket - it looks like tickets can be cached - because s4u goes to Container string parameter in TicketCacheEntry and allows to correctly identify record in cache.
In our case we are calling http service from backend service on behalf of the user in many parallel threads - every call to GetServiceTicket(..., s4u: username) goes to KDC (because ticket for user is not cached) and we running out of SocketPool in case of many threads (even if TcpKerberosTransport.MaxPoolSize increased).
We have workarounds on this: locking call to GetServiceTicket or using SemaphoreSlim(TcpKerberosTransport.MaxPoolSize,TcpKerberosTransport.MaxPoolSize) before it ... but it looks too rude
The text was updated successfully, but these errors were encountered:
Ish. It's more designed to prevent polluting caches that don't understand S4U which would be very bad security-wise. Making that work requires reworking the cache system a bit.
in this PR #249
CanCacheTickets
property was introduced in order to fix issue #248But when we pass string
s4u
toGetServiceTicket
- it looks like tickets can be cached - becauses4u
goes toContainer
string parameter inTicketCacheEntry
and allows to correctly identify record in cache.It will not break the test case described in #248
In our case we are calling http service from backend service on behalf of the user in many parallel threads - every call to
GetServiceTicket(..., s4u: username)
goes to KDC (because ticket for user is not cached) and we running out of SocketPool in case of many threads (even if TcpKerberosTransport.MaxPoolSize increased).We have workarounds on this: locking call to GetServiceTicket or using SemaphoreSlim(TcpKerberosTransport.MaxPoolSize,TcpKerberosTransport.MaxPoolSize) before it ... but it looks too rude
The text was updated successfully, but these errors were encountered: