Say I have two user accounts on my computer. One admin, one standard user. If I then use sudo and other things which need admin rights from my Standard user account, install a lot of different packages and just experiment a lot with that user account, and then decide to delete the account at some point, will there be any effects for my admin user account later? is i possible that this will change certain files in my admin account etc.?
Related
I want to implement Azure File share for my network, but I can't find any possibility to set up user specific access permissions. There are some pre-built groups, which are for no use in this scenario, but I found a MS page recommending using Windows ACLs, but how can I proceed with setting user specific permissions, when I want to assign different permissions to different folders/files to different users, who are part of the same Administrator group in AD?
Problem solved! You just need to remove permissions inheritance and remove all inherited security groups/users permissions and add your own users or custom defined groups.
In windows, is it possible for TortoiseGit to use the credentials of the currently logged user, or via LDAP, rather than the user having to enter in a user name and password and this getting stored?
For us, using git-credential-wincred option for the credentials_helper setting isn't feasible. The user environment is very restricted and locked down, and administered by a third party. A change to an AD account password it can result in a wait of days (they have a 4 day response in the SLA) before the credentials are removed and the user can get back to using TortoiseGit.
So storing the passwords is not a realistic option. For now Credential_helper is set to none, forcing the users to enter the username & password on every push. Not the ideal situation, but better than a 4 day wait.
[edit]
A few more details about our environment. It's an HVD, based on a master image. The master image is maintained by another company, and each time the users log on, their session is created from the master image. The users cannot install anything on it. They cannot make changes to the setup or settings. They cannot access the internet with it. There's no command line (OS, Git bash or anything else). There is only restricted access to a handful of internal servers.
The master image has TortoiseGit and Git, and we have GitLab on one of the server that the HVD can access.
I am new to SonarQube and trying to setup up a proper access control, with requirements as follows:
We have a few project areas, each area should have someone able to
manage their area, such as creating new projects and manage the
boards, not sure exactly what. This is something like project area
administrators.
A few administrators can do anything.
Integrate to AD
A few questions:
In a few places like this link: http://www.sonarsource.com/products/features/security/, I see this role based method, but I can't find these default roles, "SonarSource products come with three project-specific roles – project administrators, project users and project code viewers" anywhere in the system. Right now, I am using the community edition I guess without a license. Is there any more detailed document on that?
I kind of understand the default Global Permissions and Project Permissions. In my case, shall I create e.g. three groups in AD, sonar-administrators,sonar-project-administrators, sonar-users to map to the default groups?
I notice the following: right now I don't have the above AD groups, when I integrate to AD, I can login with my domain id/password, but once logout/in, the group information I added to the local user gone. I guess it sych with AD. So to use AD, I have to create these groups in AD?
Jirong
Access control in SonarQube is managed through Global Permissions and Project Permissions. Each permission can be granted to user(s) and/or to group(s). The documentation you pointed at is quite outdated, read the Authorization page for the most up to date details.
AD/LDAP integration is a different topic, documented here. With group mapping, group membership stays managed in AD but will be replicated in SonarQube when users log in (the AD groups must first be created in SonarQube with the same name).
To your example: if AD users belonging to group foo deserve to administer your SonarQube, just create group foo in SonarQube, and (in the Global Permissions settings) give Administer System permission to group foo.
I am trying to delete the ITIM A/C created for a user, however it doesn't let me delete it, an error is displayed "following accounts cannot be deleted since they are governed by automatic provisioning policy".
Please let me know what is the reason for it and how to correct it.
The reason is that there is a Provisioning Policy defined in your environment with the following parameters :
One of the entitlements of the Provisioning Policy is an ITIM Account (possibly with some entitlement parameters)
The provisioning option for this entitlement is set to Automatic
The role membership of the provisioning policy either is a specific role that your user has or applies to all users in the organization.
What the above mean is that there is a provisioning policy that says "All the users that have this role MUST have an ITIM account". This is why you cannot manually delete the ITIM Account for that person.
It's not about correcting, but rather on figuring out what you want to achieve there. You have several options but first you need to take a step back and understand the reason instead of just attempting to fix the symptom. Why should this user not have an ITIM Account ?
IF there is a role that gives him this account you need to figure out which role is that and remove the role from the person. Then, the Provisioning Policy enforcement will remove the ITIM Account ( oversimplifying here assuming there are no other PPs that apply to the person and have an ITIM Account as entitlement)
If , on the other hand, the provisioning policy applies to everyone and you found out now that some of them should not have an account or that you should be able to remove accounts from them, you either need to make the provision option manual (this means everyone CAN have an account but they will need to request it or get it provisioned by someone/some process) or change the membership of the policy to a more exclusive role that contains only the persons who should have an ITIM Account.
EDIT
You would need to go a little bit back and try to understand the notions of Provisioning Policies in the context of ITIM and RBAC in general. This is not the place to analyze the topic :) However, shortly and for the question at hand
The ITIM Account is not necessarily mapped 1:1 to every ITIM person. ITIM Persons are the entities that are managed by your Identity Management System (ITIM) and they might have ITIM accounts, that is accounts on the ITIM Service that is predefined in ITIM.
The ITIM Account is the account that gives access to the ITIM Administrative console and the Self Service UI, not all persons need this/should have this.
The reason why as you say, the user got an ITIM Account when you created the user, is that there is a Provisioning Policy that has the ITIM Service as entitlement and is set to automatic. This says that all ITIM users MUST have an ITIM account. This is why you can't remove the ITIM account by itself because it contradicts the Provisioning Policy that is in place.
Reason of not deleting account is automatic provisioning policy which is not allowing to delete itim account. Make the provisioning policy from automatic to manual then only it will allow deletion of accounts.
I need to create a temporary folder that will be accessed from the application only.
It means that even current user and system administrator are not able to open it from the Explorer.
While application is running, there'll be some files put into it. Once it's terminated, folder and all its content are deleted (again programmatically, no manual delete ability).
P.S. I found few posts here but there are no proper solution given yet.
Thanks in advance.
Windows security does not work that way. You cannot restrict access by application, only by user. If you want only your app to have access to a given resource then you have to create a new user account, configure the resource to grant access to only that user, and then run your app using that user, or at least have your app impersonate that user when needed. Files/folders are securable objects, and Windows security is based on user accounts.