Application security error only on some applications
(version 14) We have about 30 different applications on our logi info server (Windows) and would like to use NT authentication. In the _Settings file, when we add the Security element and set security to true with AuthNT type and specify our domain, it seems to work for the reports in about 80% of our applications and fails in about 20%.
My question is... given the same security configuration on the same server, what are the different variables that could cause it to work fine in some applications and fail with an authorization error ("you are not authorized to...") to the clients in other apps?
I can't find what is different in the _Settings file for the applications it works in vs the applications it doesn't work in. Setting constants? Using a theme? Maybe setting that Studio Element Seeker Port? In the security element, only those 3 attributes are set (Authentication Source, NT Authentication Domain, and Security Enabled) and all are set to the exact same values, so it's got to be another element.
-
The most important configuration in order to use NT Authentication actually occurs in IIS Manager. Each application to use NT Authentication must be configured to disable Anonymous Authentication and enabled to use Windows Authentication. This passes the user’s windows authenticated user to the Logi Application.
Logi’s other security methods use Anonymous Authentication because the user’s windows credentials are not being used. Possibly those applications that aren’t working do not have IIS Authentication properly configured.
0 -
Thanks for the tip. It looks like the IIS authentication is the same for every "site" and it looks like every app is its own site. They all have this IIS authentication configuration:
0 -
It has been awhile since I have used NT Auth. The other things that can affect security are Roles and Rights (which I believe NTAuth transposes the user’s Windows Security Groups and the actual file system permissions. If I get a chance I’ll run some tests.
Are you getting a Logi Error message or an Application Error?
0 -
I don't have roles or rights added to the Security element. It's just the Security element enabled to True with the NT domain specified and AuthNT. This is the Logi error message:
The one thing I noticed that was enabled/set on the application that gives the authentication error, that was not set on the applications that work, is the Studio Element Seeker Port setting in the general part of the _Settings file. I haven't yet been able to say that having the Studio Element Seeker Port being used is causing the authentication error, but it's the one setting I noticed.
0 -
Hi Scott
This is the error Logi returns when you have a Security Rights ID specified on a report (or report element) that is not being returned by AuthNT from your Active Directory memberships. AuthNT will return all of the AD Group memberships you have and provided one of these matched the Security Rights ID you've specified you will pass security and be allowed to view the report.
You can test this easily by running a report you have access to and then adding a random name or string (e.g. PreventAccess) to the Security Rights ID attribute for the report. Try running the report again and you'll see this error.
You need to check the Security Right IDs that have been specified for the reports you can't see and make sure that they are correct and that AuthNT will return said values for your user.
You can easily supplement your AD security rights by adding a User Rights element and returning the rights you want a user to have from a database query. This is the method we use to manage users' rights directly rather than having to have our infrastructure team manage specific AD Groups for users for specific applications.
You can find more details on this in DevNet here: Adding Security to a Logi Application – Logi Analytics
I hope this helps.
Regards
Neil Quinby
Format14 Limited0 -
I just wanted to follow-up... Neil Quinby's answer helped me a lot in debugging what was going on. We had individual reports that all had SecurityReportRightID elements in them. When we disabled security at the application level, it didn't matter what SecurityReportRightID values were in individual reports, and they all worked. Once we enabled security at the application level, say, for all employees within our NT domain, then the reports would stop working because the SecurityReportRightID elements in those individual reports over-rode the setting at the application level. I don't mean that as a negative either. That's probably the way it should work.
If a report within an application has more restrictive security than the application it is contained within, the report will use it's more restrictive security than what is specified at the application level. For example: Application 1 has security enabled for the NT domain assigned to the whole organization. Reports A, B, and C have security enabled for an element that species only the HR division (Active Directory group) can see. Then those reports will only work for the HR division.
This all makes sense.
0 -
Thanks for the follow-up Scott and I'm glad this helped. Let me know if you have any more questions about security structures within applications and I'll do what I can to help.
0
Please sign in to leave a comment.
Comments
7 comments