@Tony Clews: Hi Tony, I have passed your request on to the C9 team. Please see my blog post here, http://bit.ly/k52dWk, and here, http://bit.ly/m6cGnG, for the Excel resources that I have just recently posted to MSDN in support of these two videos.
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.
guercheLE:
It appears that you need to adjust your syntax just a bit to:
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
Comments
Reimagine SharePoint Development: A better way to customize SharePoint
These three samples are published on Code Gallery:
SharePoint 2013: Retrieve user profile information in an app part
https://code.msdn.microsoft.com/officeapps/SharePoint-2013-Retrieve-3e573eb4#content
SharePoint 2013: Add list item properties with a remote event receiver
https://code.msdn.microsoft.com/SharePoint-2013-Add-list-2c6e71e0
SharePoint 2013: Create a taxonomy group in an app for SharePoint
https://code.msdn.microsoft.com/SharePoint-2013-Create-a-cc760cfc
Designing Excel Solutions for the Web: Part 1
@Tony Clews: Hi Tony, I have passed your request on to the C9 team. Please see my blog post here, http://bit.ly/k52dWk, and here, http://bit.ly/m6cGnG, for the Excel resources that I have just recently posted to MSDN in support of these two videos.
Demystified Series: WinForms App Single Sign On in 2 Lines of Code!
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.
guercheLE:
It appears that you need to adjust your syntax just a bit to:
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
This should fix it.