In Drupal 6, the administer menu is gone. The super user (uid = 1) can see it, but the Admin role, that has the correct permission, does not. If a user with the Admin role were to go to the pages, they could access them (like nodes/add/content_type or something), but there is no menu. (So hypothetically, the site could be administered by Admins by going direcly to URLs instead of using menus.)
Why could this be happening? I've flushed the caches.
The Admin role has the Menu Module >> Administer Menu permission. The Authenticated user has this role, too (as a test), but it still doesn't work.
UPDATE: Clarification of above: if an Admin navigates to /admin, he will get an Access Denied error.
This is what print_r(debug_backtace()); yields:
Array (
[0] =>
Array ( [file] => /home/sitename/public_html/subdir/index.php
[line] => 27
[function] => drupal_access_denied
[args] => Array ( ) ) )
If the admin user can see the menu, the you just need to go to admin/user/permissions, scroll to menu module, and make sure that administer menu is selected for the Admin role.
Related
Environment:
Two Azure ADs: Company, Customers
Company publishes an ASP.NET5 web app called Portal, the app is setup to be multi-tenant.
Customers have 2 user: user (who is just a user) and admin (who is a Global Administrator in the directory).
Portal, is initially set up to ask for 1 Application Permission: Read Directory Data
-
Here comes the flow that I went through, and I believe Azure AD misbehaves at multiple steps. Please point out if I am missing something.
I open the web app, and first try to sign in as admin
I have to consent to the Read Directory data permission, so I do that
Application appears (I have no roles assigned yet, which is fine) -- so far everything works.
I re-open the web-app in a new incognito session, and try to sign in as the user
Now, I get [AADSTS90093: This operation can only be performed by an administrator. Sign out and sign in as an administrator or contact one of your organization's administrators.] -- the admin already consented, so why do I get this??
I go to Company AD and change the application permissions to include Read & Write Directory data
I go to Customer AD check the app Portal and the dashboard already shows the new permission listed. No one had to consent! The admin do not see any change even on next login. How is this not a security hole?
My understanding of https://msdn.microsoft.com/en-us/library/azure/dn132599.aspx is that Application Permissions are not deprecated.
UPDATE
My configuration in the WebApp:
app.UseOpenIdConnectAuthentication(options =>
{
options.ClientId = Configuration.Get("ActiveDirectory:ClientId");
options.Authority = String.Format(Configuration.Get("ActiveDirectory:AadInstance"), "common/"); //"AadInstance": "https://login.windows.net/{0}"
options.PostLogoutRedirectUri = Configuration.Get("ActiveDirectory:PostLogoutRedirectUri"); //"PostLogoutRedirectUri": "https://localhost:44300/"
options.TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters
{
// The following commented-out line should work according to
// http://stackoverflow.com/questions/29317910/why-does-the-role-claim-have-incorrect-type
// But, it does not work in ASP.NET5 (currently), so see the "Hack." down below
// RoleClaimType = "roles",
ValidIssuers = new[] { "https://sts.windows.net/a1028d9b-bd77-4544-8127-d3d42b9baebb/", "https://sts.windows.net/47b68455-a2e6-4114-90d6-df89d8468abc/" }
};
options.Notifications = new OpenIdConnectAuthenticationNotifications
{
RedirectToIdentityProvider = (context) =>
{
// This ensures that the address used for sign in and sign out is picked up dynamically from the request,
// which is neccessary if we want to deploy the app to different URLs (eg. localhost/immerciti-dev, immerciti.azurewebsites.net/www.immerciti.com)
string appBaseUrl = context.Request.Scheme + "://" + context.Request.Host + context.Request.PathBase;
context.ProtocolMessage.RedirectUri = appBaseUrl;
context.ProtocolMessage.PostLogoutRedirectUri = appBaseUrl;
return Task.FromResult(0);
},
AuthorizationCodeReceived = async context =>
{
// Get Access Token for User's Directory
try
{
var identity = (ClaimsIdentity)context.AuthenticationTicket.Principal.Identity;
// Hack. TODO: keep an eye on developments around here
foreach (var claim in identity.FindAll("roles"))
{
// Readd each role with the proper claim type
identity.AddClaim(new Claim(identity.RoleClaimType, claim.Value, claim.ValueType, claim.Issuer, claim.OriginalIssuer));
}
}
catch (AdalException)
{
context.HandleResponse();
context.Response.Redirect("/Error/ShowError?errorMessage=Were having trouble signing you in&signIn=true");
}
}
};
};
Thanks for the information you've provided. I'm going to answer #7 first, because it looks pretty alarming. It does at first glance look like a security hole, but it's not. It's a bug in the Azure Management Portal that we are working to fix. In the "customers" tenant view, the UX is showing the permissions that the application (defined in the company tenant) is requesting. It should be showing the permissions actually granted in the "customers" tenant. In this case, if your app actually tries a call to write to the Graph API it'll get an access denied error. Anyways - not a security hole - but can sure understand why it looked that way to you - so sorry about this. We'll try to get this fixed as soon as we can.
On to some of your other questions about consent behavior... BTW this is something we are looking to improve in our documentation. Anyways, I'll try and answer this broadly in terms of the design behavior, because it looks like you've changed your app config multiple times.
If you pick any app permissions (not delegated permissions), the consent UX defaults to the "consent on behalf of the organization" experience. In this mode the consent page ALWAYS shows, whether the admin consented previously or not. You can also force this behavior if you make a request to the authorize endpoint with the QS parameter of prompt=admin_consent. So let's say you went down this path AND the only permission you have is app-only "Read Directory" and the admin consents. Now a user comes the user doesn't have any grant that allows them to sign in and get an id_token for the app (Read Directory app-only is not currently good for this), so the consent dialog tries to show the admin on behalf of org consent, but this is a non-admin so you get the error.
Now, if you add the delegated "sign me in and read my profile" permission for the app, and have your admin reconsent, you'll see that now the user will not be prompted for consent.
What I'll do is go back to our team and see whether ANY directory permission (app only or delegated) should allow any user to get a sign in token. One could argue that this should be the case.
HTHs,
I am attempting to use section access with Qlik Sense. I am testing against "ADMIN1", that is a RootAdmin in Qlik Sense, but also admin in the Windows server. I tried the following script in data load editor, I hit load data, quit then re-enter. Qlik says: "Access Denied".
Section Access;
LOAD * Inline [
ACCESS, USERID
ADMIN, ADMIN1
];
Section Application;
LOAD * Inline[
Customer, Age
1,1];
I replaced ADMIN, ADMIN1 with ADMIN, DOMAIN1\ADMIN1 but still "Access is Denied". Same when I try ADMIN, * or ADMIN, '*'.
How can I make this simple test work?
Thanks,
Amir.
In case someone comes across this same issue, here's an example:
section access;
LOAD
ACCESS, USERID, SECURITY;
SQL SELECT access AS ACCESS,
'DOMAIN\'+UPPER(userName) AS USERID,
SECURITY
FROM dbo.securityRules;
section application;
LOAD
field1,
field2,
secureFieldID AS SECURITY;
The securityRules table "Access" column is either set as "ADMIN" or as "USER", the secureFieldID column either indicates an ID which corresponds to the resource we are granting access to (e.g. cost centre ID, section ID etc) or it can be "*" for ADMIN which means they can see everything which is defined in the table (all users access).
Everything in uppercase per the example or it will not work.
Just noticed that in all Sense documentation, regarding Section Access, there is no "ADMIN" value in "ACCESS" column. When I've changed "ADMIN" to "USER" everything worked.
Section Access;
LOAD * Inline [
ACCESS, USERID
USER, MYDOMAIN\ADMIN1
];
Section Application;
LOAD * Inline[
Customer, Age
1,1];
Also make sure that the username is used with domain prefix and this domain is added as "User directory connector" in QMC.
I have a requirement where I have to allow all of my regular users to impersonate a user of their choice.
I haven't been able to make this work. This is what I've done so far:
Added the following properties to portal-ext.properties:
portal.jaas.enable=false
portal.impersonation.enable=true
Created a role for the purposes of impersonation
Defined permissions for this new role: Portal > Users and organizations > View & Impersonate
Assigned this role to a non-administrator user (user A)
I don't need my users to see the list of users they can impersonate, I just want liferay to impersonate a user if ?doAsUserId=x is present in the url (which does work if you are an administrator).
When I try to impersonate user B using user A, nothing happens. I get this error in the tomcat log:
1ERROR [http-bio-8180-exec-85][PortalImpl:5990] User 80413 does not have the permission to impersonate 25105
(User 80413 is my User A, the one attempting to impersonate user B [25105])
Am I missing something else?
There is a condition in Lifeary, which checks the permission on the list of organizations for the impersonation. So, the user who is impersoneting the other user, must have a permission for "impersonation" in all the organisation of which, these users are part of.
if (doAsUser.isDefaultUser() ||
UserPermissionUtil.contains(
permissionChecker, doAsUserId, organizationIds,
ActionKeys.IMPERSONATE)) {
request.setAttribute(WebKeys.USER_ID, new Long(doAsUserId));
return doAsUserId;
}
So, those 2 users must be part of same organization and must be having impersonation permission for that organization.
I am using the auto assign role module to assign the role of editor to anyone registering via the "create new account" link. This works just fine.
However, users of the editor role can create other users of different role types. To do this I am using the uCreate module.
The problem is when an editor creates a user, that user also gets the editor role.
I have looked into a number of hooks to programmatically remove the unwanted role but without success. How might I resolve this issue?
When the "editor role" users creates the users by "uCreate module", the hook_user is being called reside in "auto assign role module", This is the problem.
The user_save function from "ucreate module line:299" call the hook_user with "insert" parameter in "auto assign role.module file", line no 155.
case 'insert':
// If this is an administrator creating the account only use auto_assign if
// allowed by auto_admin_active
if (arg(0) == 'admin' && _autoassignrole_get_settings('auto_admin_active') == 0) {
return;
}
Here the code check whether it is admin user, If it is not admin then it will assign editor role to that user.
Instead you can create a custom module and implement hook_user and change the role when a user are inserted.For more info please refer user_save in drupal 6
I have a custom form that lists the site groups and the users in each group.
the form has twi drop down lists: one to display the site's group and the other to display the users in that group.
when I log to the form with the administrator user it works fine.
But if I log in with a user with manage hierarchy permission level, it omly displays the info of the domain groups and if I try to access a sharepoint group I get an access denied error.
I use run with elevated permissions in my code
I really don't know what to do in this
thanks.
Two common mistakes when using RunWithElevatedPrivileges is:
Using the SPContext.Current.Web (or Site etc) won't change the identity of the web object, it is already in memory.
Declaring the SPWeb outside the delegate, with similar results of mistake 1
That said, try something like:
Guid siteId = SPContext.Current.Site.Id;
SPSecurity.RunWithElevatedPrivileges(() =>
using (SPSite elevatedSite = new SPSite(siteId))
using (SPWeb elevatedWeb = elevatedSite.RootWeb)
{
//impl
});