SQL User Manager Login Screen

  • 26 November 2004
  • 9 replies
  • 2 views

Badge +2
We're using K2 SP1a, SQL User Manager 3.4201.1.0 and the SP1a SQLUM Patch to investigate the option of using SQL User Manager for clients who have not yet rolled out Active Directory across their enterprise.

We have been able to authenticate successfully within our own bespoke web pages (simply by adding the appropriate connection string to all our calls to K2ROM.Connection.Open). But we are having some strange problems authenticating in the workspace page.

We have found that the SQLUM Login page always results in the error "The request failed with HTTP status 401: Unauthorized". If instead we call the Workspace.aspx page direct with the ServerName and Connstr parameters explicitly included in the workspace URL then the first attempt to do this usually gives us the same 401 error, but the second and subsequent attempts always work OK.

Any idea why we would be getting this erratic authentication behaviour in the workspace/login pages?

9 replies

Badge +9
Hi,

Please see if the following resolves the issue:

1. Add the Authenticated Users group to the following directory C:WINDOWSTemp and give them Read and Write access on the folder.
2. Add the Authenticated Users group to the following directory C:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Files and give them Read and Write access on the folder.
3. Test K2.net 2003 Workspace

A 401 Access denied error on IIS has got to do with local security on your IIS Machine, also try to play around with File Security on your actual K2WS ( C:Program FilesK2.net 2003K2WS ) folders.
As a last resort, change the IIS Site settings in IIS Manager so that K2V3/Workspace allows Anonymous.

Please note: Keep track of changes made, if a change has no effect always reset the settings back to default.

Please let me know!!
Badge +2
Thanks for the suggestions. Sadly they did not seem to work for us.

Fortunately we now appear to have solved our problem. We've written a dummy ASPX page that gets the current authenticated user ID and uses this to construct a connection string. It then redirects to the Workspace page with the URL arguments needed to log on. Seems to work remarkably smoothly.

Here's the Page_Load routine of our dummy ASPX page (the user never sees this page as it simply redirects to the Workspace page):

private void Page_Load(object sender, System.EventArgs e)
{
// Get the connection string from Web.config
string connstr = ConfigurationSettings.AppSettings["K2ConnectionString"];

// Construct workspace page URL
string url = "Workspace.aspx";
if (connstr!= null)
{
// Get the server and user names from current context
string serverName = HttpContext.Current.Server.MachineName;
string userName = HttpContext.Current.User.Identity.Name;

// Add server name and connection string to URL arguments
connstr = connstr.Replace("[UserName]", userName);
url += "?ServerName=" + serverName + "&Connstr=" + connstr;
}

// Redirect to the workspace page
HttpContext.Current.Response.Redirect(url, false);
}
Badge +9
That s good news just one question to make sure I do understand your workaround?

Do you follow the following path to login:

Login.htm --> Dummy.aspx --> Workspace.aspx

Thanks.
Badge +2
We don't use Login.htm. The user selects AutoLogin.aspx (that's the name of our dummy ASPX page) to start the workspace. We've set up our SQLUM database to identify all users by their Windows user name (eg MYDOMAINmyname), and we've assigned the same hardcoded password to all users. We rely on Windows to authenticate the user (this happens automatically since we've disabled anonymous access to our web site). We then simply use the Windows authenticated user name together with our hardcoded password to log into the workspace.

So the only login screen the user ever sees is the standard Windows login screen. The use of a hard-coded password in the SQLUM database does not introduce any security problems since the user must get past Windows authentication before they are allowed to use the system.
Badge +9
I guess the only question from my side is Why then use the SQL User Manager?
Badge +2
As I mentioned in my original posting, we were looking for a way to deploy K2 to clients who do not have Active Directory yet as they are still using NT domains.
Badge +9
Ok :wink:
Badge +3
I am currently, working on a project that will use K2 for workflow. The company is still on an NT doamin (Active directory is not an option)

So far obtaining any information about SQL User Manager have been extremely difficult.

Please HELP!

Any feed back regarding documentations and postive and or negative experience inplmenting SQL User Manager would be greatly appreciated.

K2 support please note...the download page at the k2 portal do not have the SQL User Manager components.
Badge +1
Hi .. please do login to k2.net partner portal and go here

Downloads-> additional components.

While downloading please keep in mind that do not use asian mirror as it gives some cotrrupted pdf. Please user african mirror. There is one Pdf available for sql user manager. go through it i think it;s good.

cheers and best of luck

Reply