Re: WCF authentication and remote workstations
- From: stcheng@xxxxxxxxxxxxxxxxxxxx ("Steven Cheng")
- Date: Mon, 01 Dec 2008 02:21:38 GMT
{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}{\f1\fswiss\fprq2\fcharset134 System;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Thanks for your reply Frank,
\par
\par Yes, if you want to keep the solutio simple and always consistently use a single endpoint and authentication schema, then the two workarounds you mentioned are reasonable. Either make both VPN and non VPN connections use windows authentication or just completely use custom authentication.
\par
\par Anyway, if you have any further questions later, please feel free to post here.
\par
\par Sincerely,
\par
\par Steven Cheng
\par
\par Microsoft MSDN Online Support Lead
\par
\par
\par Delighting our customers is our #1 priority. We welcome your comments and suggestions about how we can improve the support we provide to you. Please feel free to let my manager know what you think of the level of service provided. You can send feedback directly to my manager at: msdnmg@xxxxxxxxxxxxxx
\par
\par \pard\li720 --------------------
\par Date: Fri, 28 Nov 2008 09:33:13 +0100
\par From: Frank Hauptlorenz <ecstasy.tribe@xxxxxxxxxxxxx>
\par User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
\par MIME-Version: 1.0
\par Subject: Re: WCF authentication and remote workstations
\par
\par Hi Steven,
\par
\par thanks for your answer. This confirms my speculation.
\par I think a way to get around this is
\par
\par a) move to another VPN solution, which can make our notebooks part of
\par the network
\par b) disable the authentication and use an own one
\par
\par For your Idea with another endpoint: nice idea but way to complicated.
\par
\par
\par Thank you,
\par Frank
\par
\par
\par Steven Cheng schrieb:
\par > Hi Frank,
\par >
\par > As for the WCF communcation scenario in your context, would you provide
\par > some further information about the binding and security configuration of
\par > the service/endpoint. For example, are you using transport layer security,
\par > let the runtime forward the windows credential automatically for use
\par > message laye security(such as username authentication to authenticate the
\par > client)?
\par >
\par > For the first one(windows authentication that let the client automatically
\par > forward the client security context(the current logon user). And I think
\par > this may somewhat cause the problem on your side. Because when the laptops
\par > are moved outside the domain. However, user can still logon the laptop via
\par > their domain credentials due to the cache, and I think it is likely that
\par > (when it works out side the domain), it is the cached domain credentials
\par > that's fowarded to server-side service. While in cases that the server may
\par > require the client to reauthenticate against their user identity, it failes
\par > since it's not in the domain. You can just put some trace code at
\par > server-side to print out the user identity. e.g.
\par >
\par > ====================
\par > OperationContext.Current.ServiceSecurityContext.WindowsIdentity
\par > ====================
\par >
\par > if the service is correctly called, and the security identity got at
\par > server-side correctly reflect the client user, that means the cached token
\par > are forwarded to server-side.
\par >
\par > BTW, for such kind of environment, do you think the following design will
\par > help?
\par >
\par > Since your client is possiblely be moved outside the domain, you may
\par > consider provide an additional endpoint. This endpoint may use a different
\par > security approach, such as message layer security(which can let the client
\par > manually supply username/password credentials). And whenever the default
\par > endpoint raise such security authentication error, your client app can
\par > switch to use another endpoint. What do you think?
\par >
\par >
\par > Sincerely,
\par >
\par > Steven Cheng
\par >
\par > Microsoft MSDN Online Support Lead
\par >
\par >
\par > Delighting our customers is our #1 priority. We welcome your comments and
\par > suggestions about how we can improve the support we provide to you. Please
\par > feel free to let my manager know what you think of the level of service
\par > provided. You can send feedback directly to my manager at:
\par > msdnmg@xxxxxxxxxxxxxx
\par >
\par > ==================================================
\par > Get notification to my posts through email? Please refer to
\par > http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
\par >
\par > Note: MSDN Managed Newsgroup support offering is for non-urgent issues
\par > where an initial response from the community or a Microsoft Support
\par > Engineer within 2 business day is acceptable. Please note that each follow
\par > up response may take approximately 2 business days as the support
\par > professional working with you may need further investigation to reach the
\par > most efficient resolution. The offering is not appropriate for situations
\par > that require urgent, real-time or phone-based interactions. Issues of this
\par > nature are best handled working with a dedicated Microsoft Support Engineer
\par > by contacting Microsoft Customer Support Services (CSS) at
\par > http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
\par > ==================================================
\par > This posting is provided "AS IS" with no warranties, and confers no rights.
\par > -------------------
\par > Date: Thu, 27 Nov 2008 12:40:03 +0100
\par > MIME-Version: 1.0
\par > Subject: WCF authentication and remote workstations
\par > Content-Type: text/plain; charset=ISO-8859-15; format=flowed
\par >
\par > Hi out there,
\par >
\par > we have an application which uses WCF to talk to our services with
\par > integrated security.
\par > Some of these workstations are notebooks which are someday within our
\par > company (connected to the LAN) and
\par > somedays outside (connected through an VPN (VPN-1 from checkpoint)).
\par >
\par > On somedays the WCF throws an exception for the outside clients. On some
\par > days it works.
\par > My idea is, the WCF does not trust the remote user profile (because it's
\par > not verified with the domain controller), but why it's then working
\par > sometimes?
\par >
\par > The error message is this one (german and translated from german to
\par > english):
\par >
\par > Die Vertrauensstellung zwischen dieser Arbeitsstation und der
\par > prim\f1\'e4\'72\f0 en Dom\f1\'e4\'6e\f0 e konnte nicht hergestellt werden.
\par >
\par > The domain trust between the workstation and the primary domain could not
\par > be established.
\par >
\par >
\par >
\par > Thank you for all ideas,
\par > Frank
\par >
\par >
\par >
\par \pard
\par
\par }
- Next by Date: RE: netsh error - 1312
- Next by thread: RE: netsh error - 1312
- Index(es):
Relevant Pages
|
