Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Demystified Series: WinForms App Single Sign On in 2 Lines of Code!


Right click “Save as…”

Welcome to the Demystified Series where we seek to identify and present the strategic and critical pieces of information that a developer needs to get up and running, and feel confident, in building identity-aware, directory-enabled applications.

Many developers are unaware of two information rich objects available to them for role-based validation and that can also be leveraged to verify authenticated access, essentially single sign on (SSO), to their application because the user has already logged onto the desktop. These are the WindowPrincipal and WindowsIdentity objects. The purpose of this screencast is to demystify how to leverage the rich information these objects provide – starting with just 2 lines of code.

Sample code for this screencast is available here:

For further information regarding Identity and Access Management, please visit:


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • Very cool:P

    What are you using behind the scenes? Is this basic AD? I am wondering how I would set this up.
  • Luciano Evaristo GuercheguercheLE guerchele


    In Microsoft Visual Basic 2005 Express Edition, the line of code below


    gives me the following error

    Value of type 'System.Security.Principal.PrincipalPolicy' cannot be converted to 'System.Security.Policy.PolicyLevel'.

  • neilhut:
    Thanks! The great thing about using the WindowsPrincipal and WindowsIdentity objects is that there is no set up required – yet these encapsulate information about Windows accounts whether the machine is domain attached or not. Therefore, simply pull in the appropriate namespace(s) and instantiate the objects required for either your single or repeated validation use. From there, if desired, the developer can interrogate the Name property to evaluate for a specific DOMAIN\ requirement for access to the application. The application could then be terminated with an error prompt based on the evaluation or possibly pop up another form to collect credentials for authentication to another identity store. Also, the Type property shows the type of authentication used to identify the user – Kerberos, NTLM, etc. There may be business reasons for the application to also make decisions based on this information.

    It appears that you need to adjust your syntax just a bit to:

    This should fix it. Smiley

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.