When attempting to deploy a SSRS 2008 R2 Report to my localhost/ReportServer, or trying to login to localhost/reportserver (via web browser), I am not able to get any further than a security error message.
When trying to access the report server via a web browser, I'm prompted to enter my login credentials. Even though I am the admin on the box, I still receive the following message:
User 'PCName\Me' does not have
required permissions. Verify that
sufficient permissions have been
granted and Windows User Account
Control (UAC) restrictions have been
addressed.
I have also tried launching my browser in Administrator Mode - same issue.
When attempting to deploy a report from VS, I get a similar message:
The permissions granted to user
'PCName\Me' are insufficient for
performing this operation.
Some assistance would be appreciated.
Thanks.
Mark, thanks for the suggestion. I found the answer here where I had to change the report server's authentication type to local.
<Authentication>
<AuthenticationTypes>
<RSWindowsBasic>
<LogonMethod>3</LogonMethod>
<Realm></Realm>
<DefaultDomain></DefaultDomain>
</RSWindowsBasic>
</AuthenticationTypes>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
This satisfies my testing needs, but not secure prod environment needs.
"User 'PCName\Me'" sounds like a local logon - have you tried entering your domain logon (including the domain name before the slash - ie. Domain Name \ User Name) and password?
Related
I have problem using default Apex Application Express Authentication. If user has to change password (no matter if developer or end user), you are unable to login in. Instead of password change window i get error "Forbidden The requested operation is not allowed". If password is valid and not expired or not required to change, you can login successfully. Can't find solution for this problem. Using Apex 20.1, oracle 18c (18.0.0.0.0 ).
Accidentally found problem. All applications share same session (Session Sharing set to Workspace Sharing). This prevents user from being able to change password and login if user needs to change it. So I've went easy way. Created another application without session sharing for users, to be able to change password.
When I try to connect to Dynamics 365 CRM with the Plugin Registration Tool I get the following permission error:
"You don't have permission to access any of the organizations in the
Microsoft Common Data Service region that you specified. If you're not
sure which region your organization resides in, choose "Don't know"
for the CDS region and try again. Otherwise check with your CDS
administrator. Parameter name: EMEA"
I have the System Administrator role
I can sign-in to the web interface and work with no issues
I'm sure of our region, tried to login with and without it ("Don't know" option)
Also tried with an application password as our organization uses multi factor authentication
Using the latest version of the tool on Nuget (9.0.0.9506 in the about dialog)
I can connect to my trial server the same way
We had a user who was able to connect with the same user roles set
This seems machine and account independent. Other users including the organization creator are getting the same error
We are directly connected to the internet, no proxies
One solution I've read suggested cleaning the cache files which don't appear on my system. And we get the same error on clean installations.
Solved by leaving the "Show Advanced" checkbox unchecked and not entering User ID / Password. Then a second dialog opens for credentials and 2FA authentication which just works.
You don't need an application password, as you'll be asked for MFA in the next step.
I don't know how our old teammate was able to sign in with the "Show Advanced" option selected. He was getting the same dialog and continue.
I am unable to login inot WAS Admin console. So I am trying to reset the admin credential after disabling security(security.xml-enabled="false"), but unable to save the new password. Any idea what should I check and troubleshoot?
I tried entering the credentials on soap.clients.props, but no help. WAS version : 7.0
From
http://www-01.ibm.com/support/knowledgecenter/SS7JFU_7.0.0/com.ibm.websphere.messages.doc/com.ibm.ejs.resources.security.html?cp=SS7JFU_7.0.0%2F1-15-7-225
SECJ7342E: Failed to validate user/password
Explanation Failed to validate user password in WIM registry
Action None
The credentials that you entered do they exist in the WIM registry?
From the screen shot it appears that you are using the File Based registry. Check that the ID and passwords match the values in that File Registry.
If you disabled security, then restart your server, so it starts plain, unsecured and enable security again via console. There will be prompt to specify admin user and password (I'm assuming you are using default Federated repository with file based). Provide new password there and restart the server.
In the page you are showing now, leave Server user identity as default - Automatically generated. This is not page, where you change user password.
Settings in soap.clients.props are not related to password changing. Once you set new password via console, you can update that file, so you won't be prompted, when you stop server from the command line.
This technote is also helpful when forgetting your WAS Admin console password:
Forgot password and cannot access WebSphere Application Server administrative console
https://www.ibm.com/support/docview.wss?uid=swg21405302
I have successfully deployed OBIEE 10g (10.1.3.4) on my workstation with BI Publisher being part of the installation.
However, when I login to BI Publisher using "Administrator" I'm unable to see the "Admin" tab. Nor I'm able to view the share folders or create a new report.
On clicking the shared folders, following error is shown. I'm sure this is something to do with access rights / security groups configuration.
Error
Unauthorized Access: please contact the administrator.
Kindly help!
Thanks.
are you sure you have login with the administrator priviledge.
When you installed it gives you a username and password. Make sure you used that.
I have made an ASP.NET MVC 3 Intranet site with Windows Authentication enabled:
in the Visual Studio project file properties
in the web.config, i.e. <authentication mode="Windows"/>
on the site properties in the IIS 7.5. server
Anonymous access is disabled for all these three above, the web.config says <deny users="?"/>. Impersonation is disabled in the web.config by identity <impersonate="false"/> and on the site properties in the IIS 7.5 server. And finally, the NETWORK SERVICE is set to run the app pool and also has Read on the site folder (not sure if it's needed though, you tell me, but it sure ain't enough to solve my problem below).
Now, when logging in through the standard Windows Authentication dialog box, domain users are presented with a 401.3 error after three valid login attempts. This seems to be before even reaching my MVC site's code, i.e. it seems completely IIS related. The event log gives the following kind of entry (it's an Information entry, not an Error, and I've obfuscated it a bit to protect my client) for all the users that has tried to log in:
Event code: 4008
Event message: File authorization failed for the request.
Event time: 2012-02-20 18:45:41
Event time (UTC): 2012-02-20 17:45:41
Event ID: 6dd3b4bf99784ba1a0fe06694dd89691
Event sequence: 3
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/2/ROOT-1-129742335229554599
Trust level: Full
Application Virtual Path: /
Application Path: D:\Public\BlahblahManager\
Machine name: HUB01-XYZ123
Process information:
Process ID: 2920
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Request information:
Request URL: http://blahblahmanager.user.ad.blah.com/
Request path: /
User host address: 134.XXX.XXX.XXX
User: USER-AD\teh-user
Is authenticated: True
Authentication Type: Negotiate
Thread account name: NT AUTHORITY\NETWORK SERVICE
Custom event details:
It is only when I specifically grant USER-AD\teh-user or USER-AD\Domain users the Read permission on the site's root folder (D:\Public\BlahblahManager) that the user can log in and actually see the site.
Why is this? There must be some kind of configuration that I'm missing. Shouldn't it be enough that the NETWORK SERVICE has Read on the site's root folder? I've Googled this for a while, and impersonation is mentioned here and there, but the jury is still out it seems. Some sites claims that you should go with impersonation and they provide examples on how to do it, but when I try out the examples it still doesn't work. Other sites says that impersonation is NOT the way to go and that you NEED to grant the folder permissions in these cases. But that seems such an odd thing to do. Users have no business on the actual server, they should be working through the website only.
Any suggestions? What is usually the minimum amount of configuration needed to get this to work? Any tips on how to troubleshoot this kind of problem and get to the root cause?
I refer you to see this post that declares all of MVC authentication methods. but make sure you have enabled minimum required authentication on your mvc application. Notice that Anonymous Authentication works with your group policies. you can config that by following : Internet Options -> Security Tab -> Local Intranet -> Custom Level, on your browser.
1- Another thing that may causes the problem is IIS may configured not to authorized related users. Some of them are :
iisservice
IUSR
IIS_IUSRS
Network Service
2- Also Check allowed verbs in IIS.
3- On the root folder of your application Give read access to IIS AppPool\YourAppPool.
4- Another cause could be hierarchical access rules in your application depends on what application services you are using, like web site panel access rules.
5- Setting the clientaccesspolicy.xml file.
6- Check InitializeService() Method, do you set entity access rules properly? For example:
config.SetEntitySetAccessRule("*", EntitySetRights.All);
7- Check FileAuthentication module at the web site level.
Double check Anonymous authentication is enabled on IIS.
Also, have a look at this post.
We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…
There are two IIS settings that control this:
Physical Path Credentials Physical Path Credentials Logon type
By default, Physical Path Credentials is set to Application User
(Pass-through authentication). This means that IIS doesn’t do any
impersonation when handling Windows Authentication requests. This can,
however, be set to a specific user (though not, unfortunately, the
application pool identity, which would be ideal). Physical Path
Credentials Logon Type is set by default to Clear-Text. For my testing
I set this to Interactive (though this may not be the correct value).
Possible values are Clear-Text, Batch, Interactive, and Network.
To set this up I did the following:
Created a local account (IIS-AccessUser)
Granted IIS-AccessUser read and execute access to the /home directory of the site.
Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
Set IIS-AccessUser as the Physical Path Credentials
Set Physical Path Credentials Logon Type to Interactive
Doing the above allowed me to log in to the application directly,
without having to allow Authenticated Users, or me having to be a
member of any of the groups in the /home folder. It also still
preserved .NET Authorization roles, so I still could not access parts
of the site that I was not allowed to.
I also faced this same issue on iis7 with windows authentication, but with with MVC4.
Finally found this post. Hope this might help someone in the future.
You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.
There's a better way that we were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.
For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.
Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.
http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk
In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).
It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).
-- DSB