Delegation fails over remoting if user is logged in for too long

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am currently using .NET 2.0's secure TCP channel for remoting, and have run
into a problem where if a user doesn't log out for a while (usually seems to
be about two days), delegation fails. Having the user log off and back on
fixes the problem (as does locking and unlocking the workstation).

The user is still identified (their username is being retrieved through
Thread.CurrentPrincipal), but when I impersonate the user and try to execute
a database query (using Windows Authentication) I receive a SqlException:
"Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection."

The client config file contains:
<channel ref='tcp' secure='true' impersonate="true"
tokenImpersonationLevel="Delegation" protectionLevel='EncryptAndSign'
servicePrincipalName="serviceuser@domain">
<clientProviders>
<formatter ref='binary' />
</clientProviders>
</channel>

and the server config file contains:
<channel ref="tcp" port="8081" secure="true"
tokenImpersonationLevel="Delegation" protectionLevel="EncryptAndSign">
<serverProviders>
<formatter ref="binary" />
</serverProviders>
</channel>

When impersonating, I am using this code:
If TypeOf Thread.CurrentPrincipal.Identity Is WindowsIdentity Then
context = DirectCast(Thread.CurrentPrincipal.Identity,
WindowsIdentity).Impersonate()
End If

Because this code does not throw an exception, I think the CurrentPrincipal
is a GenericPrincipal instead of a WindowsPricipal.

Why is the user principal not being authenticated as a WindowsPrincipal if
the user stays logged in for a long period of time?
 
Hi,

I've seen similar stuff on terminal servers (not .NET related) when users
are logged in for a long time. It may be related to Kerberos ticket times.
By default a ticket is valid for 10 hours (this parameter is configurable).
As far as I know, delegation uses kerberos so the problem you're having may
be related to that.

I don't have any solution for you, but you could look into it, and possible
reduce the kerberos ticket times to se if you get the errors more quickly,
or extend the time and see if the problem occurs much later.


Arild
 
Welcome to the MSDN newsgroup.

From your description, you're using the .net 2.0 remoting to build the
remote communication between clent and server machine. Also, you've
configured the client remoting channel(tcp) to supply delegation
impersonateLevel security token so that the server application can use the
token to request further remote resources. This worked well , however, you
found that the windowsIdenitity no longer delegatable after long period(two
days), correct?

Based on my experience, this behavior is likely due to the kerberos
authentication's ticket expiration timeout. As for the remoting, when we
configure it to forward delegatable windows identity, it will require the
client and server machine to use Kerberos as the authenitcation protocol.
And kerberos authenitcation is based on authentication ticket issued by
KDC(in windows domain, it is the DC generally), however, the ticket has
limited lifecycle which means after certain period , it will expires. And
whether the ticket can be renewable or how much is the max lifecycle is
configured in the KDC (kerberos policy), you can have a look at the
following msdn reference on kerberos policy:

#Kerberos Policy
http://msdn.microsoft.com/library/en-us/secauthn/security/kerberos_policy.as
p?frame=true

So for your scenario, I think you can consider adjusting your remoting
component's code logic according to such limiation. If your application
will run over long time, I suggest you disconnect the remote object after
certain period and let the client reconnect the next time.

Hope this helps.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Steven, yes you are correct. You and Arild both mentioned expiring kerberos
tickets, which is what I also thought the problem was. I have no control
over the experation time, though I will check with the AD group and see what
they currently have it set to.

So for your scenario, I think you can consider adjusting your remoting
component's code logic according to such limiation. If your application
will run over long time, I suggest you disconnect the remote object after
certain period and let the client reconnect the next time.
Click to expand...

Users continue to get the error even after closing the application and
starting it back up again. What else would I need to do to get it to
reconnect with the new kerberos ticket? Is something being cached that I
need to explicitly close/disconnect?

Thank you,
Adam Hughes
 
Thanks for your response Adam,

So event after you restart the client program does the user still get the
problem? If the behavior remains after the client recreate new server
remote objects, I'm thinking whether the token is cached by the server
objects at server-side. Is the remote object used in your application a SAO
and use singleton mode? If so, I suggest you try dispose the server object
and then republish one programmatically at serverside and let the client to
connect it to see whether it can accept new authenticated token.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Steven Cheng said:
So event after you restart the client program does the user still get the
problem?
Click to expand...

Yes. The user must either log off and back on, or lock and unlock their
workstation for the application to work again. The log on/off method fixes
the problem for about 2 days, and the lock/unlock method only fixes the
problem for a few hours (or sometimes minutes). The lock/unlock method works
even while the program is running.

Restarting the client program does not fix the problem.
If the behavior remains after the client recreate new server
remote objects, I'm thinking whether the token is cached by the server
objects at server-side. Is the remote object used in your application a SAO
and use singleton mode?
Click to expand...

The object is registered as SingleCall.

Part of the server remoting config:
<service>
<wellknown mode="SingleCall" type="MyAssembly, MyClass" objectUri="MyUri" />
</service>

The client application uses the following code to retrieve the object:
Dim proxy as IMyClass =
DirectCast(RemotingServices.Connect(GetType(IMyClass),
"tcp://server:8081/MyUri"), IMyClass)

Thanks,
Adam Hughes
 
Thanks for your response Adam,

So restarting the client program won't help. How about the server
application, will restart it change the behavior? If also not, that'll be
really tough. The RemotingServices.Marshal Method can help manually
marshal an SAO remotable object out, you can try using this method to
marshal a new object and let client-side call it to see whether the
authenticated identity is windowsIdentity. I'm fearing that the behavior is
related to the registered channel , if so, that'll be really hard to
refresh it without restart the remoting runtime.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Steven,

Restarting the windows service that hosts the remoting object does not fix
the problem either. I've tried all combinations of restarting the client
application, and the service, and both at the same time and the error still
occurs.

I don't think that I can use RemotingServices.Marshal because the mode is
SingleCall, so a new object is created with each call into the remoting
object. I can't publish an existing object.

I also don't think it is related to the registered channel, because I have
closed the client application, restarted the service, and started the client
application again and the problem still occurs. If it was the remoting
channel, the problem would have been fixed by restarting the client
application, but that doesn't fix it.

After searching around for a while, I found someone else having a problem
that could be related. See this email list:
http://rcmail.vintela.com/pipermail/putty/2005-August.txt and search for a
message that mentions KB885887. I will request the hotfix listed in KB885887
and see if that solves the problem. If it does this means that this is a
Windows problem, and not a .NET problem.

Any other suggestions would be appreciated.

Thanks,
Adam Hughes
 
Thanks for your followup Adam,

I'll have a look at that article and do some further research on this. I'll
update you soon.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Hi Adam,

How are you doing on this issue. I've taken a look at that article,
however, still haven't any clues on the related behavior in .net remoting.
Have you got progress after apply that hotfix?

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Hi Steven,

I've taken over from Adam on this project. We have not had an
opportunity to test the hotfix mentioned before--it's annoying to get
the ones that aren't available for download. However, I compared the
copy of kerberos.dll on my computer to the version listed in the KB
article, and mine is newer:

mine: kerberos.dll, 2005-06-15, 5.1.2600.2698
hotifx: kerberos.dll, 2004-11-17, 5.1.2600.2565

So, I doubt the hotfix would help.

I have not made any further progress on this problem. The research
that Adam and I did, which is detailed earlier in this thread, has
exhausted our avenues of inquiry. That is why we posted here, in hopes
of getting some more explanation, a work-around, or--ideally--a fix
from Microsoft.

If you can't help, could you please recommend someone who can?

Thanks very much for keeping tabs on this thread.
 
Thanks for your followup Will,

Based on my current research, this issue is quite difficult to perform
furhter troubleshooting due to the limitation of newsgroup support facade.
If this is an urgent or big issue in your product development, I would
recommend you contact CSS to open an regular support incident on this and
the product support team's engineer will help perform thorough
troublelshooting on this.

Thanks for your understanding.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Back
Top