Symptoms
Multi Domain Authentication nolonger works after upgrading to K2 Blackpearl 4.6.9
Diagnoses
After upgrading to K2 Blackpearl 4.6.9, multi domain no longer works and keep getting the error below for non primary domain users. This is now broken in our UAT and Production environment and this is critical for us as we have users in multiple domains.
Error
An error occurred trying to authenticate the user.
More Details
Exception Details:
System.Security.Authentication.AuthenticationException: The user name or password is incorrect. ---> System.Runtime.InteropServices.COMException: The user name or password is incorrect. at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.PropertyValueCollection.PopulateList() at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) at System.DirectoryServices.PropertyCollection.get_Item(String propertyName) at System.DirectoryServices.ActiveDirectory.PropertyManager.GetPropertyValue(DirectoryContext context, DirectoryEntry directoryEntry, String propertyName) --- End of inner exception stack trace --- at System.DirectoryServices.ActiveDirectory.PropertyManager.GetPropertyValue(DirectoryContext context, DirectoryEntry directoryEntry, String propertyName
Resolution
Admin's were previously able to restrict access to SmartForms by configuring authorization rules in the web.config of the SmartForms Application to users in specific roles (as per http://help.k2.com/KB001309_).
With the new STS Authentication (469), the user is directed to the STS where after they are authenticated and then returned back to the SmartForms application as expected. After adding this new authorization rule, it appears that they are not seen as authenticated in the application and then redirected back to the STS. This loop continues until a ”multiple Authentication attempts” error occurs.
Basically the STS did not want to resolve the Group on the Claim, so IIS could not do authentication on groups on the claims. So now we are resolving the users groups and add this on the claim so that IIS authorization could work with the claim on group level .
So in a very small and simple nutshell ... For us to allow Clients the ability to restrict SmartForms Designer/Runtime access via IIS Authentications Rules set to AD Groups , we had to change elements of how our WindowsSTS works . I have asked that they log this additional requirement for future versions