I know this looks like a dumb question, but I just found out that, last month, something terrible happened to my GitLab instance: someone signed up on it and became admin himself, without my invitation, as I was the only administrator. So he wiped off every internal and/or private project inside of it, groups too (and I don't even know whether he had stolen all of them before erasing or not, I'm worried because they were proprietary code). How did it happen? Does this have anything to do with, since the version was CE-13.3.0? If so, would version upgrading be enough to be safer, or should I make some particular configurations, such as disabling sign up page?
It is best to follow "GitLab instance: security best practices", which does include indeed:
Ensure open sign-up is disabled on your instance.
Open registration is disabled by default on self-managed instances with GitLab 13.6 and above installed.
If new sign-up is enabled and your instance is open to the internet, anyone can sign up and access data.
Administrators who would like to further restrict access on their instance can follow our documentation on how to configure user access.
Regarding the CVE mentioned, follow also "Action needed by self-managed customers in response to CVE-2021-22205", in your case: "CVE-2021-22205: How to determine if a self-managed instance has been impacted" (unless the log events have been wiped out as well).
Related
So I've got both Project Admin and Project Collection Admin rights within ADO, but I'm unable to change any of the Cards settings for my project's sprint board. In the imgur link, you can see the error I'm still getting, and the permissions that have been setup for both groups: https://imgur.com/a/kniFdZI
There's not been anything so far that seems like a dead obvious reason for why I wouldn't be able to amend these things, so basically wondering if anyone has seen this before, or if any helpful MS folk happen to know exactly what the fix would be.
It can be due to devops access level permissions.
Check your access level under the devops Organization Settings -> Users
Make sure you have "Basic" access instead of "Stakeholder".
See access levels : https://learn.microsoft.com/en-us/azure/devops/organizations/security/access-levels?view=azure-devops
I'm trying to use Azure AD as a standin for production level ADFS systems during development of an application. Up until today, everything worked fine. I don't know what I touched to break everything, but now I'm getting the following error:
AADSTS700016: Application with identifier 'https://foo.bar.localhost:44300/' was not found in the directory '[[GUID]]'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
I don't know what's changed, or why this worked last week and not today. I've been trying to change any number of settings - even deleted the app and re-created it, and nothing seems to help. Most of the other articles online keep referring to old versions of the Azure portal, so the clicks/links/menus that they are referring to no longer apply. There's a little popup on my sign in screen that says that I can enable "Advanced Diagnostics", but I don't know where those results show up so that I can see it.
Some things that I've checked:
- Under "App Registrations", the Endpoints for "Federation metadata document" and "WS-Federation sign-on endpoint" match what my application is using (so I'm going to the right place).
- When I click my application, under "Authentication", the Redirect URIs contains "https://foo.bar.localhost:44300/". I've tried with or without the trailing slash (and, sometimes, both).
Those are the biggest two places that other articles imply there may be an issue. Does anyone have any other ideas? Are there specific user-level things that I should be doing? Has something changed (very recently) that would be affecting my ability to use this feature? How are Enterprise Applications related (they're a Premium feature, and my Subscription is not)? I need to get my log-ins working again so that I can get my development process back underway. Thanks!!
Finally found the right setting. Turns out, many of my old applications were created when I was a "personal" user. I've since become a domain/work user, and it puts some things in place differently than before. In this case, I had to change the Application ID URI listed under "Expose an API" for my application. Setting this (where it wasn't set to anything before) allowed my application to be found and my login to succeed.
We used to have a plugin in LR6 that used a specific user group, which also had the administrator role assigned to it, for several use cases.
However, when trying to replicate its logic on LR7, this plugin correctly imported the users from a remote data source and put the users into this group. I can see their profile, which seems to be exactly what we need: in the "Inherited Regular Roles" the Administrator role is present.
However, they cannot see the control panel.
In an experiment, I administratively created a user group and assigned the Administrator role to the group. same behavior here, they cannot see anything.
I am poking around the source code, and it seems some parts of the module do use:
PortalPermissionUtil.contains(
permissionChecker, ActionKeys.VIEW_CONTROL_PANEL)
Which seems to verify inherited roles... Am I missing anything?
Bottom line, it seems that I cannot create usergroups of administrators anymore.
It turns out, yes I was missing something: a bug
https://issues.liferay.com/browse/LPS-61319
So, this will be an issue till GA4 at least.
As I understand it, the TFS Changeset Comments Policy may be set by any permitted user to require all team members to add a comment when making a check-in. Clearly, this must be a setting on the TFS server, rather than a local setting on the machine of the developer who makes the change. Yet my reading on this indicated that a curious notion. Prior to VS2013, this policy was not bundled with Visual Studio; rather it was in the Productivity Power Tools (PPT). Various references all indicate that each member of the team had to have PPT installed in order for the policy to be effective. One source wrote it as "if you don't have the Power Tools installed, you can still override the check-in policy". But if this is indeed a server setting, how would one be able to override it? That's part 1 of my question.
Part 2 of my question is now, with the advent of VS2013 that has the Changeset Comments Policy packaged in, I presume that the policy will just work. But what happens if there are some users running VS2013 and some running VS2012--does the same limitation still exist, i.e. that the VS2012 users with PPT can still override the check-in policy?
In TFS the checkin policies requirement are server side, but the checkin policies them selves are client side. So for users that don't have the checkin policy installed this policy will always be not fulfilled. the Comments policy is no exception. When you don't have the policy available on your computer you will just get a more cryptic failed checkin policy.
This goes for both standard/bundled policies and custom made policies. Note that you can always override failed policies. There is no way to refuse the developers the option of overriding, even for missing policies.
As a side note I can say that tfs power tools has a feature that allows for automatic distribution of checkin policies. But then you of course will have to make sure that all developers have tfpt installed. for TFS/VS2012/13 this feature might be included, but I'm not sure. You can have a look at this blog post if this is relevant
http://blogs.msdn.com/b/youhana/archive/2011/03/27/distributing-custom-check-in-policies-amp-wit-controls-using-team-members.aspx
Is it possible to prevent user X to see the admin account in the User - Manager? We want to be able to make sure this account will never be deleted.
I don't think this is at all possible. If a user has permissions to run security apps (User Manager), he will see all roles / users there.
I haven't done this before, but if I was attacking this problem, I would look at subclassing the user manager to remove the admin user before it is shown to the user. WARNING: This is quite a complicated and fragile change and may not be appropriate in your environment so be warned.
If you're interested, then in v6.4.1, I would look at the onload() function of the Sitecore.Shell.Applications.Security.UserManager class. Specifically at the managedUsers variable and possibly removing the admin user from that variable before it is set to be managed by the grid.
That's where I would start, but I'm not sure if it would work as I said, I haven't needed to implement this particular requirement before.