I'm having problem with ReflectPermission("suppressAccessChecks"). Whenever I login with authenticated user (user name and password) and try to access a .jsp or any other page in my web application I get
java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks").
This happens only when I have "Security Manager" enabled by checking it in GlassFish Security properties. When I uncheck this option the web application works.
I would like to know what causes this reason and how to solve it? I think it is not recommended to uncheck Security Manager in Security properties.
While I have checked Security Manager in GlassFish Security section, I tried to add following code above my .jsp code
ReflectPermission refperm = new ReflectPermission("suppressAccessChecks", "");
AccessController.checkPermission(refperm);
However that didn't helped either.
I am not sure about the glassfish server but, i fixed the same issue in tomcat7 by editing the catalina.policy file and adding the line
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
under grant permissions.
Related
I have a question regarding SQL Server Reporting Services 2019:
We have received a HTTPS-certificate and added a URL for both Web Service and Web Portal. When we try to access either /Reports or /ReportServer on HTTP we can get through with no problem, but when we try to access on HTTPS then we are met with a logon dialog which will give three attempts at log on before displaying a white page. All attempts at entering a valid combination of user name and password returns a 401 error.
We've tried removing and reinserting all bindings for HTTP, HTTPS, SSL, changing logon mechanism in the config file to use Kerberos, NTLM or a combination of those but nothing works.
Does anyone what the source of this problem might be and how to solve it?
We figured out what the problem was. Authentication issues did not behave the same for HTTP and HTTPS. My test user wasn't a member of the correct user group. Once we gave it "System User" access then we could log in.
I am working on dnn site and facing some issue related with authentication.
When i'm going to browse a url ../admin/ControlPanel/module.css, it's showing 401 - Unauthorized: Access is denied due to invalid credentials.
I have verified all the settings in IIS, still not able to understand why this error is coming.
Thanks,
Is that the only file/path that is having that problem?
I would start by checking to see if you have Basic Authentication enabled in IIS.
Make sure there isn't a virtual directory or application configured on the admin folder for some odd reason.
I have IIS 7.5 site:
Authentication = Windows Aythentication enabled
Application Pool = DefaultAppPool
DefaultAppPool Identity = ApplicationPoolIdentity
Load User Profile = True
On the filesystem,
DefaultAppPool has Read and Execute privileges to the entire site.
Also added a security group with Read and Execute privileges to the entire site.
With these settings, only users in the security group are able to access the site. All others get a AD login window, which has no affect. I'm not understanding this behaviour.
From research, it looks like I don't need to add the DefaultAppPool to the filesystem, if users are only executing, but still doesn't explain why they get the login challenge.
I'm also unclear if i need to set the AuthenticatedUserOverride (in Config Editor) from UseAuthenticatedUser to UseWorkerProcessUser if i want to use the filesystem security of DefaultAppPool. When i set this, i get an access error, not even the login challenge.
Note: site is not in the Default Web Site, but on a specific port number.
I'm unclear why i seem to need users listed in an ACL rather than using the generic DefaultAppPool.
Windows authentication determines how you determine who is who. Impersonation means which user account the security context runs under. Because you are loading the user profile, the context is taking on the AD user's security. Your DefaultAppPool identity is now out of the picture which is why you need ACL's on your files / folder.
Users will continue to receive the login prompt who are not cleared at the ACL level because IIS doesn't know what to do until an account that can access the files is provided. Watch in fiddler and you'll continue to see challenge messages from the server.
I'm using LifeRay in version 6.1 in combination with CAS. For testing purposes, I wanted to deactivate CAS temporarily and use the native login functionality of LifeRay instead. Therefore, I deactivated CAS in the Portal Settings. Now, I cannot login myself in LifeRay, because even if I click on "sign in" I got "You do not have permission to view this page." Where can I activate CAS again in the config-files or database OR how can I return to the native login functionality of LifeRay? Thank you!
Add the following in your portal-ext.properties(You can also create property hook, but since this is temporary, i would recommend you to change this for the moment do the clean up and then remove the property) and restart the server
auto.login.hooks=com.liferay.portal.security.auth.CASAutoLogin,com.liferay.portal.security.auth.FacebookAutoLogin,com.liferay.portal.security.auth.NtlmAutoLogin,com.liferay.portal.security.auth.OpenIdAutoLogin,com.liferay.portal.security.auth.OpenSSOAutoLogin,com.liferay.portal.security.auth.RememberMeAutoLogin,com.liferay.portal.security.auth.SiteMinderAutoLogin,com.liferay.portal.security.auth.ParameterAutoLogin
Once server is restarted add the following parameters to any of liferay's url
?parameterAutoLoginLogin=test#liferay.com¶meterAutoLoginPassword=test
Change credentials to your admin credentials
I am getting the error below while getting the Search Crawlers to work:-
The start address sts4://mysites/contentdbid={3d198865-7f27-4633-bd71-902795032d78} cannot be crawled.
*Context: Application 'Search_index_file_on_the_search_server', Catalog 'Search'*
Details:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled. (0x80041205)
I have checked all permissions and they appear to be in order.
While investigating this problem I discovered that when I RDP to the SharePoint server and connect to the sites whilst on the server (locally to the server) I get access denied.
The Central Administration works just fine, but all the other Web Applications (intranet & mysites) will not allow me to login. I get prompted to enter username and password (like I do when connecting to CA) but it never accepts the login. These sites work without any problems when accessed from client workstations.
When I check the site log file it is reporting a http 401 Unauthorised error.
Note: The sites are not using Claims Authentication
Any ideas on how to fix this?
Thanks,
Andrew
You're probably having the loopback issue problem. Follow instructions in this KB article: http://support.microsoft.com/kb/896861