Moved DB, now Users can't login to my web app.

  • NuJoizey (7/17/2008)


    yes there are a few ways to get who the user is, but when I moved over the app the current way the app is using stopped working. It shouldn't do that, so of course it must be something with either the IIS permissons or SQL Server permissions. I've looked at each like 1000 times and I can't seem to find where the difference is.

    I am by no means an expert on permissions and user configurations, but I surmise by examinining the logins and security folders that the answer your question is as follows:

    In our companywide active directory, there is a group called STAFF that contains everyone in the company. The sql server grants a login to STAFF, which maps to a local db user called STAFF. I'm fairly certain that any new employee is added by our domain admin to STAFF, and so also has certain rights to the SQL server.

    Right now the way it works is when a new user comes on board, I need to enter that person's windows login domain/username into the DB. The web app grabs the who is logged in using VB.NET code and checks it against the DB. If the person currently logged in has a record in the DB, then they have full access to all of the apps features, but if not, the user name displays "not logged in", and that user can browse certain things, but not others.

    And the problem is that my app thinks that everyone is not logged in, even valid users. Nothing in the ASP.NET code changed, so it's gotta be something with the permissions somewhere - right?

    Based on the process you describe above you do not need to allow anonymous connections to the Web App since all the users are part of the domain and as long a the STAFF AD group has rights to the Web App. You only need to allow anonymous if you are getting connections from outside the domain.

    Since you are not getting an error saying that you cannot connect to the database or for invalid username/password, but are getting your coded "not logged in" user name message then you are successfully connecting to the database and the issue is that the query against the DB user table is not returning any data.

    I suggest running Profiler against the database, taking the Audit Login, SP:StmtCompleted, and T-SQL:StmtCompleted events and filtering on the Database_ID. Then you will see the SQL that is being passed from the web app to the database and can see what value is being passed for user name.

  • Jack,

    you are on the right track, but I think the problem occurs even before that. The code uses the VB.NET my.user.name expression as a parameter to get the current username. The reason why the DB isn't returning any value (and rightly so) is becuase the my.user.name expression is returning "", and so it queries the database for user name "", which of course doesn't return any records, thus generating the "not logged in" message

    The crux of the matter is why my.user.name isn't returning who is currently logged in, because as I understand it, my.user.name is supposed to already contain the domain and username of the user who started the app session.

    I think it has something to do with anonymous login, but other than that.....i'm at an impasse.

    I've never run profiler, as you have suggested, it probably would be good for me to learn, but I suspect it would simply show that the SQL is passing "" for the user name. But maybe I'll try that anyway.

  • If you already know you are passing "" to SQL Server then you won't learn anything using Profiler. The version of the .NET framework installed on the IIS Server could potentially be an issue as well.

    As I said in the last post, it sounds like you do not need to allow Anonymous access so you should disable that anyway.

  • good suggestion about the .NET framework version, but I just checked and it's the same. RATS! I am beginning to think that perhaps the setup in the old environment where Anon. Access was enabled is actually the faulty behavior, and what I am experiencing now is by design?

    I inhereted this project, so I am having trouble discerning this system's behaviour as i wasn't privvy to its initial configuration.

  • NuJoizey (7/17/2008)


    Todd,

    hey, thanks so much for your response, this got me a step closer - Disabling anonymous does indeed solve the immediate problem of my app not seeming to recognize who is logged in. It now recognizes a valid user. However, the system was designed with the intent that an anonymous user is still able to browse the app without having to necessarily log in, but is just not able to do certain things.

    Now if try to access the URL with an account that isn't in the system, or try to access it over terminal services, I get prompted with a login box. This isn't the intended behavior.

    So my greater question - is this indeed strictly an SQL Server permissions issue? - because the permissons seem to work under certain conditions - but something is still messed up - but what is it? argh!

    The prompt in IE for existing users is a client-side issue on the Terminal Servers. It's probably not seeing your new webserver as part of your "Intranet".

    Anonymous access was enabled in the working environment? What credentials was that using? Are the web.config files between the ASP.NET applications the same as far as authentication settings?

  • Anonymous access was enabled in the working environment?

    yep.

    What credentials was that using?

    IUSR account with Read, Write, Read&Execute and ListFolder Contents permissions

    Are the web.config files between the ASP.NET applications the same as far as authentication settings

    it certainly should be. All I did was copy the site from one server to the other.

  • Sorry if this was already mentioned. I just skimmed the thread. It's long!

    Logon to the web server, right-click My Computer > Manage > IIS. Right click on whatever the website or webapp in question is and choose Properties. Under Directory Security > Authentication access control, choose Edit...

    Is Integrated Windows authentication checked? If not, try checking it.

  • thanks Rob - yep, it's checked.

  • Since anonymous access was enabled that sounds like an NTFS permission issue on the website folder.

    For example, you might have to remove the I_USR_ user and the Users group, leaving your STAFF group as a member.

  • Hi,

    have u made changes in webconfig file through which application works

    just check the server name,usr name ,password and database.

    it may work chekc this.;)

  • to all who posted, a hearty thanks to all of you, because after considering everyone's input i finally was able to diagnose what was going on here - and as I thought, it was pretty simple, but I just kept overlooking it.

    What I have come to believe what was vexing me in this situation was that the old system configuration that I had become used to using (which was not set up by me) was the "hack" so to speak, but it took me a while to figure that out.

    So when I started with a clean configuration, the "by design" behaviour looked like the anamoly, when it really wasn't.

    The bottom line is that I belive now that in the IIS security settings, anonymous access should in fact be disallowed. What was confusing me mostly was that on some of the servers where the app was configured, a virtual directory had been configured in the default website which had been left running, which pointed to the app. This allowed the app to called in two ways, like so:

    http://myApp, or http://SeverName/myApp, and different bookmarks used different URL's.

    simple answer, yet kind of maddening to figure out.

    I now also believe the reason that I could not browse directly on the server where that app resides becuase i kept getting a u/n p/w prompt is due to the IE7 high security setting that by default severely curtiails browsing from a server. That behaviour was being circumvented by the virtual directory in the old environment. A good trick, but confusing if no documentation left about it!!!

Viewing 11 posts - 16 through 25 (of 25 total)

You must be logged in to reply to this topic. Login to reply