This code was used once to get the Current user's windows logon name.
The application was published on a webserver and this code worked to get the end user's Windows Logon Name, so how could this happen when this code is actually running in the code behind on the server itself?
Dim CurrentUser As String = System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString
Please explain to me if you can.
IIS has a mode called Windows Authentication which (usually when combined with Internet Explorer) will authenticate the user with the server automatically and enable this functionality.
For this to work you usually have to disable anonymous access.
Related
I'm just in the process of trying to properly configure asp.net 4.5 on our IIS servers.
I have been able to navigate and launch an ASPX page that contains no data conenctions sucessfully so I know that the application pool authentication to the local directories is working as it should.
Now though I have a seperate SQL server that is connected to the domain and have a connection string stored in the code that connects the ASPX page to the server using a trusted connection. When running in visual studio debug mode, the connection works fine - but at that point I assume it is using my login credentials.
My question is, when a user calls the aspx page via the browser when hosted on the new IIS7 server, which account is used to call the SQL server when using a trusted connection? - Is it the end users or is it a local account from the IIS server?
When I call a page with data connections embedded I get the error: Login failed for user ADMIN\PCNAME$ ... which is an indication that this is the account that it is using. However this account doesn't exist on the domain that I'm aware of. - Or does it ?!
Thanks in advance,
It will use the account that ASP.NET is running under, as you've worked out. What you usually should do is create a Domain Account (with the right privileges) and run your ASP.NET AppPool under that account. Then a Trusted Connection will use that account for connecting to the database, and as long as you've given it access (which as a Domain Account you can do) it should all work.
Added:
After some back and forth on comments, lets go back to the start: set the new AppPool to run with the domain users account, and recycle the AppPoolo. What is it that says the password is wrong? If it's IIS trying to start the AppPool, then it is extremeny likely that the Password you gave the AppPool IS wrong, or else that the password is set to change on first logon.
If its not IIS, but opening a Database connection, are you sure that the database allows this Domain Account access to the database and the tables within it it will need? What roles have you assigned to this account? Also, what SQL statement is it trying to execute (if it's got far enough to try and execute a statement at all)?
I suggest you put any response in you original question - comments get to be a drag if there are too many of them.
I have written my own windows service which interacts with a SQL database and updates it. The service was running fine and seems to be functioning correctly, however of late it seems to go down at random times and cannot restart due to the error designated in the question. I have tried various searches to fix this, but unfortunately I have come up with nothing. The aim is to eventually having this service running on my companies server, but I can't adjust any server settings, I am but a user on the server, so I have restrictions to some settings.
Any quick fixes, would be helpful!
Open the Services Manager. ( Win + R, then type services.msc )
Then right click on the SQL Server process and click Properties
Then go to Log On, and select This account:
Then click Browse, and add your username in the box. (Notice it should contain the domain, in my case is AD\myusername), then Check Names and accept.
Finally type your password in the other two fields, and that's it, you should have permission to start your process now.
Cheers!!
One issue for us was the format of the account user name, we initially used
domain\username
and got the 1069-logon error, then ultimately I tried validating the user name in the properties | logon tab of the Service (in Control Panel / Service Manager), using the "Browse" and "Search" for the user name and it turned it suggested and validated ok with the reverse format
username#domain
This also worked and resolved the 1069 error, and let us script the startup using sc.exe.
Error 1069 is vague and can have different causes. I am sharing my experience here.
I encountered this error when trying to get a service to run under my account (I am trying to get my services to see the same LocalDB as interactive processes running on my account for development purposes). I use an MSA (Microsoft Account) with Windows’s PIN login normally, so I rarely enter my Windows password. To resolve the issue, I locked my screen, selected Password input instead of PIN input, and then entered my password. I assume this somehow reminded Windows what my password was and made my local account more legit.
Before doing this, you need to configure the user account in question to have the Logon as Service privilege. To do this, open the Group Policy Editor. Expand Computer / Windows Configuration / Security Configuration / Local Policies / User Permissions Assignment and then open Login as Service. From there, you can add your user in question.
also check for "Deny Logon service" policy.
user should not be added over there
We had this issue as well because the account was set so that the password expired. After we updated the account to not expire and set the password this error stopped.
The account could also be locked out. To unlock it, you only need to change that user's password (new and old password can be the same).
What also worked for me was re-entering the password in the services->LogOn window. Even when you think the account and password is correct, re-entering it will re-grant the account permission to log on as a service.
I've got an Application under my Default Web Site in IIS 7 and whenever I try to access another document on the same domain (but different machines), File.Exists returns False, even though the document does exist and I can access it just fine from the machine hosting the site. The AD portion of the setup appears to be working fine, I'm just not able to access documents on different machines in the domain. Here's my IIS setup:
Application Pool: .NET 4.0, Integrated Pipeline, and using the ApplicationPoolIdentity Identity. I've tried using NetworkService but that didn't seem to make a difference.
Authentication: My Application has only ASP.NET Impersonation and Windows Authentication enabled. The bin folder is the same.
If there's anything else relevant to IIS set up, please let me know and I'll get it added.
I've also tried granting my machine full permissions on the folder that has the document (which is on another machine in the same domain) which I'm trying to access. That didn't seem to make a difference either.
Has anyone come across this before or know of anything else I can try or know of any IIS settings I can check? If there's anything else relevant that I can include in my setup, please let me know!
UPDATE:
Is it possible to find out what identity is being used or who is being impersonated when System.IO.File.Exists() is called, or more specifically find out who that method impersonates as? I've tried checking Thread.CurrentPrincipal.Identity.Name right before calling File.Exists() and it correctly returns my domain user.
So it appears that isn't the user being impersonated when File.Exists() executes. What's more is that if, in IIS, I change the ASP.NET Impersonation (in Authentication settings) to use my specific domain user, everything works fine! But when I change it back to use the "Authenticated User", it doesn't?
I can also confirm that calling Principal.WindowsIdentity.GetCurrent.Name() right before File.Exists() also returns the correct domain user.
UPDATE 2:
I've also tried setting the Application Pool Identity to my specific domain user, which doesn't seem to make a difference either. At this point, I'm not sure what other account it could be impersonating as when checking if the file exists?
UPDATE 3:
I've tried using Process Monitor on the machine which has the documents I'm trying to access, but when I filter it down to the file type I'm looking for (or expecting to see), nothing shows up when I re-run my tests. I can only assume doing a File.Exists() on a file you don't have access to, doesn't register to the Process Monitor? Are there any other ways for me to find out which impersonated user/service is trying (unable) to access these documents?
UPDATE 4:
Using the examples found by #john below, I've tried to programmatically impersonate the logged in user before checking if the file exists:
Dim wID As WindowsIdentity = HttpContext.Current.User.Identity
Dim ctx As WindowsImpersonationContext = Nothing
ctx = wID.Impersonate()
If System.IO.File.Exists(sFile) Then
Else
'Still gets here?
End If
However, File.Exists() still returns false even when impersonating.
UPDATE 5 (SOLUTION):
I needed this:
Using ctx As System.Security.Principal.WindowsImpersonationContext = System.Security.Principal.WindowsIdentity.Impersonate(IntPtr.Zero)
'My code here
End Using
In IIS, select your website, then goto Authentication, select Windows Authentication,
Select Advanced Settings -> make sure kernel mode is enabled
Select Provider, check if Negotiate is the first item in the mapping
When you test only use IE and running from your Intranet.
Also you can impersonate a specific user, goto ASP.NET impersonation, specify the user who has access to the remote directory.
So here's a bit of context for the horror story:
Win 2003 SP2 64bit running on a VM exposed to outside world for web access.
SQL Server 2008 Std SP2 64bit with Reporting Services (RS) installed for native mode (i.e. not sharepoint mode).
IIS 6 .NET 3.5 web site app written to use the web services from RS. The site has been set to use Windows Authentication and nothing else.
To save writting custom authentication since I don't need it for this demo I have set-up a local account in Win 2003, i.e. servername\myDemoUser, effectively allow fake Windows Authentication.
Default.aspx lists folders on RS and the reports from each folder. It also has a link to the Report Builder 2 on the server.
The rsreportserver.config has been changed so that the only <AuthenticationType> is <RSWindowsNTLM> since <RSWindowsNegoiate> can't work since it's across the internet and users will not be on the same network (hence the local account myDemoUser).
The web site app has url of the form: http://mysite.mydomain.co.uk/ and the link on it to the Report Builder is of the form: http://mysite.mydomain.co.uk/services/reportbuilder/reportbuilder_2_0_0_0.application, in this case RS has been configured so the Web services virtual directory is "services".
The web.config for the website app has been set to <identity impersonate="true /> for <locations> for the ASPX pages that access the RS webservice. I even added a <location path="services/reportbuilder"> with the same thing and also to allow anonymous users.
So after all the above I go to the site from a machine that isn't on the network, I get prompted by IE8 for username/password and I enter servername\myDemoUser and the correct password. The homepage is displayed and correctly shows the list of folders and reports from RS. HOWEVER if I click the RS report builder link I get the pop window saying it's doing it's clickonce verfication stuff but after a couple of seconds it shows simple message box saying there was an authentication error. The details button then shows a text file with a bunch of stacktrace stuff in which eventually says that the server returned 401 while accessing the .application file mentioned above.
I turned on failure auditing for logins on the Win 2003 VM and I can see that when the clickonce fails it is trying to use the local machine account I logged into on the external (to my network) machine instead of the credentials I entered into the browser on that machine when testing it.
Much Googling and granting of permissions to Network service, everyone etc... on various folders involved later nothing the Report Builder bit just won't install via clickonce due to permissions or the incorrect use there of.
I'm looking into maybe changing something in the RS to try and grant permissions to the report builder to anonymous but at this point I'm pretty pessimistic that I'll actually find anything. The annoying thing about this is that this a test that doesn't represent the final thing (we'll be using custom authentication in RS) but unfortunately I have to do it, 8(.
Any ideas would be most appreciated.
It turns out that when using fake Windows authentication in this way when the machine you are accessing the site from a machine where you have not logged into the domain then clickOnce won't work because it won't pass the details you enter into the browser as found.
So the solution is to:
1) Log into a (any) domain on the machine that is going to access the clickonce link on your site.
2) In Control Panel go to User Accounts (XP)/Store Users and Passwords (Win 2003), and manage the network passwords for a user (XP) and add in the URL, username and password.
Whenever clickonce fires up for this URL it will pass the username/password specified as opposed to the local machine account.
Either of the above will solve this problem.
Whenever I try to access SSRS 2008 R2 through a URL (i.e. after being published on the net), it always shows a login prompt when accessing the report. The problem does not appear in the development environment.
How do I prevent this login prompt from showing whenever I try to access a report? For the time being, we are solving this problem by providing a username and password in <appSettings> in the web.config. Once this change is made, the login prompt does not appear.
Is there a better solution to this? Am I doing this the wrong way?
I am assuming the prompt is for the username / password for the domain. Internally you are likely getting through the AD authentication check in your application as you will have permissions to deliver the report (you can test that premise with Firefox or other browser that doesnt handle AD authentication like IE does/
I think you may have setup for basic authorisation to view the report RSReportServer.config rather than web.config is that what you have done? (see this to see example http://msdn.microsoft.com/en-us/library/cc281309.aspx.)
If you are trying to get full anonymous access then you are in for some fun; luckily one of the RS team blogged a way to achieve it; I wouldn't advocate doing it straight onto a production box though.
http://blogs.msdn.com/b/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx
I'd start with using Internet Explorer, on a domain.. which will pass your credentials (if that is how you have this configured).
It IS possible to configure firefox to pass Windows Authentication / Token.. I don't remember how I had done this previously.
The BEST platform for using SSRS is Apple / Safari.. because when you hit the checkbox that says 'remember password' it actually remembers the password. It blows my mind that Chrome, Firefox, IE give you a prompt that says 'remember password' - but from my experience, remembering passwords only work as I expect when I am using Safari.
I'm not sure from you're question is the login box a prompt to get you access to the report server or is it a prompt on the reports datasource.
It sounds a bit like permissions to access the report server, I guess you could try giving the app pool user permissions to access the report server and run the report or use an impersonation account to access the report.
I was running into this problem for a different reason than the accepted answer. While SSRS was installed, it wasn't properly configured. Being new to installing SSRS, I had assumed some tabs in the Reporting Services Configuration Manager were set to defaults. They weren't. Once I went back and actually set them, everything worked fine.
Disable loopback
http://thetazblog.taznetworks.com/2006/03/crm-30-sbe-sql-reporting-error.html
............................