Re: Problem with control hosted in IE

From: bogdanutz (bogdanc_at_teamnet.ro)
Date: 10/06/04

  • Next message: Michael Willers: "Re: Modifying Secuirty Policy"
    Date: Wed, 6 Oct 2004 10:19:19 +0300
    
    

    10x for responding.

    It's dissapointing that i can not access those credentials. I have some
    questions though:

    1. Why is it a security vulnerability to access those: I have access to the
    DefaultCredentials so
    what damage could be done by accessing those from IE.

    2. When a control loads in IE, an application domain is created with the
    evidence
    of the security zone from wich the code originated but without any knowledge
    of the security
    level of the assembly that will be loaded - that i can understand ... but
    why doesn't the application domain
    get from ie some knowledge of the user ?

    10x

    "Nicole Calinoiu" <ngcalinoiu REMOVETHIS AT gmail DOT com> wrote in message
    news:e$C5xowqEHA.2340@TK2MSFTNGP11.phx.gbl...
    > The control is running on the client machine, so the default credentials
    are
    > taken from the client context. These will be the Windows logon from the
    > client machine, not the credentials you entered into IE for use when
    sending
    > HTTP requests to the server.
    >
    > Basically, there is no way to read the cached IE credentials from within
    > your control (it would be a fairly big security vulnerability if you
    could),
    > so you'll need to choose an alternate approach such as one of the
    following:
    >
    > 1. Make a separate credentials request to the user from within your
    > control, then use these credentials when communicating with the web
    service.
    >
    > 2. If you're in an intranet or extranet scenario, allowing access by
    > appropriate domain accounts (which would be the client-side Windows login
    > accounts) may be a possibility.
    >
    > 3. Re-design this piece of the application so that the communication
    > between client and server would be a bit less cumbersome. One possibility
    > might be use of a stand-alone Windows Forms client to communicate with the
    > web service. Another might be removing the Windows Forms portion entirely
    > and using a plain old web UI.
    >
    > HTH,
    > Nicole
    >
    >
    >
    > "bogdanutz" <bogdanc@teamnet.ro> wrote in message
    > news:OajIVltqEHA.536@TK2MSFTNGP09.phx.gbl...
    > >I have a windows control that resides in a strong named assembly. The
    > > assembly has the AllowPartialyTrustedCallers attribute.
    > > On the server the dll that contains the control is in a virtual
    directory
    > > that also contains a webService.
    > > The virtual directory's authentication is windows (as the
    application's -
    > > i'm using impersonation).
    > >
    > > The windows control is embeded in a page with the "object" tag.
    > > I logon to another machine using a local account (not one that the IIS
    > > could
    > > now).
    > > When i request this page from that machine IE request that i give him a
    > > windows account name and password and after that
    > > the internet explorer loads the assembly just fine, but when trying to
    > > access the web service mentioned eralier
    > > IIS returns a security exception (401).
    > >
    > > Before calling any method of the web service , i set the web service's
    > > credentials to System.Net.CredentialCache.DefaultCredentials.
    > > Upon inspecting the server's event log, under security, i found a
    "Failure
    > > Audit":
    > >
    > > Logon Failure:
    > > Reason: Unknown user name or bad password
    > > User Name: Administrator
    > > Domain: VM_2KPRO_GOL
    > > Logon Type: 3
    > > Logon Process: NtLmSsp
    > > Authentication Package: NTLM
    > > Workstation Name: VM_2KPRO_GOL
    > > Caller User Name: -
    > > Caller Domain: -
    > > Caller Logon ID: -
    > >
    > > The logon failure refers to the name "Administrator" , the local account
    I
    > > used to logon to the machine, not the one I gave to IE.
    > > The documentation refering to
    > > System.Net.CredentialCache.DefaultCredentials
    > > says that it will USUALLY(?) give the windows
    > > credentials.
    > >
    > > So,what is the problem , is there another way to access the service with
    > > windows authentication?
    > >
    > > (I tried also with anonymus access on IIS and the web service and forms
    > > authentication for the app but the cookie is not sent along with the
    > > request
    > > for the web service
    > > so there is no way for me to authenticate the user)
    > >
    > > Thanx
    > >
    > >
    >
    >
    >
    >


  • Next message: Michael Willers: "Re: Modifying Secuirty Policy"

    Relevant Pages

    • Re: Linux client in Windows Domain (Security Advice)
      ... I have a windows environment and all clients are XP controled with strict security measures controled via group policy etc. ... one of the other IT guys has a liux client that sits out side most of these systems. ... (You've probably worked out I'm a windows man with very basic Linux experience. ...
      (microsoft.public.windows.server.sbs)
    • Re: Problem with control hosted in IE
      ... The control is running on the client machine, so the default credentials are ... These will be the Windows logon from the ... > I logon to another machine using a local account (not one that the IIS ...
      (microsoft.public.dotnet.security)
    • Re: What are the ~DFnnnn.tmp files?
      ... Is there a security risk in getting ... >opened, in various folders. ... NTFS is only available in Windows NT / ... kiosk window openned after signin so that after the client ...
      (microsoft.public.security)
    • Re: Recommended Windows Hosts
      ... not the one where security holes are aggresively addressed and ... just bill the client ... > Back on the Unix vs. Windows: I like ASP, but the constant security ... > holes in Windows keep me from hosting clients on the Windows platform. ...
      (microsoft.public.frontpage.client)
    • [NT] Domain Password Logon Authentication Bug in Windows 2000 Advanced Server Domain Controller
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... A security vulnerability in a mixed environment of Windows 2000, NT, and ... characters is used (uppercase and lowercase characters are treated in the ... client must type the password exactly the same (on a default installation ...
      (Securiteam)